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).
4. Procedures
The IUA layer needs to respond to various primitives it receives from
other layers as well as messages it receives from the peer IUA layer.
This section describes various procedures involved in response to
these events.
4.1. Procedures to Support Service in Section 1.4.1
These procedures achieve the IUA layer’s "Transport of Q.921/Q.931
boundary primitives" service.
4.1.1. Q.921 or Q.931 Primitives Procedures
On receiving these primitives from the local layer, the IUA layer
will send the corresponding QPTM message (Data, Unit Data, Establish,
Release) to its peer. While doing so, the IUA layer needs to fill
various fields of the common and specific headers correctly. In
addition, the message needs to be sent on the SCTP stream that
corresponds to the D channel (Interface Identifier).
4.1.2. QPTM Message Procedures
On receiving QPTM messages from a peer IUA layer, the IUA layer on an
SG or MGC needs to invoke the corresponding layer primitives
(DL-ESTABLISH, DL-DATA, DL-UNIT DATA, DL-RELEASE) to the local Q.921
or Q.931 layer.
4.2. Procedures to Support Service in Section 1.4.2
These procedures achieve the IUA layer’s "Support for Communication
between Layer Managements" service.
4.2.1. Layer Management Primitives Procedures
On receiving these primitives from the local Layer Management, the
IUA layer will provide the appropriate response primitive across the
internal local Layer Management interface.
An M-SCTP ESTABLISH request from Layer Management will initiate the
establishment of an SCTP association. An M-SCTP ESTABLISH confirm
will be sent to Layer Management when the initiated association setup
is complete. An M-SCTP ESTABLISH indication is sent to Layer
Management upon successful completion of an incoming SCTP association
setup from a peer IUA node.
An M-SCTP RELEASE request from Layer Management will initiate the
teardown of an SCTP association. An M-SCTP RELEASE confirm will be
sent by Layer Management when the association teardown is complete.
An M-SCTP RELEASE indication is sent to Layer Management upon
successful teardown of an SCTP association initiated by a peer IUA.
M-SCTP STATUS request and indication support a Layer Management query
of the local status of a particular SCTP association.
M-NOTIFY indication and M-ERROR indication indicate to Layer
Management the notification or error information contained in a
received IUA Notify or Error message, respectively. These
indications can also be generated based on local IUA events.
M-ASP STATUS request/indication and M-AS-STATUS request/indication
support a Layer Management query of the local status of a particular
ASP or AS. No IUA peer protocol is invoked.
M-ASP-UP request, M-ASP-DOWN request, M-ASP-INACTIVE request, and
M-ASP-ACTIVE request allow Layer Management at an ASP to initiate
state changes. These requests result in outgoing IUA ASP UP, ASP
DOWN, ASP INACTIVE, and ASP ACTIVE messages.
M-ASP-UP confirmation, M-ASP-DOWN confirmation, M-ASP-INACTIVE
confirmation, and M-ASP-ACTIVE confirmation indicate to Layer
Management that the previous request has been confirmed.
Upon receipt of an M-TEI Status primitive from Layer Management, the
IUA will send the corresponding MGMT message (TEI Status) to its
peer. While doing so, the IUA layer needs to fill various fields of
the common and specific headers correctly.
All MGMT messages are sent on a sequenced stream to ensure ordering.
SCTP stream ’0’ SHOULD be used.
4.2.2. Receipt of IUA Peer Management Messages
Upon receipt of IUA Management messages, the IUA layer MUST invoke
the corresponding Layer Management primitive indications (e.g., M-AS
Status ind., M-ASP Status ind., M-ERROR ind., M-TEI STATUS) to the
local layer management.
M-NOTIFY indication and M-ERROR indication indicate to Layer
Management the notification or error information contained in a
received IUA Notify or Error message. These indications can also be
generated based on local IUA events.
All MGMT messages are sent on a sequenced stream to ensure ordering.
SCTP stream ’0’ SHOULD be used.
4.3. Procedures to Support Service in Section 1.4.3
These procedures achieve the IUA layer’s "Support for management of
active associations between SG and MGC" service.
4.3.1. AS and ASP State Maintenance
The IUA layer on the SG needs to maintain the states of each ASP as
well as the state of the AS.
4.3.1.1. ASP States
The state of the each ASP, in each AS that it is configured, is
maintained in the IUA layer on the SG. The state of an ASP changes
due to the following type of events:
* Reception of messages from peer IUA layer at that ASP
* Reception of some messages from the peer IUA layer at other
ASPs in the AS
* Reception of indications from SCTP layer
* Local Management intervention
The ASP state transition diagram is shown in Figure 6. The possible
states of an ASP are the following:
ASP-DOWN: Application Server Process is unavailable and/or the
related SCTP association is down. Initially, all ASPs will be in
this state. An ASP in this state SHOULD NOT be sent any IUA