RE: M2PA Alignment Clarification
"Newman, Catherine J" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <A09345776B6C7A4985573569C0F3004311FC2DCA@rrc-dte-exs01.dte.telcordia.com> |
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 protected]] Sent: Thursday, October 05, 2006 8:57 AM To: Newman, Catherine J Cc: Davidson, Mark; [email protected]; 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 protected] http://www.openss7.org/