draft-ietf-sigtran-m2pa-01.txt

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

Data Request - Used to send a Data Message for transmission.

Start Request - Used to establish a link.

Stop Request - Used to release a link.

Retrieve BSNT Request - Request the BSNT for the changeover procedure.

Retrieval Request and FSNC - Request retrieval of unacknowledged and
unsent messages. This request includes the FSNC received from the
remote end.

Flush Buffers Request - Requests that all transmit and receive
buffers be emptied.

Continue Request - Requests that processing resume after a processor
outage.

Emergency Request - This is ignored by M2PA.

Emergency Ceases Request - This is ignored by M2PA.


Primitives sent from M2PA to MTP3:

Data Indication - Used to deliver received Data Message to MTP3.

George, et al                                                 [Page 9]


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


Congestion Indication - Indicates change in congestion level. The
indication includes the congestion level, if the protocol is using the
optional congestion levels.

In Service Indication - Indicates that the link is in service.

Out of Service Indication - Indicates that the link is out of service.

Retrieved Messages Indication - Indicates delivery of unacknowledged
and unsent messages.

Retrieval Complete Indication - Indicates that delivery of
unacknowledged and unsent messages is complete.

BSNT Confirm - Replies to the BSNT Request. The confirmation includes
the BSNT.

BSNT Not Retrievable Confirm - Replies to the BSNT Request when the
BSNT cannot be determined.

Remote Processor Outage Indication - Indicates processor outage at
remote end.

Remote Processor Recovered Indication - Indicates recovery from
processor outage at remote end.


1.8.2 Definition of the Lower Layer Boundary between M2PA and SCTP

The upper layer primitives provided by SCTP are described in Reference
[5] Section 10 "Interface with Upper Layer".


1.9 Differences Between M2PA and M2UA

The MTP2 User Adaptation Layer (M2UA) [6] also adapts the MTP3 layer
to the SCTP/IP stack. It does so through a backhauling architecture
[4]. This section intends to clarify some of the differences between
the M2PA and M2UA approaches.

A possible M2PA architecture is shown in Figure 3. Here the IPSP's
MTP3 uses its underlying M2PA as a replacement for
MTP2. Commmunication between the two layers MTP3/M2PA is defined by
the same primitives as in SS7 MTP3/MTP2. M2PA performs functions
similar to MTP2.

A comparable architecture for M2UA is shown in Figure 4. In M2UA, the
MGC's MTP3 uses the SG's MTP2 as its lower SS7 layer. In SS7,
commmunication between the MTP3 and MTP2 layers is defined by
primitives. In M2UA, the MTP3/MTP2 communication is defined as M2UA
messages and sent over the IP connection.

George, et al                                                [Page 10]


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


    ********  SS7   ***************   IP   ********
    * SEP  *--------*     SG      *--------* IPSP *
    ********        ***************        ********

    +------+        +-------------+        +------+
    | SCCP |        |    SCCP     |        | SCCP |
    +------+        +-------------+        +------+
    | MTP3 |        |    MTP3     |        | MTP3 | 
    +------+        +------+------+        +------+    
    | MTP2 |        | MTP2 | M2PA |        | M2PA |    
    +------+        +------+------+        +------+    
    | MTP1 |        | MTP1 | SCTP |        | SCTP | 
    |      |        |      +------+        +------+
    |      |        |      | IP   |        | IP   |
    +------+        +------+------+        +------+


         Figure 3:  M2PA in IP Signaling Gateway



    ********  SS7   ***************   IP   ********
    * SEP  *--------*     SG      *--------* MGC  *
    ********        ***************        ********

    +------+                               +------+
    | SCCP |                               | SCCP |
    +------+                               +------+
    | MTP3 |             (NIF)             | MTP3 | 
    +------+        +------+------+        +------+    
    | MTP2 |        | MTP2 | M2UA |        | M2UA |    
    +------+        +------+------+        +------+    
    | MTP1 |        | MTP1 | SCTP |        | SCTP | 
    |      |        |      +------+        +------+
    |      |        |      | IP   |        | IP   |
    +------+        +------+------+        +------+

       NIF   - Nodal Interworking Function


         Figure 4:  M2UA in IP Signaling Gateway











George, et al                                                [Page 11]


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

M2PA and M2UA are similar in that:

   a. Both transport MTP3 data messages.

   b. Both present an MTP2 upper interface to MTP3.

Differences between M2PA and M2UA include:

   a. M2PA: IPSP processes MTP3-to-MTP2 primitives.
      M2UA: MGC transports MTP3-to-MTP2 primitives to SG's MTP2 
            (via the NIF) for processing.

   b. M2PA: SG-IPSP connection is an SS7 link.
      M2UA: SG-MGC connection is not an SS7 link.

   c. M2PA: SG is an SS7 node with a point code.
      M2UA: SG is not an SS7 node and has no point code.

   d. M2PA: SG can have upper SS7 layers, e.g., SCCP.
      M2UA: SG does not have upper SS7 layers since it has no MTP3.

Potential users of M2PA and M2UA should be aware of these differences
when deciding how to use them for SS7 signaling transport over IP
networks.


2.  Protocol Elements

This section describes the format of various messages used in this 
protocol.

