Re: 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/