RFC 3057
ISDN Q.921-User Adaptation Layer
ISDN Q.921-User Adaptation Layer 🎀
Okay bestie, this is RFC 3057 💖 and it's an IETF Standards Track doc from the Network Working Group, dated February 2001. The authors are K. Morneault (Cisco Systems), S. Rengasami and M. Kalla (Telcordia Technologies), and G. Sidebottom (Nortel Networks) 👑. It doesn't obsolete or update any other RFCs, so it's a clean new start ✨. This is part 1 of 12, so more is coming 🦋
Status of this Memo
This doc specifies an Internet standards track protocol for the Internet community and asks for discussion and suggestions for improvements 💅. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒
Abstract
Okay so the big idea is this: this doc defines a way to backhaul ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP) 🚀. It's meant to run between a Signaling Gateway (SG) and a Media Gateway Controller (MGC), and it assumes the SG gets its ISDN signaling over a standard ISDN interface 🧚
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..................................... 661. Introduction ✨
Quick vocab check 🤓: in this doc, Q.921-User means an upper layer that uses the services of Q.921. It does not mean the user side of the ISDN interface [1] 🙈. Examples of that upper layer are Q.931 and QSIG 💜.
This section explains why we need the ISDN Q.921-User Adaptation (IUA) layer protocol, and how this protocol shall be implemented 🎀.
1.1 Scope
Here's the situation 💁♀️: we need to get Switched Circuit Network (SCN) signaling from an ISDN Signaling Gateway (SG) over to a Media Gateway Controller (MGC), like the Framework Architecture for Signaling Transport [4] describes. The delivery mechanism SHOULD meet these 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 doc covers both ISDN Primary Rate Access (PRA) and Basic Rate Access (BRA), including both point-to-point and point-to-multipoint modes 🌸. That also includes Facility Associated Signaling (FAS), Non-Facility Associated Signaling (NFAS), and NFAS with backup D channel 🫶. QSIG's adaptation layer requirements are the same as Q.931's, so the procedures here work for QSIG too ✨. To keep things simple, we'll only say Q.931 from here on 💅.
1.2 Terminology
Let's get the definitions straight, babe 📖:
- Interface: for this doc, an interface supports the relevant ISDN signaling channel. That channel MAY be a 16 kbps D channel for an ISDN BRA, or a 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 that normally uses the services of the ISDN Q.921, like Q.931, QSIG, etc. 💖
- Backhaul: the SG terminates the lower layers of an SCN protocol and backhauls the upper layer(s) to the MGC for call processing. In this doc, the SG terminates Q.921 and backhauls Q.931 to the MGC 🧚
- Association: an association is an SCTP association. It provides the transport for delivering Q.921-User protocol data units and IUA adaptation layer peer messages 🚀
- Stream: a stream is an SCTP stream, a one-way logical channel from one SCTP endpoint to another associated endpoint. Within it, all user messages are delivered in sequence, except for the ones sent through the un-ordered delivery service 🌈
- Interface Identifier: this identifies the physical interface at the SG where the signaling messages are sent or received. It can be text or integer, and its values are assigned according to network operator policy 🎀. The values are only of local significance, coordinated between the SG and ASP. Significance is not implied across SGs served by an AS 👀
- Application Server (AS): a logical entity serving one specific application instance. An example is an MGC handling Q.931 and call processing for D channels terminated by the Signaling Gateways 👑. In practice, the SG models an AS 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 are primary or backup MGC instances 💅
- Fail-over: the ability to re-route signaling traffic as needed between related ASPs when the one in use fails or becomes unavailable (e.g., from primary MGC to back-up MGC). Fail-over also applies when a previously unavailable process returns to service 🔥
- Layer Management: 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 the ASP process is running on 💻
Heads up 🙈: the terms "Application Server" and "Application Server Process" are easy to mix up. An AS is the logical service, and an ASP is one running instance of it.
1.3 IUA Overview
The architecture defined in [4] for SCN signaling transport over IP has several pieces: an IP transport protocol, a signaling common transport protocol, and an adaptation module that gives a specific SCN signaling protocol the services it expects from the layer below it 🧩.
This doc defines an adaptation module that's built for transporting ISDN Q.921-User messages (e.g., Q.931) 💜.
1.3.1 Example - SG to MGC
Picture this 🎬: at a Signaling Gateway, ISDN signaling comes in over a standard ISDN network termination. The SG then does interworking of transport functions with IP Signaling Transport, so it can carry Q.931 signaling messages to the MGC, where the peer Q.931 protocol layer lives 🌟. Here's the picture:
****** 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 ProtocolIt is recommended that the IUA use SCTP as its underlying reliable common signaling transport protocol 🫶. SCTP brings these features to the party 🎀:
- 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
- data segmentation to conform to discovered path MTU size
Not every setup needs redundancy 🙌. Some scenarios don't need it, and others get redundancy below the transport layer. In those 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
Okay this is the part where the SG keeps track of everything 🗂️💅. The IUA layer at the SG keeps tabs on the availability state of all dynamically registered remote ASPs. That lets it manage the SCTP Associations and the traffic between the SG and ASPs ✨. It also tracks whether each remote ASP is active or inactive. Active ASPs are the ones currently receiving traffic from the SG 🦋.
The IUA layer MAY be told by local management to set up an SCTP association with a peer IUA node 👑. It can do this with the M-SCTP ESTABLISH primitive, which handles requesting, indicating, and confirming the establishment of an SCTP association with that peer 💖.
The IUA layer MAY also need to tell local management what's going on with the underlying SCTP associations, using the M-SCTP STATUS request and indication primitive 📣. For example, the IUA MAY let local management know why an SCTP association was released 🔍. That reason could be decided locally inside the IUA layer, or come in as a primitive from SCTP 🫶.
1.3.3 Signaling Network Architecture ✨
okay so the Signaling Gateway is the thing that carries Q.921-User signaling traffic out to one or more distributed ASPs (think MGCs) 🫶 real talk though, IUA is NOT built to hit the performance and reliability needs for that kind of transport all by itself 😭 but when you combine a distributed setup with redundant networks, you CAN get signaling traffic over IP that's reliable enough ✨ and IUA is flexible enough to run and manage in a bunch of different physical setups, so Network Operators can actually hit their own performance and reliability goals 💅
so for ISDN signaling to be carrier grade 👑, Network Operators SHOULD ensure there is no single point of failure in the whole end-to-end network between an ISDN node and an IP ASP. no weak links, bestie 🔗
depending on how reliable the SG and ASP elements are (obviously), this is usually done with redundant QOS-bounded IP network paths for SCTP Associations between SCTP End Points, plus redundant Hosts and redundant SGs 🧚 where the ASPs live matters too. for a given Application Server, the related ASPs SHOULD be distributed over at least two Hosts 🌸
here's an example logical network architecture for carrier-grade operation in the IP network domain, shown in Figure 1 below 🦋
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Figure 2 - Logical Model Exampleand for carrier grade networks, if an ASP fails or gets cut off, that SHOULD NOT cause stable calls to be dropped 😭 which means ASPs sometimes need to share call state or be able to pass it between each other. BUT that sharing or communication of call state info is outside the scope of this document, so we're leaving it for another day 🙈
1.3.4 ASP Fail-over Model and Terminology 🔥
IUA supports ASP fail-over so call processing stays highly available 🫶 every Q.921-User message coming into an SG gets assigned to one unique Application Server, based on its Interface Identifier.
the Application Server is basically a list of all the ASPs set up to process Q.921-User messages from certain Interface Identifiers 📝 one or more ASPs on that list are normally active (aka actually handling traffic), while any others MAY be unavailable or inactive, so they can jump in if the active one(s) fail or become unavailable 💜
the fail-over model supports an n+k redundancy model 🧮 where n ASP(s) is the minimum number of redundant ASPs needed to handle traffic, and k ASPs are available to take over for a failed or unavailable ASP. 1+1 active/standby redundancy is just a subset of this model, and a simplex 1+0 model is also supported as a subset, with no ASP redundancy at all 🍓
to avoid a single point of failure, it is recommended that the list have a minimum of two ASPs, sitting in separate hosts so they're reachable over different SCTP Associations 🌈 for example, in the network from Figure 2, all messages from one particular D Channel (Interface Identifier) could go to ASP1 in Host1 OR ASP1 in Host2. the AS list at SG1 might look like this:
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Inactivein this 1+1 redundancy case, ASP1 in Host1 gets every incoming message for the registered Interface Identifiers ✨ ASP1 in Host2 would normally be brought to the active state when ASP1/Host1 fails or loses connectivity 🦋 and in this example both ASPs are Up, which just means the related SCTP association and far-end IUA peer are ready to go 💖
the AS List at SG1 can also be set up in load-share mode, like this:
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Activein this case, both ASPs get a portion of the traffic 🎀
during fail-over, it is recommended that for ASPs doing call processing, stable calls do NOT get released 😭 calls in transition MAY fail, though measures of communication between the involved ASPs can help mitigate that 💅 for example, the two ASPs MAY share call state via shared memory, or MAY use an ASP to ASP protocol to pass call state info. and yep, the ASP to ASP protocol is outside the scope of this document too 🙈
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 one always takes the client role and the other takes the server role when initiating SCTP associations. the default setup is for the SG to be the server and the ASP to be the client, and in that 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 👑 the IUA layer needs to support ALL of the primitives at 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.
1.4.2 Support for communication between Layer Management modules on SG and MGC 🧚
the IUA layer needs to provide some services that make it easier for Layer Management modules on the SG and MGC to talk to each other 🫶 these primitives are pointed out in [2], and they're 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 🔥
there's a set of primitives between the IUA layer and Layer Management, defined below, so Layer Management can manage the SCTP association(s) between the SG and MGC 💅 Layer Management can instruct the IUA layer to establish an SCTP association to a peer IUA node, and that's done with 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 tell Layer Management the status of the SCTP associations 🌸 that's done with 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).
the Layer Management MAY need to inform the IUA layer of an AS/ASP status (like failure, active, etc.), so messages can be exchanged between IUA layer peers to stop traffic to the local IUA user 🧚 that's done with the M-ASP STATUS primitive.
M-ASP STATUS 🎀
the ASP status is stored inside the 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, and it 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 an 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 an 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 an 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 an 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 🦋 it can also be used to indicate the status of the Application Server.
1.5 Functions Implemented by the IUA Layer 🌈
1.5.1 Mapping ✨
okay so the IUA layer MUST maintain a map of each Interface Identifier to a physical interface on the Signaling Gateway 🗺️ 💖 A physical interface could be a T1 line, an E1 line, and so on, and it could even include the TDM timeslot. For any given interface, the SG MUST be able to identify the signaling channel that goes with it. IUA layers on both the SG and the MGC MAY maintain the status of TEIs and SAPIs 🎀
the SG only maps an Interface Identifier to an SCTP association/stream when an ASP sends an ASP Active message for that particular Interface Identifier. It MUST be noted, though, that this mapping is dynamic and could change at any time because the ASP state changed 🦋 It could even be temporarily invalid, like during a failover from one ASP to another 😭 So the SG MUST maintain the states of AS/ASP and check them when routing a message to an AS/ASP 🫶
here's a logical picture of how the D channel, Interface Identifier, AS and ASP fit together in the SG 🧚
/---------------------------------------------------+
/ /------------------------------------------------|--+
/ / 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 supports 💅 An ASP's state changes when it receives peer-to-peer messages (ASPM messages, as described in Section 3.3.2) or when it gets indications from the local SCTP association. The ASP state transition procedures are described in Section 4.3.1 📖
at an SG, an Application Server list MAY contain active and inactive ASPs so you can do ASP load-sharing and fail-over 🔄 For example, when both a primary and a back-up ASP are available, the IUA peer protocol is required to control which ASP is currently active 👀 The ordered list of ASPs inside a logical Application Server is kept up to date in the SG so it reflects the active Application Server Process(es) ✨
the IUA layer MAY also need to tell local management when an ASP or AS changes status 📣 That can be done with the M-ASP STATUS or M-AS STATUS primitives 🍓
1.5.3 SCTP Stream Management 🌈
SCTP lets you open a user-specified number of streams during initialization 🧁 It's the IUA layer's job to make sure those streams are managed properly 💜 Streams are unidirectional, so an IUA layer doesn't know the stream number to Interface Identifier mapping of its peer IUA layer. Instead, the Interface Identifier lives in the IUA message header 🎀
using SCTP streams within IUA is recommended, because it minimizes transmission and buffering delay, which improves the overall performance and reliability of the signaling elements 🚀 It is also recommended that each D channel gets its own SCTP stream 🦋
1.5.4 Seamless Network Management Interworking 💫
if the currently active ASP moves out of the ACTIVE state, the IUA layer on the SG SHOULD pass an indication that the IUA-User (Q.931) is unavailable up to the local Layer Management 🚨 The Layer Management could then tell Q.921 to take some action, if it thinks that's appropriate 🧠
and 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 gets congested (this part is implementation dependent), it MAY stop reading from the SCTP association to flow control the peer IUA 🛑 bestie, that's a whole flow-control move 💅
1.6 Definition of IUA Boundaries 🎀
1.6.1 Definition of IUA/Q.921 boundary 💖
these are the primitives at the IUA/Q.921 boundary:
DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA1.6.2 Definition of IUA/Q.931 boundary 🌸
these are the primitives at the IUA/Q.931 boundary:
DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA1.6.3 Definition of SCTP/IUA Boundary ✨
an example of the upper layer primitives SCTP provides can be found in Reference [3] section 10 📚
1.6.4 Definition of IUA/Layer-Management Boundary 👑
here's the full list of primitives between IUA and Layer Management, with who sends what and why 💅
M-SCTP ESTABLISH request
Direction: LM -> IUA
Purpose: LM requests ASP to establish an SCTP association with an SG.
M-STCP ESTABLISH confirm
Direction: IUA -> LM
Purpose: ASP confirms to LM that it has established an SCTP
association with an SG.
M-SCTP ESTABLISH indication
Direction: IUA -> LM
Purpose: SG informs LM that an ASP has established an SCTP
association.
M-SCTP RELEASE request
Direction: LM -> IUA
Purpose: LM requests ASP to release an SCTP association with SG.
M-SCTP RELEASE confirm
Direction: IUA -> LM
Purpose: ASP confirms to LM that it has released SCTP association
with SG.
M-SCTP RELEASE indication
Direction: IUA -> LM
Purpose: SG informs LM that ASP has released an SCTP association.
M-SCTP STATUS request
Direction: LM -> IUA
Purpose: LM requests IUA to report status of SCTP association.
M-SCTP STATUS indication
Direction: IUA -> LM
Purpose: IUA reports status of SCTP association.
M-ASP STATUS request
Direction: LM -> IUA
Purpose: LM requests SG to report status of remote ASP.
M-ASP STATUS indication
Direction: IUA -> LM
Purpose: SG reports status of remote ASP.
M-AS-STATUS request
Direction: LM -> IUA
Purpose: LM requests SG to report status of AS.
M-AS-STATUS indication
Direction: IUA -> LM
Purpose: SG reports status of AS.
M-NOTIFY indication
Direction: IUA -> LM
Purpose: ASP reports that it has received a NOTIFY message
from its peer.
M-ERROR indication
Direction: IUA -> LM
Purpose: ASP or SG reports that it has received an ERROR
message from its peer.
M-ASP-UP request
Direction: LM -> IUA
Purpose: LM requests ASP to start its operation and send an ASP UP
message to the SG.
M-ASP-UP confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP UP Acknowledgement
message from the SG.
M-ASP-DOWN request
Direction: LM -> IUA
Purpose: LM requests ASP to stop its operation and send an ASP DOWN
message to the SG.
M-ASP-DOWN confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP DOWN
Acknowledgement message from the SG.
M-ASP-ACTIVE request
Direction: LM -> IUA
Purpose: LM requests ASP to send an ASP ACTIVE message to the SG.
M-ASP-ACTIVE confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP ACTIVE
Acknowledgement message from the SG.
M-ASP-INACTIVE request
Direction: LM -> IUA
Purpose: LM requests ASP to send an ASP INACTIVE message to the SG.
M-ASP-INACTIVE confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received an ASP INACTIVE
Acknowledgement message from the SG.
M-TEI STATUS request
Direction: LM -> IUA
Purpose: LM requests ASP to send a TEI status request to the SG.
M-TEI STATUS indication
Direction: IUA -> LM
Purpose: ASP reports that is has received a TEI status indication
from the SG.
M-TEI STATUS confirm
Direction: IUA -> LM
Purpose: ASP reports that is has received a TEI status confirm from the
SG.2.0 Conventions 🎀
okay so the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be read as described in [RFC2119] 🧠💜
3.0 Protocol Elements 🌷
this section describes the format of the various messages used in this protocol 📦
3.1 Common Message Header 🦋
the protocol messages for Q.921-User Adaptation need a message header that holds the adaptation layer version, the message type, and the 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 network byte order, unless stated otherwise 🔥
3.1.1 Version 💖
the version field holds the version of the IUA adaptation layer. The supported versions are below 🌈
Value Version
----- -------
1 Release 1.03.1.2 Message Classes and Types ✨
here's the list of 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]
8 Connection-Oriented Messages [SUA]
9 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensionsand here are the message names for the defined messages 🧁
Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
0 Reserved
1 Data Request Message
2 Data Indication Message
3 Unit Data Request Message
4 Unit Data Indication Message
5 Establish Request
6 Establish Confirm
7 Establish Indication
8 Release Request
9 Release Confirm
10 Release Indication
11 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined QPTM extensions
Application Server Process State Maintenance (ASPSM) messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heatbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
Application Server Process Traffic Maintenance (ASPTM) messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions
Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 TEI Status Request
3 TEI Status Confirm
4 TEI Status Indication
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions3.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 is the length of the message in octets, and that includes the Common header 📏✨
3.1.5 Variable-Length Parameter Format 🎀
okay so every IUA message is a Common Header 💅 followed by zero or more variable-length parameters, and which ones show up depends on the message type 🌸 each parameter comes in a Tag-Length-Value format that looks like this:
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. 💖 no skipping the line, bestie!
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. ✨
Parameter Length: 16 bits (unsigned integer) 🦋
This is the size of the parameter in bytes, counting the Parameter Tag, Parameter Length, and Parameter Value fields all together. The Parameter Length does not include any padding bytes. 🙈
Parameter Value: variable-length 💜
This is where the actual information being sent in the parameter lives. 🫶
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. 🔥 so the sender pads with zeros, the padding doesn't count toward the length, and the receiver just ignores it. iconic behaviour 👑
3.2 IUA Message Header ✨
okay so in addition to the common message header, QPTM and the TEI Status MGMT messages get a specific message header of their own 🌈 the IUA message header comes right after the Common header in these messages.
This header holds the Interface Identifier and the Data Link Connection Identifier (DLCI). The Interface Identifier points at the physical interface that terminates the signaling channel at the SG, which is the one the signaling messages are sent and received on. It can be text or integer, and Interface Identifiers are assigned according to network operator policy. The integer values are of local significance only, and they get coordinated between the SG and ASP. 🦋
The integer formatted Interface Identifier MUST be supported. The text formatted Interface Identifier MAY optionally be supported. 💅 so integer is a must, text is a bonus!
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 FormatHere's the breakdown 🧁:
SPR: Spare 2nd bit in octet 1, (1 bit)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 🦋
this section defines the messages and what their parameter contents look like. The IUA messages 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 one has been established. The MGC controls the state of the D channel. When the MGC wants the D channel to be in-service, it sends the Establish Request message. 👑
When the MGC sends an IUA Establish Request message, the MGC MAY start a timer. This timer gets stopped when an IUA Establish Confirm or Establish Indication comes back. If the timer expires, the MGC re-sends the IUA Establish Request message and restarts the timer. In other words, the MGC MAY keep requesting the establishment of the data link on a periodic basis until the desired state is achieved, or take some other action (notify the Management Layer). 🔁 persistence is giving main character energy ✨
When the SG receives an IUA Establish Request from the MGC, the SG shall send the Q.921 Establish Request primitive to its Q.921 entity. On top of that, the SG shall map any response received from the Q.921 entity to the appropriate message for 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 the IUA message header. They do not contain any additional parameters. 💅
3.3.1.2 Release Messages (Request, Indication, Confirmation) 🌸
The Release Request message is used to release the data link on the signaling channel. The Release Confirm and Indication messages are used to indicate that the data link on the signaling channel has been released. 🦋
If a response to the Release Request message is not received, the MGC MAY resend the Release Request message. If no response shows up, the MGC can consider the data link as released. In that 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 the 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 in the table below 💜:
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 reasonsNote: Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid reason codes for a Release Request message. 🚨 hold up, the other two aren't allowed here!
3.3.1.3 Data Messages (Request, Indication) 💖
The Data message carries an ISDN Q.921-User Protocol Data Unit (PDU) that goes with acknowledged information transfer service. 🎀
The Data messages contain the common message header followed by the 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 carries an upper layer signaling message, e.g. Q.931, QSIG. 📞
3.3.1.4 Unit Data Messages (Request, Indication) ✨
The Unit Data message carries an ISDN Q.921-User Protocol Data Unit (PDU) that goes with unacknowledged information transfer service. 🦋
The Unit Data messages contain the common message header followed by the 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) 🦋
okay so the ASP Up (ASPUP) message is how an ASP tells an SG "hey, I'm ready to receive traffic or maintenance messages" 💅✨
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. Basically it's the "got it, bestie" reply 🫶
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).
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. So this is the "pause, don't send me stuff" message 💀
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 InhibitIf 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. Same energy as the Up Ack, just for going down 🌈
The ASP Down Ack message contains the following parameters:
- Reason
- INFO String (Optional)
The format for the ASP Down Ack message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (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. This one is the main event, bestie 🔥
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)
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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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-shareWithin 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 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 🦋
okay so the ASPAC Ack is the "got it, you're active now" reply 💅 It gets sent to say yes, I saw that ASP-Active message from a remote IUA peer 🫶
the ASPAC Ack has these parameters, bestie:
- Traffic Mode Type (Mandatory)
- Interface Identifier (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (Optional)
here's the layout when your Interface Identifiers are integers 🔢✨
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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and here's the one for text formatted (string) Interface Identifiers 📝🌸
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 and Interface Identifier parameters work exactly the same as in the ASP Active message, so peep Section 3.3.2.5 for the full tea 🍵 and the optional Info String is the same as in the ASP Up message, see Section 3.3.2.1. 💜
3.3.2.7 ASP Inactive (ASPIA) 🌈
okay bestie, the ASPIA message is how an ASP says "I'm no longer an active ASP in the list, don't send me stuff anymore" 🙈 an ASP sends it to an SG, and the SG replies with an ASPIA Ack and then either drops incoming messages or buffers them for a set time and drops them after 🗑️
the ASPIA message has these parameters:
- Traffic Mode Type (Mandatory)
- Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (Optional)
here's the integer-formatted version 🔢
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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the text formatted (string) version 📝✨
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 tells you the traffic mode the ASP is running in within an AS 🧚 the valid values are in this little table:
Value Description
0x1 Over-ride
0x2 Load-sharethe optional Interface Identifiers and Info String parameters work the same as in the ASP Active message, so check Section 3.3.2.3. 🫶
the optional Interface Identifiers parameter holds a list of Interface Identifier integers or text strings, pointing at the Application Server traffic the sending ASP is configured/registered to receive but doesn't want to receive right now 🌸
3.3.2.8 ASP Inactive Ack ✨
okay so the ASP Inactive (ASPIA) Ack is the "got it, bestie" 💅 message. It gets sent back to acknowledge an ASP Inactive message that came in 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)
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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 OptionalThe 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. Literally a perfect mirror 🪞
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. It's the "um, excuse me?" message 💀
The Error message will only have the common message header. The Error message contains the following parameters:
- Error Code
- Diagnostic Information (optional)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (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 0x0cThe "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 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). very plot twist 🙃
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). this one is spicy, read it twice 🌶️
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) 🔔
Notify is the message an IUA peer uses to tell its buddy about stuff happening on the other side, without being asked. It's giving "heads up, something changed" 🫶
Notify only uses the common message header, and it carries these parameters:
- Status Type
- Status Identification
- Interface Identifiers (Optional)
- INFO String (Optional)
Here's the layout when the Interface Identifiers are Integer-formatted 💖:
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* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's the layout when the Interface Identifiers are Text-formatted 🎀:
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 tells you what kind of Notify this is 🧐. The valid Status Type values are:
Value Description
0x1 Application Server state change (AS_State_Change)
0x2 OtherThe Status Identification parameter gives the juicy details for the notification, and what it means depends on the Status Type. If the Status Type is AS_State_Change, the Status Identification values are:
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)These notifications go from an SG to an ASP whenever an Application Server's status changes 📡. The value tells you the new state of that AS.
If the Status Type is Other, these Status Information values are defined:
Value Description
1 Insufficient ASP resources active in AS
2 Alternate ASP ActiveThese ones aren't about the SG reporting a state change of an ASP or AS, so they're a different vibe 💅. For Insufficient ASP Resources, the SG is basically telling the "Inactive" ASP(s) in the AS that another ASP is needed to handle the AS's load (that's Load-sharing mode). For Alternate ASP Active, an ASP gets the news when an alternate ASP moves to the ASP-Active state in Over-ride mode 👑.
The optional Interface Identifiers and Info String parameters work the same way they do for the ASP Active message (See Section 3.3.2.3.) ✨.
3.3.3.3 TEI Status Messages (Request, Confirm and Indication) 🦋
TEI Status messages are how IUA layer peers talk about a particular TEI: they request its status, confirm it, or indicate it.
Every TEI Status message has the common message header, followed by the IUA message header. The TEI Status Request message doesn't carry any extra parameters, so it's a chill one 🌸.
Okay so, in the integrated ISDN Layer 2/3 model (like in traditional ISDN switches), it's assumed that Layer Management for Q.921 and Q.931 live in the same place. When you're backhauling ISDN, that assumption isn't necessarily true anymore 🙈. TEI status messages let the two Layer Management entities share what's up with the TEI. Knowing a TEI is in service also lets the ASP ask the SG to set up the datalink to the terminal (using the IUA Establish message) for signaling, if the ASP wants to be in charge of data link establishment 💜.
Another use: the Layer Management at the ASP can get ready to send and receive signaling to and from a given TEI, and confirm or verify that a datalink to that TEI got established 🧚. For example, if a datalink gets established for a TEI the ASP didn't know had been assigned, the ASP can check whether it really was assigned or whether there was an error in the signaling message. And if a TEI is out of service, the ASP doesn't need to bother asking the SG to set up a datalink to it 🙌.
The TEI Status Indication and Confirm messages contain this 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 in this table 🍓:
Define Value Description
ASSIGNED 0x0 TEI is considered assigned by Q.921
UNASSIGNED 0x1 TEI is considered unassigned by Q.9214.0 Procedures 🌈
The IUA layer has to respond to all sorts of primitives coming in from other layers, plus messages from its peer IUA layer 💅. This section walks through the procedures for responding to those events.
4.1 Procedures to support service in section 1.4.1 🎀
These procedures make the IUA layer's "Transport of Q.921/Q.931 boundary" service happen ✨.
4.1.1 Q.921 or Q.931 primitives procedures
When the IUA layer gets these primitives from the local layer, it sends the matching QPTM message (Data, Unit Data, Establish, Release) to its peer 📨. While doing that, the IUA layer needs to fill in the various fields of the common and specific headers correctly. The message also needs to go out on the SCTP stream that matches the D channel (Interface Identifier) 🦋.
4.1.2 QPTM message procedures
When the IUA layer on an SG or MGC receives QPTM messages from a peer IUA layer, it needs to invoke the matching layer primitives (DL-ESTABLISH, DL-DATA, DL-UNIT DATA, DL-RELEASE) toward the local Q.921 or Q.931 layer 🫶.
4.2 Procedures to support service in section 1.4.2 🧚
These procedures make the IUA layer's "Support for Communication between Layer Managements" service work 🔥.
4.2.1 Layer Management primitives procedures
When the IUA layer gets these primitives from the local Layer Management, it gives back the appropriate response primitive across the internal local Layer Management interface 💖.
An M-SCTP ESTABLISH request from Layer Management starts setting up an SCTP association. An M-SCTP ESTABLISH confirm goes back to Layer Management once that association setup finishes. An M-SCTP ESTABLISH indication goes to Layer Management when an incoming SCTP association from a peer IUA node has been set up successfully 🌸.
An M-SCTP RELEASE request from Layer Management starts tearing down an SCTP association. An M-SCTP RELEASE confirm gets sent by Layer Management when the teardown is done. An M-SCTP RELEASE indication goes to Layer Management when an SCTP association that a peer IUA started has been torn down successfully 💀.
M-SCTP STATUS request and indication let Layer Management query the local status of a particular SCTP association 🔍.
M-NOTIFY indication and M-ERROR indication tell Layer Management about the notification or error info in a received IUA Notify or Error message, respectively. These indications can also be generated from local IUA events 🙈.
M-ASP STATUS request/indication and M-AS-STATUS request/indication let Layer Management query the local status of a particular ASP or AS. No IUA peer protocol is involved here 🧠.
M-ASP-UP request, M-ASP-DOWN request, M-ASP-INACTIVE request and M-ASP-ACTIVE request let Layer Management at an ASP kick off state changes 👑. These requests end up as 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 tell Layer Management that the previous request got confirmed ✅.
When the IUA gets an M-TEI Status primitive from Layer Management, it sends the matching MGMT message (TEI Status) to its peer 🦋. While doing that, the IUA layer needs to fill in the various fields of the common and specific headers correctly.
All MGMT messages go out on a sequenced stream so they stay in order 🎀. SCTP stream '0' SHOULD be used.
4.2.2 Receipt of IUA Peer Management messages 💌
okay so whenever IUA gets a management message from its peer, it MUST invoke the matching Layer Management primitive indication to the local layer management 🫶 Think M-AS Status ind., M-ASP Status ind., M-ERROR ind., M-TEI STATUS... and so on. Totally iconic handoff 💅
M-NOTIFY ind. and M-ERROR ind. are the ones that tell Layer Management what's inside a received IUA Notify or Error message 🔥 But these indications can also be generated from local IUA events, so they're not only for incoming messages. Very flexible, very cute 🦋
All MGMT messages are sent on a sequenced stream so the order stays intact ✨ SCTP stream '0' SHOULD be used for this, bestie 🎀
4.3 Procedures to support service in section 1.4.3 🌸
These procedures are how the IUA layer delivers its "Support for management of active associations between SG and MGC" service 👑 It's giving reliable connection management, no cap 💖
4.3.1 AS and ASP State Maintenance 🧚
The IUA layer on the SG has to keep track of the state of each ASP, and also the state of the AS 💜
4.3.1.1 ASP States
okay so the SG's IUA layer keeps the state of every ASP in every AS that the ASP is configured for 💅 An ASP's state changes because of three kinds of events:
- Reception of messages from the 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 the SCTP layer
The ASP state transition diagram is shown in Figure 7 🦋 Here are the possible ASP states:
ASP-DOWN: The Application Server Process is unavailable and/or the related SCTP association is down 💀 Every ASP starts out 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: This is 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 or a 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 AS state changes due to events, and these include:
- ASP state transitions
- Recovery timer triggers
The possible AS states are these 👑
AS-DOWN: The Application Server is unavailable 💀 This state implies that all related ASPs are in the ASP-DOWN state for this AS. Every AS starts out here.
AS-INACTIVE: The Application Server is available, but no application traffic is active (so one or more related ASPs are in the ASP-INACTIVE state, but none are in the ASP-ACTIVE state) 😴 The recovery timer T(r) is not running or has already 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 moved from active to inactive or down, and it was the last remaining active ASP in the AS 😱 A recovery timer T(r) gets started, and all incoming SCN messages get queued by the SG 📦 If an ASP becomes active before T(r) expires, the AS moves to AS-ACTIVE and all the queued messages get 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 then moves to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state, otherwise it moves to AS-DOWN state.
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 Timer4.3.2 ASPM procedures for primitives 🎀
Before an SCTP association is set up, the ASP state at both the SG and the ASP is assumed to be "Down" 🙈
The ASP is the one responsible for starting the setup of an SCTP association to an SG 🫶 So when the IUA layer at an ASP gets an M-SCTP ESTABLISH request primitive from Layer Management, it tries to establish an SCTP association with the remote IUA peer at an SG. When it gets an SCTP-Communication Up confirm primitive from SCTP, it invokes M-SCTP ESTABLISH confirm to Layer Management 💖
At the SG, the IUA layer receives an SCTP Communication Up indication primitive from SCTP, and then invokes M-SCTP ESTABLISH indication to Layer Management ✨
Once the SCTP association is up and the local IUA-User is ready, the local ASP's Application Server Process Maintenance (ASPM) function starts the ASPM procedures 🚀 It uses the ASP Up/-Down/-Active/-Inactive messages to tell the SG the ASP state. See Section 4.3.3 for those 🦋
Layer Management and the IUA layer on the SG can share the status of the application server using the M-AS STATUS primitives 📣 Layer Management and the IUA layer on both the SG and the ASP can share the status of an SCTP association using the M-SCTP STATUS primitives 🔥
If Layer Management on the SG or the ASP wants to bring down an SCTP association for management reasons, it sends an M-SCTP RELEASE request primitive to the local IUA layer 🙅♀️ The IUA layer releases the SCTP association, and once it gets the SCTP Communication Down indication from the underlying SCTP layer, it informs the local Layer Management using an M-SCTP RELEASE confirm primitive 🧚
If the IUA layer gets an SCTP-Communication Down indication from the underlying SCTP layer, it tells Layer Management by invoking the M-SCTP RELEASE indication primitive 😱 The ASP state then moves to "Down" at both the SG and the ASP 💀
At an ASP, Layer Management MAY try to reestablish the SCTP association using the M-SCTP ESTABLISH request primitive 🌈
4.3.3 ASPM procedures for peer-to-peer messages 💌
All ASPM messages are sent on a sequenced stream so the order stays intact ✨ SCTP stream '0' SHOULD be used 🎀
4.3.3.1 ASP Up 🦋
After an ASP has successfully set up an SCTP association to an SG, the SG waits for the ASP to send an ASP Up message, which says the ASP IUA peer is available 🌸 The ASP is always the one who starts the ASP Up exchange.
When an ASP Up message shows up at an SG and the remote ASP isn't considered locked out for local management reasons, the SG marks that remote ASP as "Inactive" 🫶 Then the SG replies with an ASP Up Ack message to acknowledge it. The SG sends an ASP Up Ack in response to every ASP Up it receives, even when the ASP is already marked as "Inactive" at the SG 💅
If for any local reason the SG can't respond with an ASP Up Ack, it responds to the ASP Up with an ASP-Down Ack message with Reason "Management Blocking" 🙅♀️
At the ASP, the ASP Up Ack message from the SG is not acknowledged by the ASP 💖 If the ASP doesn't get a response from the SG, or it gets an ASP Down Ack instead, the ASP MAY resend ASP Up messages every 2 seconds until it gets an ASP Up Ack from the SG ⏰ If an ASP Up Ack still hasn't shown up after a few tries, the ASP MAY decide to slow down to every 5 seconds 🐢
The ASP MUST wait for the ASP Up Ack message from the SG before it sends any ASP traffic control messages (ASPAC or ASPIA) or Data messages, or it risks message loss 😬 If the SG receives QPTM, ASP Active or ASP Inactive messages before an ASP Up has been received, the SG SHOULD discard those messages 🗑️
4.3.3.2 ASP Down 🌈
The ASP sends an ASP Down to an SG when the ASP is being removed from the list of ASPs in all the Application Servers it belongs to, and it won't receive any IUA traffic or management messages anymore 👋
Whether the ASP is permanently removed from an AS is up to configuration management 🛠️
The SG marks the ASP as "Down" and returns an ASP Down Ack message to the ASP if either of these happens:
- to acknowledge an ASP Down message from an ASP,
- to reply to ASPM messages from an ASP that is locked out for management reasons.
The SG sends an ASP Down Ack message in response to every ASP Down message it receives from the ASP, even if the ASP is already marked as "Down" at the SG 💅
If the ASP doesn't get a response from the SG, the ASP MAY send ASP Down messages every 2 seconds until it gets an ASP Down Ack from the SG or the SCTP association goes down 🔁 If an ASP Down Ack still hasn't arrived after a few tries, the ASP MAY decide to slow down to every 5 seconds 🐌
4.3.3.3 IUA Version Control 🎀
okay so if an ASP Up message shows up with a version the receiving end doesn't support, that end sends back an Error message saying which version it does support, and it also tells Layer Management what happened 💅
this is super useful when protocol version upgrades are rolling out across a network 🌸 a node that got upgraded to a newer version SHOULD still support the older versions that the other nodes it talks to are using 🫶
ASPs are the ones who kick off the ASP Up procedure, so it's assumed the Error message would normally come from the SG 🧚
4.3.3.4 ASP Active ✨
any time after the ASP gets an ASP Up Ack from the SG, it sends an ASP-Active (ASPAC) to say "I'm ready to process traffic" 💖 if the ASP is set up to handle traffic for more than one Application Server across one SCTP association, the ASPAC carries one or more Interface Identifiers so the SG knows which Application Servers it applies to 🦋
when the SG gets an ASPAC, it replies with an ASPAC Ack saying "got it" 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'll risk message loss 💀 and if the SG gets QPTM messages before an ASP Active shows up, it SHOULD discard them 🙈
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 tells you which mode is used for a particular Application Server. if the SG decides the mode in an ASPAC is incompatible with the traffic handling mode the AS is currently using, it responds with an Error message indicating Unsupported Traffic Handling Mode 😭
in an Over-ride mode AS, getting an ASPAC at the SG redirects all traffic for the AS to the ASP that sent it 👑 the SG answers with an ASP-Active Ack to that ASP. any previously active ASP in the AS is now considered Inactive and stops getting traffic from the SG within the AS. the SG sends a Notify (Alternate ASP-Active) to the previously active ASP, but only after it has stopped all traffic to that ASP 🫶
in a load-share mode AS, getting an ASPAC at the SG directs traffic to the ASP that sent it, on top of all the other ASPs that are currently active in the AS 🌈 the algorithm the SG uses to load-share traffic across the active ASPs is implementation dependent. it could be round-robin, or based on info in the Data message such as the Interface Identifier, depending on what the application needs and how the ASPs in the AS handle call state 🧠 the SG responds to the ASPAC with an ASP-Active Ack message to the ASP ✨
4.3.3.5 ASP Inactive 👋
when an ASP wants to withdraw from receiving traffic within an AS, it sends an ASP Inactive (ASPIA) to the SG 💅 if the ASP is set up to process traffic for more than one Application Server across one SCTP association, the ASPIA carries one or more Interface Identifiers to say which Application Servers it applies to 🦋
there are two modes of Application Server traffic handling when withdrawing an ASP from service in the SG IUA: Over-ride and Load-sharing 👑 the Type parameter in the ASPIA message tells you the mode used for a particular Application Server. if the SG determines that the mode indicated in an ASPAC is incompatible with the traffic handling mode currently used in the AS, it responds with an Error message indicating Unsupported Traffic Handling Mode 😭
in an Over-ride mode AS, another ASP has usually already taken over the traffic with an Over-ride ASPAC, so the ASP sending the ASPIA is already considered "Inactive" by the SG 💀 an ASPIA Ack message goes back to that ASP, but only after the SG has made sure all traffic to it is stopped 🛑
in a Load-share mode AS, the SG moves the ASP to the "Inactive" state and the AS traffic gets re-allocated across the remaining "active" ASPs using the load-sharing algorithm in use within the AS 🔄 an ASPIA Ack message is sent to the ASP after all traffic to it has halted. 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 🚨 then it either discards all incoming messages for the AS, or starts buffering them for T(r) seconds, after which those messages get discarded. T(r) is configurable by the network operator ⏳ if the SG gets an ASPAC from an ASP in the AS before T(r) expires, the buffered traffic is sent to that ASP and the timer is cancelled 🎉 if T(r) expires, the AS is moved to the "Inactive" state 😔
4.3.3.6 Notify 📣
a Notify message that reflects a change in the AS state gets sent to all ASPs in the AS, except the ones in the "Down" state, with the appropriate Status Identification 💌
in the case where a Notify (AS-Pending) is sent by an SG that now has no ASPs active to service the traffic, or a NTFY (Insufficient ASPs) is sent in Load-share mode, the Notify does not explicitly force the ASP(s) that receive it to become active 🙅♀️ the ASPs stay in control of what happens and when 👑
4.3.3.7 Heartbeat 💓
the optional Heartbeat procedures MAY be used when operating over transport layers that don't have their own heartbeat mechanism for detecting loss of the transport association (so, anything other than SCTP) 🦋
after the ASP gets an ASP Up Ack 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, on 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 😭 the ASP stops sending BEAT messages and uses the ASP Up procedures 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, after examining the contents of the returned BEAT Ack message, MAY choose to consider the remote ASP unavailable 🙈 the contents and format of the Heartbeat Data parameter are 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".
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 establishing traffic between an SG and an ASP, where only one ASP is configured within an AS (no backup) 🌱 it's assumed 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 establishing traffic between an SG and two ASPs in the same Application Server 👯♀️ ASP1 is configured to be Active, and ASP2 is a standby in case of a communication failure or ASP1 withdrawing from service 🛟 ASP2 MAY act as a hot, warm, or cold standby, depending on how much ASP1 and ASP2 share call state, or can communicate call state, during failure or 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 Over-ride mode 👑
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |5.1.3 Two ASPs in an Application Server (1+1 sparing, load-sharing case)
this scenario is similar to Section 5.1.2, but this time the two ASPs are brought to active and load-share the traffic 🌈 in this case, one ASP is enough 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) 🦋
okay so this one is giving three ASPs in the same Application Server 👯♀️ two of them get brought to active and they split the load, so the total traffic is covered by a minimum of two ASPs. that's the 2+1 sparing vibe, and the third one just chills as the backup 💅
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) 🫶
this one shows what happens when an ASP withdraws from service 👋
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
|-------------------NTFY(AS-Pending) --------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| |so basically the SG tells ASP2 that the AS has moved to the Down state 📉 the SG could also (optionally) send a Notify message when the AS moved to the Pending state, so it's not required, just a nice extra 💜
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. no drama, the peer is already gone 💀
5.2.2 (1+1 Sparing, Back-up Over-ride) 👑
this is the main character moment where ASP2 wants to over-ride ASP1 and take over the traffic 😤
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. rip ASP1 🫠
5.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP) 🍓
picking up right where Section 5.1.4 left off, ASP1 decides to withdraw from service 🚪
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact------| | |
|---ASP Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |the SG has to know the minimum ASP resources it needs (this part is implementation dependent) 🧠 for example, if the SG knows that n+k = 2+1 for a load-share AS and n currently equals 1, it can work out what to do from there 🔥
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. same energy as before, the peer just vanished 👻
5.3 Q.921/Q.931 primitives backhaul Examples 🌈
okay so here's how the IUA layer handles a QPTM message going from the ASP to the SG 📨 it's a whole checklist:
- 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
- Send the QPTM message to the remote IUA peer in the SG, over the SCTP association
and going the other way, when the IUA layer on the SG has a QPTM message for the ASP, it does this:
- 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
here's the message flow for establishing a data link on a signaling channel, passing PDUs, and releasing the data link. an active association between MGC and SG is set up first (Section 5.1) before any of this happens ✨
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 ---------->and now the sad one 😭 a failed attempt to establish a data link on the signaling channel. the gateway has a problem with its physical connection (e.g., Red Alarm), so it just cannot set up the data link 🚨
SG ASP
<----------- Establish Request (ESTABLISH_START)
Release Indication ---------->
(RELEASE_PHYS)5.4 Layer Management Communication Examples 🧚
this shows Layer Management modules talking between the SG and the ASP 💬 again, an active association between ASP and SG is set up first (Section 5.1) before the flows below happen 🙌
SG ASP
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)6.0 Security 🔐
okay bestie, this section is SERIOUS. not a vibe check, a real one 🚨
IUA is designed to carry signaling messages for telephony services, so it has to think about the security needs of several parties 🫣 the end users of the services, the network providers, and the applications involved. IUA MUST involve all of those needs 😤 additional requirements MAY come from local regulation too 📜 while there's some overlap between these needs, any security solution SHOULD fulfill all of the different parties' needs 🤝
6.1 Threats 💀
there is no quick fix or one-size-fits-all solution for security, sorry not sorry 🙃 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] already provides some transport related security features, such as:
- Blind Denial of Service Attacks
- Flooding
- Masquerade
- Improper Monopolization of Services
when IUA is running in a professionally managed corporate or service provider network, it's reasonable to expect that this network has an appropriate security policy framework 🏢 the "Site Security Handbook" [5] SHOULD be consulted for guidance 📖
but when the network 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 that 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 🫧
especially for mobile users, the requirement for confidentiality MAY include masking IP addresses and ports 🕵️♀️ in that case application level encryption is not sufficient, so IPSEC ESP SHOULD be used instead. no matter which level does 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 the 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 show which protocol SCTP is carrying 📦 SCTP doesn't use it directly, but certain network entities MAY be used to spot what kind of info is in a Data chunk using it 👀
the User Adaptation peer MAY use the Payload Protocol Identifier to figure out extra info about the data SCTP hands it 🧩
7.2 IUA Protocol Extensions 🚀
this protocol can 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.
defining and using new message classes, types and parameters is an integral part of SIGTRAN adaptation layers 💫 so these extensions get 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 for a 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. (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 it does not support, it MUST respond with an Error (ERR) message with an Error Code of Unsupported Message Type. no ghosting allowed 🫶✨
7.2.3 is where we get to document our own parameters, and honestly it's giving organized 💅 Your documentation 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. 🌈
8.0 Acknowledgements ✨
Okay, the authors want to say thank you to 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. 🫶 Main character energy for sure 👑
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. ⭐
10.0 Authors' Addresses 🎀
The squad behind this one, with their contact info, lowkey iconic:
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.comMalleswar Kalla
Telcordia Technologies
PYA 2J-341
3 Corporate Place
Piscataway, NJ 08854
USA
Phone: +1-732-699-3728
EMail: mkalla@telcordia.comSelvam Rengasami
Telcordia Technologies
NVC-2Z439
331 Newman Springs Road
Red Bank, NJ 07701
USA
Phone: +1-732-758-5260
EMail: srengasa@telcordia.comGreg Sidebottom
Nortel Networks
3685 Richmond Road
Nepean, Ontario
Canada K2H5B7
Phone: +1-613-763-7305
EMail: gregside@nortelnetworks.com10. Full Copyright Statement ⚖️
Legal stuff, but it matters, so here it is in full 🫶
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. 🌈✨
📦 where this page comes from
- ietf: rfc3057 2001-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms