tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3331

 
 
 

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

Part 2 of 5, p. 16 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 16 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part