RFC 4233
Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
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
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
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.
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.
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.
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
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
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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
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)
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.
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)
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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)
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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:
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
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)
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.
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).
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:
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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
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).