Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4233

Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer

Pages: 73
Proposed Standard
Obsoletes:  3057
Updated by:  5133
Part 2 of 3 – Pages 15 to 45
First   Prev   Next

Top   ToC   RFC4233 - Page 15   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 Q.921-User Adaptation require a message header that 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Common Header Format All fields in an IUA message MUST be transmitted in the network byte order, unless otherwise stated.

3.1.1. Version

The version field contains the version of the IUA adaptation layer. The supported versions are the following: Value Version ----- ------- 1 Release 1.0
Top   ToC   RFC4233 - Page 16

3.1.2. Message Classes and Types

The following list contains the valid Message Classes: Message Class: 8 bits (unsigned integer) 0 Management (MGMT) Message 1 Reserved for Other SIGTRAN Adaptation Layer 2 Reserved for Other SIGTRAN Adaptation Layers 3 ASP State Maintenance (ASPSM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages 6 Reserved for Other SIGTRAN Adaptation Layer 7 Reserved for Other SIGTRAN Adaptation Layer 8 Reserved for Other SIGTRAN Adaptation Layer 9 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined Message Class extensions The following list contains the message names for the defined messages. Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages 0 Reserved 1 Data Request Message 2 Data Indication Message 3 Unit Data Request Message 4 Unit Data Indication Message 5 Establish Request 6 Establish Confirm 7 Establish Indication 8 Release Request 9 Release Confirm 10 Release Indication 11 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined QPTM extensions 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 Heatbeat Ack (BEAT ACK) 7 to 127 Reserved by the IETF 128 to 255 Reserved for IETF-Defined ASPSM extensions
Top   ToC   RFC4233 - Page 17
    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        TEI Status Request
       3        TEI Status Confirm
       4        TEI Status Indication
       5        TEI Query Request
     6 to 127   Reserved by the IETF
   128 to 255   Reserved for IETF-Defined MGMT extensions

3.1.3. Reserved

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

3.1.4. Message Length

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.

3.1.5. Variable-Length Parameter Format

IUA 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 Type-Length-Value (TLV) format as shown below.
Top   ToC   RFC4233 - Page 18
    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 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.  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
   Interface Identifier (integer)        0x0001
   Not Used in IUA                       0x0002
   Interface Identifier (text)           0x0003
   INFO String                           0x0004
   DLCI                                  0x0005
   Not Used in IUA                       0x0006
   Diagnostic Information                0x0007
   Interface Identifier Range            0x0008
   Heartbeat Data                        0x0009
   Not Used in IUA                       0x000a
   Traffic Mode Type                     0x000b
   Error Code                            0x000c
   Status                                0x000d
   Protocol Data                         0x000e
   Release Reason                        0x000f
   TEI Status                            0x0010
   ASP Identifier                        0x0011
   Not Used in IUA                       0x0012 - 0x003f

   The value of 65535 is reserved for IETF-defined extensions.  Values
   other than those defined in specific parameter description are
   reserved for use by the IETF.
Top   ToC   RFC4233 - Page 19
   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.  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 SHOULD NEVER pad with more than 3 bytes.  The
   receiver MUST ignore the padding bytes.

3.2. IUA Message Header

In addition to the common message header, there will be a specific message header for QPTM and the TEI Status MGMT messages. The IUA message header will immediately follow the Common header in these messages. This message header will contain the Interface Identifier and Data Link Connection Identifier (DLCI). The Interface Identifier identifies the physical interface terminating the signaling channel at the SG for which the signaling messages are sent/received. The format of the Interface Identifier parameter can be text or integer. The Interface Identifiers are assigned according to network operator policy. The integer 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.
Top   ToC   RFC4233 - Page 20
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Interface Identifier (integer)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x5)           |             Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DLCI               |              Spare            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3.  IUA 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)                 \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x5)           |             Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DLCI               |             Spare             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4.  IUA Message Header (Text-based Interface Identifier)

   The Tag value for the Text-based [2] Interface Identifier is 0x3.
   The length is variable.

   The DLCI format is shown below in Figure 5.

        most                                     least
     significant                              significant
         bit                                      bit
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |            SAPI                   | SPR |  0  |
      +-----------------------------------------------+
      |            TEI                          |  1  |
      +-----------------------------------------------+

                          Figure 5.  DLCI Format
