Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to re-synch resolves PO issue?

From: [email-masked]
Date: Fri, 10 Oct 2003 07:30:42 -0400

Hello Tom,

I suggest we use ACKs instead of LSRs, since the re-synch needs
to occur on the data stream (1). User data can also be used to re-synch.
Do you plan to address Andrew's suggestion that upon receiving LSPO,
M2PA begins to periodically send ACKs until receiving LSPR, thereby
hastening the re-synch?

Regards,

Jeff

                      Tom George                                                                                                  
                      <Tom.George@alca         To:      [email-masked]                                                          
                      tel.com>                 cc:                                                                                
                      Sent by:                 Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to      
                      sigtran-admin@ie         re-synch resolves PO issue?                                                        
                      tf.org                                                                                                      

                      10/09/03 06:49                                                                                              
                      PM                                                                                                          

All,

While working on the revised text, I wrote this example. I am thinking
about including it in section 5.4. It is more detailed than the other
examples in section 5, but it might answer some questions.

           A                        B

           User Data FSN=1
           ------------------------->
           User Data FSN=2
           ------------------------->
           User Data FSN=3
           ------------------------->
           User Data FSN=4
           ------------------------->
           User Data FSN=5
           ------------------------->
           User Data FSN=6
           ------------------------->
                     User Data FSN=11
           <-------------------------
                     User Data FSN=12
           <-------------------------
                     User Data FSN=13
           <-------------------------
                     User Data FSN=14
           <-------------------------
                     User Data FSN=15
           <-------------------------
               User Data FSN=16 BSN=3
           <-------------------------

These messages were sent at about the same time, so B did not have
time to process 4-6 yet. A processed 11-13 and was just about to ack
when A detected LPO:

           LS PO FSN=6 BSN=13
           ------------------------->

B can continue acking messages:

               User Data FSN=16 BSN=5
           <-------------------------

