Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3331

Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer

Pages: 94
Proposed Standard
Errata
Part 2 of 5 – Pages 16 to 38
First   Prev   Next

Top   ToC   RFC3331 - Page 16   prevText

3. 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.
Top   ToC   RFC3331 - Page 17

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
Top   ToC   RFC3331 - Page 18
   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.
Top   ToC   RFC3331 - Page 19

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. 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 / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mandatory parameters MUST be placed before optional parameters in a message. Parameter Tag: 16 bits (unsigned integer) The Type field is a 16 bit identifier of the type of parameter. It takes a value of 0 to 65534. The common parameters used by the adaptation layers are in the range of 0x00 to 0xff. The M2UA specific parameters have Tags in the range 0x300 to 0x3ff.
Top   ToC   RFC3331 - Page 20
   The common parameter tags (used by all User Adaptation layers) that
   M2UA uses are defined below:

      Parameter Value     Parameter Name
      ---------------     --------------
            0 (0x00)       Reserved
            1 (0x01)       Interface Identifier (Integer)
            2 (0x02)       Unused
            3 (0x03)       Interface Identifier (Text)
            4 (0x04)       Info String
            5 (0x05)       Unused
            6 (0x06)       Unused
            7 (0x07)       Diagnostic Information
            8 (0x08)       Interface Identifier (Integer Range)
            9 (0x09)       Heartbeat Data
           10 (0x0a)       Unused
           11 (0x0b)       Traffic Mode Type
           12 (0x0c)       Error Code
           13 (0x0d)       Status Type/Information
           14 (0x0e)       Unused
           15 (0x0f)       Unused
           16 (0x10)       Unused
           17 (0x11)       ASP Identifier
           18 (0x12)       Unused
           19 (0x13)       Correlation Id
          18-255           Reserved
Top   ToC   RFC3331 - Page 21
   The M2UA specific parameter Tags defined are as follows:

      Parameter Value     Parameter Name
      ---------------     --------------
        768 (0x0300)      Protocol Data 1
        769 (0x0301)      Protocol Data 2 (TTC)
        770 (0x0302)      State Request
        771 (0x0303)      State Event
        772 (0x0304)      Congestion Status
        773 (0x0305)      Discard Status
        774 (0x0306)      Action
        775 (0x0307)      Sequence Number
        776 (0x0308)      Retrieval Result
        777 (0x0309)      Link Key
        778 (0x030a)      Local-LK-Identifier
        779 (0x030b)      Signalling Data Terminal (SDT) Identifier
        780 (0x030c)      Signalling Data Link (SDL) Identifier
        781 (0x030d)      Registration Result
        782 (0x030e)      Registration Status
        783 (0x030f)      De-Registration Result
        784 (0x0310)      De-Registration Status

   Parameter Length: 16 bits (unsigned integer)

   The Parameter Length field contains the size of the parameter in
   bytes, including the Parameter Tag, Parameter Length, and Parameter
   Value fields.  Thus, a parameter with a zero-length Parameter Value
   field would have a Length field of 4.  The Parameter Length does not
   include any padding bytes.

   Parameter Value: variable-length.

   The Parameter Value field contains the actual information to be
   transferred in the parameter.

   The total length of a parameter (including Tag, Parameter Length and
   Value fields) MUST be a multiple of 4 bytes.  If the length of the
   parameter is not a multiple of 4 bytes, the sender pads the Parameter
   at the end (i.e., after the Parameter Value field) with all zero
   bytes.  The length of the padding is NOT included in the parameter
   length field.  A sender MUST NOT pad with more than 3 bytes.  The
   receiver MUST ignore the padding bytes.
Top   ToC   RFC3331 - Page 22

3.2 M2UA Message Header

In addition to the common message header, there will be a M2UA specific message header. The M2UA specific message header will immediately follow the common message header, but will only be used with MAUP messages. This message header will contain the Interface Identifier. The Interface Identifier identifies the physical interface at the SG for which the signalling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP. The integer formatted Interface Identifier MUST be supported. The text formatted Interface Identifier MAY optionally be supported. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1) | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 M2UA Message Header (Integer-based Interface Identifier) The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Interface Identifier (text) / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 M2UA Message Header (Text-based Interface Identifier) The Tag value for the Text-based Interface Identifier is 0x3. The encoding of the Identifier is ANSI X3.4-1986 [7]. The maximum string length of the text-based Interface Identifier is 255 octets. The tag length is equal to the string length of the Interface Identifier name plus four bytes for the Tag and Length fields.
Top   ToC   RFC3331 - Page 23

