Subject: [Sigtran] M2PA Alignment Question

From: "Davidson, Mark" <[email-masked]>
Date: Thu, 19 Jan 2006 13:44:53 -0600

The following text regarding LSR suggests that M2PA is expected to 
behave like Q.703, entering the Aligned-Ready state (with T1 running) 
after Proving: 

     The Link Status Ready message replaces the FISU of MTP2 that is
sent
     at the end of the proving period.  The Link Status Ready message is
     used to verify that both ends have completed proving.  When M2PA
     starts timer T1, it SHALL send a Link Status Ready message to its
     peer in the case where MTP2 would send a FISU after proving is
     complete.  If the Link Status Ready message is sent, then M2PA MAY
     send additional Link Status Ready messages while timer T1 is
running.
     These Link Status Ready messages are sent on the Link Status
stream.

But the latter part of Figure 12 of RFC shows the right side going
directly
from Proving to In-Service.  Is there some text that describes/requires
this behavior?  I understand there is a problem if you don't do this,
as you need another LSR to move from Aligned-Ready to In-Service. But
M2PA only requires one to be sent (even with repeated LSRs, once T1 
is stopped on the left, the right side could get stuck).

       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
       ----        ----        ----        ----        ----        ----
        .           .           .           .           .           .
        .           Start timer T3          .           .           .
        .           Link Status Proving     .           .           .
        .           ------------------------------------>           .
        .           .           .           .           .           .
        .           .           .     Link Status Proving           .
        .           <------------------------------------           .
        .           .           .           .           .           .
        .           Stop timer T3           .           .           .
        .           .           .           .           .           .
        .           Start timer T4          .           .           .
        .           Link Status Proving     .           .           .
        .           ------------------------------------>           .
        .           ------------------------------------>           .
        .           ------------------------------------>           .
        .           ------------------------------------>           .
        .           ------------------------------------>           .
        .           ------------------------------------>           .
        .           .           .           .           .           .
        .           Timer T4 expires        .           .           .
        .           .           .           .           .           .
 
        Send Link Status Ready (one or more) and wait for the remote end
        to complete its proving period.
 
        .           .           .           .           .           .
        .           Start timer T1          .           .           .
        .           .           .           .           .           .
        .           Link Status Ready       .           .           .
        .           ------------------------------------>           .
        .           .           .           .           .           .
        .           .           .           .           .           .
        .           .           .       Link Status Ready           .
        .           <------------------------------------           .
        .           .           .           .           .           .
        .           Stop timer T1           .           .           .
        .           .           .           .           .           .
        In Service              .           .           In Service
        <------------           .           .           ------------>
        .           .           .           .           .           .

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Jan 2006 22:47:57 -0700

Mark,

This is shown in the normal alignement procedure test cases in 3.1.5 and
3.1.6 of draft-bidulock-sigtran-m2pa-test-06.txt (and the corresponding
Q.781/1.5 and 1.6 test cases).

If you implement a Q.703 state machine directly from the SDLs with no
experience of the protocol, you may run into this problem.  I ran into
it almost 20 years ago when performing LSSU compression between the
driver and the L2 state machine.  If, for a normal Q.703 implementation,
you perform the longstanding FISUs compression technique (only providing
first and last indication from driver to state machine) with a state
machine implemented directly from the SDLs you will get this hang.

However, the state machines as described in the Q.703 SDLs have two or
three race conditions that can cause problems too.  Also, the Q.703 SDLs
will accept but never generate alignment using MSU instead of FISU as
shown in Q.781/1.6 and M2PA-TEST 3.1.6.

You will find it on Q.703/Figure 8 Sheet 6 and 7 of 14. On Sheet 6, the
SDLs send a FISU, accept FISUs/MSUs and enter the Aligned Ready state.
On Sheet 7, it takes subsequent indication of a FISU or MSU to move to
the In Service State.  To generate alignment with MSU requires that the
SDLs on Sheet 6 should check the Tx buffer and send MSU instead of FISU.
For in service on receiving an MSU (ala Q.781/1.6) the SDLs on
Q.703/Figure 16 (Sheed 3 of 6) should buffer received MSUs and mark
received FISUs during initial alignment.  Then on Q.703/Figure 8 (Sheet
7 of 14) the SDLs should detect whether an FISU/MSU was received prior
to alignment complete and move directly to the in service state.  Any
thing else will not work as shown in Q.781/1.6 (the receiver will in
fact force the in-service MSU to be retransmitted and test case
Q.781/1.6 will fail).

However, the text is overarching, and Q.703/Clause 7 does not say that
terminal waits for either FISU or MSU after alignment is complete, it
ways that it enters the aligned ready state and starts T1 after
alignment is complete and cancels T1 when it moves to the in service
state.  What it does not say, is what moves it to the in service state.

These are understandings of the nuances of the Q.703 SDLs that come with
experience and has little to do with M2PA.  What is probably more
pertinent to current discussions regarding IG and the M2PA-TEST draft,
is that Q.703 SDLs implemented precisely as described in Q.703 will fail
test case Q.781/1.6.  M2PA does not describe state machines so
precisely.  In any event, I don't think that M2PA needs to be correcting
defects in the Q.703 SDLs.

Nevertheless, just as Q.781 is itself a good guide to Q.703, the
M2PA-TEST document provides a good set of examples of how the
implementation is expected to behave.

--brian

Davidson, Mark wrote:                          (Thu, 19 Jan 2006 13:44:53)

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

---

From: devayya <[email-masked]>
Date: Fri, 20 Jan 2006 14:50:31 +0530

Brian,

Consider another case.
Suppose in AlignedReady state, PO is received from remote, we stop T1 
timer and change the state to Processor outage state and if after some 
time MSU is received from remote, then does that mean that the remote PO 
is cleared and we need to change the state to Inservice state?

Please clarify..

Thanks,
devayya

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Jan 2006 10:28:06 -0700

devayya,

Are you talking of Q.703 or M2PA?

--brian

devayya wrote:                                   (Fri, 20 Jan 2006 14:50:31)
>    time  MSU is received from remote, then does that mean that the remote
>    PO is cleared and we need to change the state to Inservice state?
>    Please clarify..
>    Thanks,
>    devayya

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

---

From: devayya <[email-masked]>
Date: Mon, 23 Jan 2006 19:16:07 +0530

Brian,

I was talking about M2PA in this case. Please guide me.

thanks,
devayya

---

From: devayya <[email-masked]>
Date: Mon, 23 Jan 2006 09:49:21 +0530

Brian,

thanks,
devayya

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 23 Jan 2006 23:59:21 -0700

devayya,

In M2PA you need to receive a Status LPR to leave the
Aligned Not Ready/RPO state.

--brian

devayya wrote:                                                                     (Mon, 23 Jan 2006 19:16:07)

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