Subject: RE: [Sigtran] M2PA LS Ready at the end of Processor Outage

From: "May, Howard" <[email-masked]>
Date: Mon, 8 Aug 2005 13:59:29 +0100

During the SN realignment both LPO an RPO may need to discard incoming
acknowledgements.  I would like clarification of what 'discard incoming
acknowledgements' means.  

Does it simply mean that the receiving side must ignore any indication
that a message has been successfully received by MTP3.

Cheers

Howard May

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Daniel B. Simonraj
>Sent: Friday, July 29, 2005 4:28 PM
>To: Brian F. G. Bidulock
>Cc: Subhashini; [email-masked]
>Subject: Re: [Sigtran] M2PA LS Ready at the end of Processor Outage
>
>Brian,
>
> It looks ok to me.
>
>with regards,
>P. Daniel Brein
>
>
>
>On Fri, 29 Jul 2005, Brian F. G. Bidulock wrote:
>
>> Daniel,
>> 
>> Well,...  After looking at Figure 16 again, I think that the 
>statement
>> should say:
>> 
>>  "M2PA SHALL NOT resume transmitting User Data Messages until it has
>>   _sent_ the Link Status Ready message."
>> 
>> Then it all works correctly, an the T1 timer will be set if there is
>> messages to send.  This is why the Remote Process Outage Recovered
>> was indicated on receipt of LS PR.
>> 
>> Comments?
>> 
>> --brian
>> 
>> Brian F. G. Bidulock wrote:                                  
>                       (Fri, 29 Jul 2005 07:56:48)
>> > Daniel,
>> > 
>> > Yes, the triple handshake is required to restart the link, as
>> > detailed in Figure 16 (which I drew), but there is no need to
>> > start a timer at MTP2.
>> > 
>> > The RPO side need not report RPR to MTP3 until it receives the
>> > last message in the resyncrhonization sequence, thus the MTP3
>> > RPO timer (T1) will still be running and put the link out of
>> > service (MTP3 Stop command) if the sequence does not complete.
>> > 
>> > Also a time-controlled changeover procedure should have been
>> > started at both sides and MTP3 CO timer (T2) will still be
>> > running.  Messages are not sent to MTP2 during RPO or while the
>> > link is blocked, so there should be no User Data messages to
>> > send from the RPO side, and if M2PA continues blocking, there
>> > are also no messages sent at the LPO side either.
>> > 
>> > So, the example in Figure 16 should show Remote Processor Outage
>> > Ceases going to MTP3 at B after receipt of the final LS Ready.
>> > That way at least one side will put the link out of service if
>> > messages suddenly get delayed for long periods of time.
>> > 
>> > M2PA at A can also keep MTP3 at A from unblocking the link, if
>> > it is capable, until the last message in the sequence.
>> > 
>> > --brian
>> > 
>> > Daniel B. Simonraj wrote:                                  
>                         (Fri, 29 Jul 2005 07:23:00)
>> > > Brian,
>> > > 
>> > >  In version 13 section 4.1.4 says "M2PA (at both the LPO 
>and RPO ends)
>> > > uses the BSN value in the received Link Status Ready message to
>> > > resynchronize its sequence numbers, if this is required 
>by MTP2. M2PA
>> > > SHALL NOT resume transmitting User Data messages until 
>it has received the
>> > > Link Status Ready message".
>> > > 
>> > >  If M2PA (RPO ends) receives Link Status Processor 
>recovered message, then
>> > > sends Link Status Ready message to resynchronize the 
>sequence number and
>> > > wait for the Ready message from other side.  If it 
>receives Ready message
>> > > from other side, then the transmitting User Data message resumes.
>> > > 
>> > > This is my interpretation. Please clarify it.
>> > > 
>> > > with regards,
>> > > P. Daniel Brein
>> > > 
>> > > 
>> > > 
>> > > On Fri, 29 Jul 2005, Brian F. G. Bidulock wrote:
>> > > 
>> > > > Subhashini,
>> > > > 
>> > > > Subhashini wrote:                                      
>                         (Fri, 29 Jul 2005 16:55:40)
>> > > > > In version 13 of M2PA, the text discussing the 
>initial value of FSN is 
>> > > > > removed. In version 7, the initial value of FSN was 
>set to 1 and when it 
>> > > > > reaches the maximum value, it was set to 0. Do we 
>still go with this? Or 
>> > > > > Is there any change in this? Can anybody clarify?
>> > > > 
>> > > > For MTP2 it is different for different variants.  (Some set it
>> > > > to all one's (i.e. -1) and some set it to zero.)  Follow the
>> > > > procedures for inittial FSN value of the MTP2 variant you are
>> > > > following.  If you want a receiver that can handle both, start
>> > > > with whatever arrives first.
>> > > > 
>> > > > > 
>> > > > > In version 13, LS Ready on stream 1 is introduced at 
>the end of 
>> > > > > Processor Outage. After sending LS Ready, while 
>waiting for LS Ready 
>> > > > > from peer to resynchronize the sequence numbers, do 
>we need to start the 
>> > > > > same T1 timer? If we do not get LS ready from peer 
>within T1, do we need 
>> > > > > to remove the link from inservice?
>> > > > 
>> > > > No, do not start a timer.  The peer will send READY if it needs
>> > > > to, otherwise it might not (doesn't need to resynchronize
>> > > > sequence numbers because there are no unacknowledged FSNs).
>> > > > 
>> > > > --brian
>> > > > 
>> > > > > 
>> > > > > thanks,
>> > > > > Subhashini ...
>> > > > > 
>> > > > > _______________________________________________
>> > > > > Sigtran mailing list
>> > > > > [email-masked]
>> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
>> > > > 
>> > > > -- 
>> > > > Brian F. G. Bidulock
>> > > > [email-masked]
>> > > > http://www.openss7.org/
>> > > > 
>> > > > _______________________________________________
>> > > > Sigtran mailing list
>> > > > [email-masked]
>> > > > https://www1.ietf.org/mailman/listinfo/sigtran
>> > > > 
>> > 
>> > -- 
>> > Brian F. G. Bidulock
>> > [email-masked]
>> > http://www.openss7.org/
>> > 
>> > _______________________________________________
>> > Sigtran mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/sigtran
>> 
>> -- 
>> Brian F. G. Bidulock
>> [email-masked]
>> http://www.openss7.org/
>> 
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/sigtran
>> 
>
>
>_______________________________________________
>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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 8 Aug 2005 09:55:48 -0600

Howard,

Although it is mentioned in the example in Figure 16 that
acknowledgements are discarded, the example was written before we
finally decided to send LS PR and LS Ready on the data stream.  Before
these messages were synchronized with the data it was possible to have
several race conditions that not longer apply.  One of them was late
arriving acknowledgements that were sent before the Link Status messages
used for SN synchronization.  This can no longer occur, as the pertinent
Link Status messages are sent sequenced on Stream 1 with the data an
SCTP will ensure proper ordering.

So, there should be no need to discard acknowledgements.

--brian

May, Howard wrote:                           (Mon, 08 Aug 2005 13:59:29)

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