Subject: Re: [Sigtran] M2PA Last Call Comment - RPO

From: Andrew Booth <[email-masked]>
Date: Fri, 01 Aug 2003 16:20:27 -0400

Hi Brian,

It looks like your proposal will only handle the case where the M2PA in 
LPO is able to pass all messages in its TB to the remote M2PA and that 
the remote M2PA is able to deliver these to MTP3.  If the remote M2PA 
implementation is not able to deliver Data to MTP3 while in RPO then 
your proposal as is does not work.  Am I correct so far?

There are several reasons why an M2PA in RPO might not be able to pass 
messages to its MTP3
- it might not be allowed by its interface to MTP3 to pass data after RPO
- it might need to stop delivering messages to MTP3 to make changeovers 
work correctly e.g. after receiving a BSNT request
In either of these cases the M2PA in RPO may need to queue messages 
until RPO is finished.  I don't think that your proposal addresses the 
case where the side in LPO is unable to empty its TB/RTB because the 
other end was forced to queue.

Consider the following difference between MTP2 and M2PA:  When MTP2 is 
in RPO it cannot receive more data until the RPO condition abates (since 
the remote MTP2 is sending only SIPO during this period).  This means in 
particular that the BSNT does not change while MTP2 is in Processor 
Outage.  I believe that several procedures/SDLs depend on this 
assumption (it mostly affects changeover).

In M2PA on the other hand LS PO/LS PR and Data are sent on different 
streams so there are a variety of cases in which Data can be received 
during RPO.  In past revisions of M2PA we handled this by queueing the 
messages in a receive buffer and not delivering them to MTP3, so again 
the BSNT does not change during RPO.

I have an alternative proposal that I think allows for the 
implementation you suggested, but does not require it.  I think the 
extra changes you propose (e.g. passing messages to MTP3 during RPO and 
acking them) can be left within the scope of an implementation.

-------------------------------
Proposal:
Overview:
The implementation of the interface between MTP3 and M2PA will have an 
impact on how an implementation can reasonably deal with changeover 
during RPO.  Leave the existing proposal largely as it is.  Make the 
minimal changes needed to allow an M2PA to continue to send to MTP3 
while in RPO, but leave it to implementations to handle the details of 
interacting with changeover.

Add to 4.1.4:
The side in LPO MAY send data in its TB to the remote M2PA and SHOULD 
continue to process Data Acknowledgment messages received from the peer.

Modify in 4.1.4 the description of the side in RPO:

Change
=====================================
While there is a remote processor outage condition:

   (a) Any User Data messages received from the peer after the Link
       Status Processor Outage MUST NOT be acknowledged and MUST be
       buffered.

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

 Some implementations may continue to deliver messages to MTP3 during 
RPO.  This is considered an implementation dependent option.  Such an 
implementation must continue to handle MTP3 changeover procedures 
correctly during various processor outage states, the details of which 
is out of the scope of M2PA.  With these comments in mind,
while there is a remote processor outage condition:

   (a) Any User Data messages received from the peer after the Link
       Status Processor Outage SHOULD NOT be acknowledged, SHOULD be
       buffered and MUST NOT be discarded.

   (b) M2PA SHOULD continue to acknowledge User Data messages received
       and accepted by MTP3, regardless of the processor outage 
condition.  This
       applies in particular to messages received and processed before 
the remote
       processor outage.
=======================================

Also, I like Brian's comment about high speed links, although I'm 
personally not overly familiar with High speed links.

As Q.2140 handles processor outage by putting the link out of service, also add:

  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]).

----------------------------------

Thoughts?
Andrew

Brian F. G. Bidulock wrote:

>Tom,
>
>See the original note on this thread for suggested changes.
>
>--brian
>
>Tom George wrote:                                                                      (Thu, 31 Jul 2003 17:29:15)
>  
>
>>Brian, Andrew, et. al.,
>>
>>So where do we stand on this issue? If it is true that some MTP3 
>>implementations would accept incoming messages during RPO and some would 
>>not, then we should probably cover both cases.
>>
>>tomG.
>>
>>    
>>
>  
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tom George <[email-masked]>
Date: Fri, 15 Aug 2003 18:54:26 -0500

