RE: M2PA Alignment Question

Brian,

Thank you for your informative response.  

I agree that using an implementation which, for instance, filters
duplicate FISUs in HW, would require changes to Q.703 SDLs in order to
work.  Also, I understand this is a fairly simple problem to work
around.  But if an implementation chooses not to deliver SUs to MTP2,
then modifications to the SDLs are beyond the scope of Q.703, and not
necessarily "defects."  On the other hand, Q.781 tests acknowledge that
FISU filtering is a fact of life.

The heart of the issue though, is that M2PA specifically says to "follow
the requirements of the applicable MTP2 specification" except as
modified in the RFC.  If using Q.703 as a basis, how is one supposed to
know when to follow Q.703 and when not to? If Q.703 is considered
defective, why is it chosen as the normative document?  Why are these
known "defects" not addressed in the RFC?

I appreciate the effort you put in to your test plan draft, and I assure
you is is widely used, but I would prefer issues such as this to be
spelled out in something normative.

-Mark




-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]]
Sent: Friday, January 20, 2006 12:48 AM
To: Davidson, Mark
Cc: [email protected]
Subject: Re: [Sigtran] M2PA Alignment Question

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


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