Top   ToC   RFC4233 - Page 21
   SPR:  Spare 2nd bit in octet 1 (1 bit)

   SAPI: Service Access Point Identifier (6 bits)

   TEI:  Terminal Endpoint Identifier (7 bits)

   As an example, SAPI = 0, TEI = 64, SPR = 0 would be encoded as
   follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x5)           |             Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x0      |      0x81     |               0x0             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The DLCI field (including the SAPI and TEI) is coded in accordance
   with Q.921.

3.3. IUA Messages

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

3.3.1. Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages

3.3.1.1. Establish Messages (Request, Confirm, Indication)
The Establish Messages are used to establish a data link on the signaling channel or to confirm that a data link on the signaling channel has been established. The MGC controls the state of the D channel. When the MGC desires the D channel to be in-service, it will send the Establish Request message. When the MGC sends an IUA Establish Request message, the MGC MAY start a timer. This timer would be stopped upon receipt of an IUA Establish Confirm or Establish Indication. If the timer expires, the MGC would resend the IUA 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 take some other action (notify the Management Layer). When the SG receives an IUA Establish Request from the MGC, the SG shall send the Q.921 Establish Request primitive to the Q.921 entity. In addition, the SG shall map any response received from the Q.921 entity to the appropriate message to the MGC. For example, if the Q.921 entity responds with a Q.921 Establish Confirm primitive, the
Top   ToC   RFC4233 - Page 22
   IUA layer shall map this to an IUA Establish Confirm message.  As
   another example, if the IUA Layer receives a Q.921 Release Confirm or
   Release Indication as an apparent response to the Q.921 Establish
   Request primitive, the IUA Layer shall map these to the corresponding
   IUA Release Confirm or Release Indication messages.

   The Establish messages contain the common message header followed by
   IUA message header.  It does not contain any additional parameters.

3.3.1.2. Release Messages (Request, Indication, Confirmation)
The Release Request message is used to release the data link on the signaling channel. The Release Confirm and Indication messages are used to indicate that the data link on the signaling channel has been released. If a response to the Release Request message is not received, the MGC MAY resend the Release Request message. If no response is received, the MGC can consider the data link as being released. In this case, signaling traffic on that D channel is not expected from the SG and signaling traffic will not be sent to the SG for that D channel. The Release messages contain the common message header followed by IUA message header. The Release Confirm message is in response to a Release Request message and it does not contain any additional parameters. The Release Request and Indication messages contain the following parameter: Reason The format for Release 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 (0xf) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4233 - Page 23
   The valid values for Reason are shown in the following table.

      Define     Value           Description
   RELEASE_MGMT   0x0     Management layer generated release.
   RELEASE_PHYS   0x1     Physical layer alarm generated release.
   RELEASE_DM     0x2     Specific to a request.  Indicates Layer 2
                          SHOULD release and deny all requests from
                          far end to establish a data link on the
                          signaling channel (i.e., if SABME is
                          received, send a DM)
   RELEASE_OTHER  0x3     Other reasons

   Note:  Only RELEASE_MGMT, RELEASE_DM, and RELEASE_OTHER are valid
   reason codes for a Release Request message.

3.3.1.3. Data Messages (Request, Indication)
The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to acknowledged information transfer service. The Data messages contain the common message header followed by IUA message header. The Data message contains the following parameter: Protocol Data The format for 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 (0xe) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Protocol Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The protocol data contains upper layer signaling message, e.g., Q.931, QSIG.
3.3.1.4. Unit Data Messages (Request, Indication)
The Unit Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to unacknowledged information transfer service. The Unit Data messages contain the common message header followed by IUA message header. The Unit Data message contains the following parameter:
Top   ToC   RFC4233 - Page 24
       Protocol Data

   The format for Unit 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 (0xe)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                        Protocol Data                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.2. Application Server Process Maintenance (ASPM) Messages