Brian, Andrew, et. al.,

Here is my attempt to incorporate all of the comments from this thread. 
I may have missed some comments, so please take a look and see if I 
missed everything. I tried to cover for both cases - where the M2PA in 
RPO could and could not pass messages to MTP3.

tomG.

Revised section 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.

When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer. 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 from
the peer M2PA. The BSN value in the Link Status Processor Recovered
message is used by the peer to resynchronize its sequence numbers, if
this is required by MTP2.

While in a local processor outage 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.

    (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, M2PA SHALL discard any
incoming messages that were queued and unacknowledged during the
processor outage condition.

Furthermore, if the M2PA experiencing processor outage receives a
Flush command,

    (a) M2PA SHALL NOT discard messages from the transmit and
        retransmit queues.

    (b) M2PA SHALL NOT perform procedures to resynchronize sequence
        numbers.

    (c) M2PA SHALL continue normal transmission of User Data.

If the M2PA experiencing remote processor outage receives a Flush
command,

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

    (b) M2PA MAY perform resynchronization of sequence numbers using
        the BSN from the received Link Status Processor Recovered
        message.  However, during resychronization, M2PA SHALL NOT
        discard any received User Data messages.

Note that because the Link Status and User Data messages are sent on
separate streams, it is possible for a User Data message sent after
the Link Status Processor Recovered message to arrive before
it. Therefore, when flushing buffers, M2PA must take care not to flush
messages sent after the remote processor recovered. M2PA SHOULD NOT
flush User Data messages with FSN greater than the FSN in the Link
Status Processor Recovered message.

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 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.

=====

Here is the previous section 4.1.4 for reference:
=====
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.

When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer. 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 from
the peer M2PA. The BSN value in the Link Status Processor Recovered
message is used by the peer to resynchronize its sequence numbers, if
this is required by MTP2.

While in a local processor outage 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.

If M2PA receives a Flush command from MTP3, M2PA SHALL discard the
incoming messages that were queued and unacknowledged during the
processor outage condition. Furthermore, M2PA SHALL discard messages
in the transmit and retransmit queues as required by MTP2.

Note that because the Link Status and User Data messages are sent on
separate streams, it is possible for a User Data message sent after
the Link Status Processor Recovered message to arrive before
it. Therefore, when flushing buffers, M2PA must take care not to flush
messages sent after the remote processor recovered. M2PA SHOULD NOT
flush User Data messages with FSN greater than the FSN in the Link
Status Processor Recovered message.

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.

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

=====

-- 
* 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.   *

---

From: Andrew Booth <[email-masked]>
Date: Wed, 20 Aug 2003 11:54:42 -0400

Hi Tom,

Looks pretty good.  Some comments/questions below.

Tom George wrote:

> Brian, Andrew, et. al.,
>
> Here is my attempt to incorporate all of the comments from this 
> thread. I may have missed some comments, so please take a look and see 
> if I missed everything. I tried to cover for both cases - where the 
> M2PA in RPO could and could not pass messages to MTP3.

>    (a) M2PA SHALL NOT discard messages from the transmit and

Any messages still in the transmit/retransmit buffer when a flush is 
received are probably already stale and should be flushed.  This is 
particularly important if the remote end cannot ack the data for some 
reason, in which case data messages can get stuck in the TB/RTB for 
arbitrarily long times.
I think this proposal was based on the assumption that the remote end 
would ack the data in the TB/RTB so these queues would empty themselves 
anyway; however there are cases where the remote end might not be able 
to ack the data in the RTB so messages might get stuck in the TB/RTB.

>    (b) M2PA SHALL NOT perform procedures to resynchronize sequence

I don't think resynchronization is necessary for either LPO or RPO, but 
I especially don't understand why it should be different between the two.

>        discard any received User Data messages.

This confuses me a bit.  Is the idea is that we don't want to discard 
messages that were sent after processor outage, taking into account the 
multistreaming?  I assume we're still expected flush the receive buffer 
at some point?

Andrew

-- 
Andrew Booth, Software Developer
Signaling Systems Group, Performance Technologies
613-237-4344

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.

---

From: Tom George <[email-masked]>
Date: Tue, 26 Aug 2003 14:14:35 -0500

Andrew, Brian, et. al.,

Comments below. Covering for the two cases is harder than it looks. 
Suggestions would be appreciated.

tomG.

> to ack the data in the RTB so messages might get stuck in the TB/RTB.

Yes, this was written with the assumption that the LPO end was going to 
keep transmitting messages. The thinking was that these messages should 
be drained out, so it would be misguided to attempt a flush.

But I think you are right in saying that any messages left over by the 
time that MTP3 commands a Flush are probably stale anyway, whether the 
other end is acking messages or not. So maybe it would be better to 
remove this (a) and follow MTP2, i.e., flush those messages.

> I especially don't understand why it should be different between the two.

If the LPO end continues normal transmission, we would not need to 
resynch the sequence numbers.

The LPO end is going to have incoming queued-but-unacked messages. It 
will have to flush those after the PO ends. So it needs to resynch the 
sequence numbers (right?).

> multistreaming?  I assume we're still expected flush the receive buffer 

Brian pointed out that in Q.703, the end recovering from RPO is allowed 
to discard a few MSUs. We do not want this to happen in M2PA, since 
there is no retransmission. But this is confusing (even to me), since 
earlier in the section I wrote that "M2PA SHALL discard any incoming 
messages that were queued and unacknowledged during the processor outage 
condition." I want it to flush the queued-and-unacked messages received 
during PO, but not discard any messages that are sent after PO ends.

>> In other respects, M2PA SHOULD follow the same procedures as MTP2 in
   [...]

---

From: Tom George <[email-masked]>
Date: Thu, 28 Aug 2003 17:14:36 -0500

Andrew, Brian, et. al.,

It looks to me like either the LPO or RPO end could have messages queued 
in the incoming or outgoing buffers. Even if the LPO end continues 
transmitting after the PO, if the RPO end does not ack these messages, 
they will remain in the LPO end's retransmit buffer. If MTP3 sends a 
Flush command, these messages need to be flushed at both ends.

So I merged the statements about the Flush command into one list, since 
I think they are the same for both LPO and RPO.

I confess to some weasel language regarding resynchronization. But my 
defense is that Q.703 does not say much about it either. As long as the 
BSN in the LS PR message is set correctly, the receiving end has the 
information it needs.

Here is my latest attempt at the Proc Outage section. Everyone please 
criticize.

tomG.

=====
4.1.4 Processor Outage

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

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.

    (c) If resynchronization of sequence numbers is required, M2PA MAY
        perform resynchronization of sequence numbers using the BSN
        from the received Link Status Processor Recovered message.
        However, during resychronization, M2PA SHALL NOT discard any
        received User Data messages.

=====

---

From: "Anatoly Khusid" <[email-masked]>
Date: Fri, 29 Aug 2003 15:47:56 -0400

Hello,

I am looking at section 3.1.6.1 (Correct Procedure (Data) with Proving).
I don't understand why DATA-ACK is <-000000, FFFFFF--
I assume this means FSN=000000 and BSN=FFFFFF ?  If yes, then why BSN=FFFFF,
I thought it should be set to 0 (peer's FSN).

Thanks

Anatoly

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Aug 2003 22:35:09 -0600

Anatoly,

The IUT in the test has not sent any DATA messages and therefore, ala Q.703,
it's SN is -1 (FFFFFF) not 0.  The first data message sent is 0.

--brian

Anatoly Khusid wrote:                                                              (Fri, 29 Aug 2003 15:47:56)

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