Subject: RE: [Sigtran] M2PA Alignment Clarification

From: "Newman, Catherine J" <[email-masked]>
Date: Thu, 5 Oct 2006 10:24:35 -0400

M2PA RFC states (section 4.1.3):
   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.

Note, MTP2 doesn't require a FISU to be sent at the end of proving...an
MSU can be sent instead (thus the same applies to M2PA). The receiving
end is required to move to In-service normal at the reception of data or
FISU(MTP2)/LSR(M2PA) and an M2PA implementation would not know for sure
that an LSR is expected.  
[Refer to ANSI T1.111.3, Section 7.3 " Following successful alignment
proving procedure, the signalling terminal enters aligned/ready state
and the aligned/ready time-out T11 is started. Time-out T1 is stopped on
entry in the in-service state (see Figure 8/T1.111.3)"  specifically,
Figure 8, sheet 4, shows receipt of either MSU or FISU causing the link
to transition to in service.] 

This is another possible solution - change the spec to require an LSR to
be sent in all cases, and thus received before reading stream 1.

Cathy Newman
Project Manager - SS7 Testing and Analysis
(732) 758-5174

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, October 05, 2006 8:57 AM
To: Newman, Catherine J
Cc: Davidson, Mark; [email-masked]; Erickson, Mark
Subject: Re: [Sigtran] M2PA Alignment Clarification

Newman,,

Newman, Catherine J wrote:                                         (Thu,
05 Oct 2006 08:40:44)
> 
> I don't believe M2PA would necessarily have access to TSN #s...per
SCTP,
> 10.2 A - DATA Arrive notification doesn't include the TSN # (just the
> assoc id and stream id). [M2PA assumes ordered delivery by stream and
> has it's own sequence numbers...I don't think it needs TSN
information.]

That's just one way.  You do not need TSNs.  As you are expecting an LSR
and have not yet received one, all that you need to is wait for a
timeout
period for an LSR on stream 0, after which you can process the DATA
(SLTM).

This will result in processing of missing LPSs before the DATA and is
purely
a local procedure at the receiver that is in accordance with RFC
4165/4.1.8.

--brian

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 5 Oct 2006 13:38:53 -0600

Catherine,

Newman, Catherine J wrote:                                         (Thu, 05 Oct 2006 10:24:35)
> FISU(MTP2)/LSR(M2PA) and an M2PA implementation would not know for sure

Then it can expect more LSPs.  The owness on it is to read from stream 0
before stream 1.  If the local SCTP implementation is so poor and cannot
assist in the matter then it will have to time-out on reading stream 0
before reading stream 1.

--brian

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