The ASPM messages will use only the common message header.
3.3.2.1. ASP Up (ASPUP)
The ASP Up (ASPUP) message is sent by an ASP to indicate to an SG that it is ready to receive traffic or maintenance messages. The ASPUP message contains the following parameters: ASP Identifier (Optional) INFO String (Optional) 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 = 0x0011 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASP Identifier: 32-bit unsigned integer
Top   ToC   RFC4233 - Page 25
   The optional ASP Identifier parameter contains a unique value that is
   locally significant among the ASPs that support an AS.  The SG 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 8-bit
   ASCII [2] character string along with the message.  Length of the
   INFO String parameter is from 0 to 255 characters.  No procedures are
   presently identified for its use, but the INFO String MAY be used for
   debugging purposes.

3.3.2.2. ASP Up Ack
The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote IUA 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 = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional INFO String parameter are 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 sent by an ASP to indicate to an SG that it is NOT ready to receive traffic or maintenance messages. The ASPDN message contains the following parameters: INFO String (Optional)
Top   ToC   RFC4233 - Page 26
   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 = 0x0004          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format and description of the optional INFO String parameter are
   the same as for the ASP Up message (see Section 3.3.2.1).

3.3.2.4. ASP Down Ack
The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer. The ASP Down Ack message contains the following parameters: INFO String (Optional) The format for the ASP Down 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 = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1).
3.3.2.5. ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SG that it is Active and ready to be used.
Top   ToC   RFC4233 - Page 27
   The ASPAC message contains the following parameters:

      Traffic Mode Type (Mandatory)
      Interface Identifiers (Optional)
         - Combination of integer and integer ranges, OR
         - string (text-formatted)
      INFO String (Optional)
