draft-ietf-sigtran-m2pa-03.txt

No7信令,我需要交换类似的代码, 请店长审核,谢谢了,急着交换,谢谢

George, et al                                                [Page 26]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001


4.1.3  Link Alignment

The purposes of the alignment procedure are:

1. To provide a handshaking procedure so that both endpoints are
   prepared to send SS7 traffic, and to prevent traffic from being
   sent before the other end is ready.

2. Verify that the SCTP association is suitable for use as an SS7
   link.

3. Optionally, to overcome the SCTP slow start period.

Link alignment takes place after the association is established. If
SCTP fails to establish the association, and M2PA has received a Start
Request from its MTP3, then M2PA shall report to MTP3 that the link is
out of service. 

Once the association is established and M2PA has received a Start
Request from MTP3, M2PA sends the Link Status Alignment message to its
peer. If M2PA has not already received the Link Status Alignment
message from its peer, then M2PA starts timer T1.

(Note that if the remote M2PA has not received a Start Request from its
MTP3, it will not send the Link Status Alignment message to the
local M2PA. Eventually timer T1 in the local M2PA will expire.)

M2PA stops timer T1 when it has received the Link Status Alignment
message from its peer.

If timer T1 expires, then M2PA reports to MTP3 that the link is out of
service. M2PA should leave the association established. M2PA waits for
MTP3 to initiate the alignment procedure again.


When M2PA has both sent and received the Link Status Alignment
message, it has completed alignment and moves to the proving state.

M2PA starts the proving period timer T2. During the proving period,
M2PA sends Link Status Proving messages to its peer at an interval
defined by the protocol parameter Status_Interval. M2PA sends either
the Proving Normal or Proving Emergency message, according to the
Emergency and Emergency Ceases commands from MTP3. M2PA uses the value
of T2 corresponding to the Normal or Emergency state. However, if M2PA
receives a Link Status Proving Emergency message from its peer, then
M2PA shall use the Emergency value for T2.

Also while T2 is running, M2PA shall send Proving Data messages on the
User Data stream. These messages are sent at a rate equal to the
protocol parameter Proving_Data_Rate.

When the proving period timer T2 expires, M2PA shall determine the
association's performance as described in section 4.1.6 Error

George, et al                                                [Page 27]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

Monitoring. If the association's performance is inadequate, M2PA shall
report to MTP3 that the link is out of service. M2PA should leave the
association established. M2PA waits for MTP3 to initiate the alignment
procedure again.

If the association's performance is satisfactory, M2PA shall start the
timer T3 and send Link Status Ready messages to its peer at interval
Status_Interval. These messages are used to verify that both ends have
completed proving.

M2PA shall stop timer T3 when it receives a Link Status Proving
Complete or User Data message from its peer. If timer T3 expires, then
M2PA reports to MTP3 that the link is out of service. M2PA should
leave the association established. M2PA waits for MTP3 to initiate the
alignment procedure again.

Note that if M2PA has already received a Link Status Ready message
from its peer when it finishes checking the association's performance,
there is no need to start timer T3. M2PA can just send Link Status
Ready to the peer and continue along.

When all of the following are true:

   (a) M2PA has received a Start Request from MTP3.

   (b) M2PA's proving period T2 has expired.

   (c) M2PA has sent a Link Status Ready to its peer.

   (d) M2PA has received a Link Status Ready OR User Data
       message from its peer.

then M2PA shall send Link In Service to its MTP3. 

If there is a local processor outage condition, M2PA sends Link Status
Processor Outage to its peer. When the local processor outage
condition ends, then M2PA shall send Link Status Processor Outage
Ended to its peer. M2PA shall attempt to complete the alignment
procedure during the local processor outage condition.

If M2PA receives a Link Status Processor Outage during alignment, and
M2PA had received a Start Request from its MTP3, M2PA shall report
Remote Processor Outage to MTP3.

Recommended values:

T1 Alignment - Range: 1-60 seconds   Default: 10 seconds

T2 Proving -  

   Normal - Range: 1-60 seconds   Default: 10 seconds

   Emergency - Range: 400-600 milliseconds   Default: 500 milliseconds


George, et al                                                [Page 28]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

T3 Ready -  Range: 1-60 seconds   Default: 10 seconds

Status_Interval - implementation dependent.

Proving_Data_Rate - implementation dependent.


4.1.4 Processor Outage

A processor outage occurs when M2PA cannot transfer messages because
of a condition at a higher layer than M2PA.

When M2PA detects a local processor outage, it sends a Link Status
message to its peer with status Processor Outage. M2PA shall also
cease sending User Data messages to SCTP for transmission.

M2PA should periodically send a Link Status Processor Outage message
as long as there is a local processor outage.

The peer M2PA, upon receiving the Link Status Processor Outage
message, shall report Remote Processor Outage to its MTP3. The peer
M2PA ceases sending User Data messages. M2PA stops the Remote
Congestion timer T6 if it is running.

MTP3 sends a Flush Buffers or Continue command to M2PA. When the
processor outage ceases, MTP3 sends a Local Processor Recovered
indication to M2PA. The local M2PA notifies its peer by sending a Link
Status message with status Processor Outage Ended. The peer uses the
Remote Processor Recovered Indication to notify its MTP3 that the
remote processor outage condition has ceased.


