An example of the upper layer primitives provided by SCTP are
available in Section 10 of RFC 2960 [4].
1.6.4. Definition of IUA/Layer-Management Boundary
M-SCTP ESTABLISH request
Direction: LM -> IUA
Purpose: LM requests ASP to establish an SCTP association with an SG.
M-STCP ESTABLISH confirm
Direction: IUA -> LM
Purpose: ASP confirms to LM that it has established an SCTP
association with an SG.
M-SCTP ESTABLISH indication
Direction: IUA -> LM
Purpose: SG informs LM that an ASP has established an SCTP
association.
M-SCTP RELEASE request
Direction: LM -> IUA
Purpose: LM requests ASP to release an SCTP association with SG.
M-SCTP RELEASE confirm
Direction: IUA -> LM
Purpose: ASP confirms to LM that it has released SCTP association
with SG.
M-SCTP RELEASE indication
Direction: IUA -> LM
Purpose: SG informs LM that ASP has released an SCTP association.
M-SCTP STATUS request
Direction: LM -> IUA
Purpose: LM requests IUA to report status of SCTP association.
M-SCTP STATUS indication
Direction: IUA -> LM
Purpose: IUA reports status of SCTP association.
M-ASP STATUS request
Direction: LM -> IUA
Purpose: LM requests SG to report status of remote ASP.
M-ASP STATUS indication
Direction: IUA -> LM
Purpose: SG reports status of remote ASP.
M-AS-STATUS request
Direction: LM -> IUA
Purpose: LM requests SG to report status of AS.
M-AS-STATUS indication
Direction: IUA -> LM
Purpose: SG reports status of AS.
M-NOTIFY indication
Direction: IUA -> LM
Purpose: ASP reports that it has received a NOTIFY message
from its peer.
M-ERROR indication
Direction: IUA -> LM
Purpose: ASP or SG reports that it has received an ERROR
message from its peer.
M-ASP-UP request
Direction: LM -> IUA
Purpose: LM requests ASP to start its operation and send an ASP UP
message to the SG.
M-ASP-UP confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP UP Acknowledgement
message from the SG.
M-ASP-DOWN request
Direction: LM -> IUA
Purpose: LM requests ASP to stop its operation and send an ASP DOWN
message to the SG.
M-ASP-DOWN confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP DOWN
Acknowledgement message from the SG.
M-ASP-ACTIVE request
Direction: LM -> IUA
Purpose: LM requests ASP to send an ASP ACTIVE message to the SG.
M-ASP-ACTIVE confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP ACTIVE
Acknowledgement message from the SG.
M-ASP-INACTIVE request
Direction: LM -> IUA
Purpose: LM requests ASP to send an ASP INACTIVE message to the SG.
M-ASP-INACTIVE confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP INACTIVE
Acknowledgement message from the SG.
M-TEI STATUS request
Direction: LM -> IUA
Purpose: LM requests ASP to send a TEI status request to the SG.
M-TEI STATUS indication
Direction: IUA -> LM
Purpose: ASP reports that is has received a TEI status indication
from the SG.
M-TEI STATUS confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received a TEI status confirm from
the SG.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[6].
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: