rfc3332.txt

RFC 的详细文档！

   Direction: M3UA -> LM
   Purpose: M3UA reports that an AS has moved to the AS-ACTIVE state.

   M-AS_INACTIVE indication
   Direction: M3UA -> LM
   Purpose: M3UA reports that an AS has moved to the AS-INACTIVE state.

   M-AS_DOWN indication
   Direction: M3UA -> LM
   Purpose: M3UA reports that an AS has moved to the AS-DOWN state.

   If dynamic registration of RK is supported by the M3UA layer, the
   layer MAY support the following additional primitives:

   M-RK_REG request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to register RK(s) with its peer by sending
   REG REQ message



Sidebottom, et. al.         Standards Track                    [Page 24]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


   M-RK_REG confirm
   Direction: M3UA -> LM
   Purpose: ASP reports that it has received REG RSP message with
   registration status as successful from its peer.

   M-RK_REG indication
   Direction: M3UA -> LM
   Purpose: M3UA informs LM that it has successfully processed an
   incoming REG REQ message.

   M-RK_DEREG request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to deregister RK(s) with its peer by
   sending DEREG REQ message.

   M-RK_DEREG confirm
   Direction: M3UA -> LM
   Purpose: ASP reports that it has received DEREG REQ message with
   deregistration status as successful from its peer.

   M-RK_DEREG indication
   Direction: M3UA -> LM
   Purpose: M3UA informs LM that it has successfully processed an
   incoming DEREG REQ from its peer.

2. 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
   [20].

3. M3UA Protocol Elements

   The general M3UA message format includes a Common Message Header
   followed by zero or more parameters as defined by the Message Type.
   For forward compatibility, all Message Types may have attached
   parameters even if none are specified in this version.













Sidebottom, et. al.         Standards Track                    [Page 25]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


3.1 Common Message Header

   The protocol messages for MTP3-User Adaptation require a message
   header which contains the adaptation layer version, the message type,
   and message length.

      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    |   Reserved    | Message Class | Message Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Message Length                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                                                               /

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

3.1.1 M3UA Protocol Version: 8 bits (unsigned integer)

   The version field contains the version of the M3UA adaptation layer.

   The supported versions are the following:

         1      Release 1.0

3.1.2  Message Classes and Types

   The following list contains the valid Message Classes:

   Message Class: 8 bits (unsigned integer)

   The following list contains the valid Message Type Classes:

        0     Management (MGMT) Messages
        1     Transfer Messages
        2     SS7 Signalling Network Management (SSNM) Messages
        3     ASP State Maintenance (ASPSM) Messages
        4     ASP Traffic Maintenance (ASPTM) Messages
        5     Reserved for Other Sigtran Adaptation Layers
        6     Reserved for Other Sigtran Adaptation Layers
        7     Reserved for Other Sigtran Adaptation Layers
        8     Reserved for Other Sigtran Adaptation Layers
        9     Routing Key Management (RKM) Messages
       10 to 127 Reserved by the IETF
      128 to 255 Reserved for IETF-Defined Message Class extensions




Sidebottom, et. al.         Standards Track                    [Page 26]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


      Message Type: 8 bits (unsigned integer)

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

      Management (MGMT) Messages (See Section 3.8)

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

      Transfer Messages (See Section 3.3)

        0        Reserved
        1        Payload Data (DATA)
     2 to 127    Reserved by the IETF
   128 to 255    Reserved for IETF-Defined Transfer extensions

      SS7 Signalling Network Management (SSNM) Messages (See Section
      3.4)

        0        Reserved
        1        Destination Unavailable (DUNA)
        2        Destination Available (DAVA)
        3        Destination State Audit (DAUD)
        4        Signalling Congestion (SCON)
        5        Destination User Part Unavailable (DUPU)
        6        Destination Restricted (DRST)
     7 to 127    Reserved by the IETF
   128 to 255    Reserved for IETF-Defined SSNM extensions

      ASP State Maintenance (ASPSM) Messages (See Section 3.5)

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








Sidebottom, et. al.         Standards Track                    [Page 27]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


      ASP Traffic Maintenance (ASPTM) Messages (See Section 3.7)

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

      Routing Key Management (RKM) Messages (See Section 3.6)

        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 RKM extensions

3.1.3  Reserved: 8 bits

   The Reserved field SHOULD be set to all '0's and ignored by the
   receiver.

3.1.4  Message Length: 32-bits (unsigned integer)

   The Message Length defines the length of the message in octets,
   including the Common Header.  The Message Length MUST include
   parameter padding bytes, if any.

   Note: A receiver SHOULD accept the message whether or not the final
   parameter padding is included in the message length.


















Sidebottom, et. al.         Standards Track                    [Page 28]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


3.2 Variable Length Parameter Format

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

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Parameter Tag        |       Parameter Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                       Parameter Value                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where more than one parameter is included in a message, the
   parameters may be in any order, except where explicitly mandated.  A
   receiver SHOULD accept the parameters in any order.

   Parameter Tag: 16 bits (unsigned integer)

      The Tag field is a 16-bit identifier of the type of parameter. It
      takes a value of 0 to 65534.  Common parameters used by adaptation
      layers are in the range of 0x00 to 0x3f.   M3UA-specific
      parameters have Tags in the range 0x0200 to 0x02ff.  The parameter
      Tags defined are as follows:

      Common Parameters.  These TLV parameters are common across the
      different adaptation layers:

        Parameter Name                     Parameter ID
        ==============                     ============
        Reserved                              0x0000
        Not Used in M3UA                      0x0001
        Not Used in M3UA                      0x0002
        Not Used in M3UA                      0x0003
        INFO String                           0x0004
        Not Used in M3UA                      0x0005
        Routing Context                       0x0006
        Diagnostic Information                0x0007
        Not Used in M3UA                      0x0008
        Heartbeat Data                        0x0009
        Not Used in M3UA                      0x000a
        Traffic Mode Type                     0x000b
        Error Code                            0x000c
        Status                                0x000d



Sidebottom, et. al.         Standards Track                    [Page 29]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


        Not Used in M3UA                      0x000e
        Not Used in M3UA                      0x000f
        Not Used in M3UA                      0x0010
        ASP Identifier                        0x0011
        Affected Point Code                   0x0012
        Correlation ID                        0x0013

      M3UA-Specific parameters.  These TLV parameters are specific to
      the M3UA protocol:

        Network Appearance                    0x0200
        Reserved                              0x0201
        Reserved                              0x0202
        Reserved                              0x0203
        User/Cause                            0x0204
        Congestion Indications                0x0205
        Concerned Destination                 0x0206
        Routing Key                           0x0207
        Registration Result                   0x0208
        Deregistration Result                 0x0209
        Local_Routing Key Identifier          0x020a
        Destination Point Code                0x020b
        Service Indicators                    0x020c
        Reserved