Subject: Re: [Sigtran] M2PA draft 7 question

From: [email-masked]
Date: Wed, 12 Feb 2003 11:00:06 -0500

Hello Brian,

More below....

Regards,

Jeff

On 02/12/2003 10:15:35 AM "Brian F. G. Bidulock" wrote:

>Jeff,
>
>[email-masked] wrote:

>(Wed, 12 Feb 2003 10:01:23)
>>
>> Hello Guys,
>>
>> I think that we have consensus that the M2PA finite state machine
>> should match the Q.703 SDLs, where possible. It has been several
>> M2PA revisions now that the state machine has been updated, but
>> fallen short of matching Q.703.
>>
>> I agree with Brian's suggested M2PA changes (below) with the exception
of
>> the
>> following:
>>
>> >> The first thing a link should send is LS OOS.
>> >>
>> >> In the out of service state, it would be desireable for the out of
>> >> service side to always send LS OOS in response to other messages.
>> >>
>> >> Also, the out of service side should be permitted to send LS OOS
>> >> periodically.
>>
>> What does 'first thing' mean? (upon START? upon association becoming
>> established, as the current draft states?)
>
>First thing after association established.

Okay, good.

>
>>
>> What problem is being solved by these three changes? Has anyone
>> observed alignment loops at plugtests or in testing?
>
>AFAIK the draft allows LS to be sent periodically.

I don't know about this, since

"After the association is established, M2PA SHALL send a Link Status
Out of Service message to its peer."

means 'send one LSO' to me.

Besides, you didn't answer my questions.

>
>Also, sending LS OOS in response to other messages while in the out of
service
>state handles the SCTP Restart scenario without having to directoy address
>SCTP restart.
>
>>
>> Where in Q.703 does it specify these behaviors?
>
>Q.703 repeats LSSU, particularly SIOS, when the link is initially powered
>on, regardless of any other messages while in the out of service state,
and
>continuously while in the out of service state.

Ah. I see it now -- not in the SDLs, but -- the last sentence in Q.703 7.2
implies
repeated sending of SIOS prior to Intial Alignment:

    "Status indication OS is sent on completion of 'power on' (see Figures
2
    and 8) until initial alignment is started."

Note the 'until'. Okay. So these proposed changes do match Q.703.

Let me attempt to clarify the proposed changes with regards to out of
service state:

OLD TEXT 4.1.3
After the association is established, M2PA SHALL send a Link Status
Out of Service message to its peer.

NEW TEXT 4.1.3
After the association is established, M2PA SHALL send a Link Status
Out of Service message to its peer and, prior to receiving a Start
Request from MTP3, MAY periodically send Link Status Out of
Service messages. During the Out of Service State M2PA SHOULD
respond to received messages other than Link Status Out of Service
by sending Link Status Out of Service.

>
>>
>> Do we have consensus that the changes will not result in a "potential
loop"
>> during alignment, as was the initial concern? I am not convinced that
>> these three behaviors are necessary or desirable.
>
>What loop?  There is no loop in the Q.703 SDLs for sending SIOS while
>in the out of service state.

You ask me? I'm just trying to understand what 'problem' is being
addressed by proposed changes listed in this thread.