4.1.5 Level 2 Flow Control

Notification of receive congestion from SCTP to M2PA is implementation
dependent. This section assumes that M2PA has some means of
determining when SCTP is in receive congestion, such as a receive
congestion notification from SCTP to M2PA. Since SCTP has its own
congestion control, the purpose of the M2PA level 2 flow control is to
monitor the association and decide if it should be aborted.

If M2PA determines that SCTP is in receive congestion for an
association, M2PA shall send a Link Status Busy message to its peer on
that association.

M2PA should periodically send a Link Status Busy message as long as
its SCTP is in receive congestion.

When the peer M2PA receives the Link Status Busy message, it shall
start the Remote Congestion timer T6. If timer T6 expires, M2PA shall
use the ABORT primitive to end the association and take the link out
of service.

The peer M2PA shall continue transmitting messages to SCTP while its

George, et al                                                [Page 29]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

T6 timer is running, i.e., while the other end is Busy. 

If M2PA determines that SCTP is no longer in receive congestion for
the association, M2PA shall send a Link Status Busy Ended message to
its peer on that association.

When the peer M2PA receives the Link Status Busy Ended message, it
shall stop timer T6.

Recommended value of T6 is 1-6 seconds. 


4.1.6 Error Monitoring

If M2PA loses the SCTP association for a link, M2PA shall report to
MTP3 that the link is out of service.

As long as the SCTP association is up, M2PA shall regularly monitor
the association performance. It is recommended that M2PA use the
following data to determine the performance of the association:

   - Smooth Round Trip Time (SRTT). This can be obtained from SCTP by
     invoking the SCTP GETSRTTREPORT primitive.

   - Frequency of SCTP retransmissions. 

   - Frequency of SCTP Gap Acknowledgements received. 

If these values are not acceptable, the link is considered failed and
taken out of service. 

The acceptable values of these data are implementation dependent. 

The interval between successive checks of the performance data should
be a configurable parameter. Its value is implementation dependent.


4.1.7  Transmission and Reception Priorities

In MTP, Link Status messages have priority over User Data messages
([2] Q.703, section 11.2). To achieve this in M2PA, M2PA shall send
Link Status and User Data messages on separate streams in its SCTP
association. All messages are sent using the ordered delivery option.

M2PA SHOULD give higher priority to reading the Link Status stream
over the User Data stream.

M2PA SHOULD give higher priority to receiving notifications from SCTP
over reading either the Link Status stream or the User Data stream.

Implementation Note: If the SCTP implementation allows streams to have
different priorities for sending messages, then M2PA SHOULD set the
Link Status stream to a higher priority than the User Data stream. See
[13] for a possible extension to SCTP to allow for stream priorities.

George, et al                                                [Page 30]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001


4.1.8  M2PA Version Control

A node upgraded to a newer version of M2PA SHOULD support the older
versions used on other nodes with which it is communicating. If that
is the case, then alignment can proceed normally.

In particular, it is recommended that for future modifications to this
protocol:

- Any newer version should be able to process the messages from a
  lower version.

- A newer version of M2PA should refrain from sending messages to an
  older version of M2PA messages that the older version cannot
  process.

- If an older version of M2PA receives a message that it cannot
  process, it should discard the message.

- In cases where different processing is done in two versions for the
  same format of a message, then the newer version should contain
  procedures to recognize this and handle it appropriately.

In case a newer version of M2PA is incompatible with an older version,
the newer version should recognize this and prevent the alignment of
the link. If a Link Status Alignment message with an unsupported
version is received by the newer version, the receiving end's M2PA
shall not complete the alignment procedure.


4.2 Procedures to Support the MTP3/MTP2 Interface

4.2.1  Sending/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.


4.2.2  Link activation and restoration

When MTP3 requests that M2PA activate or restore a link by a Start

George, et al                                                [Page 31]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

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 send an ABORT primitive to SCTP.

4.2.4  Flush Buffers, 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 either a Flush Buffers or Continue command from MTP3,
and the processor outage condition ceases, M2PA shall resume receiving
and transmitting messages.


4.2.5 MTP3 Signaling Link Congestion

Notification of transmit congestion from SCTP to its upper layer
(M2PA) is implementation dependent. Nevertheless, M2PA should receive
notification from SCTP adequate to allow MTP3 to meet its requirements
for signaling link transmit congestion in [2] 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.

Note: M2PA does not discard messages because of transmit
congestion. Discarding of messages due to transmit congestion is
performed by MTP3.


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

George, et al                                                [Page 32]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

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
       SCTP, 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. References to stream sequence
numbers in this section refer only to the User Data stream's stream
sequence numbers.

In order to support changeover in M2PA, the SCTP Stream Sequence
Numbers must be used in place of the Forward and Backward Sequence
Numbers (FSN/BSN) of SS7.

Stream Sequence Numbers used by SCTP are 16 bits long.  MTP2's Forward
and Backward Sequence Numbers are only seven bits long.  Hence it is
necessary for MTP3 to accommodate the larger SSNs. This is done
through the use of the Extended Changeover Order (XCO) and Extended
Changeover Acknowledgement (XCA) messages in