Subject: Re: [Sigtran] M2PA draft 7 question

From: [email-masked]
Date: Wed, 12 Feb 2003 10:01:23 -0500

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?)

What problem is being solved by these three changes? Has anyone
observed alignment loops at plugtests or in testing?

Where in Q.703 does it specify these behaviors?

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.

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 08:15:35 -0700

Jeff,

[email-masked] wrote:                                             (Wed, 12 Feb 2003 10:01:23)
> established, as the current draft states?)

First thing after association established.

> observed alignment loops at plugtests or in testing?

AFAIK the draft allows LS to be sent periodically.

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.

> 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.

--brian

---

From: wayne n taylor <[email-masked]>
Date: Wed, 12 Feb 2003 10:37:56 -0500

Hi Guys,

see comments inline ...

> observed alignment loops at plugtests or in testing?
[waynet] i am not aware of anyone reporting alignment loops at plugtests
or testing. with the requirement that each peer must both send and
receive a LS Alignment message, it is pretty easy to create a loop. all
that is needed to form a loop is to have the peers to keep missing each
others LS Alignment message as described in my earlier comments. Brian's
earlier comments describes how the Q.703 SDLs eliminates this behavior.

> these three behaviors are necessary or desirable.

[waynet] i dont think Brian's suggestions concerning the sending of LS
OOS is intended as a solution to the loop concerns i mentioned. is
comments about following the Q.703 SDLs to eliminate a potential loop is
valid.