3.3 M2UA Messages

The following section defines the messages and parameter contents. The M2UA messages will use the common message header (Figure 2) and the M2UA message header (Figure 3 and Figure 4).

3.3.1 MTP2 User Adaptation Messages

3.3.1.1 Data
The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The Data message contains the following parameter: Protocol Data (mandatory) Correlation Id (optional) The format for the Data Message parameters 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Protocol Data / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x13) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol Data field contains the MTP2-User application message in network byte order starting with the Signalling Information Octet (SIO). The Correlation Id parameter uniquely identifies the MSU carried in the Protocol Data within an AS. This Correlation Id parameter is assigned by the sending M2UA. The purpose of the Correlation Id is to permit the newly active ASP to synchronize its processing of the traffic in each ordered stream with other ASPs in the broadcast group.
Top   ToC   RFC3331 - Page 24
   The format for a Data Message with TTC PDU parameters 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x301)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               \
   \                    TTC Protocol Data                          /
   /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x13)           |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Correlation Id                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Protocol Data field contains the MTP2-User application message in
   network byte order starting with the Length Indicator (LI) octet.
   The Japanese TTC variant uses the spare bits of the LI octet for
   priority.

   The length of the Protocol Data and TTC Protocol Data MUST NOT exceed
   the length of a MTP2-User application message [2,3,5].

3.3.1.2 Data Acknowledge Message
The Data Acknowledge message contains the Correlation Id of the Data message that the sending M2UA is acknowledging as successfully processed to the peer M2UA. The Data Acknowledge message contains the following parameter: Correlation Id Mandatory The following format MUST be used for the Data Ack Message: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x13) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Correlation Id parameter of the Data message and the Data Ack message provide a mechanism, for those SG implementations capable of taking advantage of them, to obtain an acknowledgment that the MSU has been transferred to the M2UA peer before acknowledging the MSU to
Top   ToC   RFC3331 - Page 25
   the SS7 peer, removing the risk of losing messages due to association
   failure or SCTP congestion.

   The Data Ack message MUST be sent if a Correlation Id parameter is
   received from the peer.  Otherwise, the Data Ack message MUST NOT be
   sent.

   If the Data Acknowledge is not sent for Correlation Id(s) or is sent
   with Invalid Correlation Id(s), the SS7 link will eventually fail due
   to lack of MTP Level 2 acknowledgments of the SS7 peer's MSUs.

3.3.1.3 Establish (Request, Confirmation)
The Establish Request message is used to establish the SS7 link or to indicate that the channel has been established. The MGC controls the state of the SS7 link. When the MGC desires the SS7 link to be in- service, it will send the Establish Request message. Note that the SGP MAY already have the SS7 link established at its layer. If so, upon receipt of an Establish Request, the SGP takes no action except to send an Establish Confirm. When the MGC sends an M2UA Establish Request message, the MGC MAY start a timer. This timer would be stopped upon receipt of an M2UA Establish Confirm. If the timer expires, the MGC would resend the M2UA Establish Request message and restart the timer. In other words, the MGC MAY continue to request the establishment of the data link on a periodic basis until the desired state is achieved or some other action is taken (notify the Management Layer). The mode (Normal or Emergency) for bringing the SS7 link in service is defaulted to Normal. The State Request (described in Section 3.3.1.5 below) can be used to change the mode to Emergency.
3.3.1.4 Release (Request, Indication, Confirmation)
This Release Request message is used to release the channel. The Release Confirm and Indication messages are used to indicate that the channel has been released.
3.3.1.5 State Request
The State Request message can be sent from a MGC to cause an action on a particular SS7 link supported by the Signalling Gateway Process. The SGP sends a State Confirm to the MGC if the action has been successfully completed. The State Confirm reflects that state value received in the State Request message.
Top   ToC   RFC3331 - Page 26
   The State Request message contains the following parameter:

    State (mandatory)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x302)           |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             State                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            Define           Value        Description
      STATUS_LPO_SET          0x0      Request local processor outage
      STATUS_LPO_CLEAR        0x1      Request local processor outage
                                       recovered
      STATUS_EMER_SET         0x2      Request emergency alignment
      STATUS_EMER_CLEAR       0x3      Request normal alignment (cancel
                                       emergency)
      STATUS_FLUSH_BUFFERS    0x4      Flush or clear receive, transmit
                                       and retransmit queues
      STATUS_CONTINUE         0x5      Continue or Resume
      STATUS_CLEAR_RTB        0x6      Clear the retransmit queue
      STATUS_AUDIT            0x7      Audit state of link
      STATUS_CONG_CLEAR       0x8      Congestion cleared
      STATUS_CONG_ACCEPT      0x9      Congestion accept
      STATUS_CONG_DISCARD     0xa      Congestion discard

