draft-george-sigtran-m2peer-00.txt

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

     MTP2 User Adaptatation Messages

        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  8]


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

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

2.2.1 Data 

The Data message contains an SS7 MTP2-User message.  It is the
equivalent of a Message Signal Unit in MTP. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ...
   |                         Protocol Data                         |
                                   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Note that the Protocol Data field contains only the MTP2-User
application message. The header transmitted by MTP2 (which includes
the Flag, BSN, BIB, FSN, FIB, LI) is 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 MTP.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            State                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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.

   Define    Value  Description
		     
   STATUS_O   0x0   Status indication O  - Out of alignment
   STATUS_N   0x1   Status indication N  - Normal alignment status
   STATUS_E   0x2   Status indication E  - Emergency alignment status
   STATUS_OS  0x3   Status indication OS - Out of Service
   STATUS_PO  0x4   Status indication PO - Processor Outage
   STATUS_B   0x5   Status indication B  - Busy




George, et al                                               [Page  9]


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

3.  Procedures

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 message delimitation, sequence numbering, and error
correction. Therefore the header transmitted by MTP2 (which includes
the Flag, BSN, BIB, FSN, FIB, LI) is not needed in M2UA.

3.1.2 Link Alignment

MTP3 can request that an SS7 link be brought into alignment ([2]
Q.703, section 7).  During alignment, communication to the other end
of the link is tested for a period of time to make sure that the link
is ready for traffic. Once the link is aligned, proving begins. During
proving, messages are sent from both ends of the link to verify that
the link is capable of sustaining traffic. 

Proving may take place for a Normal or (shorter) Emergency time
period. MTP3 determines whether the alignment procedure is Normal or
Emergency, and informs M2UA through the Emergency and Emergency Ceases
commands.

To begin alignment in M2UA, M2UA sends the Associate primitive to
SCTP. 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 sends Link Status SIO to its
peer at an implementation-dependent rate. If the remote end sends a
Link Status of SIN, SIE, or SIO before time interval T2 elapses, the
link is in an aligned state. If the remote end does not send one of
those Link Status messages before T2, M2UA shall report to MTP3 that
the link is out of service.

When the link gets to an aligned state, M2UA sends Link Status SIN or
SIE (for Normal or Emergency proving) at an implementation-dependent
rate. If the remote end sends a Link Status of SIN, SIE, or SIO before
time interval T3 elapses, the link is in proving state. If the remote
end does not send one of those Link Status messages before T3, M2UA
shall report to MTP3 that the link is out of service.

While in the proving state, M2UA continues to send SIN/SIEs for a
period of T4. If T4 elapses and the link has not failed, proving is
complete. The link is ready for traffic.

When proving is complete, M2UA may send a Status primitive to SCTP to
determine if the smoothed round-trip time and other status data are

George, et al                                              [Page  10]


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

acceptable. Sending of the Status primitive is optional. Use of the
Status information is implementation dependent.

3.1.3 Processor Outage

A processor outage occurs when M2UA cannot transfer messages to MTP3.

When M2UA detects a local processor outage (e.g., by receiving a 
Local Processor Outage from MTP3), it sends a Link Status message to 
its peer with status PO. It discards any messages received.

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

When the processor outage ceases, MTP3 sends a Local Processor 
Recovered indication to M2UA. The local M2UA notifies its peer by 
sending the next Data message. The peer notifies its MTP3 that the 
remote processor outage has ceased.

3.1.4 Level 2 Flow Control

Congestion control is provided by SCTP. Any congestion control 
procedures in M2UA are implementation dependent.

MTP3 expects notification of link congestion.  For example, this is
accomplished by two messages 1) Link Congestion Onset 2) Link
Congestion Abated.  For example, congestion could be detected if M2UA
receives a failure response when it attempts to send a message to SCTP
(this is implementation dependent, and it is assumed that the SEND
Failure has an error code that indicates congestion).  M2UA reports
Link Congestion Onset to MTP3. Subsequently M2UA can poll the status
of SCTP.  When SCTP is no longer congested, M2UA reports Link
Congestion Abated to MTP3. If the congestion condition should
continue, the link will be taken out of service.  In this case, it is
possible to start the link changeover procedure.

The US National version of SS7 has congestion levels [3]. For US
National SS7, the Indication primitive for Congestion Onset should
report the congestion level.

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 MTP2 Timers in M2UA

This section explains which MTP2 timers are needed in M2UA.

3.1.6.1  T2 Not Aligned, T3 Aligned

Timers T2 and T3 are used to verify that the other end of the link is

George, et al                                              [Page  11]


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

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.

3.1.6.2  T4 Proving Period

Since M2UA directs the Proving procedure, timer T4 Proving Period is
implemented in M2UA as in MTP2.

Recommended values are:

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

3.1.6.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).

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.6.4  T5 Sending SIB

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

3.1.6.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.6.6  T7 Excessive Delay of Acknowledgement

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

George, et al                                              [Page  12]


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



3.2 Procedures to Support the MTP3/MTP2 Interface

3.2.1  Sending/receiving messages

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

If 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

If MTP3 requests that M2UA activate or restore a link by a Start 
command, M2UA shall follow the alignment procedure in section 3.1.2.

3.2.3  Link deactivation

If MTP3 requests that M2UA deactivate a link by a Stop command, M2UA 
shall send a TERMINATE primitive to SCTP.

3.2.4  Flush buffers

The Flush Buffers request from MTP3 is not supported by SCTP.

3.2.5 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 identifying all those messages in
the retransmission buffer of the unavailable signaling link which have
not been received by the far end.  Retrieval includes transferring the
concerned messages to the transmission buffers of the alternative
links.  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 to modify MTP3 to accomodate the larger SSNs.  Reference [7]
section 9.8.1 should be used as a guide for the MTP3 changes. Only the
Extended Changeover Order and Extended Changeover Acknowledgement
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.


George, et al                                              [Page  13]


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

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.  During normal period, SCTP delivers ordered messages to
the application.  However, during congestion or failure condition, the
sequence numbers of the acknowledged messages can 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 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 Retrieve
FSN 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.


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.



















George, et al                                              [Page  14]


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

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.


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

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

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

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

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

                             (SCTP Association
                              procedure)

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


Even though the SCTP association is established, it is important that
M2UA not send MTP3 data at this point. It must be confirmed that both
ends of the link are ready for traffic. Otherwise, messages could be
lost. Therefore proving begins at this time:



















George, et al                                              [Page  15]


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


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

                 Link Status SIO
                 ------------------------------------>

                                       Link Status SIN
                 <------------------------------------

                 Link Status SIN
                 ------------------------------------>

                                       Link Status SIN
                 <------------------------------------

                 Link Status SIN