Subject: [Sigtran] M2PA draft 7 question

From: wayne n taylor <[email-masked]>
Date: Fri, 07 Feb 2003 01:22:26 -0500

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.

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
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tom George <[email-masked]>
Date: Mon, 10 Feb 2003 16:07:21 -0600

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.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 10 Feb 2003 17:09:38 -0700

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

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: wayne n taylor <[email-masked]>
Date: Tue, 11 Feb 2003 16:06:34 -0500

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