3.3.1.6 State Confirm
The State Confirm message will be sent by the SGP in response to a State Request from the MGC. The State Confirm reflects that state value received in the State Request message. The State Confirm message contains the following parameter: State (mandatory) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x302) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC3331 - Page 27
   The valid values for State are shown in the following table.  The
   value of the State field SHOULD reflect the value received in the
   State Request message.

            Define           Value        Description
      STATUS_LPO_SET          0x0      Request local processor outage
      STATUS_LPO_CLEAR        0x1      Request local processor outage
                                       recovered
      STATUS_EMER_SET         0x2      Request emergency alignment
      STATUS_EMER_CLEAR       0x3      Request normal alignment (cancel
                                       emergency)
      STATUS_FLUSH_BUFFERS    0x4      Flush or clear receive, transmit
                                       and retransmit queues
      STATUS_CONTINUE         0x5      Continue or Resume
      STATUS_CLEAR_RTB        0x6      Clear the retransmit queue
      STATUS_AUDIT            0x7      Audit state of link
      STATUS_CONG_CLEAR       0x8      Congestion cleared
      STATUS_CONG_ACCEPT      0x9      Congestion accept
      STATUS_CONG_DISCARD     0xa      Congestion discard

3.3.1.7 State Indication
The MTP2 State Indication message can be sent from a SGP to an ASP to indicate a condition on a SS7 link. The State Indication message contains the following parameter: Event (mandatory) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x303) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for Event are shown in the following table. Define Value Description EVENT_RPO_ENTER 0x1 Remote entered processor outage EVENT_RPO_EXIT 0x2 Remote exited processor outage EVENT_LPO_ENTER 0x3 Link entered processor outage EVENT_LPO_EXIT 0x4 Link exited processor outage
Top   ToC   RFC3331 - Page 28
3.3.1.8 Congestion Indication
The Congestion Indication message can be sent from a Signalling Gateway Process to an ASP to indicate the congestion status and discard status of a SS7 link. When the MSU buffer fill increases above an Onset threshold or decreases below an Abatement threshold or crosses a Discard threshold in either direction, the SGP SHALL send a congestion indication message when it supports SS7 MTP2 variants that support multiple congestion levels. The SGP SHALL send the message only when there is actually a change in either the discard level or the congestion level to report, meaning it is different from the previously sent message. In addition, the SGP SHALL use an implementation dependent algorithm to limit the frequency of congestion indication messages. An implementation may optionally send Congestion Indication messages on a "high priority" stream in order to potentially reduce delay. The Congestion Indication message contains the following parameters: Congestion Status (mandatory) Discard Status (optional) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x304) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x305) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discard Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for Congestion Status and Discard Status are shown in the following table. Define Value Description LEVEL_NONE 0x0 No congestion LEVEL_1 0x1 Congestion Level 1 LEVEL_2 0x2 Congestion Level 2 LEVEL_3 0x3 Congestion Level 3
Top   ToC   RFC3331 - Page 29
   For SS7 networks that do not support multiple levels of congestion,
   only the LEVEL_NONE and LEVEL_3 values will be used.  For SS7
   networks that support multiple levels of congestion, it is possible
   for all values to be used.  Refer to [2], [3] and [12] for more
   details on the Congestion and Discard Status of SS7 signalling links.

