Subject: [Sigtran] M2PA: Revised section 4.2

From: Tom George <[email-masked]>
Date: Fri, 07 Mar 2003 21:16:24 -0600

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.

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

Link Status and User Data messages SHALL be sent via SCTP on separate
streams.

When M2PA receives a User Data message from SCTP, M2PA passes the
message to MTP3.

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.

The first User Data message sent after the link is placed in service
is given a Forward Sequence Number (FSN) of 1.

The Forward Sequence Number of the header is incremented by 1 for each
User Data message sent (provided that the message contains a data
payload). When the FSN reaches the maximum value, the next FSN is 0.

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

The Backward Sequence Number is set to the FSN of the last User Data
message M2PA received from its peer. This serves as an M2PA-level
acknowledgement of the message. After the link is placed in service
and before a User Data message has been received, the BSN is set to 0.

When M2PA receives a User Data message with Backward Sequence Number
equal to 'n', it may remove all messages with Forward Sequence Number
<= n from its queue.

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 follow the criterion of Q.703 [Q.703], section 5.3.1 for
incorrect BSNs: If any two BSNs in three consecutively received User
Data messages are not the same as the previous one or any of the FSNs
of the User Data messages in the M2PA retransmit buffer at the time
they are received, then MTP3 SHOULD be informed that the link is
faulty.

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

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 retransmitted
and timer T7 (below) does not apply to them.

Note that since SCTP provides reliable delivery and ordered delivery
within the stream, M2PA does not perform retransmissions.

Timer T7 provides an indication of excessive delay of
acknowledgement. If the following conditions are true: 

   (a) There is at least one message in the M2PA retransmit buffer.

   (b) The remote M2PA is not in a Busy condition (i.e., the local
       timer T6 is not running).

   (c) There is a message in the M2PA retransmit buffer that has not
       received an acknowledgement in the span of T7 since its last
       transmission.

   then M2PA SHOULD place the link out of service (see section 4.1.6
   Link Out of Service).

Recommended values:

   T7 Acknowledgement - Range: 0.5-2 seconds. Default: 1.0 seconds.

4.2.2  Link activation and restoration

When MTP3 requests that M2PA activate or restore a link by a Start
Request, M2PA SHALL follow the alignment procedure in section 4.1.3.

4.2.3  Link deactivation

When MTP3 requests that M2PA deactivate a link by a Stop command, M2PA
SHALL place the link out of service (see section 4.1.6 Link Out of
Service).

The peer M2PA, upon receiving Link Status Out of Service, SHALL place
the link out of service (see section 4.1.6 Link Out of Service).

4.2.4  Flush Buffers and Continue

The Flush Buffers and Continue commands allow M2PA to resume normal
operations (i.e., transmission of messages to SCTP and receiving
messages from SCTP) after a processor outage (local and/or remote)
ceases.

If M2PA receives a Flush Buffers command from MTP3, M2PA:

   (a) SHALL NOT transmit any messages to SCTP that are currently
       waiting to be transmitted to SCTP. These messages SHALL be
       discarded.

   (b) SHALL discard all messages currently waiting to be passed 
       to MTP3.

If M2PA receives a Continue command from MTP3, M2PA:

   (a) SHALL resume transmitting any messages to SCTP that are waiting
       to be transmitted to SCTP. 

   (b) SHALL pass to MTP3 any messages waiting to be passed to MTP3.

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 Q.704 [Q.704],
section 3.8.

M2PA SHALL use the Congestion Indication primitive to notify its upper
layer MTP3 of changes in the signaling link congestion status and the
signaling link discard status. For national networks with multiple
congestion threshold levels, M2PA SHALL notify MTP3 of the congestion
and discard status levels.

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

For data retrieval, MTP3 requests the Backward Sequence Number to be
Transmitted (BSNT) from M2PA through the Retrieve BSNT request. M2PA
determines the Forward Sequence Number of the last User Data message
received from the peer for which an acknowledgement was sent. This
value is the BSNT. M2PA sends the BSNT value to MTP3 in the BSNT
confirmation. In the same way, the remote end also detects its
BSNT. The MTP3 layers exchange BSNT values through the XCO and XCA
messages. The BSNT received from the other end is called the
FSNC. When MTP3 receives the FSNC from the other end, MTP3 retrieves
all the unsent and unacknowledged messages starting with sequence
number (FSNC + 1).  This is accomplished through a Retrieval Request
and FSNC request. After all the messages are sent from M2PA to MTP3,
M2PA sends a Retrieval Complete indication to MTP3.

If there are any messages on the M2PA or SCTP receive queues that have
not been acknowledged by M2PA, M2PA SHOULD discard these messages. The
peer will retransmit them on an alternate link. Any messages
acknowledged by M2PA MUST NOT be discarded. These messages MUST be
delivered to MTP3.

If M2PA receives a Retrieve BSNT request from MTP3, M2PA SHALL respond
with the BSNT confirmation. The BSNT value is the Forward Sequence
Number of the last User Data message received from the peer.

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

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

   (b) any untransmitted User Data messages.

Then M2PA SHALL send the Retrieval Complete indication to MTP3.

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 in order and deliver to
MTP3:

   (a) any untransmitted User Data messages.

Then M2PA SHALL send the Retrieval Complete indication to MTP3.

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 in order and
deliver to MTP3:

   (a) any transmitted but unacknowledged User Data messages.

   (b) any untransmitted User Data messages.

Then M2PA SHALL send the Retrieval Complete indication to MTP3.

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

---

From: "S Magesh" <[email-masked]>
Date: Thu, 20 Mar 2003 13:18:56 +0530

Tom

Under section 4.2.1, 

The first User Data Message sent after link is placed in service
is given a FSN of 1.  

Once the FSN has reached the maximum value, the next FSN is 0.

The above two statements are contradicting.

Apart from the above statements, for BSN the initial value is 0.

So for first user data message the FSN value should be 0 rather 1, 
once the link is placed inservice.

Regards

Magesh

----- Original Message ----- 
From: "Tom George" <[email-masked]>
To: "SIGTRAN e-mail list" <[email-masked]>
Sent: Saturday, March 08, 2003 8:46 AM
Subject: [Sigtran] M2PA: Revised section 4.2

Recommended values:

4.2.3  Link deactivation

4.2.6 Changeover

   - BSNT Confirmation

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Mar 2003 01:11:13 -0700

All,

Is there are reason do deviate from Q.703 on the assignment
of initial sequence numbers?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran