draft-george-sigtran-m2peer-01.txt

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

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000


2.1 Common Message Header

The protocol messages for MTP2 User Adaptation require a message
header structure which contains a version, message type and message
length.  This message header is common among all SCN adaptation
layers. The header structure is shown in Figure 3.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Spare     |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |


                 Figure 3:  Common Message Header


2.1.1  Version

The version field (vers) contains the version of the M2UA adapation 
layer.  The supported versions are:

      01   Release 1.0 of M2UA adaptation protocol

2.1.2  Message Type

The valid message types are defined below and the message contents are
described in Section 2.2.  Each message can contain parameters.

The following list contains the message types for the defined messages.


     MTP2 User Adaptatation Messages

        Type                     Value (Hex)

        User Data                0601
        Link Status              0602

       
2.1.3  Message Length

The Message length defines the length of the message in octets, not 
including the header.

2.2 M2UA Messages

The following section defines the messages and parameter contents.  The

George, et al                                                [Page 9]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000

M2UA messages will use the command header and the M2UA specific header.

2.2.1 User Data 

The User Data parameter is the data sent from the MTP3 in the form of
the contiguous SIO and SIF fields of the MSU ([2] Q.703, section 2.2
Signal Unit Format). The format for the Data message is as follows:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ...
   |                           User Data                           |
                                   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


No padding is added to the MTP3 message.

Note that the User Data field contains only the SIF and SIO
octets. The other components of the message transmitted by MTP2 (the
Flag, BSN, BIB, FSN, FIB, LI, CK) are not included in M2UA.

2.2.2  Link Status

The MTP2 Link Status message can be sent between M2UA peers to
indicate link status. It is the equivalent of the Link Status Signal
Unit in MTP2.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Link Status                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The valid values for State are shown in the following table. All
values defined in the MTP2 Link Status Signal Unit have an equivalent
in this M2UA Link Status message. This does not imply that all values
must be used by M2UA.

    Value  Description

     1     In Alignment
     2     In Service
     3     Processor Outage
     4     Processor Outage Ended


3.  Procedures


George, et al                                               [Page 10]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000

3.1 Procedures to Support MTP2 Features

3.1.1 Signal Unit Format, Delimitation, Acceptance

Messages for transmission across the network must follow the format
described in section 2.

SCTP provides reliable, in-sequence delivery. Therefore the related
functionality of MTP2 is not needed. SCTP does not provide functions
related to Link State Control in MTP2. These functions must be
provided by M2UA.

3.1.2 Link Alignment

To begin alignment in M2UA, M2UA sends the ASSOCIATE primitive to SCTP
if the SCTP association is not already established. The association
shall contain one stream in each direction. If SCTP fails to establish
the association, M2UA shall report to MTP3 that the link is out of
service.

Once the association is established, M2UA has the option of sending
Link Status messages with status In Alignment. These messages can be
used for proving the link. If M2UA receives a Link Status In
Alignment, it should ignore the message.

Once the association is established and In Alignment messages (if any)
have been sent, if MTP3 has not deactivated the link, M2UA sends a
Link Status of In Service to its peer.

The link is ready for traffic when the association is established,
M2UA has sent Link Status In Service to its peer, and has received
Link Status In Service from its peer. Then M2UA sends Link In Service
to its MTP3.

If M2UA receives a Link Status of Processor Outage during alignment,
M2UA shall report to MTP3 that the link is out of service.

M2UA shall ignore the Emergency and Emergency Ceases commands from
MTP3.


3.1.3 Processor Outage

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

When M2UA detects a local processor outage, it sends a Link Status
message to its peer with status Processor Outage. It discards any
messages received. 

The peer M2UA, upon receiving the Link Status Processor Outage
message, notifies its MTP3. It ceases sending Data messages.


George, et al                                               [Page 11]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000

When the processor outage ceases, MTP3 sends a Local Processor
Recovered indication to M2UA. The local M2UA notifies its peer by
sending a Link Status message with status Processor Outage Ended.  The
peer notifies its MTP3 that the remote processor outage has ceased.

3.1.4 Level 2 Flow Control

Notification of receive congestion from M2UA to MTP3 is implementation
dependent.

3.1.5 Error monitoring

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

3.1.6  Transmission Priorities

Link Status messages have priority over User Data messages ([2] Q.703,
section 11.2). To achieve this, Link Status messages shall be sent
via SCTP using the unordered delivery option.

User Data messages shall be sent via SCTP using ordered delivery.

It is recommended that SCTP give higher transmission priority to
unordered messages. In other words, SCTP should follow the
Implementation Note in [5] section 6.6, "Ordered and Un-ordered
Delivery".

3.1.7  MTP2 Timers in M2UA

This section explains which MTP2 timers are needed in M2UA.

3.1.7.1  T2 Not Aligned, T3 Aligned

Timers T2 and T3 are used to verify that the other end of the link is
communicating. In MTP2, if either of timers T2 or T3 expire, alignment
is not possible, so MTP2 reports to MTP3 that the link is out of
service ([2] Q.703, Figures 8 and 9).

Timer T2 is used to verify that the remote end responds to the initial
attempt to align the link. Timer T3 is used to verify that the remote
end is proving the link along with the local end. 

Both timers T2 Not Aligned and T3 Aligned are implemented in M2UA.

Recommended value of T2 is 5-150 seconds.
Recommended value of T3 is 1-2 seconds.

These are the same values recommended in [2] Q.703.

3.1.7.2  T4 Proving Period

Since M2UA directs the Proving procedure, timer T4 Proving Period is

George, et al                                               [Page 12]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000

implemented in M2UA as in MTP2.

Recommended values are:

    normal proving period: 7.5-9.5 seconds
    emergency proving period: 400-600 milliseconds

These are the same values recommended in [2] Q.703.

3.1.7.3  T1 Alignment Ready

In MTP2, timer T1 is started when alignment is complete. If T1 expires
before an MSU or FISU is received, MTP2 LSC reports to MTP3 that the
link is out of service ([2] Q.703, Figure 8, sheet 6).

M2UA does not send FISUs. The purpose of FISUs is served by the
Heartbeats in SCTP. SCTP uses the Heartbeats to determine if
communication has been lost on the connection.  M2UA does not need to
verify that the link is in service. Therefore it is not necessary to
implement timer T1 in M2UA.

3.1.7.4  T5 Sending SIB

Since SCTP provides congestion control, it is not necessary to
implement timer T5 in M2UA.

3.1.7.5  T6 Remote Congestion

MTP2 uses T6 to determine if a link has been congested so long that it
should be failed.

Since SCTP determines when an association has failed, it is not
necessary to implement timer T6 in M2UA.

3.1.7.6  T7 Excessive Delay of Acknowledgement

SCTP performs acknowledgements and retransmissions. Therefore it is
not necessary to implement timer T7 in M2UA.

3.2 Procedures to Support the MTP3/MTP2 Interface

3.2.1  Sending/receiving messages

When MTP3 sends a message for transmission to M2UA, M2UA adds the M2UA
header to the message, then passes the message to SCTP using the SEND
primitive.

When M2UA receives a Data message from SCTP, M2UA removes the M2UA
header and passes the message to MTP3.

3.2.2  Link activation and restoration

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

George, et al                                               [Page 13]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000

command, M2UA shall follow the alignment procedure in section 3.1.2.

3.2.3  Link deactivation

When MTP3 requests that M2UA deactivate a link by a Stop command, M2UA
shall send an ABORT primitive to SCTP.

3.2.4  Flush buffers

Processing of the Flush Buffers request from MTP3 is implementation
dependent.

3.2.5 Signaling Link Congestion

Notification of transmit congestion from SCTP to its upper layer
(M2UA) is implementation dependent. Nevertheless, M2UA 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.

3.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 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 reopening 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
       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 transmitted
over the alternate links. Since Link Status messages are sent with the
unordered delivery option of SCTP, they do not have Stream Sequence
Numbers. 

In order to support changeover in M2UA, 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 accomodate the larger SSNs. 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

George, et al                                               [Page 14]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000

messages are specified in Reference [7] section 9.8.1. Only the XCO
and XCA messages from [7] are used. These messages have a 24-bit field
for the sequence number. The upper 8 bits of the 24 bit field should
be set to 0, and the SSN placed in the lower 16 bits.

For data retrieval, MTP3 requests Backward Sequence Number (BSN) from
M2UA.  This is the sequence number of the last message received by the
local end.  Normally, SCTP delivers ordered messages to the
application.  However, during congestion or failure condition, the
sequence numbers of the acknowledged messages may have gaps.  In
particular, the SACK (selective acknowledgement message) message can
have several of these gaps.  Hence, it is important to scan through
these gaps and find the sequence number before the first gap.  This is
the number from which the remote end has to transmit the messages.  So
this is the number considered as the Backward Sequence Number and
communicated to the remote end.  In a similar way, the remote end also
detects the BSN and indicates to the local end. As soon as the MTP3 of
the local end receives this BSN, MTP3 retrieves all the unacknowledged
messages starting from BSN.  This is accomplished through a Retrieval
Request and FSNC request.  After all the messages are sent from M2UA
to MTP3, a Retrieval Complete indication is sent.

Note that the sequence numbers and messages requested by MTP3 are sent
from SCTP to M2UA in the Communication Lost primitive. Retrieval of
messages is an optional feature in SCTP. To perform data retrieval, it
is necessary that this option be implemented, and that the SSNs of the
messages are identified.

If M2UA receives a Retrieve BSNT request from MTP3, M2UA responds with
the BSNT indication. The BSNT value is the SCTP stream sequence number
of the last message received by SCTP before any gaps in the stream
sequence numbers. 

(Note that any messages with stream sequence number greater than this
BSNT value have been acknowledged by SCTP, but have not been passed up
to M2UA. Therefore these messages should be retransmitted by the far
end on the alternate link.)

If M2UA receives a Retrieval Request and FSNC request from MTP3, M2UA
retrieves from SCTP:

       (a) any transmitted but unacknowledged messages beginning with
	   the stream sequence number FSNC + 1, and

       (b) any untransmitted messages in SCTP.

Each of these messages is sent to MTP3, first (a), then (b). Then M2UA
sends the Retrieval Complete indication to MTP3.

Note: The changeover procedure makes it impossible for M2UA to have
multiple streams in a direction for one link. Buffer updating would
have to be done for each stream separately to avoid duplication of
messages. But there is only one XCO message for sending the

George, et al                                               [Page 15]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000

last-received SSN.


4.  Examples of MTP2 User Adaptation (M2UA) Procedures

In general, messages passed between MTP3 and M2UA are the same as
those passed between MTP3 and MTP2.  M2UA interprets messages from MTP3
and sends the appropriate message to SCTP. Likewise, messages from
SCTP are used to generate a meaningful message to MTP3.

Note that throughout this section, the primitives between MTP3 and
M2UA are named using the MTP terminology [1][2]. Communications
between M2UA and SCTP are named using SCTP terminology.

4.1  Link Initialization (Alignment)

An example of the message flow to bring an SS7 link in-service is
shown below. Proving is done by both ends of the link. To simplify the
diagram, proving is shown on one end only. It is assumed in this
example that SCTP has been initialized.


    MTP3        M2UA        SCTP        SCTP        M2UA        MTP3
    ----        ----        ----        ----        ----        ----

     Out of Service
     <------------

     Emergency OR
     Emergency Ceases
     ------------>

     Start
     ------------>

                 Associate
                 ------------>

                             (SCTP Association
                              procedure)

                 Communication Up        Communication Up
                 <------------           ------------>











George, et al                                               [Page 16]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  May 2000