Re: M2PA: resynchronization of sequence numbers after PO

Dario,

What the side sending the first LSR does not know until it
receives an LSR is whether its choice of sequence number is
acceptable to the peer.  Once an LSR is received from the peer
it is known that not only have both sides chosen a new sequence
number, but that choice is acceptable at both sides of the link.
It is better to await this acknowledgement before restarting
traffic.  In the event that traffic is restarted early and the
peer does not accept the new sequence number (for example, it is
unable to synchronize at all), the link will be placed out of
service and the sender risks message lost and missequencing by
sending data when the situation could have been avoided.
Therefore, wait until you receive LSR before restarting traffic.

--brian

Dario wrote:                                                        (Fri, 16 Nov 2007 04:29:16)
> 
> Hi Brian,
> 
> Perhaps this was not clear from the description in section 4.1.4 of RFC,
> however section 
> 5.4 brings more doubts:
> In figure 16, the "B"-side (the side that receives Link Status Processor
> Recovered message),
> after receiving LS PR and after sending LS Ready (stream 1) message "has
> completed synchronization
> of sequence numbers and has sent LS Ready, so it is able to resume sending
> data at this point with
> the new sequence numbers".
> 
> A side (the side that recovered from PO) sends the second LS Ready (stream
> 1) but it seems noone
> does anything with that message: if the purpose of synchronization was to
> send the last received BSN
> to synchronize FSNs at remote peer, then two messages seem to be sufficient?
> 
> Best regards, Dario
> 
> 
> 
> 
> Brian F. G. Bidulock wrote:
> > 
> > Dario,
> > 
> > Dario wrote:                                 (Thu, 15 Nov 2007 06:22:27)
> >> 
> > -X--snip--X-
> >>
> >> Could you please explain why the second Link Status Ready (stream 1) is
> >> needed?
> >> thanks!
> >> Kind regards, Dario
> >> 
> > 
> > To acknowledge the LSR sent from the other end and permit the peer to
> > again send MSUs.
> > 
> > --brian
> > 
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > 
> 
> -- 
> View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13792229
> Sent from the IETF - Sigtran mailing list archive at Nabble.com.
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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