All fields in an M2PA message must be transmitted in the network byte
order, i.e., most significant byte first, unless otherwise stated.


2.1 Common Message Header

The protocol messages for M2PA 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 5.












George, et al                                                [Page 12]


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


    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 5:  Common Message Header


2.1.1  Version

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

      01   Release 1.0 of M2PA 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 M2PA Messages

The following section defines the messages and parameter contents.  An
M2PA message consists of a Common Message Header followed by the data
appropriate to the message.






George, et al                                                [Page 13]


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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                     Common Message Header                     |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                         Message Data                          |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.2.1 User Data 

The User Data is the data sent from the MTP3 in the form of the
contiguous LI, SIO, and SIF octets of the MSU ([2] Q.703, section 2.2
Signal Unit Format). The LI octet includes the two undefined bits
between the SIO and LI fields.

The format for the User 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                            Data                               |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


No padding is added to the MTP3 message.

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

Note: The two spare bits in the LI octet are used in a national
version of SS7 by MTP3 as a Priority field. See [9], section 14
"Common Characteristics of message signal unit formats", section 14.2
(A) Priority Indicator (PRI).


2.2.2  Link Status

The MTP2 Link Status message can be sent between M2PA peers to
indicate link status. This message performs a function similar to the
the Link Status Signal Unit in MTP2.






George, et al                                                [Page 14]


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


    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. 

    Value  Description

     1     In Service
     2     Processor Outage
     3     Processor Outage Ended
     4     Busy
     5     Busy Ended


3.  M2PA Link States

The M2PA link moves from one state to another in response to various
events.  The events that may result in a change of state include:

   - MTP3 primitive requests

   - SCTP notifications

   - Receipt of Status messages from the peer M2PA

   - Expiration of certain timers

Figure 6 illustrates state changes together with the causing events.
Note that some of the error conditions are not shown in the state
diagram.

Following is a list of the M2PA Link States and a description of each.

IDLE - State of link during power-up initialization.

OOS - Out Of Service. Power-up initialization is complete. 

AIP - Alignment In Progress. M2PA is attempting to establish SCTP
association.

INS-LOCAL - In Service Local. Association is established. M2PA is
waiting for peer to verify that it is In Service.

INS - In Service. Link is ready for traffic.

RETRIEVAL - Link no longer carries traffic. M2PA is waiting for
request for message retrieval from MTP3.

George, et al                                                [Page 15]


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


                           +-----------+
                           |   IDLE    |
                           +-----------+
                                 |
                                 | Power On
                                 |
                                 V
                           +-----------+
                  +------->|    OOS    |---------+
                  |        +-----------+         |
                  |              |               |
                  |              | Client AND    | Server AND
                  |              | MTP3 Start    | MTP3 Start
                  |              |               |
                  |              V               |
                  |        +-----------+         |
                  |        |    AIP    |<--------+
                  |        +-----------+
                  |              |                                
                  |              | SCTP 			     
                  |              | Communication Up		     
                  |              |                                
                  |              V                                
                  |        +-----------+			     
                  |        | INS-LOCAL |			     
                  |        +-----------+			     
                  |              |                                
                  |              | Link Status		     
                  |              | In Service received	     
                  |              |                                
                  |              V                                
                  |        +-----------+			     
                  |        |    INS    |			     
                  |        +-----------+			     
                  |              |                                
        Retrieval |              | MTP3 Stop                      
        Complete  |              | OR SCTP Communication Error    
                  |              | OR SCTP Communication Lost     
                  |              | OR T6 Expiration               
                  |              |                                
                  |              V                                
                  |        +-----------+                          
                  +--------| RETRIEVAL |
                           +-----------+


                Figure 6: M2PA Link State Transition Diagram.





George, et al                                                [Page 16]


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

4.  Procedures

4.1 Procedures to Support MTP2 Features

4.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 M2PA.


4.1.2 Link Alignment

Link alignment includes the establishment of an SCTP association and a
handshaking procedure between the M2PA peers to verify that the
association is ready to be used as a link.

To prevent duplicate associations from being established, it must be
decided in advance which endpoint initiates the establishment of the
association. In a pair of endpoints, the endpoint that initiates the
establishment of the association is called the client. The other
endpoint is the server. An endpoint may be a client in its
relationship with one endpoint, and a server in its relationship with
another endpoint. The designations of client and server are needed
only to decide which endpoint initiates the establishment of the
association. After that, the endpoints function as peers.

The client initiates the association using the server's IP address and
the M2PA well-known port number as the destination endpoint. In order
to allow for multiple links between the two endpoints, the client uses
a different local port number for each link. It must be decided in
advance which local ports are used by the client. Each of these client
ports must be known to the server. Each combination of client IP
address/port and server IP address/port must be mapped to the same
Signaling Link Code (SLC) in the client and server, so that each
endpoint knows which link is being created at the time the SCTP
association is established. However, M2PA does not do any processing
based on the SLC.

An example of the relationships between the associations and the SLCs
is shown in Figure 7 and Table 1. Note that a link is an SCTP
association identified by two endpoints, in this case a client and
server. Each endpoint is identified by an IP address and port
number. Each association is mapped to an SLC. Table 1 is only
conceptual. The actual method for mapping the SCTP associations to the
SLCs is implementation dependent.



George, et al                                                [Page 17]