Subject: [Sigtran] M2PA draft "7b" - section 4.2

From: Tom George <[email-masked]>
Date: Fri, 11 Apr 2003 15:51:44 -0500

Here is section 4.2. Of course, the sections marked "(deleted)" will be
deleted.

tomG.

4.2 Procedures to Support the MTP3/MTP2 Interface

4.2.1  Sending and receiving messages

When MTP3 sends a message for transmission to M2PA, M2PA passes the
corresponding M2PA message to SCTP using the SEND primitive.

User Data messages SHALL be sent via stream 1 of the association.

M2PA Link Status messages are passed to SCTP using the SEND primitive.

Link Status messages SHALL be sent via stream 0 of the association.

If M2PA receives a message from SCTP with an invalid Message Class or
unsupported Message Type in the Common Message Header, M2PA SHALL
discard the message.

For message types other than User Data, the Forward Sequence Number is
set to the FSN of the last User Data message sent.

If M2PA receives a User Data message with an FSN that is out of order,
M2PA SHALL place the link out of service (see section 4.1.6 Link Out
of Service).

M2PA SHOULD ignore the FSN and BSN contained in a Link Status message.

Note: In all calculations involving FSN and BSN, the programmer should
be aware that the value wraps around to 0 after reaching its maximum
value.

If there is no other User Data message to be sent when there is a
message to acknowledge, M2PA SHOULD send a User Data message with no
data payload. The FSN for this empty User Data message is not
incremented. It MUST contain the same FSN as the most recently sent
User Data message containing Data. This message SHOULD be sent
promptly in order to prevent poor SS7 performance. 

If M2PA receives an empty User Data message, it SHALL NOT send an
acknowledgement of that message. 

Note that there is no reason to place empty User Data messages in the
M2PA retransmit buffer, since the empty messages are not retrieved for
changeover and timer T7 does not apply to them.

Note that since SCTP provides reliable delivery and ordered delivery
within the stream, M2PA does not perform
retransmissions. Nevertheless, M2PA SHALL retain transmitted User Data
messages in a retransmit queue until they are acknowledged. These
messages are needed in case MTP3 performs data retrieval as part of a
changeover procedure.

Because propagation delays in IP networks are more variable than in
traditional SS7 networks, a single T7 timer (excessive delay of
acknowledgement) is inadequate. A T7 timer SHALL be started for each
message in the M2PA retransmit buffer.

4.2.2  Link activation and restoration

(deleted)

4.2.3  Link deactivation

(deleted)

4.2.4  Flush Buffers and Continue

(deleted)

4.2.5 MTP3 Signaling Link Congestion

M2PA SHALL detect transmit congestion in its buffers according to the
requirements for signaling link transmit congestion in MTP3, e.g.,
Q.704 [Q.704], section 3.8.

4.2.6 Changeover

The objective of the changeover is to ensure that signaling traffic
carried by the unavailable signaling link is diverted to the
alternative signaling link(s) as quickly as possible while avoiding
message loss, duplication, or mis-sequencing.  For this purpose, the
changeover procedure includes data retrieval, which is performed
before opening the alternative signaling links to the diverted
traffic.  Data retrieval consists of these steps:

   (1) buffer updating, i.e., identifying all those User Data 
       messages in the retransmission buffer of the unavailable
       signaling link which have not been received by the far end
       M2PA, as well as untransmitted messages, and

   (2) transferring those messages to the transmission buffers of the
       alternate links.

Note that only User Data messages are retrieved and transmitted over
the alternate links. Link Status messages SHALL NOT be retrieved and
transmitted over the alternate links. 

M2PA's Sequence Numbers are 24 bits long.  MTP2's Forward and Backward
Sequence Numbers are only seven bits long.  Hence it is necessary for
MTP3 to accommodate the larger sequence numbers. This is done through
the use of the Extended Changeover Order (XCO) and Extended Changeover
Acknowledgement (XCA) messages instead of the Changeover Order (COO)
and Changeover Acknowledgement (COA) messages. The XCO and XCA
messages are specified in [Q.2210] section 9.8.1 and T1.111.4
[T1.111], section 15.4. Only the XCO and XCA messages from [Q.2210] or
[T1.111] are required. The BSN is placed in the XCO/XCA message as
explained in [Q.2210] and [T1.111].

Also, the following MTP3/MTP2 primitives MUST use the larger sequence
numbers:

   - BSNT Confirmation

   - Retrieval Request and FSNC

If M2PA receives a Retrieval Request and FSNC request from MTP3, M2PA
SHALL retrieve from its buffers and deliver to MTP3 in order:

   (a) any transmitted User Data messages beginning with the first
       unacknowledged message with FSN greater than FSNC.

   (b) any untransmitted User Data messages.

For emergency changeover, MTP3 retrieves only the unsent messages for
transmission on the alternate link(s). If M2PA receives a Retrieval
Request and FSNC request with no FSNC value, or with an invalid FSNC,
then M2PA SHALL retrieve from its buffers and deliver to MTP3 in
order:

   (a) any untransmitted User Data messages.

Note: For the Japanese version of MTP defined in [JT-Q704], MTP3
retrieves both unsent and unacknowleged messages for transmission on
the alternate link(s). In this version of MTP, if M2PA receives a
Retrieval Request and FSNC request with no FSNC value, or with an
invalid FSNC, then M2PA SHALL retrieve from its buffers and deliver to
MTP3 in order:

   (a) any transmitted but unacknowledged User Data messages.

   (b) any untransmitted User Data messages.

4.2.6.1 Multiple User Data Streams and Changeover

The changeover procedure makes it problematic for M2PA to have
multiple User Data streams in one direction for a link. Buffer
updating would have to be done for each User Data stream separately to
avoid duplication or loss of messages. But MTP3 provides for only one
XCO/XCA message for sending the last-received sequence number.

Even with sequence numbering of User Data messages at the M2PA layer,
it is necessary to perform buffer updating on each stream. Since the
M2PA messages would be delivered over multiple streams, there could be
a gap in the M2PA sequence numbers at the receiving end when the
changeover procedure begins. If only the M2PA sequence number is used
in the XCO/XCA message, there would be a possibility of losing the
messages in the gap, or duplicating messages after the gap.

M2PA links with multiple User Data streams would be possible if a
multiple-BSNT XCO/XCA message is defined in MTP3, or MTP3 allows
multiple XCO/XCA messages (one for each User Data stream) to be sent
during a changeover. This is beyond the scope of this document.

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. 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