3.3.1.9 Retrieval Request
The MTP2 Retrieval Request message is used during the MTP Level 3 changeover procedure to request the BSN, to retrieve PDUs from the transmit and retransmit queues or to flush PDUs from the retransmit queue. Examples of the use of Retrieval Request for SS7 Link Changeover are provided in Section 5.3.6. The Retrieval Request message contains the following parameters: Action (mandatory) Sequence Number (optional) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x306) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x307) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for Action are shown in the following table. Define Value Description ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit and retransmit queues In the Retrieval Request message, the Sequence Number field SHOULD NOT be present if the Action field is ACTION_RTRV_BSN. The Sequence Number field contains the Forward Sequence Number (FSN) of the far end if the Action is ACTION_RTRV_MSGS.
Top   ToC   RFC3331 - Page 30
3.3.1.10 Retrieval Confirm
The MTP2 Retrieval Confirm message is sent by the Signalling Gateway in response to a Retrieval Request message. Examples of the use of the Retrieval Confirm for SS7 Link Changeover are provided in Section 5.3.6. The Retrieval Confirm message contains the following parameters: Action (mandatory) Result (mandatory) Sequence Number (optional) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x306) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x308) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x307) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for Action are the same as in Retrieval Request. The values for Result are shown below: Define Value Description RESULT_SUCCESS 0x0 Action successful RESULT_FAILURE 0x1 Action failed When the Signalling Gateway Process sends a Retrieval Confirm to a Retrieval Request, it echos the Action field. If the Action was ACTION_RTRV_BSN and the SGP successfully retrieved the BSN, the SGP will put the Backward Sequence Number (BSN) in the Sequence Number field and will indicate a success in the Result field. If the BSN could not be retrieved, the Sequence Number field will not be included and the Result field will indicate failure.
Top   ToC   RFC3331 - Page 31
   For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of
   the Result field will indicate success or failure.  A failure means
   that the buffers could not be retrieved.  The Sequence Number field
   is not used with ACTION_RTRV_MSGS.

3.3.1.11 Retrieval Indication
The Retrieval Indication message is sent by the Signalling Gateway with a PDU from the transmit or retransmit queue. The Retrieval Indication message does not contain the Action or Sequence Number fields, just a MTP3 Protocol Data Unit (PDU) from the transmit or retransmit queue. Examples of the use of the Retrieval Indication for SS7 Link Changeover are provided in Section 5.3.6. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ Protocol Data / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For TTC Data messages, the following parameter will be used to indicate a TTC PDU which starts at LI. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x301) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ TTC Protocol Data / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The M2UA implementation MAY consider the use of the bundling feature of SCTP for Retrieval Indication messages.
3.3.1.12 Retrieval Complete Indication
The MTP2 Retrieval Complete Indication message is exactly the same as the MTP2 Retrieval Indication message except that it also indicates that retrieval is complete. In addition, it MAY contain a PDU (which MUST be the last PDU) from the transmit or retransmit queue.
Top   ToC   RFC3331 - Page 32

3.3.2 Application Server Process Maintenance (ASPM) Messages

The ASPM messages will only use the common message header.
3.3.2.1 ASP Up (ASPUP)
The ASP Up (ASPUP) message is used to indicate to a remote M2UA peer that the Adaptation layer is ready to receive traffic or maintenance messages. The ASPUP message contains the following parameters ASP Identifier (optional) Info String (optional) Note: The ASP Identifier MUST be used where the SGP cannot identify the ASP by pre-configured address/port number information (e.g., where an ASP is resident on a Host using dynamic address/port number assignment). The format for ASPUP Message parameters 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x11) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The optional ASP Identifier parameter would contain a unique value that is locally significant among the ASPs that support an AS. The SGP should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.3.3.2). The optional INFO String parameter can carry any meaningful UTF-8 [6] character string along with the message. Length of the INFO String parameter is from 0 to 255 octets. No procedures are presently identified for its use but the INFO String MAY be used for debugging purposes.
Top   ToC   RFC3331 - Page 33
3.3.2.2 ASP Up Ack
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote M2UA peer. The ASPUP Ack message contains the following parameters: INFO String (optional) The format for ASPUP Ack Message parameters 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the ASP UP message (See Section 3.3.2.1).
3.3.2.3 ASP Down (ASPDN)
The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer that the adaptation layer is not ready to receive traffic or maintenance messages. The ASPDN message contains the following parameters INFO String (optional) The format for the ASPDN message parameters 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the ASP Up message (See Section 3.3.2.1).
Top   ToC   RFC3331 - Page 34
3.3.2.4 ASP Down Ack
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M2UA peer. The ASP Down Ack message contains the following parameters: INFO String (optional) The format for the ASPDN Ack message parameters 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ INFO String* / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the ASP UP message (See Section 3.3.2.1).
3.3.2.5 Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the M2UA peers are still available to each other. The BEAT message contains the following parameter: Heartbeat Data Optional The format for the BEAT 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0009 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Heartbeat Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The sending node defines the Heartbeat Data field contents. It may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details.
Top   ToC   RFC3331 - Page 35
   The receiver of a Heartbeat message does not process this field as it
   is only of significance to the sender.  The receiver echoes the
   content of the Heartbeat Data in a BEAT ACK message.

