summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3057.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3057.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3057.txt')
-rw-r--r--doc/rfc/rfc3057.txt3699
1 files changed, 3699 insertions, 0 deletions
diff --git a/doc/rfc/rfc3057.txt b/doc/rfc/rfc3057.txt
new file mode 100644
index 0000000..641083d
--- /dev/null
+++ b/doc/rfc/rfc3057.txt
@@ -0,0 +1,3699 @@
+
+
+
+
+
+
+Network Working Group K. Morneault
+Request for Comments: 3057 Cisco Systems
+Category: Standards Track S. Rengasami
+ M. Kalla
+ Telcordia Technologies
+ G. Sidebottom
+ Nortel Networks
+ February 2001
+
+
+ ISDN Q.921-User Adaptation Layer
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document defines a protocol for backhauling of ISDN Q.921 User
+ messages over IP using the Stream Control Transmission Protocol
+ (SCTP). This protocol would be used between a Signaling Gateway (SG)
+ and Media Gateway Controller (MGC). It is assumed that the SG
+ 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 Contents
+
+ 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. Introduction
+
+ In this document, the term Q.921-User refers to an upper layer which
+ 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 Scope
+
+ There is a need for Switched Circuit Network (SCN) signaling protocol
+ delivery from an ISDN Signaling Gateway (SG) to a Media Gateway
+ Controller (MGC) as described in the Framework Architecture for
+
+
+
+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 the
+ following criteria:
+
+ * Support for transport of the Q.921 / Q.931 boundary primitives
+ * Support for communication between Layer Management modules on SG
+ and MGC
+ * Support for management of active associations between SG and MGC
+
+ This document supports both ISDN Primary Rate Access (PRA) as well as
+ Basic Rate Access (BRA) including the support for both point-to-point
+ and point-to-multipoint modes of communication. This support
+ includes Facility Associated Signaling (FAS), Non-Facility Associated
+ Signaling (NFAS) and NFAS with backup D channel. QSIG adaptation
+ layer requirements do not differ from Q.931 adaptation layer, hence;
+ the procedures described in this document are also applicable for a
+ QSIG adaptation layer. For simplicity, only Q.931 will be mentioned
+ in the rest of this document.
+
+1.2 Terminology
+
+ Interface - For the purposes of this document an interface supports
+ the relevant ISDN signaling channel. This signaling channel MAY be a
+ 16 kbps D channel for an ISDN BRA as well as 64 kbps primary or
+ backup D channel for an ISDN PRA. For QSIG, the signaling channel is
+ a Qc channel.
+
+ Q.921-User - Any protocol normally using the services of the ISDN
+ Q.921 (e.g., Q.931, QSIG, etc.).
+
+ Backhaul - A SG terminates the lower layers of an SCN protocol and
+ backhauls the upper layer(s) to MGC for call processing. For the
+ purposes of this document the SG terminates Q.921 and backhauls Q.931
+ to MGC.
+
+ Association - An association refers to a SCTP association. The
+ association will provide the transport for the delivery of Q.921-User
+ protocol data units and IUA adaptation layer peer messages.
+
+ Stream - A stream refers to an SCTP stream; a uni-directional logical
+ channel established from one SCTP endpoint to another associated SCTP
+ endpoint, within which all user messages are delivered in-sequence
+ except for those submitted to the un-ordered delivery service.
+
+ Interface Identifier - The Interface Identifier identifies the
+ physical interface at the SG for which the signaling messages are
+ sent/received. The format of the Interface Identifier parameter can
+ be text or integer, the values of which are assigned according to
+
+
+
+
+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 significance
+ only, coordinated between the SG and ASP. Significance is not
+ implied across SGs served by an AS.
+
+ Application Server (AS) - A logical entity serving a specific
+ application instance. An example of an Application Server is a MGC
+ handling the Q.931 and call processing for D channels terminated by
+ the Signaling Gateways. Practically speaking, an AS is modeled at
+ the SG as an ordered list of one or more related Application Server
+ Processes (e.g., primary, secondary, tertiary).
+
+ Application Server Process (ASP) - A process instance of an
+ Application Server. Examples of Application Server Processes are
+ primary or backup MGC instances.
+
+ Fail-over - The capability to re-route signaling traffic as required
+ between related ASPs in the event of failure or unavailability of the
+ currently used ASP (e.g., from primary MGC to back-up MGC). Fail-
+ over also applies upon the return to service of a previously
+ unavailable process.
+
+ Layer Management - Layer Management is a nodal function that handles
+ the inputs and outputs between the IUA layer and a local management
+ 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 Overview
+
+ The architecture that has been defined [4] for SCN signaling
+ transport over IP uses multiple components, including an IP transport
+ protocol, a signaling common transport protocol and an adaptation
+ module to support the services expected by a particular SCN signaling
+ protocol from its underlying protocol layer.
+
+ This document defines an adaptation module that is suitable for the
+ transport of ISDN Q.921-User (e.g., Q.931) messages.
+
+1.3.1 Example - SG to MGC
+
+ In a Signaling Gateway, it is expected that the ISDN signaling is
+ received over a standard ISDN network termination. The SG then
+ provides interworking of transport functions with IP Signaling
+ Transport, in order to transport the Q.931 signaling messages to the
+ 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 Function
+ EP - ISDN End Point
+ SCTP - Stream Control Transmission Protocol (Refer to [3])
+ IUA - ISDN User Adaptation Layer Protocol
+
+ It is recommended that the IUA use the services of the Stream Control
+ Transmission Protocol (SCTP) as the underlying reliable common
+ signaling transport protocol. The use of SCTP provides the following
+ 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 user
+ messages,
+ - optional multiplexing of user messages into SCTP datagrams,
+ - network-level fault tolerance through support of multi-homing
+ at either or both ends of an association,
+ - resistance to flooding and masquerade attacks, and
+ - data segmentation to conform to discovered path MTU size
+
+ There are scenarios without redundancy requirements and scenarios in
+ which redundancy is supported below the transport layer. In these
+ cases, the SCTP functions above MAY NOT be a requirement and TCP can
+ be used as the underlying common transport protocol.
+
+1.3.2 Support for the management of SCTP associations between the SG
+ and ASPs
+
+ The IUA layer at the SG maintains the availability state of all
+ dynamically registered remote ASPs, in order to manage the SCTP
+ Associations and the traffic between the SG and ASPs. As well, the
+ active/inactive state of remote ASP(s) are also maintained. Active
+ 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 an
+ SCTP association to a peer IUA node. This can be achieved using the
+ M-SCTP ESTABLISH primitive to request, indicate and confirm the
+ establishment of an SCTP association with a peer IUA node.
+
+ The IUA layer MAY also need to inform local management of the status
+ of the underlying SCTP associations using the M-SCTP STATUS request
+ and indication primitive. For example, the IUA MAY inform local
+ management of the reason for the release of an SCTP association,
+ determined either locally within the IUA layer or by a primitive from
+ the SCTP.
+
+1.3.3 Signaling Network Architecture
+
+ A Signaling Gateway is used to support the transport of Q.921-User
+ signaling traffic to one or more distributed ASPs (e.g., MGCs).
+ Clearly, the IUA protocol is not designed to meet the performance and
+ reliability requirements for such transport by itself. However, the
+ conjunction of distributed architecture and redundant networks does
+ allow for a sufficiently reliable transport of signaling traffic over
+ IP. The IUA protocol is flexible enough to allow its operation and
+ management in a variety of physical configurations, enabling Network
+ Operators to meet their performance and reliability requirements.
+
+ To meet the ISDN signaling reliability and performance requirements
+ for carrier grade networks, Network Operators SHOULD ensure that
+ there is no single point of failure provisioned in the end-to-end
+ network architecture between an ISDN node and an IP ASP.
+
+ Depending of course on the reliability of the SG and ASP functional
+ elements, this can typically be met by the provision of redundant
+ QOS-bounded IP network paths for SCTP Associations between SCTP End
+ Points, and redundant Hosts, and redundant SGs. The distribution of
+ ASPs within the available Hosts is also important. For a particular
+ Application Server, the related ASPs SHOULD be distributed over at
+ least two Hosts.
+
+ An example logical network architecture relevant to carrier-grade
+ 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
+
+
+ Host1
+ ******** **************
+ * *_________________________________________* ******** *
+ * * _________* * ASP1 * *
+ * SG1 * SCTP Associations | * ******** *
+ * *_______________________ | * *
+ ******** | | **************
+ | |
+ ******** | |
+ * *_______________________________|
+ * * |
+ * SG2 * SCTP Associations |
+ * *____________ |
+ * * | | Host2
+ ******** | | **************
+ | |_________________* ******** *
+ |____________________________* * ASP1 * *
+ * ******** *
+ * *
+ **************
+ .
+ .
+ .
+
+ Figure 2 - Logical Model Example
+
+ For carrier grade networks, the failure or isolation of a particular
+ ASP SHOULD NOT cause stable calls to be dropped. This implies that
+ ASPs need, in some cases, to share the call state or be able to pass
+ the call state between each other. However, this sharing or
+ communication of call state information is outside the scope of this
+ document.
+
+1.3.4 ASP Fail-over Model and Terminology
+
+ The IUA layer supports ASP fail-over functions in order to support a
+ high availability of call processing capability. All Q.921-User
+ messages incoming to an SG are assigned to a unique Application
+ Server, based on the Interface Identifier of the message.
+
+ The Application Server is, in practical terms, a list of all ASPs
+ configured to process Q.921-User messages from certain Interface
+ Identifiers. One or more ASPs in the list are normally active (i.e.,
+ handling traffic) while any others MAY be unavailable or inactive, to
+ be possibly used in the event of failure or unavailability of the
+ 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 traffic
+ and k ASPs are available to take over for a failed or unavailable
+ ASP. Note that 1+1 active/standby redundancy is a subset of this
+ model. A simplex 1+0 model is also supported as a subset, with no
+ ASP redundancy.
+
+ To avoid a single point of failure, it is recommended that a minimum
+ of two ASPs be in the list, resident in separate hosts and therefore
+ available over different SCTP Associations. For example, in the
+ network shown in Figure 2, all messages from a particular D Channel
+ (Interface Identifier) could be sent to ASP1 in Host1 or ASP1 in
+ Host2. The AS list at SG1 might look like the following:
+
+ Interface Identifier(s) - Application Server #1
+ ASP1/Host1 - State=Up, Active
+ ASP1/Host2 - State=Up, Inactive
+
+ In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
+ message for the Interface Identifiers registered. ASP1 in Host2
+ would normally be brought to the active state upon failure of, or
+ loss of connectivity to, ASP1/Host1. In this example, both ASPs are
+ Up, meaning that the related SCTP association and far-end IUA peer is
+ ready.
+
+ The AS List at SG1 might also be set up in load-share mode as shown
+ below:
+
+ Interface Identifier(s) - Application Server #1
+ ASP1/Host1 - State=Up, Active
+ ASP1/Host2 - State=Up, Active
+
+ 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 of
+ ASPs supporting call processing, stable calls do not get released.
+ It is possible that calls in transition MAY fail, although measures
+ of communication between the ASPs involved can be used to mitigate
+ this problem. For example, the two ASPs MAY share call state via
+ shared memory, or MAY use an ASP to ASP protocol to pass call state
+ information. The ASP to ASP protocol is outside the scope of this
+ document.
+
+1.3.5 Client/Server Model
+
+ It is recommended that the SG and ASP be able to support both client
+ and server operation. The peer endpoints using IUA SHOULD be
+ configured so that one always takes on the role of client and the
+
+
+
+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. The
+ default orientation would be for the SG to take on the role of server
+ while the ASP is the client. In this case, ASPs SHOULD initiate the
+ SCTP association to the SG.
+
+ The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
+ is 9900.
+
+1.4 Services Provided by the IUA Layer
+
+1.4.1 Support for transport of Q.921/Q.931 boundary primitives
+
+ In the backhaul scenario, the Q.921/Q.931 boundary primitives are
+ exposed. IUA layer needs to support all of the primitives of this
+ boundary to successfully backhaul Q.931.
+
+ This includes the following primitives [1]:
+
+ DL-ESTABLISH
+
+ The DL-ESTABLISH primitives are used to request, indicate and confirm
+ the outcome of the procedures for establishing multiple frame
+ operation.
+
+ DL-RELEASE
+
+ DL-RELEASE primitives are used to request, indicate, and confirm the
+ outcome of the procedures for terminating a previously established
+ multiple frame operation, or for reporting an unsuccessful
+ establishment attempt.
+
+ DL-DATA
+
+ 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 transfer
+ service.
+
+ DL-UNIT DATA
+
+ 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 layer
+ 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 SG
+ and MGC
+
+ It is envisioned that the IUA layer needs to provide some services
+ that will facilitate communication between Layer Management modules
+ on the SG and MGC. These primitives are pointed out in [2], which
+ are shown below:
+
+ M-TEI STATUS
+
+ The M-TEI STATUS primitives are used to request, confirm and indicate
+ the status (assigned/unassigned) of a TEI.
+
+ M-ERROR
+
+ The M-ERROR primitive is used to indicate an error with a received
+ IUA message (e.g., interface identifier value is not known to the
+ SG).
+
+1.4.3 Support for management of active associations between SG and MGC
+
+ A set of primitives between the IUA layer and the Layer Management
+ are defined below to help the Layer Management manage the SCTP
+ association(s) between the SG and MGC. The IUA layer can be
+ instructed by the Layer Management to establish an SCTP association
+ to a peer IUA node. This procedure can be achieved using the M-SCTP
+ ESTABLISH primitive.
+
+ M-SCTP ESTABLISH
+
+ The M-SCTP ESTABLISH primitives are used to request, indicate, and
+ confirm the establishment of an SCTP association to a peer IUA node.
+
+ M-SCTP RELEASE
+
+ The M-SCTP RELEASE primitives are used to request, indicate, and
+ confirm the release of an SCTP association to a peer IUA node.
+
+ The IUA layer MAY also need to inform the status of the SCTP
+ associations to the Layer Management. This can be achieved using the
+ M-SCTP STATUS primitive.
+
+ M-SCTP STATUS
+
+ The M-SCTP STATUS primitives are used to request and indicate the
+ 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/ASP
+ status (i.e., failure, active, etc.), so that messages can be
+ exchanged between IUA layer peers to stop traffic to the local IUA
+ user. This can be achieved using the M-ASP STATUS primitive.
+
+ M-ASP STATUS
+
+ The ASP status is stored inside IUA layer on both the SG and MGC
+ sides. The M-ASP STATUS primitive can be used by Layer Management to
+ request the status of the Application Server Process from the IUA
+ layer. This primitive can also be used to indicate the status of the
+ Application Server Process.
+
+ M-ASP-UP
+
+ The M-ASP-UP primitive can be used by Layer Management to send a ASP
+ Up message for the Application Server Process. It can also be used
+ to generate an ASP Up Acknowledgement.
+
+ M-ASP-DOWN
+
+ The M-ASP-DOWN primitive can be used by Layer Management to send a
+ ASP Down message for the Application Server Process. It can also be
+ used to generate an ASP Down Acknowledgement.
+
+ M-ASP-ACTIVE
+
+ The M-ASP-UP primitive can be used by Layer Management to send a ASP
+ Active message for the Application Server Process. It can also be
+ used to generate an ASP Active Acknowledgement.
+
+ M-ASP-INACTIVE
+
+ The M-ASP-UP primitive can be used by Layer Management to send a ASP
+ Inactive message for the Application Server Process. It can also be
+ used to generate an ASP Inactive Acknowledgement.
+
+ M-AS STATUS
+
+ The M-AS STATUS primitive can be used by Layer Management to request
+ the status of the Application Server. This primitive can also be
+ 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 Layer
+
+1.5.1 Mapping
+
+ The IUA layer MUST maintain a map of the Interface Identifier to a
+ physical interface on the Signaling Gateway. A physical interface
+ would be a T1 line, E1 line, etc., and could include the TDM
+ timeslot. In addition, for a given interface the SG MUST be able to
+ identify the associated signaling channel. IUA layers on both SG and
+ MGC MAY maintain the status of TEIs and SAPIs.
+
+ The SG maps an Interface Identifier to an SCTP association/stream
+ only when an ASP sends an ASP Active message for a particular
+ Interface Identifier. It MUST be noted, however, that this mapping
+ is dynamic and could change at any time due to a change of ASP state.
+ This mapping could even temporarily be invalid, for example during
+ failover of one ASP to another. Therefore, the SG MUST maintain the
+ states of AS/ASP and reference them during the routing of an messages
+ 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 | v
+ / +----+ | +----+ | +-----+ +-------+ -+--+--+--+-
+ / +->| AS |--+ Streams
+ / +----+ | +----+ stb+-----+
+D chan2-------->|IID |-+ | ASP |
+ +----+ +-----+
+
+ where IID = Interface Identifier
+
+ Note that an ASP can be in more than one AS.
+
+1.5.2 Status of ASPs
+
+ The IUA layer on the SG MUST maintain the state of the ASPs it is
+ supporting. The state of an ASP changes because of reception of
+ peer-to-peer messages (ASPM messages as described in Section 3.3.2)
+ or reception of indications from the local SCTP association. ASP
+ 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 inactive
+ ASPs to support ASP load-sharing and fail-over procedures. When, for
+ example, both a primary and a back-up ASP are available, IUA peer
+ protocol is required to control which ASP is currently active. The
+ ordered list of ASPs within a logical Application Server is kept
+ updated in the SG to reflect the active Application Server
+ Process(es).
+
+ Also the IUA layer MAY need to inform the local management of the
+ 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 Management
+
+ SCTP allows a user specified number of streams to be opened during
+ the initialization. It is the responsibility of the IUA layer to
+ ensure proper management of these streams. Because of the
+ unidirectional nature of streams, an IUA layer is not aware of the
+ 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 to
+ minimize transmission and buffering delay, therefore improving the
+ overall performance and reliability of the signaling elements. It is
+ recommended that a separate SCTP stream is used for each D channel.
+
+1.5.4 Seamless Network Management Interworking
+
+ The IUA layer on the SG SHOULD pass an indication of unavailability
+ of the IUA-User (Q.931) to the local Layer Management, if the
+ currently active ASP moves from the ACTIVE state. The Layer
+ Management could instruct Q.921 to take some action, if it deems
+ appropriate.
+
+ Likewise, if an SCTP association fails, the IUA layer on both the SG
+ and ASP sides MAY generate Release primitives to take the data links
+ out-of-service.
+
+1.5.5 Congestion Management
+
+ If the IUA layer becomes congested (implementation dependent), it MAY
+ stop reading from the SCTP association to flow control from the peer
+ IUA.
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 13]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+1.6 Definition of IUA Boundaries
+
+1.6.1 Definition of IUA/Q.921 boundary
+
+ DL-ESTABLISH
+ DL-RELEASE
+ DL-DATA
+ DL-UNIT DATA
+
+1.6.2 Definition of IUA/Q.931 boundary
+
+ DL-ESTABLISH
+ DL-RELEASE
+ DL-DATA
+ DL-UNIT DATA
+
+1.6.3 Definition of SCTP/IUA Boundary
+
+ An example of the upper layer primitives provided by SCTP are
+ available in Reference [3] section 10.
+
+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.
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 14]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ 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.
+
+
+
+
+Morneault, et al. Standards Track [Page 15]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ 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.0 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
+ [RFC2119].
+
+
+
+Morneault, et al. Standards Track [Page 16]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+3.0 Protocol Elements
+
+ This section describes the format of various messages used in this
+ protocol.
+
+3.1 Common Message Header
+
+ The protocol messages for Q.921-User Adaptation require a message
+ header which contains the adaptation layer version, the message type,
+ and message length.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version | Reserved | Message Class | Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3 Common Header Format
+
+ All fields in an IUA message MUST be transmitted in the network byte
+ order, unless otherwise stated.
+
+3.1.1 Version
+
+ The version field contains the version of the IUA adaptation layer.
+ The supported versions are the following:
+
+ Value Version
+ ----- -------
+ 1 Release 1.0
+
+3.1.2 Message Classes and Types
+
+ The following List contains the valid Message Classes:
+
+ Message Class: 8 bits (unsigned integer)
+
+ 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
+ 1 Transfer Messages [M3UA]
+ 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
+ 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
+ 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
+ 5 Q.921/Q.931 Boundary Primitives Transport (QPTM)
+ Messages [IUA]
+ 6 MTP2 User Adaptation (MAUP) Messages [M2UA]
+ 7 Connectionless Messages [SUA]
+
+
+
+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 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
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 18]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ Management (MGMT) Messages
+
+ 0 Error (ERR)
+ 1 Notify (NTFY)
+ 2 TEI Status Request
+ 3 TEI Status Confirm
+ 4 TEI Status Indication
+ 5 to 127 Reserved by the IETF
+ 128 to 255 Reserved for IETF-Defined MGMT extensions
+
+3.1.3 Reserved
+
+ The Reserved field is 8-bits. It SHOULD be set to all '0's and
+ ignored by the receiver.
+
+3.1.4 Message Length
+
+ The Message length defines the length of the message in octets,
+ including the Common header.
+
+3.1.5 Variable-Length Parameter Format
+
+ IUA messages consist of a Common Header followed by zero or more
+ variable-length parameters, as defined by the message type. The
+ variable-length parameters contained in a message are defined in a
+ Tag-Length-Value format as shown below.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Parameter Tag | Parameter Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ \ \
+ / Parameter Value /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Mandatory parameters MUST be placed before optional parameters in a
+ message.
+
+ Parameter Tag: 16 bits (unsigned integer)
+
+ The Tag field is a 16 bit identifier of the type of parameter. It
+ takes a value of 0 to 65534.
+
+ The value of 65535 is reserved for IETF-defined extensions. Values
+ other than those defined in specific parameter description are
+ reserved for use by the IETF.
+
+
+
+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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+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. The
+ length is always set to a value of 8.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x3) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifier (text) |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x5) | Length=8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DLCI | Spare |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5 IUA Message Header (Text-based Interface Identifier)
+
+ The Tag value for the Text-based Interface Identifier is 0x3. The
+ length is variable.
+
+ The DLCI format is shown below in Figure 6.
+
+ 0 1 2 3 4 5 6 7
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | 0 | SPR | SAPI |
+ +-----------------------------------------------+
+ | 1 | TEI |
+ +-----------------------------------------------+
+
+ Figure 6 DLCI Format
+
+ SPR: Spare 2nd bit in octet 1, (1 bit)
+
+
+
+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 octet
+ 1 (6 bits)
+
+ TEI: Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
+ (7 bits)
+
+ The DLCI field (including the SAPI and TEI) is coded in accordance
+ with Q.921.
+
+3.3 IUA Messages
+
+ The following section defines the messages and parameter contents.
+ The IUA messages will use the common message header (Figure 3) and
+ the IUA message header (Figure 4 and Figure 5).
+
+3.3.1 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
+
+3.3.1.1 Establish Messages (Request, Confirm, Indication)
+
+ The Establish Messages are used to establish a data link on the
+ signaling channel or to confirm that a data link on the signaling
+ channel has been established. The MGC controls the state of the D
+ channel. When the MGC desires the D channel to be in-service, it
+ will send the Establish Request message.
+
+ When the MGC sends an IUA Establish Request message, the MGC MAY
+ start a timer. This timer would be stopped upon receipt of an IUA
+ Establish Confirm or Establish Indication. If the timer expires, the
+ MGC would re-send the IUA Establish Request message and restart the
+ timer. In other words, the MGC MAY continue to request the
+ establishment of the data link on periodic basis until the desired
+ state is achieved or take some other action (notify the Management
+ Layer).
+
+ When the SG receives an IUA Establish Request from the MGC, the SG
+ shall send the Q.921 Establish Request primitive to the its Q.921
+ entity. In addition, the SG shall map any response received from the
+ Q.921 entity to the appropriate message to the MGC. For example, if
+ the Q.921 entity responds with a Q.921 Establish Confirm primitive,
+ the IUA layer shall map this to an IUA Establish Confirm message. As
+ another example, if the IUA Layer receives a Q.921 Release Confirm or
+ Release Indication as an apparent response to the Q.921 Establish
+ Request primitive, the IUA Layer shall map these to the corresponding
+ IUA Release Confirm or Release Indication messages.
+
+ The Establish messages contain the common message header followed by
+ IUA message header. It does not contain any additional parameters.
+
+
+
+
+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 the
+ signaling channel. The Release Confirm and Indication messages are
+ used to indicate that the data link on the signaling channel has been
+ released.
+
+ If a response to the Release Request message is not received, the MGC
+ MAY resend the Release Request message. If no response is received,
+ the MGC can consider the data link as being released. In this case,
+ signaling traffic on that D channel is not expected from the SG and
+ signaling traffic will not be sent to the SG for that D channel.
+
+ The Release messages contain the common message header followed by
+ IUA message header. The Release confirm message is in response to a
+ Release Request message and it does not contain any additional
+ parameters. The Release Request and Indication messages contain the
+ following parameter:
+
+ REASON
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xf) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reason |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The valid values for Reason are shown in the following table.
+
+ Define Value Description
+ RELEASE_MGMT 0x0 Management layer generated release.
+ RELEASE_PHYS 0x1 Physical layer alarm generated release.
+ RELEASE_DM 0x2 Specific to a request. Indicates Layer 2
+ SHOULD release and deny all requests from
+ far end to establish a data link on the
+ signaling channel (i.e., if SABME is
+ received send a DM)
+ RELEASE_OTHER 0x3 Other reasons
+
+ Note: Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid
+ reason codes for a Release Request message.
+
+3.3.1.3 Data Messages (Request, Indication)
+
+ The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU)
+ corresponding to acknowledged information transfer service.
+
+
+
+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 IUA
+ message header. The Data message contains the following parameters:
+
+ PROTOCOL DATA
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xe) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Protocol Data |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The protocol data contains upper layer signaling message e.g. Q.931,
+ QSIG.
+
+3.3.1.4 Unit Data Messages (Request, Indication)
+
+ The Unit Data message contains an ISDN Q.921-User Protocol Data Unit
+ (PDU) corresponding to unacknowledged information transfer service.
+
+ The Unit Data messages contain the common message header followed by
+ IUA message header. The Unit Data message contains the following
+ parameters
+
+ PROTOCOL DATA
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xe) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Protocol Data |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.3.2 Application Server Process Maintenance (ASPM) Messages
+
+ The ASPM messages will only use the common message header.
+
+3.3.2.1 ASP Up (ASPUP)
+
+ The ASP Up (ASPUP) message is sent by an ASP to indicate to an SG
+ that it is ready to receive traffic or maintenance messages.
+
+
+
+
+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-bit
+ ASCII character string along with the message. Length of the INFO
+ String parameter is from 0 to 255 characters. No procedures are
+ presently identified for its use but the INFO String MAY be used for
+ debugging purposes.
+
+3.3.2.2 ASP Up Ack
+
+ The ASP Up Ack message is used to acknowledge an ASP Up message
+ received from a remote IUA peer.
+
+ The ASPUP Ack message contains the following parameters:
+
+ INFO String (optional)
+
+ The format for ASPUP Ack Message parameters is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The format and description of the optional Info String parameter is
+ the same as for the ASP Up message (See Section 3.3.3.1).
+
+
+
+
+
+
+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 SG
+ that it is NOT ready to receive traffic or maintenance messages.
+
+ The ASPDN message contains the following parameters:
+
+ Reason
+ INFO String (Optional)
+
+ The format for the ASPDN message parameters is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xa) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reason |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The format and description of the optional Info String parameter is
+ the same as for the ASP Up message (See Section 3.3.3.1.).
+
+ The Reason parameter indicates the reason that the remote IUA
+ adaptation layer is unavailable. The valid values for Reason are
+ shown in the following table.
+
+ Value Description
+ 0x1 Management Inhibit
+
+ If a ASP is removed from Management Inhibit, the ASP will send an ASP
+ Up message.
+
+3.3.2.4 ASP Down Ack
+
+ The ASP Down Ack message is used to acknowledge an ASP Down message
+ received from a remote IUA peer.
+
+ The ASP Down Ack message contains the following parameters:
+
+ Reason
+ INFO String (Optional)
+
+
+
+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 is
+ the same as for the ASP Up message (See Section 3.3.2.1.).
+
+ The format of the Reason parameter is the same as for the ASP Down
+ message (See Section 3.3.2.3).
+
+3.3.2.5 ASP Active (ASPAC)
+
+ The ASPAC message is sent by an ASP to indicate to an SG that it is
+ Active and ready to be used.
+
+ The ASPAC message contains the following parameters
+
+ Traffic Mode Type (Mandatory)
+ Interface Identifier (Optional)
+ - Combination of integer and integer ranges, OR
+ - string (text formatted)
+ INFO String (Optional)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 Interface
+ Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xb) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Traffic Mode Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x1=integer) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifiers* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x8=integer range) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StartN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StopN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x1 or 0x8 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+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 of
+ operation of the ASP within an AS. The valid values for Type are
+ shown in the following table:
+
+ Value Description
+ 0x1 Over-ride
+ 0x2 Load-share
+
+ Within a particular Interface Identifier, only one Traffic Mode Type
+ can be used. The Over-ride value indicates that the ASP is operating
+ in Over-ride mode, where the ASP takes over all traffic in an
+ Application Server (i.e., primary/back-up operation), over-riding any
+ currently active ASPs in the AS. In Load-share mode, the ASP will
+ share in the traffic distribution with any other currently active
+ ASPs.
+
+ The optional Interface Identifiers parameter contains a list of
+ Interface Identifier integers (Type 0x1 or Type 0x8) or text strings
+ (Type 0x3) indexing the Application Server traffic that the sending
+ ASP is configured/registered to receive. If integer formatted
+
+
+
+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 of
+ Interface Identifiers (Type 0x8). Interface Identifier types Integer
+ (0x1) and Integer Range (0x8) are allowed in the same message. Text
+ formatted Interface Identifiers (0x3) cannot be used with either
+ Integer (0x1) or Integer Range (0x8) types.
+
+ If no Interface Identifiers are included, the message is for all
+ provisioned Interface Identifiers within the AS(s) in which the ASP
+ is provisioned. If only a subset of Interface Identifiers are
+ included, the ASP is noted as Active for all the Interface
+ Identifiers provisioned for that AS.
+
+ Note: If the optional Interface Identifier parameter is present, the
+ integer formatted Interface Identifier MUST be supported, while the
+ text formatted Interface Identifier MAY be supported.
+
+ The format and description of the optional Info String parameter is
+ the same as for the ASP Up message (See Section 3.3.2.1.).
+
+ An SG that receives an ASPAC with an incorrect Traffic Mode Type for
+ a particular Interface Identifier will respond with an Error Message
+ (Cause: Unsupported Traffic Handling Mode).
+
+3.3.2.6 ASP Active Ack
+
+ The ASPAC Ack message is used to acknowledge an ASP-Active message
+ received from a remote IUA peer.
+
+ The ASPAC Ack message contains the following parameters:
+
+ Traffic Mode Type (Mandatory)
+ Interface Identifier (Optional)
+ - Combination of integer and integer ranges, OR
+ - string (text formatted)
+ INFO String (Optional)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 Interface
+ Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xb) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Traffic Mode Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x1=integer) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifiers* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x8=integer range) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StartN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StopN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x1 or 0x8 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 31]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The format for the ASP Active Ack message using text formatted
+ (string) Interface Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xb) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Traffic Mode Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x3=string) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifier* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x3 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The format of the Traffic Mode Type and Interface Identifier
+ parameters is the same as for the ASP Active message (See Section
+ 3.3.2.5).
+
+ The format and description of the optional Info String parameter is
+ the same as for the ASP Up message (See Section 3.3.2.1.).
+
+3.3.2.7 ASP Inactive (ASPIA)
+
+ The ASPIA message is sent by an ASP to indicate to an SG that it is
+ no longer an active ASP to be used from within a list of ASPs. The
+ SG will respond with an ASPIA Ack message and either discard incoming
+ messages or buffer for a timed period and then discard.
+
+ The ASPIA message contains the following parameters
+
+ Traffic Mode Type (Mandatory)
+ Interface Identifiers (Optional)
+ - Combination of integer and integer ranges, OR
+ - string (text formatted)
+
+
+
+Morneault, et al. Standards Track [Page 32]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ INFO String (Optional)
+
+ The format for the ASP Inactive message parameters using Integer
+ formatted Interface Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xb) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Traffic Mode Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x1=integer) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifiers* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x8=integer range) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StartN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StopN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x1 or 0x8 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Morneault, et al. Standards Track [Page 33]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The format for the ASP Inactive message using text formatted (string)
+ Interface Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xb) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Traffic Mode Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x3=string) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifier* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x3 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Traffic Mode Type parameter identifies the traffic mode of
+ operation of the ASP within an AS. The valid values for Traffic Mode
+ Type are shown in the following table:
+
+ Value Description
+ 0x1 Over-ride
+ 0x2 Load-share
+
+ The format and description of the optional Interface Identifiers and
+ Info String parameters is the same as for the ASP Active message (See
+ Section 3.3.2.3.).
+
+ The optional Interface Identifiers parameter contains a list of
+ Interface Identifier integers or text strings indexing the
+ Application Server traffic that the sending ASP is
+ configured/registered to receive, but does not want to receive at
+ this time.
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 34]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+3.3.2.8 ASP Inactive Ack
+
+ The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP
+ Inactive message received from a remote IUA peer.
+
+ The ASPIA Ack message contains the following parameters:
+
+ Traffic Mode Type (Mandatory)
+ Interface Identifiers (Optional)
+ - Combination of integer and integer ranges, OR
+ - string (text formatted)
+ INFO String (Optional)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 35]
+
+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 (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 36]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The format for the ASP Inactive Ack message using text formatted
+ (string) Interface Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xb) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Traffic Mode Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x3=string) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifier* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x3 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The format of the Traffic Mode Type and Interface Identifier
+ parameters is the same as for the ASP Inactive message (See Section
+ 3.3.2.7).
+
+ The format and description of the optional Info String parameter is
+ the same as for the ASP Up message (See Section 3.3.2.1).
+
+3.3.2.9 Heartbeat (BEAT)
+
+ The Heartbeat message is optionally used to ensure that the IUA peers
+ are still available to each other. It is recommended for use when
+ the IUA runs over a transport layer other than the SCTP, which has
+ its own heartbeat.
+
+ The BEAT message contains the following parameters:
+
+ Heartbeat Data Optional
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 37]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The format for the BEAT message is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag = 9 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ \ \
+ | Heartbeat Data * |
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Heartbeat Data parameter contents are defined by the sending
+ node. The Heartbeat Data could include, for example, a Heartbeat
+ Sequence Number and, or Timestamp. The receiver of a Heartbeat
+ message does not process this field as it is only of significance to
+ the sender. The receiver MUST respond with a Heartbeat Ack message.
+
+3.3.2.10 Heartbeat Ack (BEAT-Ack)
+
+ The Heartbeat Ack message is sent in response to a received Heartbeat
+ message. It includes all the parameters of the received Heartbeat
+ message, without any change.
+
+3.3.3 Layer Management (MGMT) Messages
+
+3.3.3.1 Error (ERR)
+
+ The Error message is used to notify a peer of an error event
+ associated with an incoming message. For example, the message type
+ might be unexpected given the current state, or a parameter value
+ might be invalid.
+
+ The Error message will only have the common message header. The
+ Error message contains the following parameters:
+
+ Error Code
+ Diagnostic Information (optional)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 38]
+
+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 (0xc) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Error Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x7) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Diagnostic Information* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Error Code parameter indicates the reason for the Error Message.
+ The Error parameter value can be one of the following values:
+
+ Invalid Version 0x01
+ Invalid Interface Identifier 0x02
+ Unsupported Message Class 0x03
+ Unsupported Message Type 0x04
+ Unsupported Traffic Handling Mode 0x05
+ Unexpected Message 0x06
+ Protocol Error 0x07
+ Unsupported Interface Identifier Type 0x08
+ Invalid Stream Identifier 0x09
+ Unassigned TEI 0x0a
+ Unrecognized SAPI 0x0b
+ Invalid TEI, SAPI combination 0x0c
+
+ The "Invalid Version" error would be sent if a message was received
+ with an invalid or unsupported version. The Error message would
+ contain the supported version in the Common header. The Error
+ message could optionally provide the supported version in the
+ Diagnostic Information area.
+
+ The "Invalid Interface Identifier" error would be sent by a SG if an
+ ASP sends a message with an invalid (unconfigured) Interface
+ Identifier value.
+
+ The "Unsupported Traffic Handling Mode" error would be sent by a SG
+ if an ASP sends an ASP Active with an unsupported Traffic Handling
+ Mode. An example would be a case in which the SG did not support
+ load-sharing.
+
+ The "Unexpected Message" error would be sent by an ASP if it received
+ a QPTM message from an SG while it was in the Inactive state (the ASP
+ could optionally drop the message and not send an Error). It would
+
+
+
+Morneault, et al. Standards Track [Page 39]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ also be sent by an ASP if it received a defined and recognized
+ message that the SG is not expected to send (e.g., if the MGC
+ receives an IUA Establish Request message).
+
+ The "Protocol Error" error would be sent for any protocol anomaly
+ (i.e., a bogus message).
+
+ The "Invalid Stream Identifier" error would be sent if a message was
+ received on an unexpected SCTP stream (i.e., a MGMT message was
+ received on a stream other than "0").
+
+ The "Unsupported Interface Identifier Type" error would be sent by a
+ SG if an ASP sends a Text formatted Interface Identifier and the SG
+ only supports Integer formatted Interface Identifiers. When the ASP
+ receives this error, it will need to resend its message with an
+ Integer formatted Interface Identifier.
+
+ The "Unsupported Message Type" error would be sent if a message with
+ an unexpected or unsupported Message Type is received.
+
+ The "Unsupported Message Class" error would be sent if a message with
+ an unexpected or unsupported Message Class is received.
+
+ The "Unassigned TEI" error may be used when the SG receives an IUA
+ message that includes a TEI which has not been assigned or recognized
+ for use on the indicated ISDN D-channel.
+
+ The "Unrecognized SAPI" error would handle the case of using a SAPI
+ that is not recognized by the SG. The "Invalid TEI, SAPI
+ combination" error identify errors where the TEI is assigned and the
+ the SAPI is recognized, but the combination is not valid for the
+ interface (e.g., on a BRI the MGC tries to send Q.921 Management
+ messages via IUA when Layer Management at the SG SHOULD be performing
+ this function).
+
+ The optional Diagnostic information can be any information germane to
+ the error condition, to assist in identification of the error
+ condition. To enhance debugging, the Diagnostic information could
+ contain the first 40 bytes of the offending message.
+
+3.3.3.2 Notify (NTFY)
+
+ The Notify message used to provide an autonomous indication of IUA
+ events to an IUA peer.
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 40]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The Notify message will only use the common message header. The
+ Notify message contains the following parameters:
+
+ Status Type
+ Status Identification
+ Interface Identifiers (Optional)
+ INFO String (Optional)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 41]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The format for the Notify message with Integer-formatted Interface
+ Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xd) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status Type | Status Identification |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x1=integer) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifiers* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x8=integer range) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop1* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Start2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier Stop2* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . .
+ . .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StartN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier StopN* |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x1 or 0x8 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 42]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The format for the Notify message with Text-formatted Interface
+ Identifiers is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0xd) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status Type | Status Identification |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x3=string) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Interface Identifier* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | Additional Interface Identifiers |
+ | of Tag Type 0x3 |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x4) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ | INFO String* |
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Status Type parameter identifies the type of the Notify message.
+ The following are the valid Status Type values:
+
+ Value Description
+ 0x1 Application Server state change (AS_State_Change)
+ 0x2 Other
+
+ The Status Identification parameter contains more detailed
+ information for the notification, based on the value of the Status
+ Type. If the Status Type is AS_State_Change the following Status
+ Identification values are used:
+
+ Value Description
+ 1 Application Server Down (AS_Down)
+ 2 Application Server Inactive (AS_Inactive)
+ 3 Application Server Active (AS_Active)
+ 4 Application Server Pending (AS_Pending)
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 43]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ These notifications are sent from an SG to an ASP upon a change in
+ status of a particular Application Server. The value reflects the
+ new state of the Application Server.
+
+ If the Status Type is Other, then the following Status Information
+ values are defined:
+
+ Value Description
+ 1 Insufficient ASP resources active in AS
+ 2 Alternate ASP Active
+
+ These notifications are not based on the SG reporting the state
+ change of an ASP or AS. In the Insufficient ASP Resources case, the
+ SG is indicating to an "Inactive" ASP(s) in the AS that another ASP
+ is required in order to handle the load of the AS (Load-sharing
+ mode). For the Alternate ASP Active case, an ASP is informed when an
+ alternate ASP transitions to the ASP-Active state in Over-ride mode.
+
+ The format and description of the optional Interface Identifiers and
+ Info String parameters is the same as for the ASP Active message (See
+ Section 3.3.2.3.).
+
+3.3.3.3 TEI Status Messages (Request, Confirm and Indication)
+
+ The TEI Status messages are exchanged between IUA layer peers to
+ request, confirm and indicate the status of a particular TEI.
+
+ The TEI Status messages contain the common message header followed by
+ IUA message header. The TEI Status Request message does not contain
+ any additional parameters.
+
+ In the integrated ISDN Layer 2/3 model (e.g., in traditional ISDN
+ switches), it is assumed that the Layer Management for the Q.921
+ Layer and the Q.931 layer are co-located. When backhauling ISDN,
+ this assumption is not necessarily valid. The TEI status messages
+ allow the two Layer Management entities to communicate the status of
+ the TEI. In addition, knowing that a TEI is in service allows the
+ ASP to request the SG to establish the datalink to the terminal (via
+ the IUA Establish message) for signaling if the ASP wants to be in
+ control of data link establishment. Another use of the TEI status
+ procedure is where the Layer Management at the ASP can prepare for
+ send/receive signaling to/from a given TEI and confirm/verify the
+ establishment of a datalink to that TEI. For example, if a datalink
+ is established for a TEI that the ASP did not know was assigned, the
+ ASP can check to see whether it was assigned or whether there was an
+ error in the signaling message. Also, knowing that a TEI is out of
+ service, the ASP need not request the SG to establish a datalink to
+ that TEI.
+
+
+
+Morneault, et al. Standards Track [Page 44]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The TEI Status Indication, and Confirm messages contain the following
+ parameter:
+
+ STATUS
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x10) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The valid values for Status are shown in the following table.
+
+ Define Value Description
+ ASSIGNED 0x0 TEI is considered assigned by Q.921
+ UNASSIGNED 0x1 TEI is considered unassigned by Q.921
+
+4.0 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" 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.
+
+
+
+
+
+Morneault, et al. Standards Track [Page 45]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+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 set-
+ up is complete. An M-SCTP ESTABLISH indication is sent to Layer
+ Management upon successful completion of an incoming SCTP association
+ set-up from a peer IUA node
+
+ An M-SCTP RELEASE request from Layer Management will initiate the
+ tear-down 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 tear-down 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.
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 46]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ Upon receipt of a 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
+
+ The ASP state transition diagram is shown in Figure 7. The possible
+ states of an ASP are the following:
+
+
+
+
+
+Morneault, et al. Standards Track [Page 47]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ 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 messages.
+
+ ASP-INACTIVE: The remote IUA peer at the ASP is available (and the
+ related SCTP association is up) but application traffic is stopped.
+ In this state the ASP can be sent any non-QPTM IUA messages (except
+ for TEI Status messages).
+
+ ASP-ACTIVE: The remote IUA peer at the ASP is available and
+ application traffic is active.
+
+ Figure 7 ASP State Transition Diagram
+
+ +-------------+
+ +----------------------| |
+ | Alternate +-------| ASP-ACTIVE |
+ | ASP | +-------------+
+ | Takeover | ^ |
+ | | ASP | | ASP
+ | | Active | | Inactive
+ | | | v
+ | | +-------------+
+ | | | |
+ | +------>| ASP-INACT |
+ | +-------------+
+ | ^ |
+ ASP Down/ | ASP | | ASP Down /
+ SCTP CDI | Up | | SCTP CDI
+ | | v
+ | +-------------+
+ +--------------------->| |
+ | ASP-DOWN |
+ +-------------+
+
+ SCTP CDI: The local SCTP layer's Communication Down Indication to
+ the Upper Layer Protocol (IUA) on an SG. The local SCTP will send
+ this indication when it detects the loss of connectivity to the ASP's
+ peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN
+ COMPLETE notification and COMMUNICATION LOST notification from the
+ SCTP.
+
+4.3.1.2 AS States
+
+ The state of the AS is maintained in the IUA layer on the SG.
+
+ The state of an AS changes due to events. These events include the
+ following:
+
+
+
+Morneault, et al. Standards Track [Page 48]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ * ASP state transitions
+ * Recovery timer triggers
+
+ The possible states of an AS are the following:
+
+ AS-DOWN: The Application Server is unavailable. This state implies
+ that all related ASPs are in the ASP-DOWN state for this AS.
+ Initially the AS will be in this state.
+
+ AS-INACTIVE: The Application Server is available but no application
+ traffic is active (i.e., one or more related ASPs are in the ASP-
+ INACTIVE state, but none in the ASP-ACTIVE state). The recovery
+ timer T(r) is not running or has expired.
+
+ AS-ACTIVE: The Application Server is available and application
+ traffic is active. This state implies that at least one ASP is in
+ the ASP-ACTIVE state.
+
+ AS-PENDING: An active ASP has transitioned from active to inactive or
+ down and it was the last remaining active ASP in the AS. A recovery
+ timer T(r) will be started and all incoming SCN messages will be
+ queued by the SG. If an ASP becomes active before T(r) expires, the
+ AS will move to AS-ACTIVE state and all the queued messages will be
+ sent to the active ASP.
+
+ If T(r) expires before an ASP becomes active, the SG stops queuing
+ messages and discards all previously queued messages. The AS will
+ move to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state,
+ otherwise it will move to AS-DOWN state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 49]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ Figure 8 AS State Transition Diagram
+
+ +----------+ one ASP trans ACTIVE +-------------+
+ | |------------------------>| |
+ | AS-INACT | | AS-ACTIVE |
+ | | | |
+ | |< | |
+ +----------+ \ +-------------+
+ ^ | \ Tr Trigger ^ |
+ | | \ at least one | |
+ | | \ ASP in UP | |
+ | | \ | |
+ | | \ | |
+ | | \ | |
+ one ASP | | \ one ASP | | Last ACTIVE ASP
+ trans | | all ASP \------\ trans to | | trans to INACT
+ to | | trans to \ ACTIVE | | or DOWN
+ INACT | | DOWN \ | | (start Tr timer)
+ | | \ | |
+ | | \ | |
+ | | \ | |
+ | v \ | v
+ +----------+ \ +-------------+
+ | | -| |
+ | AS-DOWN | | AS-PENDING |
+ | | | (queueing) |
+ | |<------------------------| |
+ +----------+ Tr Expiry and no +-------------+
+ ASP in INACTIVE state
+
+ Tr = Recovery Timer
+
+4.3.2 ASPM procedures for primitives
+
+ Before the establishment of an SCTP association the ASP state at both
+ the SG and ASP is assumed to be "Down".
+
+ As the ASP is responsible for initiating the setup of an SCTP
+ association to an SG, the IUA layer at an ASP receives an M-SCTP
+ ESTABLISH request primitive from the Layer Management, the IUA layer
+ will try to establish an SCTP association with the remote IUA peer at
+ an SG. Upon reception of an eventual SCTP-Communication Up confirm
+ primitive from the SCTP, the IUA layer will invoke the primitive M-
+ SCTP ESTABLISH confirm to the Layer Management.
+
+ At the SG, the IUA layer will receive an SCTP Communication Up
+ indication primitive from the SCTP. The IUA layer will then invoke
+ the primitive M-SCTP ESTABLISH indication to the Layer Management.
+
+
+
+Morneault, et al. Standards Track [Page 50]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ Once the SCTP association is established and assuming that the local
+ IUA-User is ready, the local ASP IUA Application Server Process
+ Maintenance (ASPM) function will initiate the ASPM procedures, using
+ the ASP Up/-Down/-Active/-Inactive messages to convey the ASP state
+ to the SG - see Section 4.3.3.
+
+ The Layer Management and the IUA layer on SG can communicate the
+ status of the application server using the M-AS STATUS primitives.
+ The Layer Management and the IUA layer on both the SG and ASP can
+ communicate the status of an SCTP association using the M-SCTP STATUS
+ primitives.
+
+ If the Layer Management on SG or ASP wants to bring down an SCTP
+ association for management reasons, they would send M-SCTP RELEASE
+ request primitive to the local IUA layer. The IUA layer would
+ release the SCTP association and upon receiving the SCTP
+ Communication Down indication from the underlying SCTP layer, it
+ would inform the local Layer Management using M-SCTP RELEASE confirm
+ primitive.
+
+ If the IUA layer receives an SCTP-Communication Down indication from
+ the underlying SCTP layer, it will inform the Layer Management by
+ invoking the M-SCTP RELEASE indication primitive. The state of the
+ ASP will be moved to "Down" at both the SG and ASP.
+
+ At an ASP, the Layer Management MAY try to reestablish the SCTP
+ association using M-SCTP ESTABLISH request primitive.
+
+4.3.3 ASPM procedures for peer-to-peer messages
+
+ All ASPM messages are sent on a sequenced stream to ensure ordering.
+ SCTP stream '0' SHOULD be used.
+
+4.3.3.1 ASP Up
+
+ After an ASP has successfully established an SCTP association to an
+ SG, the SG waits for the ASP to send an ASP Up message, indicating
+ that the ASP IUA peer is available. The ASP is always the initiator
+ of the ASP Up exchange.
+
+ When an ASP Up message is received at an SG and internally the remote
+ ASP is not considered locked-out for local management reasons, the SG
+ marks the remote ASP as "Inactive". The SG responds with an ASP Up
+ Ack message in acknowledgement. The SG sends an ASP-Up Ack message
+ in response to a received ASP Up message even if the ASP is already
+ marked as "Inactive" at the SG.
+
+
+
+
+
+Morneault, et al. Standards Track [Page 51]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ If for any local reason the SG cannot respond with an ASP Up, the SG
+ responds to a ASP Up with a with an ASP-Down Ack message with Reason
+ "Management Blocking".
+
+ At the ASP, the ASP Up Ack message received from the SG is not
+ acknowledged by the ASP. If the ASP does not receive a response from
+ the SG, or an ASP Down Ack is received, the ASP MAY resend ASP Up
+ messages every 2 seconds until it receives a ASP Up Ack message from
+ the SG. The ASP MAY decide to reduce the frequency (say to every 5
+ seconds) if an ASP Up Ack is not received after a few tries.
+
+ The ASP MUST wait for the ASP Up Ack message from the SG before
+ sending any ASP traffic control messages (ASPAC or ASPIA) or Data
+ messages or it will risk message loss. If the SG receives QPTM, ASP
+ Active or ASP Inactive messages before an ASP Up is received, the SG
+ SHOULD discard these messages.
+
+4.3.3.2 ASP Down
+
+ The ASP will send an ASP Down to an SG when the ASP is to be removed
+ from the list of ASPs in all Application Servers that it is a member
+ and no longer receive any IUA traffic or management messages.
+
+ Whether the ASP is permanently removed from an AS is a function of
+ configuration management.
+
+ The SG marks the ASP as "Down" and returns an ASP Down Ack message to
+ the ASP if one of the following events occur:
+
+ - to acknowledge an ASP Down message from an ASP,
+ - to reply to ASPM messages from an ASP which is locked out for
+ management reasons.
+
+ The SG sends an ASP Down Ack message in response to a received ASP
+ Down message from the ASP even if the ASP is already marked as "Down"
+ at the SG.
+
+ If the ASP does not receive a response from the SG, the ASP MAY send
+ ASP Down messages every 2 seconds until it receives an ASP Down Ack
+ message from the SG or the SCTP association goes down. The ASP MAY
+ decide to reduce the frequency (say to every 5 seconds) if an ASP
+ Down Ack is not received after a few tries.
+
+4.3.3.3 IUA Version Control
+
+ If a ASP Up message with an unsupported version is received, the
+ receiving end responds with an Error message, indicating the version
+ the receiving node supports and notifies Layer Management.
+
+
+
+Morneault, et al. Standards Track [Page 52]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ This is useful when protocol version upgrades are being performed in
+ a network. A node upgraded to a newer version SHOULD support the
+ older versions used on other nodes it is communicating with. Because
+ ASPs initiate the ASP Up procedure it is assumed that the Error
+ message would normally come from the SG.
+
+4.3.3.4 ASP Active
+
+ Any time after the ASP has received a ASP Up Ack from the SG, the ASP
+ sends an ASP-Active (ASPAC) to the SG indicating that the ASP is
+ ready to start processing traffic. In the case where an ASP is
+ configured/registered to process the traffic for more than one
+ Application Server across an SCTP association, the ASPAC contains one
+ or more Interface Identifiers to indicate for which Application
+ Servers the ASPAC applies.
+
+ When an ASP Active (ASPAC) message is received, the SG responds to
+ the ASP with a ASPAC Ack message acknowledging that the ASPAC was
+ received and starts sending traffic for the associated Application
+ Server(s) to that ASP.
+
+ The ASP MUST wait for the ASP-Active Ack message from the SG before
+ sending any Data messages or it will risk message loss. If the SG
+ receives QPTM messages before an ASP Active is received, the SG
+ SHOULD discard these messages.
+
+ There are two modes of Application Server traffic handling in the SG
+ IUA - Over-ride and Load-sharing. The Type parameter in the ASPAC
+ message indicates the mode used in a particular Application Server.
+ If the SG determines that the mode indicates in an ASPAC is
+ incompatible with the traffic handling mode currently used in the AS,
+ the SG responds with an Error message indicating Unsupported Traffic
+ Handling Mode.
+
+ In the case of an Over-ride mode AS, reception of an ASPAC message at
+ an SG causes the redirection of all traffic for the AS to the ASP
+ that sent the ASPAC. The SG responds to the ASPAC with an ASP-Active
+ Ack message to the ASP. Any previously active ASP in the AS is now
+ considered Inactive and will no longer receive traffic from the SG
+ within the AS. The SG sends a Notify (Alternate ASP-Active) to the
+ previously active ASP in the AS, after stopping all traffic to that
+ ASP.
+
+ In the case of a load-share mode AS, reception of an ASPAC message at
+ an SG causes the direction of traffic to the ASP sending the ASPAC,
+ in addition to all the other ASPs that are currently active in the
+ AS. The algorithm at the SG for load-sharing traffic within an AS to
+ all the active ASPs is implementation dependent. The algorithm
+
+
+
+Morneault, et al. Standards Track [Page 53]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ could, for example be round-robin or based on information in the Data
+ message, such as Interface Identifier, depending on the requirements
+ of the application and the call state handling assumptions of the
+ collection of ASPs in the AS. The SG responds to the ASPAC with a
+ ASP-Active Ack message to the ASP.
+
+4.3.3.5 ASP Inactive
+
+ When an ASP wishes to withdraw from receiving traffic within an AS,
+ the ASP sends an ASP Inactive (ASPIA) to the SG. In the case where
+ an ASP is configured/registered to process the traffic for more than
+ one Application Server across an SCTP association, the ASPIA contains
+ one or more Interface Identifiers to indicate for which Application
+ Servers the ASPIA applies.
+
+ There are two modes of Application Server traffic handling in the SG
+ IUA when withdrawing an ASP from service - Over-ride and Load-
+ sharing. The Type parameter in the ASPIA message indicates the mode
+ used in a particular Application Server. If the SG determines that
+ the mode indicates in an ASPAC is incompatible with the traffic
+ handling mode currently used in the AS, the SG responds with an Error
+ message indicating Unsupported Traffic Handling Mode.
+
+ In the case of an Over-ride mode AS, where normally another ASP has
+ already taken over the traffic within the AS with an Over-ride ASPAC,
+ the ASP which sends the ASPIA is already considered by the SG to be
+ "Inactive". An ASPIA Ack message is sent to the ASP, after ensuring
+ that all traffic is stopped to the ASP.
+
+ In the case of a Load-share mode AS, the SG moves the ASP to the
+ "Inactive" state and the AS traffic is re-allocated across the
+ remaining "active" ASPs per the load-sharing algorithm currently used
+ within the AS. An ASPIA Ack message is sent to the ASP after all
+ traffic is halted to the ASP. A NTFY (Insufficient ASPs) MAY be sent
+ to all inactive ASPs, if required.
+
+ If no other ASPs are Active in the Application Server, the SG sends a
+ NTFY (AS-Pending) to all inactive ASPs of the AS and either discards
+ all incoming messages for the AS or starts buffering the incoming
+ messages for T(r)seconds, after which messages will be discarded.
+ T(r) is configurable by the network operator. If the SG receives an
+ ASPAC from an ASP in the AS before expiry of T(r), the buffered
+ traffic is directed to the ASP and the timer is cancelled. If T(r)
+ expires, the AS is moved to the "Inactive" state.
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 54]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+4.3.3.6 Notify
+
+ A Notify message reflecting a change in the AS state is sent to all
+ ASPs in the AS, except those in the "Down" state, with appropriate
+ Status Identification.
+
+ In the case where a Notify (AS-Pending) message is sent by an SG that
+ now has no ASPs active to service the traffic, or a NTFY
+ (Insufficient ASPs) is sent in the Load-share mode, the Notify does
+ not explicitly force the ASP(s) receiving the message to become
+ active. The ASPs remain in control of what (and when) action is
+ taken.
+
+4.3.3.7 Heartbeat
+
+ The optional Heartbeat procedures MAY be used when operating over
+ transport layers that do not have their own heartbeat mechanism for
+ detecting loss of the transport association (i.e., other than the
+ SCTP).
+
+ After receiving an ASP Up Ack message from the SG in response to an
+ ASP Up message, the ASP MAY optionally send Beat messages
+ periodically, subject to a provisionable timer T(beat). The SG IUA,
+ upon receiving a BEAT message from the ASP, responds with a BEAT ACK
+ message. If no BEAT message (or any other IUA message) is received
+ from the SG within the timer 2*T(beat), the SG will consider the
+ remote IUA as "Down". The SG will also send an ASP Down Ack message
+ to the ASP.
+
+ At the ASP, if no BEAT ACK message (or any other IUA message) is
+ received from the SG within 2*T(beat), the SG is considered
+ unavailable. Transmission of BEAT messages is stopped and ASP Up
+ procedures are used to re-establish communication with the SG IUA
+ peer.
+
+ The BEAT message MAY optionally contain an opaque Heartbeat Data
+ parameter that MUST be echoed back unchanged in the related Beat Ack
+ message. The ASP upon examining the contents of the returned BEAT
+ Ack message MAY choose to consider the remote ASP as unavailable.
+ The contents/format of the Heartbeat Data parameter is
+ implementation-dependent and only of local interest to the original
+ sender. The contents MAY be used, for example, to support a
+ Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a
+ timestamp mechanism (to evaluate delays).
+
+ Note: Heartbeat related events are not shown in Figure 4 "ASP state
+ transition diagram".
+
+
+
+
+Morneault, et al. Standards Track [Page 55]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+5.0 Examples
+
+5.1 Establishment of Association and Traffic between SGs and ASPs
+
+5.1.1 Single ASP in an Application Server (1+0 sparing)
+
+ This scenario shows the example IUA message flows for the
+ establishment of traffic between an SG and an ASP, where only one ASP
+ is configured within an AS (no backup). It is assumed that the SCTP
+ association is already set-up.
+
+ SG ASP1
+ |
+ |<---------ASP Up----------|
+ |--------ASP Up Ack------->|
+ | |
+ |<-------ASP Active--------|
+ |------ASP Active Ack----->|
+ | |
+
+5.1.2 Two ASPs in Application Server (1+1 sparing)
+
+ This scenario shows the example IUA message flows for the
+ establishment of traffic between an SG and two ASPs in the same
+ Application Server, where ASP1 is configured to be Active and ASP2 a
+ standby in the event of communication failure or the withdrawal from
+ service of ASP1. ASP2 MAY act as a hot, warm, or cold standby
+ depending on the extent to which ASP1 and ASP2 share call state or
+ can communicate call state under failure/withdrawal events. The
+ example message flow is the same whether the ASP-Active messages are
+ Over-ride or Load-share mode although typically this example would
+ use an Over-ride mode.
+
+ SG ASP1 ASP2
+ | | |
+ |<--------ASP Up----------| |
+ |-------ASP Up Ack------->| |
+ | | |
+ |<-----------------------------ASP Up----------------|
+ |----------------------------ASP Up Ack------------->|
+ | | |
+ | | |
+ |<-------ASP Active-------| |
+ |-----ASP Active Ack----->| |
+ | | |
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 56]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+5.1.3 Two ASPs in an Application Server (1+1 sparing, load-sharing case)
+
+ This scenario shows a similar case to Section 5.1.2 but where the two
+ ASPs are brought to active and load-share the traffic load. In this
+ case, one ASP is sufficient to handle the total traffic load.
+
+ SG ASP1 ASP2
+ | | |
+ |<---------ASP Up---------| |
+ |--------ASP Up Ack------>| |
+ | | |
+ |<------------------------------ASP Up---------------|
+ |-----------------------------ASP Up Ack------------>|
+ | | |
+ | | |
+ |<--ASP Active (Ldshr)----| |
+ |----ASP Active Ack------>| |
+ | | |
+ |<----------------------------ASP Active (Ldshr)-----|
+ |-----------------------------ASP Active Ack-------->|
+ | | |
+
+5.1.4 Three ASPs in an Application Server (n+k sparing, load-sharing
+ case)
+
+ This scenario shows the example IUA message flows for the
+ establishment of traffic between an SG and three ASPs in the same
+ Application Server, where two of the ASPs are brought to active and
+ share the load. In this case, a minimum of two ASPs are required to
+ handle the total traffic load (2+1 sparing).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 57]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ SG ASP1 ASP2 ASP3
+ | | | |
+ |<------ASP Up-------| | |
+ |-----ASP Up Ack---->| | |
+ | | | |
+ |<--------------------------ASP Up-------| |
+ |------------------------ASPUp Ack)----->| |
+ | | | |
+ |<---------------------------------------------ASP Up--------|
+ |--------------------------------------------ASP Up Ack----->|
+ | | | |
+ | | | |
+ |<-ASP Act (Ldshr)---| | |
+ |----ASP Act Ack---->| | |
+ | | | |
+ |<---------------------ASP Act (Ldshr)---| |
+ |----------------------ASP Act Ack------>| |
+ | | | |
+
+5.2 ASP Traffic Fail-over Examples
+
+5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
+
+ The following example shows a case in which an ASP withdraws from
+ service:
+
+ SG ASP1 ASP2
+ | | |
+ |<-----ASP Inactive-------| |
+ |----ASP Inactive Ack---->| |
+ |-------------------NTFY(AS-Pending) --------------->|
+ | | |
+ |<------------------------------ ASP Active----------|
+ |-----------------------------ASP Active Ack)------->|
+ | |
+
+ In this case, the SG notifies ASP2 that the AS has moved to the Down
+ state. The SG could have also (optionally) sent a Notify message
+ when the AS moved to the Pending state.
+
+ Note: If the SG detects loss of the IUA peer (IUA heartbeat loss or
+ detection of SCTP failure), the initial SG-ASP1 ASP Inactive message
+ exchange would not occur.
+
+5.2.2 (1+1 Sparing, Back-up Over-ride)
+
+ The following example shows a case in which ASP2 wishes to over-ride
+ ASP1 and take over the traffic:
+
+
+
+Morneault, et al. Standards Track [Page 58]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ SG ASP1 ASP2
+ | | |
+ |<-------------------------------ASP Active----------|
+ |-----------------------------ASP Active Ack-------->|
+ |----NTFY( Alt ASP-Act)-->|
+ | | |
+
+ In this case, the SG notifies ASP1 that an alternative ASP has
+ overridden it.
+
+5.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP)
+
+ Following on from the example in Section 5.1.4, and ASP1 withdraws
+ from service
+
+ SG ASP1 ASP2 ASP3
+ | | | |
+ |<----ASP Inact------| | |
+ |---ASP Inact Ack--->| | |
+ | | | |
+ |---------------------------------NTFY(Ins. ASPs)----------->|
+ | | | |
+ |<-----------------------------------------ASP Act (Ldshr)---|
+ |-------------------------------------------ASP Act (Ack)--->|
+ | | | |
+
+ In this case, the SG has knowledge of the minimum ASP resources
+ required (implementation dependent) for example if the SG knows that
+ n+k = 2+1 for a load-share AS and n currently equals 1.
+
+ Note: If the SG detects loss of the ASP1 IUA peer (IUA heartbeat
+ loss or detection of SCTP failure), the first SG-ASP1 ASP Inactive
+ message exchange would not occur.
+
+5.3 Q.921/Q.931 primitives backhaul Examples
+
+ When the IUA layer on the ASP has a QPTM message to send to the SG,
+ it will do the following:
+
+ - Determine the correct SG
+
+ - Find the SCTP association to the chosen SG
+
+ - Determine the correct stream in the SCTP association based on
+ the D channel
+
+ - Fill in the QPTM message, fill in IUA Message Header, fill in
+ Common Header
+
+
+
+Morneault, et al. Standards Track [Page 59]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ - Send the QPTM message to the remote IUA peer in the SG, over
+ the SCTP association
+
+ When the IUA layer on the SG has a QPTM message to send to the ASP,
+ it will do the following:
+
+ - Determine the AS for the Interface Identifier
+
+ - Determine the Active ASP (SCTP association) within the AS
+
+ - Determine the correct stream in the SCTP association based on
+ the D channel
+
+ - Fill in the QPTM message, fill in IUA Message Header, fill in
+ Common Header
+
+ - Send the QPTM message to the remote IUA peer in the ASP, over
+ the SCTP association
+
+ An example of the message flows for establishing a data link on a
+ signaling channel, passing PDUs and releasing a data link on a
+ signaling channel is shown below. An active association between MGC
+ and SG is established (Section 5.1) prior to the following message
+ flows.
+
+ SG ASP
+
+ <----------- Establish Request
+ Establish Confirm ---------->
+
+ <----------- Data Request
+ Data Indication ----------->
+ <----------- Data Request
+ Data Indication ----------->
+ <----------- Data Request
+ <----------- Data Request
+ Data Indication ----------->
+
+ <----------- Release Request (RELEASE_MGMT)
+ Release Confirm ---------->
+
+ An example of the message flows for a failed attempt to establish a
+ data link on the signaling channel is shown below. In this case, the
+ gateway has a problem with its physical connection (e.g., Red Alarm),
+ so it cannot establish a data link on the signaling channel.
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 60]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ SG ASP
+
+ <----------- Establish Request (ESTABLISH_START)
+ Release Indication ---------->
+ (RELEASE_PHYS)
+
+5.4 Layer Management Communication Examples
+
+ An example of the message flows for communication between Layer
+ Management modules between SG and ASP is shown below. An active
+ association between ASP and SG is established (Section 5.1) prior to
+ the following message flows.
+
+ SG ASP
+
+ <----------- Data Request
+ Error Indication ---------->
+ (INVALID_TEI)
+
+ <----------- TEI Status Request
+ TEI Status Confirm ---------->
+ (Unassigned)
+
+6.0 Security
+
+ IUA is designed to carry signaling messages for telephony services.
+ As such, IUA MUST involve the security needs of several parties the
+ end users of the services; the network providers and the applications
+ involved. Additional requirements MAY come from local regulation.
+ While having some overlapping security needs, any security solution
+ SHOULD fulfill all of the different parties' needs.
+
+6.1 Threats
+
+ There is no quick fix, one-size-fits-all solution for security. As a
+ transport protocol, IUA has the following security objectives:
+
+ * Availability of reliable and timely user data transport.
+ * Integrity of user data transport.
+ * Confidentiality of user data.
+
+ IUA runs on top of SCTP. SCTP [3] provides certain transport related
+ security features, such as
+
+ * Blind Denial of Service Attacks
+ * Flooding
+ * Masquerade
+ * Improper Monopolization of Services
+
+
+
+Morneault, et al. Standards Track [Page 61]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ When IUA is running in professionally managed corporate or service
+ provider network, it is reasonable to expect that this network
+ includes an appropriate security policy framework. The "Site
+ Security Handbook" [5] SHOULD be consulted for guidance.
+
+ When the network in which IUA runs in involves more than one party,
+ it MAY NOT be reasonable to expect that all parties have implemented
+ security in a sufficient manner. In such a case, it is recommended
+ that IPSEC is used to ensure confidentiality of user payload.
+ Consult [6] for more information on configuring IPSEC services.
+
+6.2 Protecting Confidentiality
+
+ Particularly for mobile users, the requirement for confidentiality
+ MAY include the masking of IP addresses and ports. In this case
+ application level encryption is not sufficient; IPSEC ESP SHOULD be
+ used instead. Regardless of which level performs the encryption, the
+ IPSEC ISAKMP service SHOULD be used for key management.
+
+7.0 IANA Considerations
+
+7.1 SCTP Payload Protocol Identifier
+
+ A request will be made to IANA to assign an IUA value for the Payload
+ Protocol Identifier in SCTP Payload Data chunk. The following SCTP
+ Payload Protocol Identifier will be registered:
+
+ IUA "1"
+
+ The SCTP Payload Protocol Identifier is included in each SCTP Data
+ chunk, to indicate which protocol the SCTP is carrying. This Payload
+ Protocol Identifier is not directly used by SCTP but MAY be used by
+ certain network entities to identify the type of information being
+ carried in a Data chunk.
+
+ The User Adaptation peer MAY use the Payload Protocol Identifier as a
+ way of determining additional information about the data being
+ presented to it by SCTP.
+
+7.2 IUA Protocol Extensions
+
+ This protocol may also be extended through IANA in three ways:
+
+ -- through definition of additional message classes,
+ -- through definition of additional message types, and
+ -- through definition of additional message parameters.
+
+
+
+
+
+Morneault, et al. Standards Track [Page 62]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+ The definition and use of new message classes, types and parameters
+ is an integral part of SIGTRAN adaptation layers. Thus, these
+ extensions are assigned by IANA through an IETF Consensus action as
+ defined in [RFC2434].
+
+ The proposed extension must in no way adversely affect the general
+ working of the protocol.
+
+7.2.1 IETF Defined Message Classes
+
+ The documentation for a new message class MUST include the following
+ information:
+
+ (a) A long and short name for the message class.
+ (b) A detailed description of the purpose of the message class.
+
+7.2.2 IETF Defined Message Types
+
+ Documentation of the message type MUST contain the following
+ information:
+
+ (a) A long and short name for the new message type.
+ (b) A detailed description of the structure of the message.
+ (c) A detailed definition and description of intended use of each
+ field within the message.
+ ti3 (d) A detailed procedural description of the use of the new
+ message type within the operation of the protocol.
+ (e) A detailed description of error conditions when receiving this
+ message type.
+
+ When an implementation receives a message type which it does not
+ support, it MUST respond with an Error (ERR) message with an Error
+ Code of Unsupported Message Type.
+
+7.2.3 IETF-defined TLV Parameter Extension
+
+ Documentation of the message parameter MUST contain the following
+ information:
+
+ (a) Name of the parameter type.
+ (b) Detailed description of the structure of the parameter field.
+ This structure MUST conform to the general type-length-value
+ format described in Section 3.1.5.
+ (c) Detailed definition of each component of the parameter value.
+ (d) Detailed description of the intended use of this parameter type,
+ and an indication of whether and under what circumstances
+ multiple instances of this parameter type may be found within the
+ same message type.
+
+
+
+Morneault, et al. Standards Track [Page 63]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+8.0 Acknowledgements
+
+ The authors would like to thank Alex Audu, Maria Sonia Vazquez
+ Arevalillo, Ming-te Chao, Keith Drage, Norm Glaude, Nikhil Jain,
+ Bernard Kuc, Ming Lin, Stephen Lorusso, John Loughney, Barry
+ Nagelberg, Neil Olson, Lyndon Ong, Heinz Prantner, Jose Luis Jimenez
+ Ramirez, Ian Rytina, Michael Tuexen and Hank Wang for their valuable
+ comments and suggestions.
+
+9.0 References
+
+ [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System
+ No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer -
+ General Aspects'
+
+ [2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a
+ Voice over Packet Network'
+
+ [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H.,
+ Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
+ "Stream Control Transmission Protocol", RFC 2960, October 2000.
+
+ [4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
+ Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural
+ Framework for Signaling Transport", RFC 2719, October 1999.
+
+ [5] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September
+ 1997.
+
+ [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet
+ Protocol", RFC 2401, November 1998.
+
+ [7] Bradner, s., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 64]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+10.0 Authors' Addresses
+
+ Ken Morneault
+ Cisco Systems Inc.
+ 13615 Dulles Technology Drive
+ Herndon, VA. 20171
+ USA
+
+ Phone: +1-703-484-3323
+ EMail: kmorneau@cisco.com
+
+
+ Malleswar Kalla
+ Telcordia Technologies
+ PYA 2J-341
+ 3 Corporate Place
+ Piscataway, NJ 08854
+ USA
+
+ Phone: +1-732-699-3728
+ EMail: mkalla@telcordia.com
+
+
+ Selvam Rengasami
+ Telcordia Technologies
+ NVC-2Z439
+ 331 Newman Springs Road
+ Red Bank, NJ 07701
+ USA
+
+ Phone: +1-732-758-5260
+ EMail: srengasa@telcordia.com
+
+
+ Greg Sidebottom
+ Nortel Networks
+ 3685 Richmond Road
+ Nepean, Ontario
+ Canada K2H5B7
+
+ Phone: +1-613-763-7305
+ EMail: gregside@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 65]
+
+RFC 3057 ISDN Q.921-User Adaptation Layer February 2001
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morneault, et al. Standards Track [Page 66]
+