Re: M2PA Alignment Question

Mark,

  "The detailed functional breakdown shown in the following diagrams is
   intended to illustrate a reference model and to assist interpretation
   of the text in the earlier clauses.  The stat transition diagrams are
   intended to show precisely the behaviour of the signalling system
   under normal and abnormal conditions AS VIEWED FROM A REMOTE
   LOCATION.  It must be emphasized that the functional partitioining
   shown in the following diagrams is used only to facilitate
   understanding of the system behaviour and is NOT INTENDED TO SPECIFY
   THE FUNCTIONAL PARTITIONING TO BE ADOPTED IN A PRACTICAL
   IMPLEMENTATION OF THE SIGNALLING SYSTEM." Q.703/Clause 12. (Caps mine.)

--brian

Davidson, Mark wrote:                           (Fri, 20 Jan 2006 09:22:03)
> 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/
> 

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