Subject: RE: [Sigtran] M2PA Last Call Comment - LPO

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Fri, 25 Jul 2003 10:05:19 +0200

Hi Andrew,

sorry for the late response.

just one remark on the figures shown below just for sake of correctness

ITU-T Recommendation Q.703 Figure 8 (sheet 3 of 14) shows

LPO comes from the "management layer" and not from MTP L3. 
According to "note 2" MTP 3 might also send LPO to MTP2 in case of using the national option of latching processor outage. 

But neither ANSI T1.111 nor Telcordia GR-246 indicate the use of this national option.

greetings

HannsJuergen

> -----Original Message-----
> From: Andrew Booth [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 3:58 AM
> To: Gaiser Franz
> Cc: [email-masked]'; [email-masked]; Brian F. G. Bidulock
> Subject: Re: [Sigtran] M2PA Last Call Comment - LPO
> 
> 
> Hi Franz,
> 
> Before answering your question I'll ask another: do we really need to 
> resynchronize sequence numbers in M2PA, or can we just 
> mandate that the 
> sender continues to increment the FSN on every transmitted MSU?
> - This seems simpler than resynchronizing.
> - Since M2PA does not retransmit, the motivation for 
> resynchronization 
> doesn't seem to be present as it does in MTP2.
> - Some of the examples below give examples where resequencing can go 
> wrong.  Although these situations are unlikely, the consequences are 
> unpleasant.
> 
> Now for my best answer to your question: Option (2), but if 
> there are no 
> unacknowledged messages then the BSN should be set to the FSN of the 
> last acknowledged message.
> Note also that if the receiver of the LS PR uses the BSN to free 
> messages in the RTB (as you indicated below) then they have 
> to be extra 
> careful when validating BSNs in ensuing Data messages that 
> may have been 
> sent before the LS PR. I don't think this is a good idea.
> 
> Some potential issues with resynchronizing sequence numbers:
> 
> Note that the sender of LS PR cannot know if the receiver 
> will use the 
> BSN to resynchronize sequence numbers or not, since it is the 
> MTP in RPO 
> that decides when RPO is "long duration" via the MTP3 T1 timer.
> This leads to race conditions in which one side flushes and the other 
> does not, though they are unlikely.  For example, the following could 
> occur if an MSU was delayed longer than MTP3 T1 on the IP network:
> 
> 
>      MTP3                  M2PA                        M2PA
>        |                     |                          |
>        |                     |<--Data (FSN 0)-----------|
>        |                     |                          |
>        |                     |                     +----|
>        |----LPO------------->|                    /     |
>        |                     |----------LS PO----/----->|
>        |                     |                  /       |
>        |                     |                 /        |<--Flush
>        |----LPR + Continue-->|                /         |
>        |                     |----LS PR------/--------->| resync FSN
>        |                     |    (BSN 0)   /           |
>        |                     |             /            |
>        |                     |<--Data-----+             |
>        |                     |   (FSN 1)                |
>        |                     |                          |
>        |             Discard |<--Data-------------------|
>        |           (bad FSN) |   (FSN 0)                |
> 
> The following example could occur if the side in LPO flushes 
> while the 
> side in RPO does not (perhaps they have different T1 timer settings), 
> and if the side in LPO sends a BSN different from the last 
> received by M2PA:
> 
>      MTP3                  M2PA                        M2PA
>        |                     |                          |
>        |                     |<--Data (FSN 0)-----------|
>        |                     |                          |
>        |                     |                     +----|
>        |----LPO------------->|                    /     |
>        |                     |----------LS PO----/----->|
>        |                     |                  /       |
>        |                     |                 /        |
>        |               To RB |<--Data---------+         |
>        |                     |   (FSN 1)                |
>        |                     |                          |
>        |----LPR + Flush----->|                          |
>        |                     |----LS PR---------------->|
>        |                     |    (BSN 0)               |<- Continue,
>        |                     |                          |   
> don't resync FSN
>        |                     |                          |
>        |                     |                          |
>        |             Discard |<--Data (FSN 2)-----------|
>        |    (expected FSN 1) |                          |
>        |                     |                          |
>        |             Discard |<--Data (FSN 3)-----------|
>        |    (expected FSN 1) |                          |
> 
> I think this possible condition provides reasonable incentive 
> to always 
> set the BSN in the LS Processor Recovered to the last message 
> received 
> from the M2PA peer.  In that case, there doesn't seem to be 
> any point in 
> resynching sequence numbers, just let the peer increment the FSN on 
> every MSU.
> 
> In summary, these examples are unlikely but why complicate things? 
>  Unless there is a good reason to keep the MTP2 resynching procedures 
> lets get rid of them in favour of the simpler approach: the sender 
> always increments the FSN by 1 when sending MSUs.
> 
> Thoughts?
> Andrew
> 
> Gaiser Franz wrote:
> 
> >Hi All,
> >
> >implementing Processor Outage Handling of M2PA draft 09 the 
> following questions came up:
> >
> >The Processor Outage chapter 4.1.4 says
> >
> >When the local processor outage conditions ends, M2PA shall 
> send a Link
> >Status Processor Recovered message to its peer. This message is used
> >to signal in the end of the processor outage condition, instead of an
> >MSU or FISU as in MTP2. The BSN value in this message is used by the 
> >peer to resynchronize its sequence numbers, if this is required by
> >MTP2.
> >
> >What does M2PA draft 09 with BSN in this context mean, is it 
> (assume, MTP3 has send Continue Command)
> >
> >(1) the FSN of the last received message before LPO or 
> >(2) the FSN of the last message in the incoming messages 
> that were queued and unacknowledged
> >during the processor outage (with that the remote side can 
> release the messages in its RTB) ? 
> >
> >
> >
> >thanks
> >best regards, Franz 
> >
> >
> >
> >
> >
> >_______________________________________________
> >Sigtran mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >  
> >
> 
> -- 
> Andrew Booth, Software Developer
> Signaling Systems Group, Performance Technologies
> 613-237-4344
> 
> Visit www.pt.com/mailing.html to subscribe to our Packets & 
> Signals eLetter.
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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

---

From: Andrew Booth <[email-masked]>
Date: Fri, 25 Jul 2003 11:21:11 -0400

Hi HannsJuergen,

Thanks for the correction, my appologies for the innacuracy.

Andrew

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.