rfc3331.txt

RFC 的详细文档！

   The upper layer and layer management primitives provided by SCTP are
   provided in Reference [8] Section 10.

1.6.4  Definition of Layer Management / M2UA Boundary

   M-SCTP_ESTABLISH request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to establish an SCTP association with an
            SGP.

   M-SCTP_ESTABLISH confirm
   Direction: M2UA -> LM
   Purpose: ASP confirms to LM that it has established an
            SCTP association with an SGP.

   M-SCTP_ESTABLISH indication
   Direction: M2UA -> LM
   Purpose: SGP informs LM that an ASP has established an SCTP
            association.

   M-SCTP_RELEASE request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to release an SCTP association with SGP.

   M-SCTP_RELEASE confirm
   Direction: M2UA -> LM
   Purpose: ASP confirms to LM that it has released SCTP association
            with SGP.

   M-SCTP_RELEASE indication
   Direction: M2UA -> LM
   Purpose: SGP informs LM that ASP has released an SCTP association.

   M-SCTP_RESTART indication
   Direction: M2UA -> LM
   Purpose: M2UA informs LM that a SCTP Restart indication has
            been received.

   M-SCTP_STATUS request
   Direction: LM -> M2UA
   Purpose: LM requests M2UA to report status of SCTP association.

   M-SCTP_STATUS indication
   Direction: M2UA -> LM
   Purpose: M2UA reports status of SCTP association.




Morneault, et. al.          Standards Track                    [Page 13]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


   M-ASP_STATUS request
   Direction: LM -> M2UA
   Purpose: LM requests SGP to report status of remote ASP.

   M-ASP_STATUS indication
   Direction: M2UA -> LM
   Purpose: SGP reports status of remote ASP.

   M-AS_STATUS request
   Direction: LM -> M2UA
   Purpose: LM requests SG to report status of AS.

   M-AS_STATUS indication
   Direction: M2UA -> LM
   Purpose: SG reports status of AS.

   M-NOTIFY indication
   Direction: M2UA -> LM
   Purpose: ASP reports that it has received a NOTIFY message
            from its peer.

   M-ERROR indication
   Direction: M2UA -> LM
   Purpose: ASP or SGP reports that it has received an ERROR
            message from its peer.

   M-ASP_UP request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to start its operation and send an ASP UP
            message to the SGP.

   M-ASP_UP confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that it has received an ASP UP Acknowledgment
            message from the SGP.

   M-ASP_DOWN request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to stop its operation and send an ASP DOWN
            message to the SGP.

   M-ASP_DOWN confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that is has received an ASP DOWN Acknowledgment
            message from the SGP.






Morneault, et. al.          Standards Track                    [Page 14]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


   M-ASP_ACTIVE request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP.

   M-ASP_ACTIVE confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that is has received an ASP ACTIVE
            Acknowledgment message from the SGP.

   M-ASP_INACTIVE request
   Direction: LM -> M2UA
   Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP.

   M-ASP_INACTIVE confirm
   Direction: M2UA -> LM
   Purpose: ASP reports that is has received an ASP INACTIVE
            Acknowledgment message from the SGP.

   M-LINK_KEY_REG Request
   Direction:  LM -> M2UA
   Purpose: LM requests ASP to register Link Key with SG by sending REG
            REQ message.

   M-LINK_KEY_REG Confirm
   Direction:   M2UA -> LM
   Purpose: ASP reports to LM that it has successfully received a REG
            RSP message from SG.

   M-LINK_KEY_REG Indication
   Direction:  M2UA -> LM
   Purpose:  SG reports to LM that it has successfully processed an
             incoming REG REQ message from ASP.

   M-LINK_KEY_DEREG Request
   Direction:  LM -> M2UA
   Purpose:  LM requests ASP to de-register Link Key with SG by sending
             DEREG REQ message.

   M-LINK_KEY_DEREG Confirm
   Direction:  M2UA -> LM
   Purpose:  ASP reports to LM that it has successfully received a
             DEREG RSP message from SG.

   M-LINK_KEY_DEREG  Indication
   Direction:  M2UA -> LM
   Purpose:  SG reports to LM that it has successfully processed an
             incoming DEREG REQ message from ASP.




Morneault, et. al.          Standards Track                    [Page 15]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