Top   ToC   RFC4233 - Page 28
   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 = 0x000b          |           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 Identifier Parameters         /
   \                  of Tag Type 0x1 or 0x8                       \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4233 - Page 29
   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 = 0x000b          |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic Mode Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tag (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                     Interface Identifiers                     /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /           Additional Interface Identifier Parameters          /
   \                      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            Over-ride
      0x2            Load-share

   Within a particular AS, only one Traffic Mode Type can be used.  The
   Over-ride value indicates that the ASP is operating in Over-ride
   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.

   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
Top   ToC   RFC4233 - Page 30
   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 or ASes in which the
   ASP is provisioned.  If only a subset of Interface Identifiers is
   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, whereas the
   text-formatted Interface Identifier MAY be supported.

   The format and description of the optional INFO String parameter are
   the same as for the ASP Up message (see Section 3.3.2.1.).

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

3.3.2.6. ASP Active Ack
The ASPAC Ack message is used to acknowledge an ASP Active message received from a remote IUA peer. The ASPAC Ack message contains the following parameters: Traffic Mode Type (Mandatory) Interface Identifier (Optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (Optional)
Top   ToC   RFC4233 - Page 31
   The format for the ASPAC Ack message with 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 = 0x000b          |           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 Identifier Parameters         /
   \                  of Tag Type 0x1 or 0x8                       \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4233 - Page 32
   The format for the ASP Active Ack 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 = 0x000b          |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic Mode Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tag (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                     Interface Identifiers                     /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /           Additional Interface Identifier Parameters          /
   \                      of Tag Type 0x3                          \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the Traffic Mode Type and Interface Identifier
   parameters is the same as for the ASP Active message (see Section
   3.3.2.5).

   The format and description of the optional INFO String parameter are
   the same as for the ASP Up message (see Section 3.3.2.1).

3.3.2.7. ASP Inactive (ASPIA)
The ASPIA message is sent by an ASP to indicate to an SG that it is no longer an active ASP to be used from within a list of ASPs. The SG will respond with an ASPIA Ack message and either discard incoming messages or buffer for a timed period and then discard.
Top   ToC   RFC4233 - Page 33
   The ASPIA message contains the following parameters:

      Interface Identifiers (Optional)
         - Combination of integer and integer ranges, OR
         - string (text formatted)

      INFO String (Optional)

   The format for the ASP Inactive message parameters using integer-
   formatted Interface Identifiers is as follows:
Top   ToC   RFC4233 - Page 34
    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=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 Identifier Parameters         /
   \                  of Tag Type 0x1 or 0x8                       \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4233 - Page 35
   The format for the ASP Inactive 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 (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                     Interface Identifiers                     /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /           Additional Interface Identifier Parameters          /
   \                      of Tag Type 0x3                          \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The optional Interface Identifiers parameter contains a list of
   Interface Identifier integers or text strings indexing the
   Application Server traffic that the sending ASP is
   configured/registered to receive, but does not want to receive at
   this time.

   The format and description of the optional Interface Identifiers and
   INFO String parameters are the same as for the ASP Active message
   (see Section 3.3.2.5).

3.3.2.8. ASP Inactive Ack
The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP Inactive message received from a remote IUA peer. The ASPIA Ack message contains the following parameters: Interface Identifiers (Optional) - Combination of integer and integer ranges, OR - string (text formatted) INFO String (Optional)
Top   ToC   RFC4233 - Page 36
   The format for the ASP Inactive Ack message parameters 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 (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 Identifier Parameters         /
   \                  of Tag Type 0x1 or 0x8                       \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4233 - Page 37
   The format for the ASP Inactive Ack 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 (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                     Interface Identifiers                     /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /           Additional Interface Identifier Parameters          /
   \                      of Tag Type 0x3                          \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format and description of the optional Interface Identifiers and
   INFO String parameters are the same as for the ASP Active message
   (see Section 3.3.2.5).

3.3.2.9. Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the IUA peers are still available to each other. It is recommended for use when the IUA runs over a transport layer other than the SCTP, which has its own heartbeat. The BEAT message contains the following parameters: Heartbeat Data (Optional)
Top   ToC   RFC4233 - Page 38
   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 Heartbeat Data parameter contents are defined by the sending
   node.  The Heartbeat Data could include, for example, a Heartbeat
   Sequence Number and/or Timestamp.  The receiver of a Heartbeat
   message does not process this field as it is only of significance to
   the sender.  The receiver MUST respond with a Heartbeat Ack message.

3.3.2.10. Heartbeat Ack (BEAT-Ack)
The Heartbeat Ack message is sent in response to a received Heartbeat message. It includes all the parameters of the received Heartbeat message, without any change.

3.3.3. Layer Management (MGMT) Messages

3.3.3.1. Error (ERR)
The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid. The Error message will have only the common message header. The Error message contains the following parameters: Error Code Diagnostic Information (Optional)
Top   ToC   RFC4233 - Page 39
    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 = 0x000c         |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Error Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag = 0x0007         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   /                     Diagnostic Information                    \
   \                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Code parameter indicates the reason for the Error message.
   The Error parameter value can be one of the following values:

      Invalid Version                               0x01
      Invalid Interface Identifier                  0x02
      Unsupported Message Class                     0x03
      Unsupported Message Type                      0x04
      Unsupported Traffic Handling Mode             0x05
      Unexpected Message                            0x06
      Protocol Error                                0x07
      Unsupported Interface Identifier Type         0x08
      Invalid Stream Identifier                     0x09
      Unassigned TEI                                0x0a
      Unrecognized SAPI                             0x0b
      Invalid TEI, SAPI combination                 0x0c
      Refused - Management Blocking                 0x0d
      ASP Identifier Required                       0x0e
      Invalid ASP Identifier                        0x0f

   The "Invalid Version" error would be sent if a message was received
   with an invalid or unsupported version.  The Error message would
   contain the supported version in the Common header.  The Error
   message could optionally provide the supported version in the
   Diagnostic Information area.

   The "Invalid Interface Identifier" error would be sent by an SG if an
   ASP sends a message with an invalid (unconfigured) Interface
   Identifier value.  For this error, the Diagnostic Information MUST
   contain enough of the offending message to identify the invalid
   Interface Identifier.  For example, in the case of QPTM and TEI
   Status management messages, the Common and IUA message headers of the
   offending message would be placed in the Diagnostic Information at a
   minimum.
Top   ToC   RFC4233 - Page 40
   The "Unsupported Traffic Handling Mode" error would be sent by an SG
   if an ASP sends an ASP Active with an unsupported Traffic Handling
   Mode.  An example would be a case in which the SG did not support
   load-sharing.

   The "Unexpected Message" error would be sent by an ASP if it received
   a QPTM message from an SG while it was in the Inactive state (the ASP
   could optionally drop the message and not send an error).  It would
   also be sent by an ASP if it received a defined and recognized
   message that the SG is not expected to send (e.g., if the MGC
   receives an IUA Establish Request message).

   The "Protocol Error" error would be sent for any protocol anomaly
   (i.e., a bogus message).

   The "Invalid Stream Identifier" error would be sent if a message was
   received on an unexpected SCTP stream (e.g., a MGMT message was
   received on a stream other than "0").

   The "Unsupported Interface Identifier Type" error would be sent by an
   SG if an ASP sends a text-formatted Interface Identifier and the SG
   only supports integer-formatted Interface Identifiers.  When the ASP
   receives this error, it will need to resend its message with an
   integer-formatted Interface Identifier.

   The "Unsupported Message Type" error would be sent if a message with
   an unexpected or unsupported Message Type is received.

   The "Unsupported Message Class" error would be sent if a message with
   an unexpected or unsupported Message Class is received.

   The "Unassigned TEI" error may be used when the SG receives an IUA
   message that includes a TEI that has not been assigned or recognized
   for use on the indicated ISDN D-channel.

   The "Unrecognized SAPI" error would handle the case of using an SAPI
   that is not recognized by the SG.  The "Invalid TEI, SAPI
   combination" error identifies errors where the TEI is assigned and
   the SAPI is recognized, but the combination is not valid for the
   interface (e.g., on a Basic Rate Interface (BRI), the MGC tries to
   send Q.921 Management messages via IUA when Layer Management at the
   SG SHOULD be performing this function).

   The "Refused - Management Blocking" error is sent when an ASP Up or
   ASP Active message is received and the request is refused for
   management reasons (e.g., management lockout).
Top   ToC   RFC4233 - Page 41
   The "ASP Identifier Required" is sent by an SG in response to an ASP
   Up message that does not contain an ASP Identifier parameter when the
   SG requires one.  The ASP SHOULD resend the ASP Up message with an
   ASP Identifier.

   The "Invalid ASP Identifier" is sent by a SG in response to an ASP Up
   message with an invalid (i.e., non-unique) ASP Identifier.

   Diagnostic Information: variable length

      When included, the optional Diagnostic information can be any
      information germane to the error condition, to assist in
      identification of the error condition.  The Diagnostic information
      SHOULD contain the offending message.

   Error messages MUST NOT be generated in response to other Error
   messages.

3.3.3.2. Notify (NTFY)
The Notify message used to provide an autonomous indication of IUA events to an IUA peer. The Notify message will use only the common message header. The Notify message contains the following parameters: Status (Mandatory) ASP Identifier (Optional) Interface Identifiers (Optional) INFO String (Optional) The format for the Notify message with integer-formatted Interface Identifiers is as follows:
Top   ToC   RFC4233 - Page 42
    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 = 0x000d           |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Status Type            |    Status Identification      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Tag = 0x0011           |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ASP Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     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 Identifier Parameters         /
   \                  of Tag Type 0x1 or 0x8                       \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0004          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC4233 - Page 43
   The format for the Notify message with text-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 = 0x000d           |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Status Type            |    Status Identification      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Tag = 0x0011           |           Length = 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ASP Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tag (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                     Interface Identifiers                     /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /           Additional Interface Identifier Parameters          /
   \                      of Tag Type 0x3                          \
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0004          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                         INFO String                           /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Status Type: 16 bits (unsigned integer)

      The Status Type parameter identifies the type of the Notify
      message.  The following are the valid Status Type values:

         1     Application Server State Change (AS-State_Change)
         2     Other

   Status Information: 16 bits (unsigned integer)

      The Status Information parameter contains more detailed
      information for the notification, based on the value of the Status
      Type.  If the Status Type is AS-State_Change, the following Status
      Information values are used:
Top   ToC   RFC4233 - Page 44
         1    reserved
         2    Application Server Inactive (AS-INACTIVE)
         3    Application Server Active (AS-ACTIVE)
         4    Application Server Pending (AS-PENDING)

   These notifications are sent from an SG to an ASP upon a change in
   status of a particular Application Server.  The value reflects the
   new state of the Application Server.

   If the Status Type is Other, then the following Status Information
   values are defined:

      Value          Description
        1    Insufficient ASP resources active in AS
        2    Alternate ASP Active
        3    ASP Failure

   These notifications are not based on the SG reporting the state
   change of an ASP or AS.  In the Insufficient ASP Resources case, the
   SG is indicating to an ASP-INACTIVE ASP(s) in the AS that another ASP
   is required in order to handle the load of the AS (Load-sharing
   mode).  For the Alternate ASP Active case, an ASP is informed when an
   alternate ASP transitions to the ASP-ACTIVE state in Over-ride mode.
   The ASP Identifier (if available) of the Alternate ASP MUST be placed
   in the message.  For the ASP Failure case, the SG is indicating to
   ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN.
   The ASP Identifier (if available) of the failed ASP MUST be placed in
   the message.

   The format and description of the optional ASP Identifier are the
   same as for the ASP Up message (see Section 3.3.2.1).  The format and
   description of the optional Interface Identifiers and INFO String
   parameters are the same as for the ASP Active message (see Section
   3.3.2.5).

3.3.3.3. TEI Status Messages (Request, Confirm, and Indication)
The TEI Status messages are exchanged between IUA layer peers to request, confirm, and indicate the status of a particular TEI. The TEI Status messages contain the common message header followed by IUA message header. The TEI Status Request message does not contain any additional parameters. In the integrated ISDN Layer 2/3 model (e.g., in traditional ISDN switches), it is assumed that the Layer Management for the Q.921 Layer and the Q.931 layer are co-located. When backhauling ISDN, this assumption is not necessarily valid. The TEI Status messages
Top   ToC   RFC4233 - Page 45
   allow the two Layer Management entities to communicate the status of
   the TEI.  In addition, knowing that a TEI is in service allows the
   ASP to request the SG to establish the datalink to the terminal (via
   the IUA Establish message) for signaling if the ASP wants to be in
   control of data link establishment.  Another use of the TEI Status
   procedure is where the Layer Management at the ASP can prepare for
   send/receive signaling to/from a given TEI and confirm/verify the
   establishment of a datalink to that TEI.  For example, if a datalink
   is established for a TEI that the ASP did not know was assigned, the
   ASP can check to see whether it was assigned or whether there was an
   error in the signaling message.  Also, knowing that a TEI is out of
   service, the ASP need not request the SG to establish a datalink to
   that TEI.

   The TEI Status Indication and Confirm messages contain the following
   parameter:

     STATUS

    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 = 0x0010         |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Status                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Define     Value           Description
   ASSIGNED       0x0        TEI is considered assigned by Q.921
   UNASSIGNED     0x1        TEI is considered unassigned by Q.921

3.3.3.4. TEI Query Message (Request)
The TEI Query message is sent by the ASP to query the TEI(s). This message consists of the common header and IUA header. The DLCI in the IUA header MUST be ignored by the SG. The SG will respond to this message with TEI Status Indication(s).