tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3057

 
 
 

ISDN Q.921-User Adaptation Layer

Part 2 of 3, p. 17 to 45
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
3.0 Protocol Elements

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

3.1 Common Message Header

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |   Reserved    | Message Class | Message Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3 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

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 [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]

Top      Up      ToC       Page 18 
     8      Connection-Oriented Messages [SUA]
  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

    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

Top      Up      ToC       Page 19 
    Management (MGMT) Messages

       0        Error (ERR)
       1        Notify (NTFY)
       2        TEI Status Request
       3        TEI Status Confirm
       4        TEI Status Indication
     5 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.

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
   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 Tag field is a 16 bit identifier of the type of parameter.  It
   takes a value of 0 to 65534.

   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      Up      ToC       Page 20 
   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      Up      ToC       Page 21 
    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 4 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 5  IUA Message Header (Text-based Interface Identifier)

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

   The DLCI format is shown below in Figure 6.

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  0  | SPR |      SAPI                         |
   +-----------------------------------------------+
   |  1  |            TEI                          |
   +-----------------------------------------------+

              Figure 6  DLCI Format

   SPR:  Spare 2nd bit in octet 1, (1 bit)

Top      Up      ToC       Page 22 
   SAPI: Service Access Point Identifier, 3rd through 8th bits in octet
      1 (6 bits)

   TEI:  Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
      (7 bits)

   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 3) and
   the IUA message header (Figure 4 and Figure 5).

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 re-send 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 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 its 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 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.

Top      Up      ToC       Page 23 
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

    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                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

Top      Up      ToC       Page 24 
   The Data messages contain the common message header followed by IUA
   message header.  The Data message contains the following parameters:

     PROTOCOL DATA

    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
   parameters

     PROTOCOL DATA

    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 only use 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.

Top      Up      ToC       Page 25 
   The ASPUP message contains the following parameters:

     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 (0x4)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          INFO String*                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The optional INFO String parameter can carry any meaningful 8-bit
   ASCII 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 (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.3.1).

Top      Up      ToC       Page 26 
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:

      Reason
      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 (0xa)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Reason                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           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.3.1.).

   The Reason parameter indicates the reason that the remote IUA
   adaptation layer is unavailable.  The valid values for Reason are
   shown in the following table.

      Value         Description
      0x1          Management Inhibit

   If a ASP is removed from Management Inhibit, the ASP will send an ASP
   Up message.

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:

      Reason
      INFO String (Optional)

Top      Up      ToC       Page 27 
   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 (0xa)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Reason                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           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.).

   The format of the Reason parameter is the same as for the ASP Down
   message (See Section 3.3.2.3).

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.

   The ASPAC 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      Up      ToC       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 (0xb)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     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 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 (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            Over-ride
      0x2            Load-share

   Within a particular Interface Identifier, 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/back-up 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      Up      ToC       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(s) in which the ASP
   is provisioned.  If only a subset of Interface Identifiers 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.

   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.).

   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      Up      ToC       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 (0xb)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      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 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 (0xb)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic Mode Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tag (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                     Interface Identifier*                     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |              Additional Interface Identifiers                 |
   |                        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 is
   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.

   The ASPIA message contains the following parameters

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

Top      Up      ToC       Page 33 
      INFO String (Optional)

   The format for the ASP Inactive 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 (0xb)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     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 34 
   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 (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 Traffic Mode
   Type are shown in the following table:

      Value          Description
       0x1            Over-ride
       0x2            Load-share

   The format and description of the optional Interface Identifiers and
   Info String parameters is the same as for the ASP Active message (See
   Section 3.3.2.3.).

   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.

Top      Up      ToC       Page 35 
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:

      Traffic Mode Type (Mandatory)
      Interface Identifiers (Optional)
         - Combination of integer and integer ranges, OR
         - string (text formatted)
      INFO String (Optional)

Top      Up      ToC       Page 36 
    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 (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 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 (0xb)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Traffic Mode Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tag (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                     Interface Identifier*                     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |              Additional Interface Identifiers                 |
   |                        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 Inactive message (See Section
   3.3.2.7).

   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.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      Up      ToC       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 = 9            |            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 only have the common message header.  The
   Error message contains the following parameters:

      Error Code
      Diagnostic Information (optional)

Top      Up      ToC       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 (0xc)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Error Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x7)           |            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

   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 a SG if an
   ASP sends a message with an invalid (unconfigured) Interface
   Identifier value.

   The "Unsupported Traffic Handling Mode" error would be sent by a 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

Top      Up      ToC       Page 40 
   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 (i.e., a MGMT message was
   received on a stream other than "0").

   The "Unsupported Interface Identifier Type" error would be sent by a
   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 which has not been assigned or recognized
   for use on the indicated ISDN D-channel.

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

   The optional Diagnostic information can be any information germane to
   the error condition, to assist in identification of the error
   condition.  To enhance debugging, the Diagnostic information could
   contain the first 40 bytes of the offending message.

3.3.3.2  Notify (NTFY)

   The Notify message used to provide an autonomous indication of IUA
   events to an IUA peer.

Top      Up      ToC       Page 41 
   The Notify message will only use the common message header.  The
   Notify message contains the following parameters:

      Status Type
      Status Identification
      Interface Identifiers (Optional)
      INFO String (Optional)

Top      Up      ToC       Page 42 
   The format for the Notify 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 (0xd)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Status Type            |    Status Identification      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     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 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 (0xd)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Status Type            |    Status Identification      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tag (0x3=string)        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                     Interface Identifier*                     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |              Additional Interface Identifiers                 |
   |                        of Tag Type 0x3                        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0x4)             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          INFO String*                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Value          Description
       0x1   Application Server state change (AS_State_Change)
       0x2   Other

   The Status Identification 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
   Identification values are used:

      Value          Description
        1    Application Server Down (AS_Down)
        2    Application Server Inactive (AS_Inactive)
        3    Application Server Active (AS_Active)
        4    Application Server Pending (AS_Pending)

Top      Up      ToC       Page 44 
   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

   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 "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 format and description of the optional Interface Identifiers and
   Info String parameters is the same as for the ASP Active message (See
   Section 3.3.2.3.).

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
   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.

Top      Up      ToC       Page 45 
   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 (0x10)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              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



(page 45 continued on part 3)

Next RFC Part