2.0 Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [RFC2119].

3.0  Protocol Elements

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

3.1  Common Message Header

   The protocol messages for MTP2-User Adaptation require a message
   structure that contains a version, message class, message type,
   message length, and message contents.  This message header is common
   among all signalling protocol adaptation layers:

    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 2  Common Message Header

   All fields in an M2UA message MUST be transmitted in the network byte
   order, unless otherwise stated.

3.1.1  Version

   The version field contains the version of the M2UA adaptation layer.
   The supported versions are:

         Value    Version
         -----    -------
           1      Release 1.0

3.1.2  Spare

   The Spare field is 8-bits.  It SHOULD be set to all '0's by the
   sender and ignored by the receiver.






Morneault, et. al.          Standards Track                    [Page 16]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


3.1.3  Message Class

   The following List contains the valid Message Classes:

   Message Class: 8 bits (unsigned integer)

     0      Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
     1      Transfer Messages [M3UA]
     2      SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
     3      ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
     4      ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
     5      Q.921/Q.931 Boundary Primitives Transport (QPTM)
            Messages [IUA]
     6      MTP2 User Adaptation (MAUP) Messages [M2UA]
     7      Connectionless Messages [SUA]
     8      Connection-Oriented Messages [SUA]
     9      Routing Key Management (RKM) Messages (M3UA)
    10      Interface Identifier Management (IIM) Messages (M2UA)
 11 to 127  Reserved by the IETF
128 to 255  Reserved for IETF-Defined Message Class extensions

3.1.4  Message Type

   The following List contains the Message Types for the valid Message
   Classes:

   MTP2 User Adaptation (MAUP) Messages

        0      Reserved
        1      Data
        2      Establish Request
        3      Establish Confirm
        4      Release Request
        5      Release Confirm
        6      Release Indication
        7      State Request
        8      State Confirm
        9      State Indication
       10      Data Retrieval Request
       11      Data Retrieval Confirm
       12      Data Retrieval Indication
       13      Data Retrieval Complete Indication
       14      Congestion Indication
       15      Data Acknowledge
    16 to 127  Reserved by the IETF
   128 to 255  Reserved for IETF-Defined MAUP extensions





Morneault, et. al.          Standards Track                    [Page 17]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


   Application Server Process State Maintenance (ASPSM) messages

        0      Reserved
        1      ASP Up (UP)
        2      ASP Down (DOWN)
        3      Heartbeat (BEAT)
        4      ASP Up Ack (UP ACK)
        5      ASP Down Ack (DOWN ACK)
        6      Heartbeat Ack (BEAT ACK)
     7 to 127  Reserved by the IETF
   128 to 255  Reserved for IETF-Defined ASPSM extensions

   Application Server Process Traffic Maintenance (ASPTM) messages

        0      Reserved
        1      ASP Active (ACTIVE)
        2      ASP Inactive (INACTIVE)
        3      ASP Active Ack (ACTIVE ACK)
        4      ASP Inactive Ack (INACTIVE ACK)
     5 to 127  Reserved by the IETF
   128 to 255  Reserved for IETF-Defined ASPTM extensions

   Management (MGMT) Messages

        0      Error (ERR)
        1      Notify (NTFY)
     2 to 127  Reserved by the IETF
   128 to 255  Reserved for IETF-Defined MGMT extensions

   Interface Identifier Management (IIM) Messages

        0        Reserved
        1        Registration Request (REG REQ)
        2        Registration Response (REG RSP)
        3        Deregistration Request (DEREG REQ)
        4        Deregistration Response (DEREG RSP)
     5 to 127    Reserved by the IETF
   128 to 255    Reserved for IETF-Defined IIM extensions

3.1.5  Message Length

   The Message Length defines the length of the message in octets,
   including the header.  The Message Length MUST include parameter
   padding bytes, if any.  The Message Length MUST NOT be longer than a
   MTP3 message [2,3,4,5] plus the length of the common and M2UA message
   headers.





Morneault, et. al.          Standards Track                    [Page 18]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


3.1.6  Variable-Length Parameter Format

   M2UA messages consist of a Common Header followed by zero or more
   variable-length parameters, as defined by the message type.  The
   variable-length parameters contained in a message are defined in a
   Tag-Length-Value format as shown below.