draft-ietf-sigtran-m2pa-02.txt

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

services to its user as provided by MTP Level 2 to MTP Level 3.

George, et al                                                 [Page 7]


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


These services are described in the following subsections.

1.6.1 Support for MTP Level 2 / MTP Level 3 interface boundary

This interface is the same as the MTP2/MTP3 interface described in [2]
and [10], with the addition of support for larger sequence numbers in
[7].

Because SCTP uses larger sequence numbers than MTP, the MTP3
Changeover procedure must use the Extended Changeover Order and
Extended Changeover Acknowledgment messages described in [7]. This
will allow for use of the SCTP stream sequence numbers in the
changeover messages.

Also, the following MTP3/MTP2 primitives must use the larger sequence
numbers:

   - BSNT Indication

   - Retrieval Request and FSNC


1.6.2 Support for peer-to-peer communication

In SS7, MTP Level 2 sends three types of messages, known as signal
units: Message Signal Units (MSUs), Link Status Signal Units (LSSUs),
and Fill-In Signal Units (FISUs).

MSUs originate at a higher level than MTP2, and are destined for a
peer at another node. Likewise, M2PA passes these messages from MTP3
to SCTP as data for transport across a link. These are called User
Data messages in M2PA.

LSSUs allow peer MTP2 layers to exchange status information. Analogous
messages are needed for M2PA. The Link Status message serves this
purpose.

FISUs are sent when no other signal units are waiting to be sent. This
purpose is served by the heartbeat messages in SCTP. FISUs also carry
acknowledgment of messages. This function is performed by
SCTP. Therefore, it is unnecessary for M2PA to provide a protocol unit
like the FISU.

1.7 Functions Provided by M2PA

1.7.1 Support of MTP3/MTP2 Primitives

M2PA receives the primitives sent from MTP3 to its lower layer. M2PA
processes these primitives or maps them to appropriate primitives at
the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like
those used in the MTP3/MTP2 interface.

George, et al                                                 [Page 8]


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


1.7.2 MTP2 Functionality

M2PA provides MTP2 functionality that is not provided by SCTP. This
includes

   - Data retrieval to support the MTP3 changeover procedure

   - Reporting of link status changes to MTP3

   - Processor outage procedure

   - Link alignment procedure


1.7.3 Mapping of SS7 and IP Entities

For each IP link, the M2PA layer must maintain a map of the SS7 link
to its SCTP association and its corresponding IP destination.


1.7.4 SCTP Stream Management

SCTP allows a user-specified number of streams to be opened during the
initialization.  It is the responsibility of the M2PA layer to ensure
proper management of the streams allowed within each association.

M2PA uses two streams in each direction in each association. Stream 0
in each direction is designated for Link Status messages. Stream 1 is
designated for User Data messages. Separating the Link Status and User
Data messages onto separate stream allows M2PA to prioritize the
messages in a manner similar to MTP2.

 
1.7.5  Retention of MTP3 in the SS7 Network 

M2PA allows MTP3 to perform all of its Message Handling and Network
Management functions with IPSPs as with other SS7 nodes.


1.8 Definition of the M2PA Boundaries

1.8.1 Definition of the M2PA / MTP Level 3 boundary

The upper layer primitives provided by M2PA are the same as those
provided by MTP2 to MTP3. These primitives are described in [2] and
[10]. Following is a list of the primitives.

Primitives sent from MTP3 to M2PA:

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


George, et al                                                 [Page 9]


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

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.

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

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.


George, et al                                                [Page 10]


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


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

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


    ********  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 12]


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

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

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


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