A flushes 14-16 (buffer but don't ack) as LPO ends:

           LS PR FSN=6 BSN=13
           ------------------------->

B should not resynch its sequence numbers now and start with
FSN=14. If B sent a message now with FSN=14, A might have trouble
figuring out if it was 14 before the resynch or 14 after the resynch.

A should discard any incoming acks at this point. They could be left
over from before the LS PR. And there is no harm, because A will get
the ack from a later message.

B never got around to processing message 6 so it decides to flush it
from its Receive Buffer. There has to be a way of notifying A of this,
so we use the LS Ready:

                LS Ready FSN=16 BSN=5
           <-------------------------

Now A knows to resynch his FSN to start with 6. He also knows that B
is expecting a resynch-ed sequence number.

B should discard any incoming acks at this point, since it is hard to
know if they were sent before or after B's LS Ready.

           LS Ready FSN=5 BSN=13
           ------------------------->

Now B can resynch his FSN to start with 14. And off we go:

           User Data FSN=6 BSN=13
           ------------------------->
               User Data FSN=14 BSN=5
           <-------------------------

etc.

--
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

_______________________________________________
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: Tom George <[email-masked]>
Date: Fri, 10 Oct 2003 10:47:05 -0500

Jeff,

I think you need a different kind of message than the data ack message. 
If we used the data ack, how would the receiving M2PA tell the 
difference between a pre-resynch and post-resynch data ack? The example 
does not show them, but there can be data ack messages straggling in 
during the time between LS PR and the end of the resynch. If M2PA just 
looks for a different message type, it is relatively easy. There is no 
reason it _has_ to be the LS Ready message, but that one was handy. Or 
we could have made up a new one (Link Status Resynch?).

M2PA can indeed ack during RPO. And M2PA can continue transmitting data 
(and acks) during LPO. I did not show this in the example, but I could 
modify it to show this.

tomG.

> M2PA begins to periodically send ACKs until receiving LSPR, thereby
   [...]

---

From: Tom George <[email-masked]>
Date: Fri, 10 Oct 2003 13:39:33 -0500

Here is my example. I revised it to show that the LPO end can continue 
transmitting, and the RPO end can continue acking.

           A                        B

6 messages
---------->
                                     6 messages
                                    <----------

           User Data FSN=1

A detects LPO.

           LS PO FSN=3 BSN=11

               User Data FSN=14 BSN=3
               User Data FSN=15 BSN=3

A can continue transmitting. A can ack messages that were received. A
must buffer 14-16 without acking them.

           User Data FSN=4 BSN=13
           User Data FSN=5 BSN=13

B can continue acking messages. Suppose that it receives 4, but has
not gotten to 5 and 6 yet.

               User Data FSN=16 BSN=4  (empty)
           <-------------------------

LPO ends. A flushes 14-16 (buffer but don't ack).

           LS PR FSN=6 BSN=13

               User Data FSN=16 BSN=5  (empty)
           <-------------------------
A discards this message.

                LS Ready FSN=16 BSN=5

           LS Ready FSN=5 BSN=13

           User Data FSN=6 BSN=13

etc.

---

From: Tom George <[email-masked]>
Date: Fri, 10 Oct 2003 13:45:40 -0500

Also, here is my proposed new text for 4.1.4:

=====
4.1.4 Processor Outage

The Link Status Processor Outage message replaces the SIPO message of
MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. M2PA SHALL send a Link Status Processor Outage message
to its peer at the beginning of a processor outage condition where
MTP2 would send SIPO. M2PA MAY send additional Link Status Processor
Outage messages as long as that condition persists. The Link Status
Processor Outage message SHALL be sent on the User Data stream.

While in a local processor outage (LPO) condition:

    (a) Any User Data messages received from the peer MUST NOT be
        acknowledged and MUST be buffered.

    (b) M2PA SHOULD continue to acknowledge User Data messages received
        and accepted by MTP3 before the local processor outage.

    (c) M2PA SHOULD continue to transmit messages that have been sent
        by its upper layer MTP3.

While there is a remote processor outage (RPO) condition:

    (a) M2PA SHOULD continue to acknowledge User Data messages received
        and accepted by MTP3 regardless of the remote processor outage.

    (b) If any User Data messages received from the peer after the Link
        Status Processor Outage cannot be delivered to MTP3, then these
        messages MUST NOT be acknowledged and MUST be buffered.

If M2PA receives a Flush command from MTP3,

    (a) M2PA SHALL discard any incoming messages that were queued and
        unacknowledged during the processor outage condition.

    (b) M2PA SHALL discard messages in the transmit and retransmit
        queues as required by MTP2.

If M2PA receives a Continue command from MTP3, M2PA SHALL begin
processing the incoming messages that were queued and unacknowledged
during the processor outage condition.

When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer on the User Data
stream. This message is used to signal the end of the processor outage
condition, instead of an MSU or FISU as in MTP2. 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.

Upon receiving the Link Status Processor Recovered message, the M2PA
in RPO SHALL respond with a Link Status Ready message on the User Data
stream. The BSN in the Link Status Ready message is set to the FSN of
the last User Data message received (and not discarded) from the peer
M2PA.

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.

During resynchronization, M2PA SHALL NOT discard any received User
Data messages that were sent after the processor outage ended.

When M2PA experiences a local processor outage, it MAY put the link
out of service by sending a Link Status Out of Service message if
allowed by the applicable MTP2 standard (e.g., [Q.2140]).

In other respects, M2PA SHOULD follow the same procedures as MTP2 in
processor outage.
=====

---

From: Tom George <[email-masked]>
Date: Fri, 10 Oct 2003 19:38:17 -0500

The only other significant change I made for this issue was in the last 
paragraph of 4.1.2:

=====
The association SHALL contain two streams in each direction. Stream 0
is designated for Link Status messages. Stream 1 is designated for
User Data messages, as well as Link Status messages that must remain
in sequence with the User Data messages.

The following Link Status messages SHALL be sent on the Link Status
stream (stream 0):

    - Alignment
    - Proving Normal
    - Proving Emergency
    - Ready (when sent during alignment)
    - Busy
    - Busy Ended
    - Out of Service

The following Link Status messages SHALL be sent on the User Data
stream (stream 1):

    - Processor Outage
    - Processor Recovered
    - Ready (when sent at the end of processor outage)
=====

I put some very similar text in the beginning of 4.2.1.