RFC 4233
Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
RFC 4233 📮 ISDN Q.921-User Adaptation Layer 🎀
Okay bestie, this is RFC 4233 💖, titled Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer. It's a Standards Track doc from the Network Working Group, dated January 2006. The authors are K. Morneault (Cisco Systems), S. Rengasami (Tridea Works), M. Kalla (Telcordia Technologies), and G. Sidebottom (Signatus Technologies). It also obsoletes RFC 3057 🫶, so RFC 3057 is officially retired and this one is the new main character 👑.
Status of This Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's basically asking everyone to discuss it and suggest improvements 🗣️. For the standardization state and status of this protocol, 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 (2006).
Abstract 🦋
This doc defines a protocol for backhauling ISDN Q.921 User messages over IP, using the Stream Control Transmission Protocol (SCTP) 🚀. It's used between a Signaling Gateway (SG) and a Media Gateway Controller (MGC). It's assumed that the SG receives ISDN signaling over a standard ISDN interface 🔌.
This document obsoletes RFC 3057. 🙈
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. IUA Overview ...............................................5
1.4. Services Provided by the IUA Layer .........................7
1.5. Functions Implemented by the IUA Layer ....................10
1.6. Definition of IUA Boundaries ..............................12
2. Conventions ....................................................15
3. Protocol Elements ..............................................15
3.1. Common Message Header .....................................15
3.2. IUA Message Header ........................................19
3.3. IUA Messages ..............................................21
4. Procedures .....................................................46
4.1. Procedures to Support Service in Section 1.4.1 ............46
4.2. Procedures to Support Service in Section 1.4.2 ............46
4.3. Procedures to Support Service in Section 1.4.3 ............48
5. Examples .......................................................58
5.1. Establishment of Association and Traffic between
SGs and ASPs ..............................................58
5.2. ASP Traffic Fail-over Examples ............................62
5.3. Q.921/Q.931 Primitives Backhaul Examples ..................63
5.4. Layer Management Communication Examples ...................64
6. Security .......................................................65
7. IANA Considerations ............................................65
7.1. SCTP Payload Protocol Identifier ..........................65
7.2. IUA Protocol Extensions ...................................65
8. Timer Values ...................................................67
9. Acknowledgements ...............................................67
10. References ....................................................67
10.1. Normative References .....................................67
10.2. Informative References ...................................67
11. Change Log ....................................................68
Appendix A ........................................................69
A.1. Signaling Network Architecture ............................69
A.2. Application Server Process Redundancy .....................701. 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 🍓
There's a real need to deliver Switched Circuit Network (SCN) signaling protocol from an ISDN Signaling Gateway (SG) to a Media Gateway Controller (MGC), as described in the Framework Architecture for Signaling Transport [5] 🛤️. 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 SCTP active associations between SG and MGC
This doc supports both ISDN Primary Rate Access (PRA) and Basic Rate Access (BRA), including both point-to-point and point-to-multipoint modes of communication 📞. That covers 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 also apply to a QSIG adaptation layer 🙌. To keep things simple, the rest of the doc only mentions Q.931 🫶.
1.2. Terminology 📖
- Application Server (AS) - A logical entity serving a specific application instance. For example, an AS can be an MGC handling the 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 🧚.
- Association - An association refers to an SCTP association. It provides the transport for delivering Q.921-User protocol data units and IUA adaptation layer peer messages 🚚.
- 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 🔁.
- Fail-over - The ability to re-route signaling traffic between related ASPs when the one in use fails or becomes unavailable (e.g., from primary MGC to backup MGC). Fail-over also kicks in when a previously unavailable process comes back into service 🦸♀️.
- Host - The computing platform the ASP process is running on 💻.
- Interface - In 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 🎧.
- Interface Identifier - This identifies the physical interface at the SG where signaling messages are sent and received. The Interface Identifier parameter 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 🪪.
- 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 🔢.
- Stream - A stream refers to an SCTP stream: a uni-directional logical channel established from one SCTP endpoint to another associated SCTP endpoint. Within it, all user messages are delivered in sequence, except those submitted to the un-ordered delivery service 🌊.
- Q.921-User - Any protocol that normally uses the services of ISDN Q.921 (e.g., Q.931, QSIG, etc.) 💅.
1.3. IUA Overview 🦋
The architecture defined for SCN signaling transport over IP [5] has multiple components: an IP transport protocol, a signaling common transport protocol, and an adaptation module. The adaptation module supports the services a particular SCN signaling protocol expects from its underlying protocol layer 🧩.
This doc defines an adaptation module that's suitable for transporting ISDN Q.921-User (e.g., Q.931) messages 💖.
1.3.1. Example: SG to MGC 🌈
In a Signaling Gateway (SG), ISDN signaling is expected to arrive over a standard ISDN network termination. The SG then provides interworking of transport functions with IP Signaling Transport. That lets it carry Q.931 signaling messages to the MGC, where the peer Q.931 protocol layer lives, as shown below 🛰️:
****** 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 [4,8])
IUA - ISDN User Adaptation Layer ProtocolFigure 1. IUA in the SG to MGC Application 🎀
It is recommended that the IUA use the services of the Stream Control Transmission Protocol (SCTP) as its underlying reliable common signaling transport protocol. SCTP gives you these features 🔥:
- explicit packet-oriented delivery (not stream-oriented)
- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages
- optional multiplexing of user messages into SCTP datagrams
- network-level fault tolerance through support of multi-homing at either or both ends of an association
- resistance to flooding and masquerade attacks
- data segmentation to conform to discovered path MTU size
There are scenarios without redundancy requirements, and scenarios where redundancy is handled below the transport layer. In those cases, the SCTP functions above MAY be determined to not be required, and TCP MAY be used as the underlying common transport protocol 🫧.
1.3.2. Support for the Management of SCTP Associations between the SG and ASPs
okay bestie, so the IUA layer at the SG keeps track of the availability state of all the dynamically registered remote ASPs 💖 It does this so it can manage the SCTP associations and the traffic going between the SG and the ASPs ✨. It also keeps the active/inactive states of remote ASP(s) 🦋. Active ASPs are the ones currently receiving traffic from the SG, iykyk 💅.
The IUA layer MAY be instructed by local management to establish an SCTP association to a peer IUA node. This can be done with the M-SCTP ESTABLISH primitive, which is used to request, indicate, and confirm the establishment of an SCTP association with a peer IUA node 🎀.
The IUA layer MAY also need to tell local management about the status of the underlying SCTP associations using the M-SCTP STATUS request and indication primitive 🌸. For example, the IUA MAY inform local management of the reason for the release of an SCTP association, whether that was determined locally within the IUA layer or by a primitive from the SCTP 🧚.
1.3.3. ASP Fail-over Model and Terminology
the IUA layer supports ASP fail-over functions so it can keep call processing highly available 📞✨. All Q.921-User messages coming into an SG get assigned to a unique Application Server, based on the Interface Identifier of the message 👑.
The Application Server is, practically speaking, a list of all the ASPs configured to process Q.921-User messages from certain Interface Identifiers 💜. One or more ASPs in the list are normally active (i.e., handling traffic) while any others MAY be unavailable or inactive, so they can possibly step in if the active ASP(s) fail or become unavailable 🫶.
The IUA layer supports an n+k redundancy model (active-standby, load sharing, broadcast) where n is the minimum number of redundant ASPs required to handle traffic and k ASPs are available to take over for a failed or unavailable ASP. Note that 1+1 active/standby redundancy is a subset of this model 🍓. A simplex 1+0 model is also supported as a subset, with no ASP redundancy 🌈.
1.3.4. Client/Server Model
it is recommended that the SG and ASP be able to support both client and server operation 🙈. The peer endpoints using IUA SHOULD be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations. The default orientation would be for the SG to take on the role of server while the ASP is the client. In this case, ASPs SHOULD initiate the SCTP association to the SG 💅.
The SCTP and 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 of this boundary to successfully backhaul Q.931 💖.
This includes the following primitives [1]:
DL-ESTABLISH
The DL-ESTABLISH primitives are used to request, indicate, and confirm the outcome of the procedures for establishing multiple frame operation ✨.
DL-RELEASE
DL-RELEASE primitives are used to request, indicate, and confirm the outcome of the procedures for terminating a previously established multiple frame operation, or for reporting an unsuccessful establishment attempt 🥀.
DL-DATA
The DL-DATA primitives are used to request and indicate layer 3 (Q.931) messages that 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 that 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
it is envisioned that the IUA layer needs to provide some services that will facilitate communication between Layer Management modules on the SG and MGC 🧚. These primitives are shown below:
M-TEI STATUS
The M-TEI STATUS primitives are used to request, confirm, and indicate the status (assigned/unassigned) of an ISDN Terminal Endpoint Identifier (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, to help Layer Management manage the SCTP association(s) between the SG and MGC 💜. The IUA layer can be instructed by Layer Management to establish an SCTP association to a peer IUA node. This procedure can be achieved using the M-SCTP ESTABLISH primitive ✨.
M-SCTP ESTABLISH
The M-SCTP ESTABLISH primitives are used to request, indicate, and confirm the establishment of an SCTP association to a peer IUA node 💅.
M-SCTP RELEASE
The M-SCTP RELEASE primitives are used to request, indicate, and confirm the release of an SCTP association to a peer IUA node 🥀.
The IUA layer MAY also need to inform Layer Management of the status of the SCTP associations. This can be achieved using the M-SCTP STATUS primitive 🌈.
M-SCTP STATUS
The M-SCTP STATUS primitives are used to request and indicate the status of the underlying SCTP association(s) 🦋.
Layer Management MAY need to inform the IUA layer of an AS/ASP status (i.e., failure, active, etc.), so that messages can be exchanged between IUA layer peers to stop traffic to the local IUA user. This can be achieved using the M-ASP STATUS primitive 🫶.
M-ASP STATUS
The ASP status is stored inside 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. This primitive can also be used to indicate the status of the Application Server Process ✨.
M-ASP-UP
The M-ASP-UP primitive can be used by Layer Management to send a ASP Up message for the Application Server Process. It can also be used to generate an ASP Up Acknowledgement 🎀.
M-ASP-DOWN
The M-ASP-DOWN primitive can be used by Layer Management to send a ASP Down message for the Application Server Process. It can also be used to generate an ASP Down Acknowledgement 🍓.
M-ASP-ACTIVE
The M-ASP-UP primitive can be used by Layer Management to send a ASP Active message for the Application Server Process. It can also be used to generate an ASP Active Acknowledgement 🌸.
M-ASP-INACTIVE
The M-ASP-UP primitive can be used by Layer Management to send a ASP Inactive message for the Application Server Process. It can also be used to generate an ASP Inactive Acknowledgement 🧚.
M-AS STATUS
The M-AS STATUS primitive can be used by Layer Management to request the status of the Application Server. This primitive can also be used to indicate the status of the Application Server 👑.
1.5. Functions Implemented by the IUA Layer
1.5.1. Mapping
The IUA layer MUST maintain a map of the Interface Identifier to a physical interface on the Signaling Gateway 🗺️. A physical interface would be a T1 line, E1 line, etc., and could include the Time-Division Multiplexing (TDM) timeslot. In addition, for a given interface the SG MUST be able to identify the associated signaling channel 📡. IUA layers on both SG and MGC MAY maintain the status of ISDN Terminal Endpoint Identifiers (TEIs) and Service Access Point Identifiers (SAPIs) 💜.
The SG maps an Interface Identifier to an SCTP association/stream only when an ASP sends an ASP Active message for a particular Interface Identifier. It MUST be noted, however, that this mapping is dynamic and could change at any time due to a change of ASP state 😭. This mapping could even temporarily be invalid, for example, during fail-over of one ASP to another. Therefore, the SG MUST maintain the states of AS/ASP and reference them during the routing of an messages to an AS/ASP 🔥.
One example of the logical view of relationship between D channel, Interface Identifier, AS, and ASP in the SG is shown below 🧠:
/---------------------------------------------------+
/ /------------------------------------------------|--+
/ / v |
/ / +----+ act+-----+ +-------+ -+--+-|+--+-
D chan1-------->|IID |-+ +-->| ASP |--->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+--+-
/ +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+
D chan2-------->|IID |-+ | ASP |
+----+ +-----+where IID = Interface Identifier
Note that an ASP can be in more than one AS 💅.
1.5.2. Status of ASPs
The IUA layer on the SG MUST maintain the state of the ASPs it is supporting 🫶. The state of an ASP changes because of reception of peer-to-peer messages (ASPM messages as described in Section 3.3.2) or reception of indications from the local SCTP association. ASP state transition procedures are described in Section 4.3.1 🦋.
At an SG, an Application Server list MAY contain active and inactive ASPs to support ASP load-sharing and fail-over procedures. When, for example, both a primary and a backup ASP are available, IUA peer protocol is required to control which ASP is currently active 🎀. The ordered list of ASPs within a logical Application Server is kept updated in the SG to reflect the active Application Server Process(es) 🌸.
Also the IUA layer MAY need to inform local management of the change in status of an ASP or AS. This can be achieved using the M-ASP STATUS or M-AS STATUS primitives 🧚.
1.5.3. SCTP Stream Management
SCTP allows a user-specified number of streams to be opened during the initialization. It is the responsibility of the IUA layer to ensure proper management of these streams 🌊. Because of the unidirectional nature of streams, an IUA layer is not aware of the stream number to Interface Identifier mapping of its peer IUA layer. Instead, the Interface Identifier is in the IUA message header 💖.
The use of SCTP streams within IUA is recommended in order to minimize transmission and buffering delay, therefore improving the overall performance and reliability of the signaling elements ✨. It is recommended that a separate SCTP stream is used for each D channel 👑.
1.5.4. Seamless Network Management Interworking
The IUA layer on the SG SHOULD pass an indication of unavailability of the IUA-User (Q.931) to the local Layer Management, if the currently active ASP moves from the ACTIVE state 😳. The Layer Management could instruct Q.921 to take some action, if it deems appropriate 💅.
Likewise, if an SCTP association fails, the IUA layer on both the SG and ASP sides MAY generate Release primitives to take the data links out-of-service 🥀.
1.5.5. Congestion Management
If the IUA layer becomes congested (implementation dependent), it MAY stop reading from the SCTP association to flow control from the peer IUA 🌧️.
1.6. Definition of IUA Boundaries
1.6.1. Definition of IUA/Q.921 Boundary
DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA1.6.2. Definition of 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 provided by SCTP are available in Section 10 of RFC 2960 [4] 📖🫶
1.6.4. Definition of IUA/Layer-Management Boundary ✨
okay so this is where the Layer Management (LM) side talks to the IUA 💅 these are the primitives LM uses to tell the ASP what to do, and how the ASP and SG report back. here they all are:
M-SCTP ESTABLISH request(Direction: LM -> IUA): LM tells the ASP to set up an SCTP association with an SG 💖M-STCP ESTABLISH confirm(Direction: IUA -> LM): the ASP confirms to LM that its SCTP association with an SG is up ✨M-SCTP ESTABLISH indication(Direction: IUA -> LM): the SG lets LM know an ASP has set up an SCTP association 🫶M-SCTP RELEASE request(Direction: LM -> IUA): LM tells the ASP to release its SCTP association with the SG 🦋M-SCTP RELEASE confirm(Direction: IUA -> LM): the ASP confirms it has released its SCTP association with the SG 🌸M-SCTP RELEASE indication(Direction: IUA -> LM): the SG tells LM that an ASP has released an SCTP association 💀M-SCTP STATUS request(Direction: LM -> IUA): LM asks the IUA for the status of an SCTP association 🔥M-SCTP STATUS indication(Direction: IUA -> LM): the IUA reports the status of an SCTP association 👑M-ASP STATUS request(Direction: LM -> IUA): LM asks the SG for the status of a remote ASP 🧚M-ASP STATUS indication(Direction: IUA -> LM): the SG reports the status of a remote ASP 💜M-AS-STATUS request(Direction: LM -> IUA): LM asks the SG for the status of an AS 🌈M-AS-STATUS indication(Direction: IUA -> LM): the SG reports the status of an AS ⭐M-NOTIFY indication(Direction: IUA -> LM): the ASP reports that it got a NOTIFY message from its peer 🍓M-ERROR indication(Direction: IUA -> LM): the ASP or SG reports that it got an ERROR message from its peer 😭M-ASP-UP request(Direction: LM -> IUA): LM tells the ASP to start operating and send an ASP UP message to the SG 🎀M-ASP-UP confirm(Direction: IUA -> LM): the ASP reports that it got an ASP UP Acknowledgement from the SG 🫶M-ASP-DOWN request(Direction: LM -> IUA): LM tells the ASP to stop operating and send an ASP DOWN message to the SG 🙈M-ASP-DOWN confirm(Direction: IUA -> LM): the ASP reports that it got an ASP DOWN Acknowledgement from the SG 🌸M-ASP-ACTIVE request(Direction: LM -> IUA): LM tells the ASP to send an ASP ACTIVE message to the SG 🔥M-ASP-ACTIVE confirm(Direction: IUA -> LM): the ASP reports that it got an ASP ACTIVE Acknowledgement from the SG 💅M-ASP-INACTIVE request(Direction: LM -> IUA): LM tells the ASP to send an ASP INACTIVE message to the SG 🦋M-ASP-INACTIVE confirm(Direction: IUA -> LM): the ASP reports that it got an ASP INACTIVE Acknowledgement from the SG ✨M-TEI STATUS request(Direction: LM -> IUA): LM tells the ASP to send a TEI status request to the SG 🧚M-TEI STATUS indication(Direction: IUA -> LM): the ASP reports that it got a TEI status indication from the SG 💜M-TEI STATUS confirm(Direction: IUA -> LM): the ASP reports that it got a TEI status confirm from the SG 👑
2. Conventions 🎀
okay so when MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL show up in this doc, read them the way [6] explains. these words carry real weight, so don't skip them 🫶
3. Protocol Elements 🌸
this section breaks down the format of the messages this protocol uses, and it's honestly the good stuff 🔥
3.1. Common Message Header 💅
the protocol messages for Q.921-User Adaptation all need a header that carries the adaptation layer version, the message type, and the message length. it's the very first thing you see, so it's giving main character 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2. Common Header Format
every field in an IUA message MUST be sent in network byte order, unless it's stated otherwise 🌈
3.1.1. Version 🍓
the version field tells you which version of the IUA adaptation layer you're dealing with. right now the supported versions are:
Value Version
----- -------
1 Release 1.03.1.2. Message Classes and Types 🧚
here's the list of valid Message Classes. it's a long one, but it's lowkey iconic 💖
Message Class: 8 bits (unsigned integer)
0 Management (MGMT) Message
1 Reserved for Other SIGTRAN Adaptation Layer
2 Reserved for Other SIGTRAN Adaptation Layers
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
6 Reserved for Other SIGTRAN Adaptation Layer
7 Reserved for Other SIGTRAN Adaptation Layer
8 Reserved for Other SIGTRAN Adaptation Layer
9 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensionsand here are the message names for each defined message. each class has its own little list:
Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
0 Reserved
1 Data Request Message
2 Data Indication Message
3 Unit Data Request Message
4 Unit Data Indication Message
5 Establish Request
6 Establish Confirm
7 Establish Indication
8 Release Request
9 Release Confirm
10 Release Indication
11 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined QPTM extensions
Application Server Process State Maintenance (ASPSM) messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heatbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
Application Server Process Traffic Maintenance (ASPTM) messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions
Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 TEI Status Request
3 TEI Status Confirm
4 TEI Status Indication
5 TEI Query Request
6 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions3.1.3. Reserved 🫶
the Reserved field is 8 bits. it SHOULD be set to all '0's, and the receiver should just ignore it 🙈
3.1.4. Message Length 💜
the Message Length tells you how long the whole message is in octets, and that includes the Common Header. the Message Length MUST count any parameter padding bytes, if there are any 🍓
Note: A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length.
3.1.5. Variable-Length Parameter Format ✨
an IUA message is a Common Header followed by zero or more variable-length parameters, depending on the message type. these parameters use a Type-Length-Value (TLV) format, which 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 go before optional parameters in a message. no skipping that order, bestie 💅
Parameter Tag: 16 bits (unsigned integer)
the Tag field is a 16-bit identifier for the type of parameter. it takes a value from 0 to 65534. common parameters used by adaptation layers sit in the range 0x00 to 0x3f. the parameter Tags defined here are:
Common Parameters. These TLV parameters are common across the
different adaptation layers:
Parameter Name Parameter ID
============== ============
Reserved 0x0000
Interface Identifier (integer) 0x0001
Not Used in IUA 0x0002
Interface Identifier (text) 0x0003
INFO String 0x0004
DLCI 0x0005
Not Used in IUA 0x0006
Diagnostic Information 0x0007
Interface Identifier Range 0x0008
Heartbeat Data 0x0009
Not Used in IUA 0x000a
Traffic Mode Type 0x000b
Error Code 0x000c
Status 0x000d
Protocol Data 0x000e
Release Reason 0x000f
TEI Status 0x0010
ASP Identifier 0x0011
Not Used in IUA 0x0012 - 0x003fthe value 65535 is reserved for IETF-defined extensions. any value that isn't defined in a specific parameter description is reserved for the IETF to use later 🦋
Parameter Length: 16 bits (unsigned integer)
the Parameter Length field holds the size of the parameter in bytes. that count includes the Parameter Tag, Parameter Length, and Parameter Value fields, but it does not include any padding bytes 🌈
Parameter Value: variable-length
the Parameter Value field is where the actual info for the parameter lives 💖
Padding
the total length of a parameter (Tag, Parameter Length, and Value together) MUST be a multiple of 4 bytes. if it isn't, the sender adds zero-valued padding bytes at the end, after the Parameter Value field. the length of that padding is not counted in the Parameter Length field. a sender SHOULD NEVER pad with more than 3 bytes. and the receiver MUST ignore the padding bytes, so it's not going to fuss about them 🙈
3.2. IUA Message Header ✨
okay so, on top of the common message header, QPTM and the TEI Status MGMT messages get their own special header 🎀. The IUA message header comes right after the Common header in these messages.
This header carries the Interface Identifier and the Data Link Connection Identifier (DLCI) 💖. The Interface Identifier names the physical interface that terminates the signaling channel at the SG, which is where the signaling messages get sent and received 🦋. It can be text or integer. Interface Identifiers get assigned according to network operator policy, and the integer values only mean something locally, coordinated between the SG and ASP 🧚.
The integer-formatted Interface Identifier MUST be supported. The text-formatted Interface Identifier MAY optionally be supported.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IUA Message Header (Integer-based Interface Identifier)The Tag value for the Integer-based Interface Identifier is 0x1. The length is always set to a value of 8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Interface Identifier (text) \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. IUA Message Header (Text-based Interface Identifier)The Tag value for the Text-based [2] Interface Identifier is 0x3. The length is variable.
The DLCI format is shown below in Figure 5 🌸.
most least
significant significant
bit bit
+-----+-----+-----+-----+-----+-----+-----+-----+
| SAPI | SPR | 0 |
+-----------------------------------------------+
| TEI | 1 |
+-----------------------------------------------+
Figure 5. DLCI FormatSPR: Spare 2nd bit in octet 1 (1 bit)
SAPI: Service Access Point Identifier (6 bits)
TEI: Terminal Endpoint Identifier (7 bits)
As an example, SAPI = 0, TEI = 64, SPR = 0 would be encoded as follows 🍓:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x81 | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The DLCI field (including the SAPI and TEI) is coded in accordance with Q.921.
3.3. IUA Messages 📬
Here's where the messages and their parameter contents get defined. The IUA messages will use the common message header (Figure 2) and the IUA message header (Figure 3 and Figure 4).
3.3.1. Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages 💌
3.3.1.1. Establish Messages (Request, Confirm, Indication)
The Establish Messages are used to establish a data link on the signaling channel, or to confirm that a data link on the signaling channel has been established 🔥. The MGC controls the state of the D channel. When the MGC wants the D channel to be in-service, it will send the Establish Request message.
When the MGC sends an IUA Establish Request message, the MGC MAY start a timer. This timer would be stopped upon receipt of an IUA Establish Confirm or Establish Indication. If the timer expires, the MGC would resend the IUA Establish Request message and restart the timer. In other words, the MGC MAY continue to request the establishment of the data link on a periodic basis until the desired state is achieved, or take some other action (notify the Management Layer) 💅.
When the SG receives an IUA Establish Request from the MGC, the SG shall send the Q.921 Establish Request primitive to the Q.921 entity. In addition, the SG shall map any response received from the Q.921 entity to the appropriate message to the MGC. For example, if the Q.921 entity responds with a Q.921 Establish Confirm primitive, the IUA layer shall map this to an IUA Establish Confirm message. As another example, if the IUA Layer receives a Q.921 Release Confirm or Release Indication as an apparent response to the Q.921 Establish Request primitive, the IUA Layer shall map these to the corresponding IUA Release Confirm or Release Indication messages 🦋.
The Establish messages contain the common message header followed by 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 is received, the MGC can consider the data link as being released. In this case, signaling traffic on that D channel is not expected from the SG, and signaling traffic will not be sent to the SG for that D channel 😭.
The Release messages contain the common message header followed by 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
The format for Release Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xf) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The valid values for Reason are shown in the following table 👑.
Define Value Description
RELEASE_MGMT 0x0 Management layer generated release.
RELEASE_PHYS 0x1 Physical layer alarm generated release.
RELEASE_DM 0x2 Specific to a request. Indicates Layer 2
SHOULD release and deny all requests from
far end to establish a data link on the
signaling channel (i.e., if SABME is
received, send a DM)
RELEASE_OTHER 0x3 Other reasonsNote: Only RELEASE_MGMT, RELEASE_DM, and RELEASE_OTHER are valid reason codes for a Release Request message.
3.3.1.3. Data Messages (Request, Indication)
The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to the acknowledged information transfer service ✨.
The Data messages contain the common message header followed by the IUA message header. The Data message contains the following parameter:
Protocol Data
The format for Data 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 (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The protocol data contains an upper layer signaling message, e.g., Q.931, QSIG 🧚.
3.3.1.4. Unit Data Messages (Request, Indication)
The Unit Data message contains an ISDN Q.921-User Protocol Data Unit (PDU) corresponding to the 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 parameter:
Protocol Data
The format for Unit Data 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 (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.3.2. Application Server Process Maintenance (ASPM) Messages 🎀
The ASPM messages will use only the common message header 💜.
3.3.2.1. ASP Up (ASPUP) ✨
okay bestie, the ASP Up (ASPUP) message is how an ASP tells an SG "hiii, I'm ready for traffic or maintenance messages" 🦋 it's sent by the ASP to the SG to say exactly that 💖
The ASPUP message contains the following parameters:
ASP Identifier (Optional)
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 = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ASP Identifier: 32-bit unsigned integer. The optional ASP Identifier parameter is a unique value that is locally significant among the ASPs that support an AS. The SG should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.3.3.2) 🔥
The optional INFO String parameter can carry any meaningful 8-bit ASCII [2] 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 🫶 like, "got it, thanks bestie" 💅
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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1) 🌸
3.3.2.3. ASP Down (ASPDN)
the ASP Down (ASPDN) message is sent by an ASP to tell an SG that it is NOT ready to receive traffic or maintenance messages. it's the "brb, logging off" 🥺🌙
The ASPDN message contains the following parameters:
INFO String (Optional)The format for the ASPDN message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1) 💜
3.3.2.4. ASP Down Ack
the ASP Down Ack message is used to acknowledge an ASP Down message received from a remote IUA peer. the "ok bye, see ya" reply 👋🦋
The ASP Down Ack message contains the following parameters:
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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format and description of the optional INFO String parameter are the same as for the ASP Up message (see Section 3.3.2.1) 🎀
3.3.2.5. ASP Active (ASPAC) 💖
okay bestie, this is the ASPAC message 🦋 an ASP sends it to an SG to say "hi, I'm Active and ready to take traffic" ✨ literally the main character announcement
The ASPAC 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)
okay so when the Interface Identifiers are integers, the ASPAC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and when they're text-formatted (string) it 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Traffic Mode Type parameter tells the SG what traffic mode the ASP is running in within an AS 🍓 the valid values are in this table, no cap:
Value Description
0x1 Over-ride
0x2 Load-sharewithin a particular AS, only one Traffic Mode Type can be used 👑 the Over-ride value means the ASP is in Over-ride mode, where it takes over ALL the traffic in an Application Server (aka primary/backup vibes) and over-rides any ASPs that are currently active in the AS 😭 Load-share mode is more of a team sport: the ASP shares the traffic distribution with any other currently active ASPs 🫶
the optional Interface Identifiers parameter is a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) that index the Application Server traffic the sending ASP is configured/registered to receive 💅 if you're using integers, the ASP can also send ranges (Type 0x8) ✨ integers (0x1) and integer ranges (0x8) can be mixed in the same message, but text-formatted ones (0x3) can't be combined with either of them. not allowed bestie 🙈
if there are no Interface Identifiers at all, the message covers all the provisioned Interface Identifiers in the AS or ASes where the ASP is provisioned 🧚 if you only send a subset, the ASP is marked 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, whereas the text-formatted Interface Identifier MAY be supported. 🔥
the INFO String parameter works exactly the same way as it does in the ASP Up message (see Section 3.3.2.1.) 🌈
and last but not least, if an SG gets an ASPAC with an incorrect Traffic Mode Type for a particular Interface Identifier, it responds with an Error Message (Cause: Unsupported Traffic Handling Mode) 💀 rip to that ASPAC
3.3.2.6. ASP Active Ack ✨
Okay bestie, the ASPAC Ack is the reply that says "yep, got your ASP Active message" 💌 It's sent to acknowledge an ASP Active message that came in from a remote IUA peer. Iconic behaviour, honestly 💅
The ASPAC Ack message has these parameters:
- Traffic Mode Type (Mandatory) 🎀
- Interface Identifier (Optional) 🦋
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (Optional) 🧚
Here's how the ASPAC Ack looks when the 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 = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now for the text-formatted (string) Interface Identifiers version 🌸 The format for the ASP Active Ack message using text-formatted (string) Interface Identifiers is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ 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 🦋 (see Section 3.3.2.5). And the optional INFO String parameter is the same as in the ASP Up message 🧚 (see Section 3.3.2.1). Bestie, you're learning so fast 🫶
3.3.2.7. ASP Inactive (ASPIA) 🌈
So the ASPIA message is what an ASP sends to tell an SG "hey, I'm no longer an active ASP you should be routing to" 🙈 It's basically the ASP stepping out of the list of ASPs that can get traffic. The SG answers with an ASPIA Ack, and then it either throws away incoming messages, or buffers them for a set amount of time and then throws them away 💀
The ASPIA message has these parameters:
- Interface Identifiers (Optional) 🎀
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (Optional) 🧚
Here's the ASP Inactive message with integer-formatted 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 (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's the text-formatted (string) version 🍓 The format for the ASP Inactive message using text-formatted (string) Interface Identifiers is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The optional Interface Identifiers parameter is a list of Interface Identifier integers or text strings that point at the Application Server traffic the sending ASP is configured or registered to receive, but doesn't want to receive right now 🥺
The format and description of the optional Interface Identifiers and INFO String parameters are the same as in the ASP Active message 💖 (see Section 3.3.2.5).
3.3.2.8. ASP Inactive Ack 🎀
okay so the ASPIA Ack is the "got it, bestie" reply 💅 It gets sent to acknowledge an ASP Inactive message that came in from a remote IUA peer 🫶
The ASPIA Ack message has these parameters:
- Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (Optional)
Here's the layout for the ASP Inactive Ack when the 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 (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (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 (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format and description of the optional Interface Identifiers and INFO String parameters are the same as for the ASP Active message (see Section 3.3.2.5). It's giving copy-paste energy, and I love that for us 🌸
3.3.2.9. Heartbeat (BEAT) 💓
the Heartbeat message is optionally used to make sure the IUA peers are still around for each other 🥹 It's recommended for use when the IUA runs over a transport layer other than the SCTP, which already has its own heartbeat ✨
The BEAT message has this parameter:
- Heartbeat Data (Optional)
Here's the format for the BEAT message 🦋
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 = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Heartbeat Data contents are defined by the sending node 🧁 It could include things like a Heartbeat Sequence Number and/or a Timestamp. The receiver doesn't process this field, because it only matters to the sender 🙈 The receiver MUST respond with a Heartbeat Ack message. no cap, that one is non-negotiable 💅
3.3.2.10. Heartbeat Ack (BEAT-Ack) ✨
The Heartbeat Ack message gets sent in response to a received Heartbeat message 💖 It includes all the parameters of the received Heartbeat message, completely unchanged. iconic, no edits 🫶
3.3.3. Layer Management (MGMT) Messages 🌈
3.3.3.1. Error (ERR) 🚨
okay so the Error message is how you tell your peer "hey, something about that last message was not it" 🙈 It gets sent to notify a peer of an error event tied to an incoming message. Maybe the message type doesn't make sense for the current state, or a parameter value is invalid. Literally that's the whole vibe ✨
The Error message has only the common message header 💅 and it carries these 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 = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Diagnostic Information \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Code parameter tells you the reason for the Error message 🎀 Its value can be one of these:
Invalid Version 0x01
Invalid Interface Identifier 0x02
Unsupported Message Class 0x03
Unsupported Message Type 0x04
Unsupported Traffic Handling Mode 0x05
Unexpected Message 0x06
Protocol Error 0x07
Unsupported Interface Identifier Type 0x08
Invalid Stream Identifier 0x09
Unassigned TEI 0x0a
Unrecognized SAPI 0x0b
Invalid TEI, SAPI combination 0x0c
Refused - Management Blocking 0x0d
ASP Identifier Required 0x0e
Invalid ASP Identifier 0x0f"Invalid Version" 🙅 is what you'd get if a message shows up with an invalid or unsupported version. The Error message would carry the supported version in the Common header, and it could optionally also list the supported version in the Diagnostic Information area ✨
"Invalid Interface Identifier" is sent by an SG when an ASP sends a message with an invalid (unconfigured) Interface Identifier value. For this error, the Diagnostic Information MUST contain enough of the offending message to identify the invalid Interface Identifier. For example, with QPTM and TEI Status management messages, the Common and IUA message headers of the offending message would go in the Diagnostic Information at a minimum 🧚
"Unsupported Traffic Handling Mode" is sent by an SG when an ASP sends an ASP Active with a Traffic Handling Mode the SG doesn't support. Like, if the SG didn't support load-sharing 🍓
"Unexpected Message" is the one an ASP sends if it gets a QPTM message from an SG while it's in the Inactive state (the ASP could optionally drop the message and skip sending an error). It also gets sent by an ASP that receives a defined and recognized message the SG isn't supposed to send, like when the MGC receives an IUA Establish Request message 👀
"Protocol Error" is for any protocol anomaly, aka a bogus message 💀
"Invalid Stream Identifier" shows up when a message arrives on an unexpected SCTP stream, like an MGMT message received on a stream other than "0" 🌸
"Unsupported Interface Identifier Type" is sent by an SG when an ASP sends a text-formatted Interface Identifier and the SG only supports integer-formatted ones. When the ASP gets this error, it'll need to resend its message with an integer-formatted Interface Identifier 🦋
"Unsupported Message Type" is for a message with an unexpected or unsupported Message Type, and "Unsupported Message Class" is the same deal but for the Message Class 🙈
"Unassigned TEI" may be used when the SG gets an IUA message that includes a TEI which hasn't been assigned or recognized for use on the indicated ISDN D-channel 🫶
"Unrecognized SAPI" covers the case where you use a SAPI the SG doesn't recognize. "Invalid TEI, SAPI combination" is a little more specific: the TEI is assigned and the SAPI is recognized, but the combo isn't valid for that interface. For example, on a Basic Rate Interface (BRI), the MGC tries to send Q.921 Management messages via IUA when Layer Management at the SG SHOULD be performing this function. Not me, the MGC thinking it's the boss 😭
"Refused - Management Blocking" is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons, like a management lockout 🔥
"ASP Identifier Required" is sent by an SG in response to an ASP Up message that doesn't include an ASP Identifier parameter when the SG requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier 💜
"Invalid ASP Identifier" is sent by an SG in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier. Unique IDs only, bestie 👑
Diagnostic Information is variable length 🌈 When it's included, the optional Diagnostic Information can be any info that's germane to the error condition, so it helps identify what went wrong. The Diagnostic Information SHOULD contain the offending message ⭐
Error messages MUST NOT be generated in response to other Error messages. Error messages don't reply to error messages, periodt 💅
3.3.3.2. Notify (NTFY) 📣
Okay so the Notify message is how an IUA peer gets an autonomous heads-up about IUA events. It's giving "hey, something just changed, you should know" 👀
The Notify message uses only the common message header. Its parameters are:
Status(Mandatory)ASP Identifier(Optional)Interface Identifiers(Optional)INFO String(Optional)
Here's how it looks 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 = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x1 or 0x8 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's the text-formatted Interface Identifiers 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 = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifiers /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional Interface Identifier Parameters /
\ of Tag Type 0x3 \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Status Type is a 16-bit unsigned integer 🎀 It says what kind of Notify this is. The valid values are:
1 Application Server State Change (AS-State_Change)
2 OtherStatus Information is also a 16-bit unsigned integer ✨ It gives more detail, and what it means depends on the Status Type. When the Status Type is AS-State_Change, these are the Status Information values:
1 reserved
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 AS's new state.
When the Status Type is Other, these Status Information values are defined 🌸
Value Description
1 Insufficient ASP resources active in AS
2 Alternate ASP Active
3 ASP FailureThese notifications aren't about the SG reporting a state change of an ASP or AS 🙈 For Insufficient ASP Resources, the SG is telling the ASP-INACTIVE ASP(s) in the AS that another ASP is needed to handle the AS's load (Load-sharing mode). For Alternate ASP Active, an ASP gets told when an alternate ASP moves to the ASP-ACTIVE state in Over-ride mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For ASP Failure, the SG is telling the ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP MUST be placed in the message.
The format and description of the optional ASP Identifier are the same as for the ASP Up message (see Section 3.3.2.1). The optional Interface Identifiers and INFO String parameters work the same way they do in the ASP Active message (see Section 3.3.2.5). 🫶
3.3.3.3. TEI Status Messages (Request, Confirm, and Indication) 🧚
The TEI Status messages get exchanged between IUA layer peers to request, confirm, and indicate the status of a particular TEI. 🦋
They carry the common message header, followed by the IUA message header. The TEI Status Request message doesn't have any extra parameters.
Okay, background bit: in the integrated ISDN Layer 2/3 model (like traditional ISDN switches), the Layer Management for Q.921 and Q.931 is assumed to be co-located 🏠 When you're backhauling ISDN, that assumption doesn't necessarily hold. TEI Status messages let the two Layer Management entities talk about a TEI's status. Knowing a TEI is in service also lets the ASP ask the SG to set up the datalink to the terminal (via the IUA Establish message) if the ASP wants to be in charge of data link establishment 💅 The ASP's Layer Management can also get ready to send and receive signaling to and from a given TEI, and confirm or verify that a datalink to that TEI is set up. For example, say a datalink is 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 ask the SG to set up a datalink to it. Iykyk 😌
The TEI Status Indication and Confirm messages have 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 = 0x0010 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.9213.3.3.4. TEI Query Message (Request) 🔍
The TEI Query message is what the ASP sends to query the TEI(s) 💌 It's made of the common header and the IUA header. The DLCI in the IUA header MUST be ignored by the SG. The SG responds to this message with TEI Status Indication(s).
4. Procedures ✨
The IUA layer has to respond to the various primitives it gets from other layers, plus the messages it gets from the peer IUA layer 🦋 This section covers those procedures and what to do in response to these events.
4.1. Procedures to Support Service in Section 1.4.1 💖
These procedures achieve the IUA layer's "Transport of Q.921/Q.931 boundary primitives" service 🎀
4.1.1. Q.921 or Q.931 Primitives Procedures 🌈
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 it's 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 corresponds to 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) to the local Q.921 or Q.931 layer 👑
4.2. Procedures to Support Service in Section 1.4.2 🌸
These procedures achieve the IUA layer's "Support for Communication between Layer Managements" service 🫶
4.2.1. Layer Management Primitives Procedures
okay so when the local Layer Management sends these primitives, IUA has to hand back the matching response primitive across the internal local Layer Management interface. no skipping that step 💅
an M-SCTP ESTABLISH request from Layer Management kicks off setting up an SCTP association 🦋 once that setup is finished, Layer Management gets an M-SCTP ESTABLISH confirm. when a peer IUA node sets up an incoming association and it works, Layer Management gets an M-SCTP ESTABLISH indication ✨
an M-SCTP RELEASE request from Layer Management starts tearing down an SCTP association 🫶 when the teardown is done, Layer Management gets an M-SCTP RELEASE confirm. if a peer IUA is the one that tore it down successfully, Layer Management gets an M-SCTP RELEASE indication instead 🌸
M-SCTP STATUS request and M-SCTP STATUS indication are how Layer Management asks about the local status of one particular SCTP association 🔍
M-NOTIFY indication and M-ERROR indication tell Layer Management what notification or error info came in with a received IUA Notify or Error message. these can also get generated from local IUA events, so they aren't only for incoming stuff 🎀
M-ASP STATUS request/indication and M-AS-STATUS request/indication let Layer Management check the local status of a specific ASP or AS. no IUA peer protocol gets involved for these, it's all local, no cap 🧚
M-ASP-UP request, M-ASP-DOWN request, M-ASP-INACTIVE request, and M-ASP-ACTIVE request let Layer Management at an ASP start state changes. these requests lead to outgoing IUA ASP UP, ASP DOWN, ASP INACTIVE, and ASP ACTIVE messages, so the peer hears about it 📣
M-ASP-UP confirmation, M-ASP-DOWN confirmation, M-ASP-INACTIVE confirmation, and M-ASP-ACTIVE confirmation just tell Layer Management that the previous request got confirmed ✅
when IUA gets an M-TEI Status primitive from Layer Management, it sends the matching MGMT message (TEI Status) to its peer 💖 while it's doing that, the IUA layer has to fill in the various fields of the common and specific headers correctly. main character energy, no shortcuts 👑
all MGMT messages go out on a sequenced stream so they arrive in order 🧚♀️ SCTP stream '0' SHOULD be used for this 🌈
4.2.2. Receipt of IUA Peer Management Messages
okay so when IUA gets IUA Management messages, the IUA layer MUST invoke the matching Layer Management primitive indications and pass them up to local layer management 🫶 for example, M-AS Status ind., M-ASP Status ind., M-ERROR ind., and M-TEI STATUS 💅
M-NOTIFY indication and M-ERROR indication tell Layer Management what notification or error info was inside a received IUA Notify or Error message 🎀 these can also be generated from local IUA events, which is lowkey a fun detail 🌸
all MGMT messages go out on a sequenced stream to keep the ordering 🦋 SCTP stream '0' SHOULD be used here too 💜
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 🌟 this part is giving teamwork between the SG and the MGC 🫶
4.3.1. AS and ASP State Maintenance
the IUA layer on the SG has to keep track of the state of every ASP, plus the state of the AS itself 🧠 it's a whole juggling act, bestie 🤹♀️
4.3.1.1. ASP States
okay this is where it gets good 💅 the IUA layer on the SG keeps track of the state of each ASP in each AS it's configured for 🧚 an ASP's state changes because of these kinds of events:
- Reception of messages from peer IUA layer at that ASP
- Reception of some messages from the peer IUA layer at other ASPs in the AS
- Reception of indications from SCTP layer
- Local Management intervention
the ASP state transition diagram is Figure 6 👀 the possible states of an ASP are these:
ASP-DOWN: 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 🔥
+--------------+
+----------------------| |
| Alternate +-------| ASP-ACTIVE |
| ASP | +--------------+
| Takeover | ^ |
| | ASP | | ASP Inactive /
| | Active | | ASP Up
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI /
SCTP RI | | v SCTP RI
| +--------------+
+--------------------->| |
| ASP-DOWN |
+--------------+
Figure 6. ASP State Transition DiagramSCTP CDI: this is the local SCTP layer's Communication Down Indication to the Upper Layer Protocol (IUA) on an SG 📡 the local SCTP sends it when it notices it lost connectivity to the ASP's peer SCTP layer 💔 SCTP CDI counts as either a SHUTDOWN COMPLETE notification or a COMMUNICATION LOST notification from SCTP 🫠
SCTP RI: this is the local SCTP layer's Restart indication to the upper layer protocol (IUA) on an SG 🔄 the local SCTP sends it when it detects that the ASP's peer SCTP layer restarted 🌈
4.3.1.2. AS States
the state of the AS is kept in the IUA layer on the SG 👑
an AS's state changes because of events 🎢 those include:
- ASP state transitions
- Recovery timer triggers
the possible states of an AS are these:
AS-DOWN: the Application Server is unavailable 💀 this state means all related ASPs are in the ASP-DOWN state for this AS 🌫️ the 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 means at least one ASP is in the ASP-ACTIVE state 💖
AS-PENDING: an active ASP went from active to inactive or down, and it was the last remaining active ASP in the AS 😬 a recovery timer T(r) starts, and the SG queues all incoming SCN messages 📥 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 any ASP becomes active, the SG stops queuing and throws away all the messages it queued 🗑️ the AS moves to AS-INACTIVE if at least one ASP is in ASP-INACTIVE state, otherwise it moves to AS-DOWN 🫶
+----------+ one ASP trans to ASP-ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state
Tr = Recovery Timer
Figure 7: AS State Transition Diagram4.3.2. ASPM Procedures for Primitives
before an SCTP association gets set up, the ASP state at both the SG and the ASP is assumed to be ASP-DOWN 🫧
the ASP is the one responsible for starting the SCTP association setup to an SG 🚀 so when the IUA layer at an ASP gets an M-SCTP ESTABLISH request primitive from Layer Management, it tries to set up an SCTP association with the remote IUA peer at an SG 🤞 when the SCTP sends back an SCTP-Communication Up confirm primitive, the IUA layer invokes the M-SCTP ESTABLISH confirm primitive to Layer Management 🎀
at the SG, the IUA layer receives an SCTP Communication Up indication primitive from SCTP 📨 the IUA layer then invokes the M-SCTP ESTABLISH indication primitive to Layer Management 💫
once the SCTP association is up and the local IUA-User is ready, the local ASP IUA Application Server Process Maintenance (ASPM) function starts the ASPM procedures 🔁 it uses the ASP Up/-Down/-Active/-Inactive messages to tell the SG what state the ASP is in (see Section 4.3.3) 💌
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 tells the local Layer Management with an M-SCTP_RELEASE confirm primitive 🌙
if the IUA layer gets an SCTP-COMMUNICATION_DOWN indication from the underlying SCTP layer, it informs Layer Management by invoking the M-SCTP RELEASE indication primitive 🫠 the state of the ASP 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 🔄
in the case of an SCTP-RESTART indication at an ASP, the ASP is now considered by its IUA peer to be in the ASP-DOWN state 📉 if the ASP wants to recover, it must begin any recovery with the ASP Up procedure 💪
4.3.3. ASPM Procedures for Peer-to-Peer Messages
all ASPM messages go out on a sequenced stream so they stay in order 🧵 SCTP stream '0' SHOULD be used for these too 🌸
4.3.3.1. ASP Up Procedures ✨
Okay so once an ASP has successfully set up an SCTP association to an SG, the SG just waits 🥺 for the ASP to send an ASP Up message, which basically says "hiii, I'm available as an IUA peer" 💖. The ASP is always the one who starts the ASP Up message. This action MAY be triggered at the ASP by an M-ASP_UP request primitive from Layer Management, or it MAY be kicked off automatically by an IUA management function 🦋.
When an ASP Up lands at an SG, and the remote ASP is internally sitting in ASP-DOWN and isn't locked out for local management reasons, the SG flips it to ASP-INACTIVE and tells Layer Management with an M-ASP_Up indication primitive 🌸. If the SG knows from current configuration data which Application Servers that ASP is set up to operate in, it updates the ASP state to ASP-INACTIVE in each AS it's a member of.
Alternatively, the SG may move the ASP into a pool of Inactive ASPs 🧚 that are available for future configuration within Application Server(s), which gets decided in a later ASP Active procedure. If the ASP Up message contains an ASP Identifier, the SG should save that ASP Identifier for that ASP. The SG MUST send an ASP Up Ack message in response to a received ASP Up message, even if the ASP is already marked as ASP-INACTIVE at the SG. No exceptions, bestie 💅.
If the SG can't respond with an ASP Up Ack message for any local reason (like a management lockout) 🙈, it responds to the ASP Up message with an Error message whose reason is "Refused - Management Blocking".
At the ASP, the ASP Up Ack message that comes back isn't acknowledged. Layer Management just gets informed with an M-ASP_UP confirm primitive ✨.
When the ASP sends an ASP Up message, it starts timer T(ack) ⏰. If the ASP doesn't get a response to that ASP Up message within T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until it gets an ASP Up Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In that method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication 😭.
The ASP must wait for the ASP Up Ack message before sending any other IUA messages (e.g., ASP Active) 🫶. If the SG receives any other IUA messages before an ASP Up message is received (other than ASP Down; see Section 4.3.3.2), the SG MAY discard them 🗑️.
If an ASP Up message is received and internally the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message gets returned, along with an Error message ("Unexpected Message") 💀. The remote ASP state is then changed to ASP-INACTIVE in all relevant Application Servers.
If an ASP Up message is received and internally the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned and that's it, no further action is taken 🌈.
4.3.3.2. ASP Down Procedures 🍓
The ASP will send an ASP Down message to an SG when it wants to be removed from the list of ASPs in every Application Server it's a member of, and when it no longer wants to receive any IUA QPTM or ASPTM messages 🙅♀️. This action MAY be initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management, or MAY be initiated automatically by an IUA management function.
Whether the ASP is permanently removed from an AS is a function of configuration management, so that's a different vibe 🎀.
The SG marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the ASP 💜.
The SG MUST send an ASP Down Ack message in response to a received ASP Down message from the ASP, even if the ASP is already marked as ASP-DOWN at the SG. Iconic behaviour, honestly 👑.
At the ASP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with an M-ASP_DOWN confirm primitive. If the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP should now consider itself to be in the ASP-DOWN state. If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the ASP should then start procedures to return itself to that previous state 🦋.
When the ASP sends an ASP Down message, it starts timer T(ack) ⏰. If the ASP doesn't receive a response to an ASP Down message within T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In that method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a negative indication 🥀.
4.3.3.3. IUA Version Control 🔀
If an ASP Up message with an unsupported version is received, the receiving end responds with an Error message 🚨. That message tells the sender which version the receiving node supports, and the receiving end also notifies Layer Management.
This is super useful when protocol version upgrades are happening across a network 🌍. A node that got upgraded to a newer version SHOULD support the older versions used by the other nodes it's talking to, so nobody gets left on read 🫠. Because ASPs are the ones who start the ASP Up procedure, it's assumed that the Error message would normally come from the SG 💖.
4.3.3.4. ASP Active Procedures 🚀
Any time after the ASP has received an ASP Up Ack from the SG, the ASP sends an ASP Active message to the SG to say it's ready to start processing traffic 🙌. This action MAY be initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer Management, or it MAY be kicked off automatically by an IUA management function. If an ASP is configured or registered to process traffic for more than one Application Server across a single SCTP association, the ASPAC contains one or more Interface Identifiers so everyone knows which Application Servers the ASPAC applies to 🧩.
If the Application Server can be successfully activated, the SG responds to the ASP with an ASPAC Ack message. That message says "got your ASPAC!" ✅, and then the SG starts sending traffic for the Application Server to that ASP 🎉.
If an "out-of-the-blue" ASP Active message shows up (meaning the ASP hasn't registered with the SG, or the SG has no static configuration data for that ASP) 😶, the message MAY be silently discarded 🤫.
The SG MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the ASP-ACTIVE state at the SG. Non-negotiable, babe 💅.
At the ASP, the ASP Active Ack message that comes back isn't acknowledged. Layer Management is informed with an M-ASP_ACTIVE confirm primitive. The ASP might receive Data message(s) before the ASP Active Ack message shows up, because the ASP Active Ack and the Data messages from an SG may be sent on different SCTP streams 🌊. Message loss is possible here, since the ASP doesn't consider itself to be in the ASP-ACTIVE state until it receives the ASP Active Ack message 😬.
When the ASP sends an ASP Active message, it starts timer T(ack) ⏰. If the ASP doesn't receive a response to an ASP Active message within T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until it receives an ASP Active Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Active messages MAY be put under control of Layer Management. In that method, expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying a negative indication 😭.
The ASP MUST wait for the ASP Active Ack message from the SG before sending any Data messages, or it will risk message loss 🚫. If the SG receives QPTM messages before an ASP Active is received, the SG SHOULD discard these messages 🗑️.
There are two modes of Application Server traffic handling in the SG IUA: Over-ride and Load-sharing 👯. The Type parameter in the ASPAC message tells you which mode is used for a particular Application Server. If the SG decides the mode indicated in an ASPAC is incompatible with the traffic handling mode currently used in the AS, the SG responds with an Error message indicating Unsupported Traffic Handling Mode 🙅♀️.
In the Over-ride mode, reception of an ASPAC message at an SG redirects all traffic for the AS to the ASP that sent the ASPAC 👑. The SG responds to the ASPAC with an ASP Active Ack message to that ASP. Any previously active ASP in the AS is now considered Inactive and won't receive traffic from the SG within the AS anymore. The SG sends a Notify (Alternate ASP Active) to the previously active ASP in the AS, after it stops all traffic to that ASP 📨.
In the load-share mode, reception of an ASPAC message at an SG directs traffic to the ASP sending the ASPAC, in addition to all the other ASPs that are currently active in the AS 🌸. How the SG load-shares traffic across all the active ASPs in an AS is implementation dependent. The algorithm could, for example, be round-robin, or it could be based on information in the Data message, such as the Interface Identifier 🧠. It depends on the requirements of the application and on the call state handling assumptions of the collection of ASPs in the AS. The SG responds to the ASPAC with an ASP Active Ack message to the ASP 💫.
4.3.3.5. ASP Inactive Procedures 🦋
Okay so when an ASP wants to bounce from receiving traffic within an AS, it sends an ASP Inactive message to the SG 💅. This action MAY be started at the ASP by an M-ASP_INACTIVE request primitive from Layer Management, or it MAY be triggered automatically by an IUA management function ✨. If an 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 so it's clear which Application Servers the ASP Inactive message applies to 🎀.
There are two modes of Application Server traffic handling in the SG IUA when an ASP withdraws from service: Over-ride and Load-sharing 👑. In an Over-ride mode AS, another ASP has usually already taken over the traffic with an Over-ride ASPAC message, so the SG already treats the ASP sending the ASPIA as ASP-INACTIVE. The ASP then gets an ASPIA Ack message, but only after the SG makes sure all traffic has stopped going to it 🫶.
In a Load-share mode AS, the SG moves the ASP to the ASP-INACTIVE state and the AS traffic gets re-allocated across the remaining ASP-ACTIVE ASPs using whatever load-sharing algorithm is currently used within the AS 🍓. The ASPIA Ack message goes to the ASP after all traffic is halted to it. A Notify (Insufficient ASPs) message MAY be sent to all inactive ASPs, if required 🔥.
When the ASP sends an ASP Inactive message, it starts timer T(ack) ⭐. If the ASP doesn't get a response to an ASP Inactive message within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it receives an ASP Inactive Ack message 😭. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In that method, expiry of T(ack) results in an M-ASP_Inactive confirm primitive carrying a negative indication 🧚.
If no other ASPs in the Application Server are in the state ASP-ACTIVE, the SG MUST send a Notify ("AS-Pending") message to all of the ASPs in the AS that are in the state ASP-INACTIVE 🌈. The SG SHOULD start buffering the incoming messages for T(r) seconds, after which messages MAY be discarded 💜. T(r) is configurable by the network operator. If the SG gets an ASP Active message from an ASP in the AS before T(r) expires, the buffered traffic goes to that ASP and the timer gets cancelled. If T(r) expires, the AS moves to the AS-INACTIVE state 💀.
At the ASP, the ASP Inactive Ack message that comes in is not acknowledged. Layer Management gets informed with an M-ASP_INACTIVE confirm primitive 🙈. If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive message, the ASP should now consider itself to be in the ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE state, it should then initiate procedures to return itself to its previous state 🎀.
4.3.3.6. Notify Procedures 🔔
A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP 🫶. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change happened because of an ASP failure or because of reception of an ASP State Management (ASPSM) / ASP Traffic Management (ASPTM) message ✨. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack) 💅.
In the case where a Notify ("AS-Pending") message is sent by an SG that now has no ASPs active to service the traffic, or an NTFY ("Insufficient ASPs") is sent in the Load-share mode, the Notify does not explicitly compel the ASP(s) receiving the message to become active. The ASPs stay in control of what (and when) action is taken 👑.
4.3.3.7. Heartbeat 💓
The optional Heartbeat procedures MAY be used when operating over transport layers that do not have their own heartbeat mechanism for detecting loss of the transport association (i.e., other than the SCTP) 🍓.
Either IUA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer T(beat). Upon receiving a Heartbeat message, the IUA peer MUST respond with a Heartbeat Ack message 🌸.
If no Heartbeat Ack message (or any other IUA message) is received from the IUA peer within 2*T(beat), the remote IUA peer is considered unavailable. Transmission of Heartbeat messages is stopped, and the signaling process SHOULD attempt to re-establish communication if it is configured as the client for the disconnected IUA peer 😭.
The BEAT message MAY optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Beat Ack message. The ASP, upon examining the contents of the returned BEAT Ack message, MAY choose to consider the remote ASP as unavailable 🙈. The contents/format of the Heartbeat Data parameter 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 6, "ASP State Transition Diagram".
5. Examples 🎀
5.1. Establishment of Association and Traffic between SGs and ASPs 🦋
5.1.1. Single ASP in an Application Server (1+0 sparing) 💖
This scenario shows the example IUA message flows for the establishment of traffic between an SG and an ASP, where only one ASP is configured within an AS (no backup). It is assumed that the SCTP association is already set up 💅.
SG ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|-----NTFY(AS-INACTIVE)--->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|
| |5.1.2. Two ASPs in Application Server (1+1 sparing) 🌈
This scenario shows the example IUA message flows for the establishment of traffic between an SG and two ASPs in the same Application Server, where ASP1 is configured to be Active and ASP2 a standby in the event of communication failure or the withdrawal from service of ASP1. ASP2 MAY act as a hot, warm, or cold standby depending on the extent to which ASP1 and ASP2 share call state or can communicate call state under failure/withdrawal events 🫶. The example message flow is the same whether the ASP Active messages are Over-ride or Load-share mode, although typically this example would use an Over-ride mode ✨.
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|5.1.3. Two ASPs in an Application Server (1+1 sparing, load-sharing case) 🍓
This scenario shows a similar case to Section 5.1.2, but where the two ASPs are brought to active and load-share the traffic load. In this case, one ASP is sufficient to handle the total traffic load 🔥.
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP Up Ack------>| |
| | |
|----NTFY(AS-INACTIVE)--->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----ASP Active Ack------>| |
| | |
|-----NTFY(AS-ACTIVE)---->| |
|----------------------NTFY(AS-ACTIVE)-------------->|
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |5.1.4. Three ASPs in an Application Server (n+k sparing, load-sharing case) 👑
This scenario shows the example IUA message flows for the establishment of traffic between an SG and three ASPs in the same Application Server, where two of the ASPs are brought to active and share the load. In this case, a minimum of two ASPs are required to handle the total traffic load (2+1 sparing) 💜.
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|-NTFY(AS-INACTIVE)->| | |
| | | |
|<--------------------------ASP Up-------| |
|-----------------------ASP Up Ack------>| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
|--NTFY(AS-ACTIVE)-->| | |
|---------------NTFY(AS-ACTIVE)--------->| |
|------------------------NTFY(AS-ACTIVE)-------------------->|5.1.5. Interface Identifier Configuration Mismatch Example 💅
okay so this one is about when the Interface Identifiers get misconfigured on the ASP side 😭 the SG has Interface Identifiers 1-5 set up for ASP1, but ASP1 is out here trying to go with 1-10. the SG only accepts the 1-5 ones and bounces the rest with Errors 🙈
SG ASP1
| |
| |
|<----ASP Active (IIDs 1-10)-----|
|---ASP Active Ack (IIDs 1-5)--->|
|-------Error (IIDs 6)---------->|
|-------Error (IIDs 7)---------->|
|-------Error (IIDs 8)---------->|
|-------Error (IIDs 9)---------->|
|-------Error (IIDs 10)--------->|
| |5.2. ASP Traffic Fail-over Examples 🦋
5.2. ASP Traffic Fail-over Examples 🦋
Now we're into the fail-over stuff, which is giving drama and I'm here for it ✨
5.2.1. (1+1 Sparing, withdrawal of ASP, Backup Over-ride) 🎀
okay so this one shows what happens when an ASP withdraws from service. ASP1 bounces, and the SG tells ASP2 that the AS has gone Down 😭
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
| | |
|----NTFY(AS-Pending)---->| |
|-------------------NTFY(AS-Pending)---------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| | |
|----NTFY(AS-ACTIVE)----->| |
|-------------------NTFY(AS-ACTIVE)----------------->|so the SG notifies ASP2 that the AS moved to the Down state 💅 the SG could also (optionally) send a Notify when the AS hits Pending too, which is a cute extra if you want it 🌸
ngl the note here is important. If the SG detects loss of the IUA peer (IUA heartbeat loss or detection of SCTP failure), the first SG-ASP1 ASP Inactive message exchange just doesn't happen 💀
5.2.2. (1+1 Sparing, Backup Over-ride) 👑
this one is ASP2 being a main character and wanting to override ASP1 and take over the traffic 😤
SG ASP1 ASP2
| | |
|<-------------------------------ASP Active----------|
|-----------------------------ASP Active Ack-------->|
|----NTFY( Alt ASP-Act)-->|
| | |the SG lets ASP1 know 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 withdraws from service and the group keeps vibing 🌈
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact------| | |
|---ASP Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |in this case the SG has to know the minimum ASP resources it needs (that part is implementation dependent) 🔥 like, if the SG knows n+k = 2+1 for a load-share AS and n is currently 1, that's the vibe.
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 doesn't happen. Same energy as before, bestie 💖
5.3. Q.921/Q.931 Primitives Backhaul Examples 🍓
okay so this is how the Q.921/Q.931 primitives get backhauled, and it's honestly so organized 😭
When the IUA layer on the ASP has a QPTM message to send to the SG, it does this:
- 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
When the IUA layer on the SG has a QPTM message to send to 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 it again 🎀 an active association between MGC and SG gets set up first (Section 5.1), so that's the prereq 💅
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 failed attempt to establish a data link on the signaling channel 💀 here the gateway has a problem with its physical connection (e.g., Red Alarm), so it can't establish a data link at all.
SG ASP
<----------- Establish Request (ESTABLISH_START)
Release Indication ---------->
(RELEASE_PHYS)5.4. Layer Management Communication Examples 🌸
last one in this section, and it's about Layer Management modules talking between SG and ASP 🧚 an active association between ASP and SG is set up first (Section 5.1), same as before.
SG ASP
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)6. Security 🔐
The security considerations discussed in "Security Considerations for SIGTRAN Protocols", RFC 3788 [3], apply to this document. Read RFC 3788 before you touch anything, bestie, it matters 😭
7. IANA Considerations 🌈
7.1. SCTP Payload Protocol Identifier ✨
IANA has assigned an IUA value for the Payload Protocol Identifier in the SCTP Payload Data chunk. The following SCTP Payload Protocol Identifier has been registered:
IUA "1"The SCTP Payload Protocol Identifier is included in each SCTP Data chunk to indicate which protocol SCTP is carrying. SCTP doesn't use this Payload Protocol Identifier directly, but certain network entities MAY use it to identify the type of information being carried in a Data chunk 👀
The User Adaptation peer MAY use the Payload Protocol Identifier as a way of figuring 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.
new message classes, types, and parameters are an integral part of SIGTRAN adaptation layers, so IANA assigns these extensions through an IETF Consensus action as defined in [7] 🫶
the proposed extension must in no way adversely affect the general working of the protocol. no exceptions, periodt 💅
7.2.1. IETF-Defined Message Classes 🎀
the documentation for a new message class MUST include the following information:
- (a) A long and short name for the message class.
- (b) A detailed description of the purpose of the message class.
7.2.2. IETF-Defined Message Types 🌸
documentation of the message type MUST contain the following information:
- (a) A long and short name for the new message type.
- (b) A detailed description of the structure of the message.
- (c) A detailed definition and description of intended use of each field within the message.
- (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 gets a message type it doesn't support, it MUST respond with an Error (ERR) message with an Error Code of Unsupported Message Type 😤
7.2.3. IETF-Defined TLV Parameter Extension ✨
documentation of the message parameter MUST contain the following information:
- (a) Name of the parameter type.
- (b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.1.5.
- (c) Detailed definition of each component of the parameter value.
- (d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same message type.
8. Timer Values ⏰
the following are suggestions for default timer values 💅
T(r) 3-5 seconds
T(ack) 2-5 seconds
T(beat) Heartbeat Timer 30 seconds9. Acknowledgements 🫶
the authors would like to thank Alex Audu, Maria Sonia Vazquez Arevalillo, Ming-te Chao, Keith Drage, Norm Glaude, Nikhil Jain, Bernard Kuc, Ming Lin, Stephen Lorusso, John Loughney, Barry Nagelberg, Neil Olson, Lyndon Ong, Heinz Prantner, Jose Luis Jimenez Ramirez, Ian Rytina, Michael Tuexen, and Hank Wang for their valuable comments and suggestions 💖✨
10. References 📚
10.1. Normative References 🎀
- [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General Aspects'
- [2] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
- [3] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, June 2004.
10.2. Informative References ✨
okay so these are the "for your reading pleasure" refs bestie 📚🫶 nothing here is required to implement the thing, but they're the receipts behind it:
[4] 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.
[5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework
Architecture for Signaling Transport", RFC 2719, October 1999.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.11. Change Log 🦋
okay so this section is the glow-up diary 📖💅 it lists the major changes between this doc and RFC 3057, which is the older version it's replacing:
- The TEI Query message was added. 🧚
- An explanation of the DLCI format (shown in Figure 6) is provided. 💖
- The ASP and AS procedures in Section 4 were aligned with RFC3331 and RFC3332. 🎀
- The format of the ASPSM and ASPTM messages was aligned with RFC3331 and RFC3332. These changes include removing the Reason field from the ASP Down and ASP Down Ack messages and the Traffic Mode Type field from the ASP Inactive and ASP Inactive Ack messages. 💀
- Sections 1.3.3 and 1.3.4 were moved to Appendix A. A new section was added in place of Section 1.3.3. 🌸
- The references have been split between Normative and Informative. 📚
- The new Sigtran security document is referenced and Section 6 has been updated appropriately. 🔥
Appendix A ✨
A.1. Signaling Network Architecture 🌈
so a Signaling Gateway is used to carry Q.921-User signaling traffic out to one or more distributed ASPs (think MGCs) 📡 and clearly, IUA on its own is NOT built to hit the performance and reliability bar for that job 😭 BUT the combo of a distributed setup plus redundant networks does get you a reliable enough path for signaling over IP 🫶 the IUA protocol is flexible enough to run and manage in a bunch of different physical setups, so Network Operators can hit their own performance and reliability goals 💅
to meet the ISDN signaling reliability and performance requirements for carrier grade networks, Network Operators SHOULD ensure that there is no single point of failure provisioned in the end-to-end network architecture between an ISDN node and an IP ASP. ⭐
depending on how reliable the SG and ASP elements are (no pressure lol 🙈), this is usually achieved with redundant Quality of Service (QoS)-bounded IP network paths for SCTP Associations between SCTP End Points, plus redundant Hosts and redundant SGs. where the ASPs live across the available Hosts matters too 👑 for a particular 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 8 below 🧚
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Figure 8. Logical Model Examplefor carrier-grade networks, if a particular ASP fails or gets isolated, stable calls SHOULD NOT get dropped 📞🚫 which means ASPs sometimes need to share the call state or be able to pass it to each other 🥺 this sharing or communication of call state info is outside the scope of this document, so we're leaving it there 🤷♀️
A.2. Application Server Process Redundancy 💖
to avoid a single point of failure, it is recommended that a minimum of two ASPs be in the list, living in separate hosts and therefore reachable over different SCTP Associations 🦋 like, in the network from Figure 8, all messages from a particular D Channel (Interface Identifier) could go to ASP1 in Host1 OR ASP1 in Host2. the AS list at SG1 might look something 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 ✨ and ASP1 in Host2 would normally be brought to the active state when ASP1/Host1 fails or loses connectivity 🔥 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 so:
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 🌈 so it's basically sharing the load, bestie 💅
during fail-over, it is recommended that, for ASPs supporting call processing, stable calls do not get released 📞 calls that are in transition MAY fail, though communication between the ASPs involved can be used to 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 information. the ASP-to-ASP protocol is outside the scope of this document 🙈
Authors' Addresses 🎀
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Malleswar Kalla
Telcordia Technologies
PYA 2J-341
3 Corporate Place
Piscataway, NJ 08854
USA
Phone: +1-732-699-3728
EMail: mkalla@telcordia.com
Selvam Rengasami
Tridea Works
Phone: +1-732-512-0969
EMail: selvam@trideaworks.com
Greg Sidebottom
Signatus Technologies
Kanata, Ontario, Canada
EMail: greg@signatustechnologies.comFull Copyright Statement 🌸
Copyright (C) The Internet Society (2006).
this document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 🦋
THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 💜
the IETF takes no position on whether any Intellectual Property Rights (or other rights) that might be claimed to cover the technology in this document are valid or in scope, or whether any license under those rights might be available. it also doesn't claim to have done any independent work to find such rights 🙈 info on how rights work for RFC documents is in BCP 78 and BCP 79 📚
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗
the IETF also invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🧚
funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) ✨💖
📦 where this page comes from
- ietf: rfc4233 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms