Re: M2PA Alignment Question

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

Brian F. G. Bidulock wrote:

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

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