>
>--brian
>
>>
>> Regards,
>>
>> Jeff
>>
>> On 02/11/2003 04:06:34 PM sigtran-admin wrote:
>>
>> >Tom,
>> >as i described earlier, my concern is the potential loop that could
>> >occur during the initial LS Alignment exchange based on the requirement
>> >that both peers must send and receive LS Alignment messages. Brian has
>> >shown in his response (and i agree) that the scenario i described will
>> >not happen if the procedures defined in the SDLs of the Q.703 spec is
>> >adopted for m2pa in regards to the initial "alignment" exchange.
>> >
>> >wayne
>> >
>> >"Brian F. G. Bidulock" wrote:
>> >>
>> >> Tom,
>> >>
>> >> The first thing a link should send is LS OOS.
>> >>
>> >> In the out of service state, it would be desireable for the out of
>> >> service side to always send LS OOS in response to other messages.
>> >>
>> >> Also, the out of service side should be permitted to send LS OOS
>> >> periodically.
>> >>
>> >> With regards to Q.703 state machines, LS OOS in response to alignment
>> >> will not abort alignment and T2 should still expire.  See test case
>> >> "3.1.2 Timer T2" in draft-bidulock-sigtran-m2pa-test-02.txt.
>> >>
>> >> T2 is defined as the duration of time that the M2PA peer wil wait to
>> >> receive a status "Alignment" message after sending a status
"Alignment"
>> >> message.
>> >>
>> >> As status Alignment will abort an otherwise in-service link, other
>> >> link status received while running T2 should be ignored.
>> >>
>> >> Any different behaviour could interfere with MTP Level 3's link
>> >> restoration timers and procedures.
>> >>
>> >> More comments below...
>> >>
>> >> Tom George
>> >wrote:
>>
>> >(Mon, 10 Feb 2003 16:07:21)
>> >> > Wayne,
>> >> >
>> >> > Yes, I want both sides to send and receive a LS Alignment message
to
>> >> > complete alignment.
>> >> >
>> >> > To fix the problem you describe, how about this" If M2PA has not
>> >> > received MTP3 Start and receives LS Alignment, M2PA replies with LS
>> OOS
>> >> > (instead of not replying at all and counting on the other end's T2
>> >> > expiring).
>> >> >
>> >> > tomG.
>> >> >
>> >> > wayne n taylor wrote:
>> >> > >
>> >> > > Hi All,
>> >> > >
>> >> > > i have a couple of comments/questions about the initial exchange
of
>> the
>> >> > > Link Status Alignment messages. there seems to be some
inconsistency
>> in
>> >> > > the text and finite state machine.
>> >> > >
>> >> > > section 4.1.3 paragraph 4:
>> >> > >
>> >> > > "Once the association is established and M2PA has received a
Start
>> >> > > Request from MTP3, M2PA sends the Link Status Alignment message
to
>> its
>> >> > > peer. If M2PA has not already received the Link Status Alignment
>> >> > > message from its peer, then M2PA starts timer T2."
>> >> > >
>> >> > > what state would the local M2PA be in to receive a LS Alignment
>> message
>> >> > > from its peer prior to getting a MTP3 Start ?. i assume the OOS
>> state,
>> >> > > but the finite state machine does not show LS Alignment as an
input.
>> >> > >
>> >> > > section 4.1.3 paragraph 5:
>> >> > >
>> >> > > "(Note that if the remote M2PA has not received a Start Request
from
>> >> > > its MTP3, it will not send the Link Status Alignment message to
the
>> >> > > local M2PA. Eventually timer T2 in the local M2PA will expire. If
>> the
>> >> > > remote M2PA receives a Start Request from its MTP3 and sends Link
>> >> > > Status Alignment before the local M2PA's timer T2 expires, the
>> >> > > alignment procedure can continue.)"
>> >> > >
>> >> > > assume the local M2PA receives a Start Request from MTP3, sends
LS
>> >> > > Alignment and start T2, but the remote peer has not received a
Start
>> >> > > Request and is in OOS. the current finite state machine does not
>> show
>> >> > > what to do with the LS Alignment from the local peer so lets
assume
>> the
>> >> > > LS Alignment is dropped. the remote peer receives a Start Request
>> from
>> >> > > MTP3, sends LS Alignment and start T2 (since the remote peer
didnt
>> get
>> >> > > the local peers LS Alignment). assume further that timer T2 is
still
>> >> > > running on the local peer. the text from section 4.1.3 above
states
>> the
>> >> > > "alignment procedure can continue". in this case the local peer
sent
>> a
>> >> > > LS Alignment and received a LS Alignment. the remote peer only
sent
>> a LS
>> >> > > Alignment and did not receive an LS Alignment (since LS Alignment
>> >> > > messages are not retried). eventually T2 on the remote peer will
>> expire,
>> >> > > T3 on the local peer will expire and the alignment procedure
starts
>> over
>> >> > > again. it seems possible for the peers to get caught in a loop
>> trying to
>> >> > > exchange LS Alignment messages.
>> >>
>> >> See draft-bidulock-sigtran-m2pa-test-02.txt Section "3.1.3 Timer T3".
>> You
>> >> will see that what you describe does not happen if you follow Q.703
>> SDLs.
>> >> In Q.703 once SIO is sent SIN is sufficient to complete alignment.
So,
>> >> one side sends ALIGNMENT and starts T2, the other side sends
ALIGNMENT
>> and
>> >> starts T2.  The first side, receives the alignment, stops T2 and
sends
>> >> PROVING-NORMAL or PROVING-EMERGENCY and starts T3.  When the second
side
>> >> receives PROVING-NORMAL or PROVING-EMERGENCY it stops T2 and sends
>> >> PROVING-NORMAL or PROVING-EMERGENCY and starts T4.  When the first
side
>> >> receives PROVING-NORMAL it stops T3 and starts T4.  When either T4
>> expires,
>> >> the side sends IN-SERVICE and starts T1.  When the side receives
>> IN-SERVICE
>> >> it stops T1 and indicates in_service to MTP3.
>> >>
>> >> This behavior can be seen on Figure 9/Q.703 (sheet 2 of 6) - Initial
>> alignment
>> >> control.  When the IAC starts it sends SIO and starts T2.  If it
>> receives
>> >> any of SIO, SIN or SIE it stops T2 and send SIN or SIE depending on
>> emergency
>> >> status and starts T3.  Receipt of a subsequent SIN or SIE (sheet 3 of
6)
>> >> stops T3 and starts T4.  Note that if it receives SIO again, it
ignores
>> it
>> >> at that point and continues to send SIE or SIN.
>> >>
>> >> These is no reason for M2PA not to follow the Q.703 SDLs in this
regard.
>> >>
>> >> A statement that might clarify is that the M2PA sends LS ALIGNMENT
and
>> if
>> >> it receives ALIGNMENT or PROVING it stops T2 and PROVING and starts
T3.
>> >> Note that it takes two PROVING messages in this case to move the peer
>> into
>> >> the proving state.  One PROVING message acts like an ALIGNMENT
(cancels
>> >> T2 and starts T3), the next acts like the first PROVING message
(cancels
>> >> T3 and starts T4).
>> >>
>> >> --brian
>> >>
>> >> > >
>> >> > > section 4.1.3 paragraph 9:
>> >> > >
>> >> > > "When M2PA has both sent and received the Link Status Alignment
>> >> > > message, it has completed alignment.  M2PA starts the aligned
timer
>> T3
>> >> > > and moves to the proving state."
>> >> > >
>> >> > > is it a requirement for both the local and remote peers to
>> send/receive
>> >> > > LS Alignment for alignment to be complete ?. the only way to
>> transition
>> >> > > from Initial Alignment to Proving is to receive LS Alignment. in
the
>> >> > > scenario above, both peers do not send and receive LS Alignment
>> >> > > messages.
>> >> > >
>> >> > > regards,
>> >> > >
>> >> > > wayne
>> >> >
>> >> > --
>> >> > * Tom George       PB7-24001 (near B-21)
[email-masked]
>> *
>> >> > * 972-519-3168   Intranet:
http://www.ssd.usa.alcatel.com/~tgeorge/
>> *
>> >> > * Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas
75075
>> *
>> >> > * I actively disclaim speaking for Alcatel USA, Inc. I do not
purport
>> *
>> >> > * to advertise or represent its position,  operations, or
activities.
>> *
>> >> > _______________________________________________
>> >> > Sigtran mailing list
>> >> > [email-masked]
>> >> > https://www1.ietf.org/mailman/listinfo/sigtran
>> >>
>> >> --
>> >> Brian F. G. Bidulock
>> >> [email-masked]
>> >> http://www.openss7.org/
>> >> _______________________________________________
>> >> Sigtran mailing list
>> >> [email-masked]
>> >> https://www1.ietf.org/mailman/listinfo/sigtran
>> >_______________________________________________
>> >Sigtran mailing list
>> >[email-masked]
>> >https://www1.ietf.org/mailman/listinfo/sigtran
>>
>
>--
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 09:54:26 -0700

jeffrey.craig,

[email-masked] wrote:                                             (Wed, 12 Feb 2003 11:00:06)
> >First thing after association established.

There's another "first thing".

Suppose that an implementation separates the SCTP association
from the M2PA.  In this case, the M2PA could go away and come
back without the SCTP association being dropped.  In that case
the M2PA should first send LS OOS when it comes back in the
Out of Service state.

--brian