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

From: Tom George <[email-masked]>
Date: Wed, 03 Sep 2003 17:12:54 -0500

Andrew, Brian, et. al.,

Andrew sent me a comment by private e-mail and I made a small change to 
(c) under the statement about the Flush command.

So here is my latest version of 4.1.4...
tomG.

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

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

While there is a remote processor outage 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.

    (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 that were sent after the processor
        outage ended.

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.

=====

Tom George wrote:
> 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.
   [...]

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Sep 2003 17:09:13 -0600

Tom,

Reads good to me.  There is more resynchronization language in T1.111.3.

--brian

Tom George wrote:                                                                      (Wed, 03 Sep 2003 17:12:54)

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