Re: Processor Outage and Resynchronizing Sequence Numbers
"Hecht Martin" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <849535E338E99741B7F7413F73253EDB0A0D593D@us-nj-mail1.comverse.com> |
Hi Brian, Thanks for this and the other responses. It is my understanding that any message received during the local processor outage and received between the processor recovered and the READY handshake, will not be sent to L3. This means that they are lost messages. I understand from your emails that the sync will be as if they were ack'd, even though they are lost, i.e. not sent to L3. Is this understanding correct? Thanks again, Martin -----Original Message----- From: Brian F. G. Bidulock [mailto:[email protected]] Sent: Tuesday, February 24, 2009 2:45 PM To: Hecht Martin Cc: [email protected] Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence Numbers Hecht, Hecht Martin wrote: (Tue, 24 Feb 2009 13:43:06) > Brian, > > I'll have to think about your response. > > By the way, am I correct in my understanding that the synchronization > actually takes place according to the READY messages that must be > exchanged? > > 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 sent the Link Status > Ready message. Well now, here's the rub. MTP2 requires that when either side clears its RTB that it resynchronize by setting FSNT to BSNR; however, FSNT is only different from BSNR when some message in the RTB has failed to reach the other end. This cannot happen for M2PA as specified in the RFC because SCTP is a reliable transport and both the PROCESSOR- RECOVERED and READY messages are sent ordered on the data stream. This means that all messages sent before it are received before these messages are received. Therefore, FSNT and BSNR must always be the same and is is only necessary to set FNST to BSNR "if this is required by [the] MTP2 [state machine used]". So, put short, because SCTP does not lose messages, and as long as PROCESSOR-RECOVERED and the READY messages in this sequence are sent on the data stream, resynchronization is not necessary. An example: For ANSI T1.111.3 the following is the scenario: SP A BSN:FSN FSN:BSN SP B FISU [7F:7F] ---------------> <--------------- [7F:7F] FISU MSU [7F:00] -----\ MSU [7F:01] -----X\ lost MSU [7F:02] -----\ \ MSU [7F:03] -----\\ \ MSU [7F:04] -----\\X-\------ [7F:7F] SIPO MSU [7F:05] -----\X\\ \----> MSU [7F:06] -----X\\\\ MSU [7F:07] ----X\\\\\\----> <--/ \\\\\\----> \\\\\----> \\\\----> \\\----> \\----> \----> <--------------- [7F:7F] SIPO FISU [7F:07] ---------------> long duration RTB contains RB contains MSUS 00 thru 07 MSU 00 only FSNT is 07 Ack all accepted Clear RTB MSUs with ACK withheld <--------------- [7F:00] FISU Set FSNT to BSNR FSNT is now 00 Clear RB MSU [7F:01] ----------------> <--------------- [7F:01] FISU Notice that if MSU 01 could not be lost or missequenced then BSNR after acking withheld MSUs would match FSNT. The M2PA case is: SP A BSN:FSN FSN:BSN SP B LSR [7F:7F] ---------------> <--------------- [7F:7F] LSR DATA [7F:00] -----\ DATA [7F:01] -----\\ DATA [7F:02] -----\\\ DATA [7F:03] -----\\\\ DATA [7F:04] -----\\X++------ [7F:7F] LSPO DATA [7F:05] -----\X\\\\----> DATA [7F:06] -----X\\\\\----> DATA [7F:07] ----X\\\\\\----> <--/ \\\\\\----> \\\\\----> \\\\----> \\\----> \\----> \----> long duration RTB contains MSUs 00 thru 07 FSNT is 07 Ack all accepted Clear RTB MSUS with ACKs withheld <--------------- [7F:07] LSPR Set FSNT to BSR FSNT is still 07 LSR [7F:07] ---------------> <--------------- [7F:07] LSR MSU [7F:08] ---------------> <--------------- [7F:08] ACK So, again, because the LSPR and LSR cannot overtake DATA when sent ordered on the data stream, M2PA does not require resynchronization of sequence numbers. > > In the test below I don't see the SP A responding with a READY after > receiving the READY from SP B. Is that just understood? We changed to "it has sent" from "it has received" in 48 hours before the RFC was released. But of course you are right, there should be a READY sent by the recovering end before it resumes sending DATA. --brian -- Brian F. G. Bidulock [email protected] http://www.openss7.org/