As per Relevance of the word adaptation, we have this rfc below:
Network Working Group K.
Request for Comments: 3057 Cisco
Category: Standards Track S.
M.
Telcordia
G.
Nortel
February 2001
ISDN Q.921-User Adaptation
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document defines a protocol for backhauling of ISDN Q.921
messages over IP using the Stream Control Transmission
(SCTP). This protocol would be used between a Signaling Gateway (SG
and Media Gateway Controller (MGC). It is assumed that the
receives ISDN signaling over a standard ISDN interface
Morneault, et al. Standards Track [Page 1]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Table of
1. Introduction................................................. 2
1.1 Scope..................................................... 2
1.2 Terminology............................................... 3
1.3 IUA Overview.............................................. 4
1.4 Services Provided by the IUA Layer........................ 9
1.5 Functions Implemented by the IUA Layer.................... 12
1.6 Definition of IUA Boundaries.............................. 14
2. Conventions.................................................. 16
3. Protocol Elements............................................ 17
3.1 Common Message Header..................................... 17
3.2 IUA Message Header........................................ 20
3.3 Description of Messages................................... 22
4. Procedures................................................... 45
4.1 Procedures to Support Service in Section 1.4.1............ 45
4.2 Procedures to Support Service in Section 1.4.2............ 46
4.3 Procedures to Support Service in Section 1.4.3............ 47
5. Examples...................................................... 56
5.1 Establishment of associations between SG and MGC examples.. 56
5.2 ASP Traffic Fail-over Examples............................. 58
5.3 Q.921/Q.931 primitives backhaul Examples................... 59
5.4 Layer Management Communication Examples.................... 61
6. Security..................................................... 61
6.1 Threats.................................................... 61
6.2 Protecting Confidentiality ................................ 62
7. IANA Considerations.......................................... 62
7.1 SCTP Payload Protocol Identifier........................... 62
7.2 IUA Protocol Extensions.................................... 62
8. Acknowledgements............................................. 64
9. References................................................... 64
10. Authors' Addresses........................................... 65
11. Full Copyright Statement..................................... 66
1.
In this document, the term Q.921-User refers to an upper layer
uses the services of Q.921, not the user side of ISDN interface [1].
Examples of the upper layer would be Q.931 and QSIG
This section describes the need for ISDN Q.921-User Adaptation (IUA
layer protocol as well as how this protocol shall be implemented
1.1
There is a need for Switched Circuit Network (SCN) signaling
delivery from an ISDN Signaling Gateway (SG) to a Media
Controller (MGC) as described in the Framework Architecture
Morneault, et al. Standards Track [Page 2]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Signaling Transport [4]. The delivery mechanism SHOULD meet
following criteria
* Support for transport of the Q.921 / Q.931 boundary
* Support for communication between Layer Management modules on
and
* Support for management of active associations between SG and
This document supports both ISDN Primary Rate Access (PRA) as well
Basic Rate Access (BRA) including the support for both point-to-
and point-to-multipoint modes of communication. This
includes Facility Associated Signaling (FAS), Non-Facility
Signaling (NFAS) and NFAS with backup D channel. QSIG
layer requirements do not differ from Q.931 adaptation layer, hence
the procedures described in this document are also applicable for
QSIG adaptation layer. For simplicity, only Q.931 will be
in the rest of this document
1.2
Interface - For the purposes of this document an interface
the relevant ISDN signaling channel. This signaling channel MAY be
16 kbps D channel for an ISDN BRA as well as 64 kbps primary
backup D channel for an ISDN PRA. For QSIG, the signaling channel
a Qc channel
Q.921-User - Any protocol normally using the services of the
Q.921 (e.g., Q.931, QSIG, etc.).
Backhaul - A SG terminates the lower layers of an SCN protocol
backhauls the upper layer(s) to MGC for call processing. For
purposes of this document the SG terminates Q.921 and backhauls Q.931
to MGC
Association - An association refers to a SCTP association.
association will provide the transport for the delivery of Q.921-
protocol data units and IUA adaptation layer peer messages
Stream - A stream refers to an SCTP stream; a uni-directional
channel established from one SCTP endpoint to another associated
endpoint, within which all user messages are delivered in-
except for those submitted to the un-ordered delivery service
Interface Identifier - The Interface Identifier identifies
physical interface at the SG for which the signaling messages
sent/received. The format of the Interface Identifier parameter
be text or integer, the values of which are assigned according
Morneault, et al. Standards Track [Page 3]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
network operator policy. The values used are of local
only, coordinated between the SG and ASP. Significance is
implied across SGs served by an AS
Application Server (AS) - A logical entity serving a
application instance. An example of an Application Server is a
handling the Q.931 and call processing for D channels terminated
the Signaling Gateways. Practically speaking, an AS is modeled
the SG as an ordered list of one or more related Application
Processes (e.g., primary, secondary, tertiary).
Application Server Process (ASP) - A process instance of
Application Server. Examples of Application Server Processes
primary or backup MGC instances
Fail-over - The capability to re-route signaling traffic as
between related ASPs in the event of failure or unavailability of
currently used ASP (e.g., from primary MGC to back-up MGC). Fail
over also applies upon the return to service of a
unavailable process
Layer Management - Layer Management is a nodal function that
the inputs and outputs between the IUA layer and a local
entity
Network Byte Order - Most significant byte first, a.k.a Big Endian
Host - The computing platform that the ASP process is running on
1.3 IUA
The architecture that has been defined [4] for SCN
transport over IP uses multiple components, including an IP
protocol, a signaling common transport protocol and an
module to support the services expected by a particular SCN
protocol from its underlying protocol layer
This document defines an adaptation module that is suitable for
transport of ISDN Q.921-User (e.g., Q.931) messages
1.3.1 Example - SG to
In a Signaling Gateway, it is expected that the ISDN signaling
received over a standard ISDN network termination. The SG
provides interworking of transport functions with IP
Transport, in order to transport the Q.931 signaling messages to
MGC where the peer Q.931 protocol layer exists, as shown below
Morneault, et al. Standards Track [Page 4]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
****** ISDN ****** IP *******
* EP *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+
|Q.931| (NIF) |Q.931|
+-----+ +----------+ +-----+
| | | | IUA| | IUA |
| | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP | | IP |
+-----+ +-----+----+ +-----+
NIF - Nodal Interworking
EP - ISDN End
SCTP - Stream Control Transmission Protocol (Refer to [3])
IUA - ISDN User Adaptation Layer
It is recommended that the IUA use the services of the Stream
Transmission Protocol (SCTP) as the underlying reliable
signaling transport protocol. The use of SCTP provides the
features
- explicit packet-oriented delivery (not stream-oriented
- sequenced delivery of user messages within multiple streams
with an option for order-of-arrival delivery of individual
messages
- optional multiplexing of user messages into SCTP datagrams
- network-level fault tolerance through support of multi-
at either or both ends of an association
- resistance to flooding and masquerade attacks,
- data segmentation to conform to discovered path MTU
There are scenarios without redundancy requirements and scenarios
which redundancy is supported below the transport layer. In
cases, the SCTP functions above MAY NOT be a requirement and TCP
be used as the underlying common transport protocol
1.3.2 Support for the management of SCTP associations between the
and
The IUA layer at the SG maintains the availability state of
dynamically registered remote ASPs, in order to manage the
Associations and the traffic between the SG and ASPs. As well,
active/inactive state of remote ASP(s) are also maintained.
ASPs are those currently receiving traffic from the SG
Morneault, et al. Standards Track [Page 5]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
The IUA layer MAY be instructed by local management to establish
SCTP association to a peer IUA node. This can be achieved using
M-SCTP ESTABLISH primitive to request, indicate and confirm
establishment of an SCTP association with a peer IUA node
The IUA layer MAY also need to inform local management of the
of the underlying SCTP associations using the M-SCTP STATUS
and indication primitive. For example, the IUA MAY inform
management of the reason for the release of an SCTP association
determined either locally within the IUA layer or by a primitive
the SCTP
1.3.3 Signaling Network
A Signaling Gateway is used to support the transport of Q.921-
signaling traffic to one or more distributed ASPs (e.g., MGCs).
Clearly, the IUA protocol is not designed to meet the performance
reliability requirements for such transport by itself. However,
conjunction of distributed architecture and redundant networks
allow for a sufficiently reliable transport of signaling traffic
IP. The IUA protocol is flexible enough to allow its operation
management in a variety of physical configurations, enabling
Operators to meet their performance and reliability requirements
To meet the ISDN signaling reliability and performance
for carrier grade networks, Network Operators SHOULD ensure
there is no single point of failure provisioned in the end-to-
network architecture between an ISDN node and an IP ASP
Depending of course on the reliability of the SG and ASP
elements, this can typically be met by the provision of
QOS-bounded IP network paths for SCTP Associations between SCTP
Points, and redundant Hosts, and redundant SGs. The distribution
ASPs within the available Hosts is also important. For a
Application Server, the related ASPs SHOULD be distributed over
least two Hosts
An example logical network architecture relevant to carrier-
operation in the IP network domain is shown in Figure 1 below
Morneault, et al. Standards Track [Page 6]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Host
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Figure 2 - Logical Model
For carrier grade networks, the failure or isolation of a
ASP SHOULD NOT cause stable calls to be dropped. This implies
ASPs need, in some cases, to share the call state or be able to
the call state between each other. However, this sharing
communication of call state information is outside the scope of
document
1.3.4 ASP Fail-over Model and
The IUA layer supports ASP fail-over functions in order to support
high availability of call processing capability. All Q.921-
messages incoming to an SG are assigned to a unique
Server, based on the Interface Identifier of the message
The Application Server is, in practical terms, a list of all
configured to process Q.921-User messages from certain
Identifiers. One or more ASPs in the list are normally active (i.e.,
handling traffic) while any others MAY be unavailable or inactive,
be possibly used in the event of failure or unavailability of
active ASP(s).
Morneault, et al. Standards Track [Page 7]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
The fail-over model supports an n+k redundancy model, where n ASP(s
are the minimum number of redundant ASPs required to handle
and k ASPs are available to take over for a failed or
ASP. Note that 1+1 active/standby redundancy is a subset of
model. A simplex 1+0 model is also supported as a subset, with
ASP redundancy
To avoid a single point of failure, it is recommended that a
of two ASPs be in the list, resident in separate hosts and
available over different SCTP Associations. For example, in
network shown in Figure 2, all messages from a particular D
(Interface Identifier) could be sent to ASP1 in Host1 or ASP1
Host2. The AS list at SG1 might look like the following
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up,
ASP1/Host2 - State=Up,
In this 1+1 redundancy case, ASP1 in Host1 would be sent any
message for the Interface Identifiers registered. ASP1 in Host
would normally be brought to the active state upon failure of,
loss of connectivity to, ASP1/Host1. In this example, both ASPs
Up, meaning that the related SCTP association and far-end IUA peer
ready
The AS List at SG1 might also be set up in load-share mode as
below
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up,
ASP1/Host2 - State=Up,
In this case, both the ASPs would be sent a portion of the traffic
In the process of fail-over, it is recommended that in the case
ASPs supporting call processing, stable calls do not get released
It is possible that calls in transition MAY fail, although
of communication between the ASPs involved can be used to
this problem. For example, the two ASPs MAY share call state
shared memory, or MAY use an ASP to ASP protocol to pass call
information. The ASP to ASP protocol is outside the scope of
document
1.3.5 Client/Server
It is recommended that the SG and ASP be able to support both
and server operation. The peer endpoints using IUA SHOULD
configured so that one always takes on the role of client and
Morneault, et al. Standards Track [Page 8]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
other the role of server for initiating SCTP associations.
default orientation would be for the SG to take on the role of
while the ASP is the client. In this case, ASPs SHOULD initiate
SCTP association to the SG
The SCTP (and UDP/TCP) Registered User Port Number Assignment for
is 9900.
1.4 Services Provided by the IUA
1.4.1 Support for transport of Q.921/Q.931 boundary
In the backhaul scenario, the Q.921/Q.931 boundary primitives
exposed. IUA layer needs to support all of the primitives of
boundary to successfully backhaul Q.931.
This includes the following primitives [1]:
DL-
The DL-ESTABLISH primitives are used to request, indicate and
the outcome of the procedures for establishing multiple
operation
DL-
DL-RELEASE primitives are used to request, indicate, and confirm
outcome of the procedures for terminating a previously
multiple frame operation, or for reporting an
establishment attempt
DL-
The DL-DATA primitives are used to request and indicate layer 3
(Q.931) messages which are to be transmitted, or have been received
by the Q.921 layer using the acknowledged information
service
DL-UNIT
The DL-UNIT DATA primitives are used to request and indicate layer 3
(Q.931) messages which are to be transmitted, by the Q.921
using the unacknowledged information transfer service
Morneault, et al. Standards Track [Page 9]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
1.4.2 Support for communication between Layer Management modules on
and
It is envisioned that the IUA layer needs to provide some
that will facilitate communication between Layer Management
on the SG and MGC. These primitives are pointed out in [2],
are shown below
M-TEI
The M-TEI STATUS primitives are used to request, confirm and
the status (assigned/unassigned) of a TEI
M-
The M-ERROR primitive is used to indicate an error with a
IUA message (e.g., interface identifier value is not known to
SG).
1.4.3 Support for management of active associations between SG and
A set of primitives between the IUA layer and the Layer
are defined below to help the Layer Management manage the
association(s) between the SG and MGC. The IUA layer can
instructed by the Layer Management to establish an SCTP
to a peer IUA node. This procedure can be achieved using the M-
ESTABLISH primitive
M-SCTP
The M-SCTP ESTABLISH primitives are used to request, indicate,
confirm the establishment of an SCTP association to a peer IUA node
M-SCTP
The M-SCTP RELEASE primitives are used to request, indicate,
confirm the release of an SCTP association to a peer IUA node
The IUA layer MAY also need to inform the status of the
associations to the Layer Management. This can be achieved using
M-SCTP STATUS primitive
M-SCTP
The M-SCTP STATUS primitives are used to request and indicate
status of the underlying SCTP association(s).
Morneault, et al. Standards Track [Page 10]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
The Layer Management MAY need to inform the IUA layer of an AS/
status (i.e., failure, active, etc.), so that messages can
exchanged between IUA layer peers to stop traffic to the local
user. This can be achieved using the M-ASP STATUS primitive
M-ASP
The ASP status is stored inside IUA layer on both the SG and
sides. The M-ASP STATUS primitive can be used by Layer Management
request the status of the Application Server Process from the
layer. This primitive can also be used to indicate the status of
Application Server Process
M-ASP-
The M-ASP-UP primitive can be used by Layer Management to send a
Up message for the Application Server Process. It can also be
to generate an ASP Up Acknowledgement
M-ASP-
The M-ASP-DOWN primitive can be used by Layer Management to send
ASP Down message for the Application Server Process. It can also
used to generate an ASP Down Acknowledgement
M-ASP-
The M-ASP-UP primitive can be used by Layer Management to send a
Active message for the Application Server Process. It can also
used to generate an ASP Active Acknowledgement
M-ASP-
The M-ASP-UP primitive can be used by Layer Management to send a
Inactive message for the Application Server Process. It can also
used to generate an ASP Inactive Acknowledgement
M-AS
The M-AS STATUS primitive can be used by Layer Management to
the status of the Application Server. This primitive can also
used to indicate the status of the Application Server
Morneault, et al. Standards Track [Page 11]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
1.5 Functions Implemented by the IUA
1.5.1
The IUA layer MUST maintain a map of the Interface Identifier to
physical interface on the Signaling Gateway. A physical
would be a T1 line, E1 line, etc., and could include the
timeslot. In addition, for a given interface the SG MUST be able
identify the associated signaling channel. IUA layers on both SG
MGC MAY maintain the status of TEIs and SAPIs
The SG maps an Interface Identifier to an SCTP association/
only when an ASP sends an ASP Active message for a
Interface Identifier. It MUST be noted, however, that this
is dynamic and could change at any time due to a change of ASP state
This mapping could even temporarily be invalid, for example
failover of one ASP to another. Therefore, the SG MUST maintain
states of AS/ASP and reference them during the routing of an
to an AS/ASP
One example of the logical view of relationship between D channel
Interface Identifier, AS and ASP in the SG is shown below
/---------------------------------------------------+
/ /------------------------------------------------|--+
/ / v |
/ / +----+ act+-----+ +-------+ -+--+-|+--+-
D chan1-------->|IID |-+ +-->| ASP |--->| Assoc |
/ +----+ | +----+ | +-----+ +-------+ -+--+--+--+-
/ +->| AS |--+
/ +----+ | +----+ stb+-----+
D chan2-------->|IID |-+ | ASP |
+----+ +-----+
where IID = Interface
Note that an ASP can be in more than one AS
1.5.2 Status of
The IUA layer on the SG MUST maintain the state of the ASPs it
supporting. The state of an ASP changes because of reception
peer-to-peer messages (ASPM messages as described in Section 3.3.2)
or reception of indications from the local SCTP association.
state transition procedures are described in Section 4.3.1.
Morneault, et al. Standards Track [Page 12]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
At a SG, an Application Server list MAY contain active and
ASPs to support ASP load-sharing and fail-over procedures. When,
example, both a primary and a back-up ASP are available, IUA
protocol is required to control which ASP is currently active.
ordered list of ASPs within a logical Application Server is
updated in the SG to reflect the active Application
Process(es).
Also the IUA layer MAY need to inform the local management of
change in status of an ASP or AS. This can be achieved using the M
ASP STATUS or M-AS STATUS primitives
1.5.3 SCTP Stream
SCTP allows a user specified number of streams to be opened
the initialization. It is the responsibility of the IUA layer
ensure proper management of these streams. Because of
unidirectional nature of streams, an IUA layer is not aware of
stream number to Interface Identifier mapping of its peer IUA layer
Instead, the Interface Identifier is in the IUA message header
The use of SCTP streams within IUA is recommended in order
minimize transmission and buffering delay, therefore improving
overall performance and reliability of the signaling elements. It
recommended that a separate SCTP stream is used for each D channel
1.5.4 Seamless Network Management
The IUA layer on the SG SHOULD pass an indication of
of the IUA-User (Q.931) to the local Layer Management, if
currently active ASP moves from the ACTIVE state. The
Management could instruct Q.921 to take some action, if it
appropriate
Likewise, if an SCTP association fails, the IUA layer on both the
and ASP sides MAY generate Release primitives to take the data
out-of-service
1.5.5 Congestion
If the IUA layer becomes congested (implementation dependent), it
stop reading from the SCTP association to flow control from the
IUA
Morneault, et al. Standards Track [Page 13]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
1.6 Definition of IUA
1.6.1 Definition of IUA/Q.921
DL-
DL-
DL-
DL-UNIT
1.6.2 Definition of IUA/Q.931
DL-
DL-
DL-
DL-UNIT
1.6.3 Definition of SCTP/IUA
An example of the upper layer primitives provided by SCTP
available in Reference [3] section 10.
1.6.4 Definition of IUA/Layer-Management
M-SCTP ESTABLISH
Direction: LM ->
Purpose: LM requests ASP to establish an SCTP association with an SG
M-STCP ESTABLISH
Direction: IUA ->
Purpose: ASP confirms to LM that it has established an
association with an SG
M-SCTP ESTABLISH
Direction: IUA ->
Purpose: SG informs LM that an ASP has established an
association
M-SCTP RELEASE
Direction: LM ->
Purpose: LM requests ASP to release an SCTP association with SG
M-SCTP RELEASE
Direction: IUA ->
Purpose: ASP confirms to LM that it has released SCTP
with SG
Morneault, et al. Standards Track [Page 14]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
M-SCTP RELEASE
Direction: IUA ->
Purpose: SG informs LM that ASP has released an SCTP association
M-SCTP STATUS
Direction: LM ->
Purpose: LM requests IUA to report status of SCTP association
M-SCTP STATUS
Direction: IUA ->
Purpose: IUA reports status of SCTP association
M-ASP STATUS
Direction: LM ->
Purpose: LM requests SG to report status of remote ASP
M-ASP STATUS
Direction: IUA ->
Purpose: SG reports status of remote ASP
M-AS-STATUS
Direction: LM ->
Purpose: LM requests SG to report status of AS
M-AS-STATUS
Direction: IUA ->
Purpose: SG reports status of AS
M-NOTIFY
Direction: IUA ->
Purpose: ASP reports that it has received a NOTIFY
from its peer
M-ERROR
Direction: IUA ->
Purpose: ASP or SG reports that it has received an
message from its peer
M-ASP-UP
Direction: LM ->
Purpose: LM requests ASP to start its operation and send an ASP
message to the SG
M-ASP-UP
Direction: IUA ->
Purpose: ASP reports that is has received an ASP UP
message from the SG
Morneault, et al. Standards Track [Page 15]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
M-ASP-DOWN
Direction: LM ->
Purpose: LM requests ASP to stop its operation and send an ASP
message to the SG
M-ASP-DOWN
Direction: IUA ->
Purpose: ASP reports that is has received an ASP
Acknowledgement message from the SG
M-ASP-ACTIVE
Direction: LM ->
Purpose: LM requests ASP to send an ASP ACTIVE message to the SG
M-ASP-ACTIVE
Direction: IUA ->
Purpose: ASP reports that is has received an ASP
Acknowledgement message from the SG
M-ASP-INACTIVE
Direction: LM ->
Purpose: LM requests ASP to send an ASP INACTIVE message to the SG
M-ASP-INACTIVE
Direction: IUA ->
Purpose: ASP reports that is has received an ASP
Acknowledgement message from the SG
M-TEI STATUS
Direction: LM ->
Purpose: LM requests ASP to send a TEI status request to the SG
M-TEI STATUS
Direction: IUA ->
Purpose: ASP reports that is has received a TEI status
from the SG
M-TEI STATUS
Direction: IUA ->
Purpose: ASP reports that is has received a TEI status confirm from
SG
2.0
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL,
they appear in this document, are to be interpreted as described
[RFC2119].
Morneault, et al. Standards Track [Page 16]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
3.0 Protocol
This section describes the format of various messages used in
protocol
3.1 Common Message
The protocol messages for Q.921-User Adaptation require a
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
All fields in an IUA message MUST be transmitted in the network
order, unless otherwise stated
3.1.1
The version field contains the version of the IUA adaptation layer
The supported versions are the following
Value
----- -------
1 Release 1.0
3.1.2 Message Classes and
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
Morneault, et al. Standards Track [Page 17]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
8 Connection-Oriented Messages [SUA
9 to 127 Reserved by the
128 to 255 Reserved for IETF-Defined Message Class
The following list contains the message names for the
messages
Q.921/Q.931 Boundary Primitives Transport (QPTM)
0
1 Data Request
2 Data Indication
3 Unit Data Request
4 Unit Data Indication
5 Establish
6 Establish
7 Establish
8 Release
9 Release
10 Release
11 to 127 Reserved by the
128 to 255 Reserved for IETF-Defined QPTM
Application Server Process State Maintenance (ASPSM)
0
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
128 to 255 Reserved for IETF-Defined ASPSM
Application Server Process Traffic Maintenance (ASPTM)
0
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
128 to 255 Reserved for IETF-Defined ASPTM
Morneault, et al. Standards Track [Page 18]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Management (MGMT)
0 Error (ERR
1 Notify (NTFY
2 TEI Status
3 TEI Status
4 TEI Status
5 to 127 Reserved by the
128 to 255 Reserved for IETF-Defined MGMT
3.1.3
The Reserved field is 8-bits. It SHOULD be set to all '0's
ignored by the receiver
3.1.4 Message
The Message length defines the length of the message in octets
including the Common header
3.1.5 Variable-Length Parameter
IUA messages consist of a Common Header followed by zero or
variable-length parameters, as defined by the message type.
variable-length parameters contained in a message are defined in
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
message
Parameter Tag: 16 bits (unsigned integer
The Tag field is a 16 bit identifier of the type of parameter.
takes a value of 0 to 65534.
The value of 65535 is reserved for IETF-defined extensions.
other than those defined in specific parameter description
reserved for use by the IETF
Morneault, et al. Standards Track [Page 19]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Parameter Length: 16 bits (unsigned integer
The Parameter Length field contains the size of the parameter
bytes, including the Parameter Tag, Parameter Length, and
Value fields. The Parameter Length does not include any
bytes
Parameter Value: variable-
The Parameter Value field contains the actual information to
transferred in the parameter
The total length of a parameter (including Tag, Parameter Length
Value fields) MUST be a multiple of 4 bytes. If the length of
parameter is not a multiple of 4 bytes, the sender pads the
at the end (i.e., after the Parameter Value field) with all
bytes. The length of the padding is NOT included in the
length field. A sender SHOULD NEVER pad with more than 3 bytes.
receiver MUST ignore the padding bytes
3.2 IUA Message
In addition to the common message header, there will be a
message header for QPTM and the TEI Status MGMT messages. The
message header will immediately follow the Common header in
messages
This message header will contain the Interface Identifier and
Link Connection Identifier (DLCI). The Interface
identifies the physical interface terminating the signaling
at the SG for which the signaling messages are sent/received.
format of the Interface Identifier parameter can be text or integer
The Interface Identifiers are assigned according to network
policy. The integer values used are of local significance only
coordinated between the SG and ASP
The integer formatted Interface Identifier MUST be supported.
text formatted Interface Identifier MAY optionally be supported
Morneault, et al. Standards Track [Page 20]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
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.
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.
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
SPR: Spare 2nd bit in octet 1, (1 bit
Morneault, et al. Standards Track [Page 21]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
SAPI: Service Access Point Identifier, 3rd through 8th bits in
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
with Q.921.
3.3 IUA
The following section defines the messages and parameter contents
The IUA messages will use the common message header (Figure 3)
the IUA message header (Figure 4 and Figure 5).
3.3.1 Q.921/Q.931 Boundary Primitives Transport (QPTM)
3.3.1.1 Establish Messages (Request, Confirm, Indication
The Establish Messages are used to establish a data link on
signaling channel or to confirm that a data link on the
channel has been established. The MGC controls the state of the
channel. When the MGC desires the D channel to be in-service,
will send the Establish Request message
When the MGC sends an IUA Establish Request message, the MGC
start a timer. This timer would be stopped upon receipt of an
Establish Confirm or Establish Indication. If the timer expires,
MGC would re-send the IUA Establish Request message and restart
timer. In other words, the MGC MAY continue to request
establishment of the data link on periodic basis until the
state is achieved or take some other action (notify the
Layer).
When the SG receives an IUA Establish Request from the MGC, the
shall send the Q.921 Establish Request primitive to the its Q.921
entity. In addition, the SG shall map any response received from
Q.921 entity to the appropriate message to the MGC. For example,
the Q.921 entity responds with a Q.921 Establish Confirm primitive
the IUA layer shall map this to an IUA Establish Confirm message.
another example, if the IUA Layer receives a Q.921 Release Confirm
Release Indication as an apparent response to the Q.921
Request primitive, the IUA Layer shall map these to the
IUA Release Confirm or Release Indication messages
The Establish messages contain the common message header followed
IUA message header. It does not contain any additional parameters
Morneault, et al. Standards Track [Page 22]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
3.3.1.2 Release Messages (Request, Indication, Confirmation
The Release Request message is used to release the data link on
signaling channel. The Release Confirm and Indication messages
used to indicate that the data link on the signaling channel has
released
If a response to the Release Request message is not received, the
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
signaling traffic will not be sent to the SG for that D channel
The Release messages contain the common message header followed
IUA message header. The Release confirm message is in response to
Release Request message and it does not contain any
parameters. The Release Request and Indication messages contain
following parameter
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
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
far end to establish a data link on
signaling channel (i.e., if SABME
received send a DM
RELEASE_OTHER 0x3 Other
Note: Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are
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
Morneault, et al. Standards Track [Page 23]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
The Data messages contain the common message header followed by
message header. The Data message contains the following parameters
PROTOCOL
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
(PDU) corresponding to unacknowledged information transfer service
The Unit Data messages contain the common message header followed
IUA message header. The Unit Data message contains the
PROTOCOL
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)
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
that it is ready to receive traffic or maintenance messages
Morneault, et al. Standards Track [Page 24]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
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-
ASCII character string along with the message. Length of the
String parameter is from 0 to 255 characters. No procedures
presently identified for its use but the INFO String MAY be used
debugging purposes
3.3.2.2 ASP Up
The ASP Up Ack message is used to acknowledge an ASP Up
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
the same as for the ASP Up message (See Section 3.3.3.1).
Morneault, et al. Standards Track [Page 25]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
3.3.2.3 ASP Down (ASPDN
The ASP Down (ASPDN) message is sent by an ASP to indicate to an
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 (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter
the same as for the ASP Up message (See Section 3.3.3.1.).
The Reason parameter indicates the reason that the remote
adaptation layer is unavailable. The valid values for Reason
shown in the following table
Value
0x1 Management
If a ASP is removed from Management Inhibit, the ASP will send an
Up message
3.3.2.4 ASP Down
The ASP Down Ack message is used to acknowledge an ASP Down
received from a remote IUA peer
The ASP Down Ack message contains the following parameters
INFO String (Optional
Morneault, et al. Standards Track [Page 26]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
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
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
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
Active and ready to be used
The ASPAC message contains the following
Traffic Mode Type (Mandatory
Interface Identifier (Optional
- Combination of integer and integer ranges,
- string (text formatted
INFO String (Optional
Morneault, et al. Standards Track [Page 27]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
The format for the ASPAC message using integer formatted
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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Morneault, et al. Standards Track [Page 28]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
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
operation of the ASP within an AS. The valid values for Type
shown in the following table
Value
0x1 Over-
0x2 Load-
Within a particular Interface Identifier, only one Traffic Mode
can be used. The Over-ride value indicates that the ASP is
in Over-ride mode, where the ASP takes over all traffic in
Application Server (i.e., primary/back-up operation), over-riding
currently active ASPs in the AS. In Load-share mode, the ASP
share in the traffic distribution with any other currently
ASPs
The optional Interface Identifiers parameter contains a list
Interface Identifier integers (Type 0x1 or Type 0x8) or text
(Type 0x3) indexing the Application Server traffic that the
ASP is configured/registered to receive. If integer
Morneault, et al. Standards Track [Page 29]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
Interface Identifiers are being used, the ASP can also send ranges
Interface Identifiers (Type 0x8). Interface Identifier types
(0x1) and Integer Range (0x8) are allowed in the same message.
formatted Interface Identifiers (0x3) cannot be used with
Integer (0x1) or Integer Range (0x8) types
If no Interface Identifiers are included, the message is for
provisioned Interface Identifiers within the AS(s) in which the
is provisioned. If only a subset of Interface Identifiers
included, the ASP is noted as Active for all the
Identifiers provisioned for that AS
Note: If the optional Interface Identifier parameter is present,
integer formatted Interface Identifier MUST be supported, while
text formatted Interface Identifier MAY be supported
The format and description of the optional Info String parameter
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
a particular Interface Identifier will respond with an Error
(Cause: Unsupported Traffic Handling Mode).
3.3.2.6 ASP Active
The ASPAC Ack message is used to acknowledge an ASP-Active
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,
- string (text formatted
INFO String (Optional
Morneault, et al. Standards Track [Page 30]
RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
The format for the ASPAC Ack message with Integer-formatted
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 |<