draft-ietf-sigtran-m2pa-03.txt

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


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 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/MTP2 primitives.
      M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
            and the MGC's MTP3 (via the NIF) for processing. 

   b. M2PA: SG-IPSP connection is an SS7 link.
      M2UA: SG-MGC connection is not an SS7 link. It is an 
            extension of MTP to a remote entity.

   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.

   e. M2PA: relies on MTP3 for management procedures.
      M2UA: uses M2UA management procedures.

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. The header
structure is shown in Figure 5.










George, et al                                                [Page 14]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 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 Class | Message Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5:  Common Message Header


2.1.1  Version

The version field contains the version of M2PA. The supported versions
are:

       Value    Version
       -----    -------
         1      Release 1.0 of M2PA protocol


2.1.2  Spare

The Spare field SHOULD be set to all zeroes (0's) by the sender and
ignored by the receiver. The Spare field SHOULD NOT be used for
proprietary information.


2.1.3  Message Class

The following List contains the valid Message Classes:

         Value    
       (decimal)  Message Class
       ---------  -------------
          11      M2PA Messages 

Other values are invalid for M2PA.


2.1.4  Message Type

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

       Value      Message Type
       -----      ------------
         1        User Data
         2        Link Status
         3        Proving Data

Other values are invalid.


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


2.1.4  Message Length

The Message Length defines the length of the message in octets, 
including the Common 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.


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


2.2.1 User Data 

The User Data is the data sent from MTP3. 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                               |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The Data field contains the following fields of the MTP Message Signal
Unit (MSU):

   - Length Indicator (LI), including the two undefined bits between
     the SIO and LI fields.
   - Service Information Octet (SIO)
   - Signaling Information Field (SIF)

The MTP MSU described in [2] Q.703, section 2.2 Signal Unit Format,
and [3] T1.111.3 section 2.2 Signal Unit Format. 

M2PA does not add padding to the MTP3 message. 



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

Note that the Data field SHALL NOT contain other components of the MTP
MSU format:

   - Flag
   - Backward Sequence Number (BSN)
   - Backward Indicator Bit (BIB)
   - Forward Sequence Number (FSN)
   - Forward Indicator Bit (FIB)
   - Check bits (CK) 

The Data field SHALL be transmitted in the byte order as defined by
MTP3. 

It is not necessary to put the message length in the LI octet as in
MTP2. The LI octet is included because the two spare bits in the LI
octet are used by MTP3 in at least one national version of SS7 to
carry MTP3 information. For example, the Japan TTC standard uses these
spare bits as an MTP3 Message Priority field. See [9], section 14
"Common Characteristics of message signal unit formats", section 14.2
(A) Priority Indicator (PRI). For versions of MTP that do not use
these two bits, the entire octet is spare.

Therefore in M2PA the format of the LI octet is:

    0               
    0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+
   |   spare   |PRI| (followed by SIO, SIF) 
   +-+-+-+-+-+-+-+-+

   PRI - Priority used only in national MTP defined in [9].
         Spare for other MTP versions.

Since the LI octet is not used for a message length, there is no need
to support the expanded LI field in [2], Q.703 Annex A. Therefore the
LI field in M2PA is always one octet.

Note: In the SS7 Recommendations, the format of the messages and
fields within the messages are based on bit transmission order.  In
these recommendations the Least Significant Bit (LSB) of each field is
positioned to the right.  The received SS7 fields are populated octet
by octet as received into the 4-octet word as shown below.

As an example, in the ANSI MTP protocol, the Data field format is
shown below:










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

   |MSB---------------------------------------------------------LSB|
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   spare   |PRI|      SIO      |   SIF octet   |      ...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                               :                               \                                   
   /                               :                               /
   \                               :                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ...      |      ...      |      ...      |   SIF octet   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Within each octet the Least Significant Bit (LSB) per the SS7
Recommendations is to the right (e.g., bit 15 of SIO is the LSB).


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. Except as modified later in this
section, the format for the Link Status 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            State                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The valid values for State are shown in the following table. 

         Value  
       (decimal)  Description
       ---------  -----------
           1      Alignment
           2      Proving Normal
           3      Proving Emergency
           4      Ready
           5      Processor Outage
           6      Processor Outage Ended
           7      Busy
           8      Busy Ended


2.2.3 Proving Data 

The Proving Data message is used during the proving period. The format
for the message is as follows.



George, et al                                                [Page 18]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...
   |                            Data                               |
                                 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


It is recommended that the length of the Data field be similar to the
size of the User Data messages that will be carried on the link.

It is recommended that the Data field contain a number pattern which
varies among the Proving Data messages, and that will allow the SCTP
checksum to be used to verify the accuracy of transmission.


3.  M2PA Link State Control

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 the link during power-up initialization.

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

AIP - Alignment In Progress. M2PA is attempting to exchange Alignment
messages with its peer.

PROVING - M2PA is sending Proving Data messages to its peer.

ALIGNED READY - Proving is complete. M2PA is waiting until peer
completes proving.

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 19]

Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer  July 2001

                              +-----------+
                              |   IDLE    |
                              +-----------+
                                    |
                                    | Power On
                                    |
                                    |   +--------------------------+
                                    |   |       (Associate)        |
                                    V   V                          |
                              +-----------+                        |
                      +------>|    OOS    |<--+                    |
                      |       +-----------+   | Link Configured    |
                      |             |   |     | (Associate)        |
                      |             |   +-----+                    |
                      |             |                              |
                      |             | MTP3 Start                   |
                      | MTP3 Stop   |                              |
                      |             V                              |
                      |       +-----------+                        |
                      +<------|    AIP    |----------------------->+
                      |       +-----------+     SCTP Comm Error    |
                      |             |        OR SCTP Comm Lost     |
                      |             |        OR T1 Expiry          |
                      |             |                              |
                      |             | Receive LS Alignment         |
                      |             |      OR LS Proving           |