Re: Processor Outage and Resynchronizing Sequence Numbers

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.

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?

Thanks,
Martin

 


-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Tuesday, February 24, 2009 1:26 PM
To: Hecht Martin
Cc: [email protected]
Subject: Re: [Sigtran] Processor Outage and Resynchronizing Sequence
Numbers

Martin,

Yes, I was afraid of that.  Test case 3.4.1 was only updated to
M2PA draft level 11.  Some changes were made to the final that
invalidate it.

The current test looks like this:

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000000->                         |
  |                        <-000000, 000001--  PROCESSOR-OUTAGE       |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                                            !msu                   |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-000000, 000001--  PROCESSOR-RECOVERED    |
  |  [ 35 bytes]     DATA  --000003, 000000->                         |
  |                 READY  --000000, 000000->                         |
  |  [ 35 bytes]     DATA  --000001, 000000->                         |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000001->                         |
  |                        <-000001, 000001--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

But it should look like this:

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000000->                         |
  |                        <-000000, 000001--  PROCESSOR-OUTAGE       |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                                            !msu                   |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-000000, 000002--  PROCESSOR-RECOVERED    |
  |                 READY  --000002, 000000->                         |
  |  [ 35 bytes]     DATA  --000003, 000000->                         |
  |                        <-000001, 000002--  DATA [   35 bytes]     |
  |              DATA-ACK  --000003, 000001->                         |
  |                        <-000001, 000003--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

So the PROCESSOR-RECOVERED acknowledges all oustanding messages
even though they are cleared from the buffer.  This is in
fitting with the text that states that:

   The BSN in the Link Status Processor Recovered message is set
   to the FSN of the last User Data message received (and not
   discarded) from the peer M2PA.

Here "not discarded" means that it passed FSN and BSN sanity
checks.  This is in fitting with the procedures of ANSI
T1.111.3/2000 Clause 8 which states:

   If level 3 requests level 2 to resume normal operation,
   level 2 resumes acceptable of message signal units from
   remote level 2 and normal transmission of message signal
   units and fill-in signal units.  The first message signal
   unit or fill-in signal unit transmitted acknowledges all
   message signal units that have been accepted from remote
   level 2, including any message signal units for which
   acknowledgement were previously withheld because of level 2
   congestion (see section 9).

Also ITU-T Rec. Q.703 (1996) Clause 8 which states:

   Because of the above, in order to (sic) avoid sending of old
   messages, the level 2 buffers on both sides should be flushed
   immediately after the local/remote processor outage state
   terminates.  In addition, the synchronization of the level 2
   sequence numbers has to be assured.  This is necessary for
   the correct operation of the link.  It is understood that
   each side is responsible for the flushing and synchronization
   concerning its own level 2 and that the specific actions
   concerning the synchonization of the level 2 sequence numbers
   must not rely on the action of the other side.  How these
   measure are performed is considered to be implementation
   dependent.

Most of the problems with sychronization of level 2 sequence
numbers under Q.703/T1.111.3 have to do with the flushing of the
retransmission buffer.  The FSN is set to the first received BSN
to avoid a NAK requiring retransmission of a flused MSU from the
RTB.  M2PA does not have this problem as it is (in the final)
assured that the MSU has reached the other side before it
receives the PROCESSOR-RECOVERED (which is now transmitted on
the data stream and cannot overtake MSUs from the RTB).
Therefore, the BSN in the READY received in response to the
PROCESSOR-RECOVERED is simply the FSNT.

The situation of 3.4.1 previouly was trying to handle the race
conditions of sending PROCESSOR-RECOVERED and READY on the
control stream instead of the data stream.

Sorry, but I gave up updating the M2PA test spec because if it
is not going to an INFORMATIONAL RFC there isn't much point.
I will likely just update the validation test suite software
and the M2PA implementation instead.

--brian

Hecht Martin wrote:                           (Tue, 24 Feb 2009
09:37:14)
> Brian,
> 
> Excuse me for using a brand name in my email, I meant no disrespect to
> the product I named.
> 
> I am running test 3.4.1-1 from the M2PA Test 08 Specification.  After
> the exchange of READY messages of step (12) synchronization is not
> happening at SP B and the Data Messages from SP B are sent with, what
SP
> A considers to be, an invalid FSN.  SP A is discarding the data
messages
> and SP B takes the link Out-of-Service due to T7 excessive delay of
ACK.
> 
> SP A   READY BSN 1 FSN 1     --------------->
>                              <---------------  SP B   READY BSN 1 FSN
3
>                              <---------------  SP B   Data Msg. BSN 1
> FSN 4
> SP A   Data Msg. BSN 1 FSN 2 ---------------->
>                              <---------------  SP B   Empty Data Msg.
> BSN 2 FSN 4
>                              <---------------  SP B   Link Status OOS
> 
> My understanding is that the Data Message from SP B after the exchange
> of READY messages should have an FSN of 2.  SP A is discarding both
the
> Data Message and the Empty Data Message.
> 
> Best regards,
> Martin
> 

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