3.3.2.6 Heartbeat Ack (BEAT ACK)
The Heartbeat ACK message is sent in response to a BEAT message. A peer MUST send a BEAT ACK in response to a BEAT message. It includes all the parameters of the received Heartbeat message, without any change. The BEAT ACK message contains the following parameter: Heartbeat Data Optional The format for the BEAT ACK 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0009 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Heartbeat Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The sending node defines the Heartbeat Data field contents. It may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details. The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver echoes the content of the Heartbeat Data in a BEAT ACK message.
3.3.2.7 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SGP that it is Active and ready to be used. The ASPAC message contains the following parameters: Traffic Mode Type (optional) Interface Identifier (optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (optional)
Top   ToC   RFC3331 - Page 36
   The format for the ASPAC message using integer formatted Interface
   Identifiers 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xb)           |            Length = 8         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic Mode Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Tag (0x1=integer)         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               \
   \                     Interface Identifiers*                    /
   /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Tag (0x8=integer range)    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Interface Identifier Start1*                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Interface Identifier Stop1*                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Interface Identifier Start2*                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Interface Identifier Stop2*                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                            .
     .                                                            .
     .                                                            .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Interface Identifier StartN*                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Interface Identifier StopN*                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               \
   \              Additional Interface Identifiers                 /
   /                    of Tag Type 0x1 or 0x8                     \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               \
   \                          INFO String*                         /
   /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC3331 - Page 37
   The format for the ASPAC message using text formatted (string)
   Interface Identifiers 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xb)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic Mode Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tag (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               \
   \                     Interface Identifier*                     /
   /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               \
   \              Additional Interface Identifiers                 /
   /                       of Tag Type 0x3                         \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               \
   \                          INFO String*                         /
   /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Traffic Mode Type parameter identifies the traffic mode of
   operation of the ASP within an AS.  The valid values for Type are
   shown in the following table:

      Value          Description
       0x1            Override
       0x2            Load-share
       0x3            Broadcast

   Within a particular AS, only one Traffic Mode Type can be used.  The
   Override value indicates that the ASP is operating in Override mode,
   where the ASP takes over all traffic in an Application Server (i.e.,
   primary/backup operation), over-riding any currently active ASPs in
   the AS.  In Load-share mode, the ASP will share in the traffic
   distribution with any other currently active ASPs.  In Broadcast
   mode, all of the Active ASPs receive all message traffic in the
   Application Server.
Top   ToC   RFC3331 - Page 38
   The optional Interface Identifiers parameter contains a list of
   Interface Identifier integers (Type 0x1 or Type 0x8) or text strings
   (Type 0x3)indexing the Application Server traffic that the sending
   ASP is configured/registered to receive.  If integer formatted
   Interface Identifiers are being used, the ASP can also send ranges of
   Interface Identifiers (Type 0x8).  Interface Identifier types Integer
   (0x1) and Integer Range (0x8) are allowed in the same message.  Text
   formatted Interface Identifiers (0x3) cannot be used with either
   Integer (0x1) or Integer Range (0x8) types.

   If no Interface Identifiers are included, the message is for all
   provisioned Interface Identifiers within the AS(s) in which the ASP
   is provisioned.  If only a subset of Interface Identifiers for an AS
   are included, the ASP is noted as Active for all the Interface
   Identifiers provisioned for that AS.

   Note: If the optional Interface Identifier parameter is present, the
         integer formatted Interface Identifier MUST be supported, while
         the text formatted Interface Identifier MAY be supported.

   An SGP that receives an ASPAC with an incorrect or unsupported
   Traffic Mode Type for a particular Interface Identifier will respond
   with an Error Message (Cause: Unsupported Traffic Handling Mode).

   The format and description of the optional Info String parameter is
   the same as for the ASP UP message (See Section 3.3.2.1).



(page 38 continued on part 3)

Next Section