RFC 3807
V5.2-User Adaptation Layer (V5UA)
RFC 3807: V5.2-User Adaptation Layer (V5UA) 🎀
Okay bestie, this one is from June 2004 and it's a Standards Track doc 💅. The authors are E. Weilandt, N. Khanchandani, and S. Rao, all from Nortel Networks. It updates RFC 3057 (the ISDN User Adaptation Layer, aka IUA) 🦋. That's the whole vibe: V5UA is basically IUA's glow-up for V5.2 networks.
Status of This Memo ✨
So this is an Internet standards track protocol spec for the Internet community, and it's asking everyone to talk about it and suggest improvements 🫶. If you want the current standardization state, go check the latest "Internet Official Protocol Standards" (STD 1) doc. And yes, distribution is totally unlimited, so share away 🌸.
Copyright Notice ✨
Copyright (C) The Internet Society (2004) 💜
Abstract ✨
Okay so the whole point of this doc is to define a way to backhaul V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP) 🦋. You'd use it between a Signaling Gateway (SG) and a Media Gateway controller (MGC). The assumption is that the SG gets its V5.2 signaling over a standard V5.2 interface 🧚.
It also builds on the ISDN User Adaptation Layer Protocol (RFC 3057) and defines every extension to the IUA Protocol that V5UA needs to actually work 💖.
Table of Contents ✨
1. Introduction ................................................. 2
1.1. Scope .................................................. 3
1.2. Terminology ............................................ 3
1.3. V5.2 Overview .......................................... 5
1.4. Distribution of responsibilities between MGC and SG .... 7
1.5. Client/Server Model .................................... 7
1.6. Addition to boundary primitives ........................ 7
1.6.1. V5 specific boundary primitives ................ 7
2. Conventions .................................................. 9
3. SCTP Stream Management ....................................... 10
4. Proposed V5.2 Backhaul Architecture .......................... 10
4.1. V5UA Message Header .................................... 11
4.2. V5 Naming Conventions for Interface Identifier ......... 12
4.3. V5 Additions to IUA Boundary Primitives ................ 13
4.4. Link Status Messages ................................... 14
4.5. Sa-Bit Messages ........................................ 16
4.6. Error Indication Message ............................... 17
5. Procedures ................................................... 18
5.1. V5 Layer 1 failure ..................................... 18
5.2. Loss of V5UA peer ...................................... 19
5.3. C-channel overload on SG ............................... 19
6. Examples ..................................................... 20
6.1. Link Identification Procedure (successful) ............. 20
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SCTP Payload Protocol Identifier ....................... 21
8.2. V5UA Port Number ....................................... 22
9. Acknowledgements ............................................. 22
10. References ................................................... 22
10.1. Normative References ................................... 22
10.2. Informative References ................................. 23
11. Authors' Addresses ........................................... 23
12. Full Copyright Statement ..................................... 241. Introduction ✨
Okay so this section explains how V5.2 backhaul messaging gets done over IP, using a modified version of the ISDN User Adaptation Layer Protocol (IUAP) [1] 🎀. V5UA basically sits on top of IUA and adds the extensions a V5.2 setup needs 💅.
Since V5UA is meant to be an extension to IUAP, everything defined in [1] is also valid for V5UA, unless this document says otherwise 🫶.
Also, this doc does not describe the V5 standard itself 🙈. The V5 protocol is defined by the ETSI standards [2,3]. Any V5 description in here is just there to make the text easier to follow 🧚.
1.1. Scope ✨
So there's a need for Switched Circuit Network (SCN) signaling protocol delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway Controller (MGC) 🦋. It's meant to be analogous to the ISDN Q.921 User Adaptation Layer (IUA) described in [1] 💖.
This document supports analog telephone access, ISDN basic rate access, and ISDN Primary rate access over a V5.2 interface 🌈.
The V5.2 Layer 2, and especially Layer 3, is different from the Q.921 [4] and Q.931 Adaptation layer. So the IUA standard has to be extended to support V5.2 🔥.
1.2. Terminology ✨
Here's the lineup of terms you need to know, bestie 📖.
Bearer Channel Connection (BCC) protocol: a protocol that lets the Local Exchange (LE) tell the Access Network (AN) to allocate bearer channels on demand, either one at a time or in multiples 🎀.
Communication channel (C-channel): a 64 kbit/s time slot on a V5.2 interface that's been provisioned to carry communication paths 🌸.
Communication path (C-path): any one of these information types:
- The layer 2 data link carrying the Control protocol
- The layer 2 data link carrying the Link Control protocol
- The layer 2 data link carrying the PSTN signaling
- Each of the layer 2 data links carrying the protection protocol
- The layer 2 data link carrying the BCC protocol
- All the ISDN Ds-type data from one or more user ports
- All the ISDN p-type data from one or more user ports
- All the ISDN t-type data from one or more user ports
Note: this definition includes the possibility that there may be more than one C-path of the same information type, each allocated to a different logical C-channel 💜.
Envelope Function Address (EFA): a 13 bit number, ranging from 0 to 8191 (decimal) 🦋. An EFA uniquely identifies one of the five V5.2 protocols, or an ISDN agent attached to an AN. Here are the possible values:
Definition Value
---------- ------
ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176
CONTROL_PROTOCOL 8177
BCC_PROTOCOL 8178
PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191Layer 1 Functional State Machine (L1 FSM): a Functional State Machine in V5 System Management that tracks and controls the states of the physical E1 links on the interface 🧚.
Logical Communication channel (Logical C-channel): a group of one or more C-paths, all of different types, but not including the C-path for the protection protocol 🌈.
Multi-link: a collection of more than one 2048 kbit/s link that together make up a V5.2 interface 🎀.
Multi-Slot: a group of more than one 64kbit/s channel providing 8Khz and time slot sequence integrity. It's generally used together within an ISDN Primary Rate Access (ISDN-PRA) user port to supply a higher bit-rate service 🔥.
Physical Communication Channel (Physical C-channel): a 64kbit/s time slot on a V5.2 interface that's been assigned for carrying logical C-channels. A physical C-channel may not be used for carrying bearer channels 🙈.
Primary Link: a 2048 kbit/s (E1) link in a multi-link V5.2 interface. Its physical C-channel in time slot 16 carries a C-path for the protection protocol and, on V5.2 initialization, also the C-path for the control protocol, link control protocol, and the BCC protocol. Other C-paths may also be carried in time slot 16 👑.
Secondary Link: a 2048 kbit/s (E1) link in a multi-link V5.2 interface whose time slot 16 carries a C-path for the protection protocol. On V5.2 initialization, it acts as the standby C-channel for the control protocol, link control protocol, and BCC protocol, and for any other C-paths initially carried in time slot 16 of the primary link 🦋.
V5 Link: a 2048 kbits/s E1 (PCM30) link used on a V5 interface. A V5 interface may use up to 16 V5 links 💖.
1.3. V5.2 Overview ✨
Okay so V5.2 is an industry standard ETSI interface (reference ETS 300 347-1 [3]) defined between a Local Exchange (LE) and an Access Network (AN) 🎀. It provides access to these types:
- Analog telephone access
- ISDN Basic rate access
- ISDN Primary Rate access
- Other analog or digital accesses for semi-permanent connections without associated outband signaling information
The original V5 spec (V5.1 [2]) uses 2048 kbps links in a non-concentrating way. V5.2, on the other hand, can use up to 16 of those interface links and supports concentration 🌈.
---------- ---------- o--o
| | E1 | |------- /
| |--------------| | --
| LE | E1 | AN |
| |--------------| | o--o
| | | |------- /
---------- ---------- --The LE and AN are connected with up to 16 E1 (PCM30) links 🧚. Channels 16, 15 and 31 on any E1 link can be reserved for data communication between the LE and AN. Those reserved data channels are called "Communication Channels" or "C-channels" 💅.
The C-channels are the physical media that exchange data between the V5.2 protocol peer entities. They also carry the ISDN BRI D-channel messages between the terminals and the LE 🫶. A logical communication path between two peer entities for one protocol is called a "C-path" 🔥.
The signaling information in V5.2 is defined as:
- Analog signals are carried by means of the V5 PSTN protocol (L3)
- ISDN/analog ports are controlled by the V5 Control protocol (L3)
- ISDN protocol messages are mapped to LAPD frames, which are carried by means of the LAPV5-EF sublayer (L2)
- V5 protocol messages are mapped to LAPV5-DL frames, which are carried by means of the LAPV5-EF sublayer (L2)
To support more traffic and dynamic allocation of bearer channels, V5.2 has several additions ✨:
- A bearer channel connection protocol establishes and disestablishes bearer connections on demand, as determined by the signaling information, under control of the Local Exchange.
- A link control protocol is defined for multi-link management, to control link identification, link blocking, and link failure conditions.
- A protection protocol, operating on two separate V5 data links, is defined to manage protection switching of communication channels in case of link failures.
The following protocols are defined for the various protocol layers:
Layer 2:
- LAPV5-EF
- LAPV5-DL
Layer 3:
- V5-Link Control
- V5-BCC
- V5-PSTN
- V5-Control
- V5-Protection
1.4. Distribution of responsibilities between MGC and SG 🧩
okay bestie, in the V5UA backhaul setup the V5 protocol entities SHALL be split between the SG and the MGC, and this diagram shows exactly how that works 💅
MGC SG
+------------+ +-------+-------+
| Lnk Cntrl | | | |
+------------+ | | |
| Cntrl | | | |
+------------+ V5UA | | | V5 +------+
| BCC | <--------> | LAPV5 | LAPV5 | <----> | AN |
+------------+ | -DL | -EF | +------+
| PSTN | | | |
+------------+ | | |
| Protection | | | |
+------------+ +-------+-------+So V5 System Management SHALL be located on the MGC 🏠, and the V5 L1 Functional State Machine (FSM) SHALL be located on the SG 📡. Dynamic TEI Management for V5 BRI over V5UA SHALL also be located on the MGC. It's giving organized 🎀
1.5. Client/Server Model 🤝
The Client/Server Model for V5UA shall follow the model as defined for IUAP. Same energy as IUAP, no notes 🦋
The SCTP [6] (and UDP/TCP) registered User Port Number Assignment for V5UA is 5675. Remember that number, it's iconic 🔢✨
1.6. Addition to boundary primitives 🌈
1.6.1. V5 specific boundary primitives
Extending IUAP to V5UA so it can support V5.2 backhaul means we need brand new boundary primitives for the Q.921/Q.931 boundary, following the definitions in the V5 standards 🌸
V5UA borrows a couple of IUA primitives from that same boundary: the DL-DATA primitive and the DL-UNIT DATA primitive. DL-DATA carries both V5 Layer 3 messages and V5 ISDN Layer 3 messages. DL-UNIT DATA is only for V5 ISDN messages, and it's used and defined the way IUAP describes 📦
Next, in the V5 standards, V5 system management is the one in charge of establishing and releasing data links 👑. So for V5UA, the DL-Establish and DL-Release primitives from IUAP get swapped out for new primitives between system management and the data link layer, following the definitions in [2]:
MDL-ESTABLISH
The MDL-Establish primitives are used to request, indicate and confirm the outcome of the procedures for establishing multiple frame operation. Super clear 🙌
MDL-RELEASE
The MDL-Release primitive is used to indicate the outcome of the procedures for terminating multiple frame operation 🧹
Here's the plot twist 😭: unlike ISDN, the V5 standards say V5.2 system management has to talk directly to V5.2 layer 1. But in a V5 backhaul scenario, V5.2 Layer 1 (including the L1 FSM) and parts of V5 system management are physically apart from each other 🙈. That means V5UA has to support some services so these two can chat. Specifically, those services are an indication of the status of a specific link, plus messages that support the link identification procedure defined by the V5 standards. It's a whole relationship, honestly 💜
The new primitives are defined as shown below:
MPH-LINK STATUS START REPORTING
The MPH-LINK STATUS START REPORTING primitive is used by V5 system management to request that a link be brought into service for use in a V5 interface. When this message is received, the L1 FSM on the SG SHALL start reporting the status of the V5 link to the MGC. It's used similarly to the MPH-proceed primitive defined by V5.2, but it means a bit more than MPH-proceed 🚀
MPH-LINK STATUS STOP REPORTING
The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system management to request that a link be taken out of service on a V5 interface. When this message is received, the L1 FSM on the SG SHALL stop reporting the status of the V5 link to the GWC. It's used similarly to the MPH-stop primitive defined by V5.2, but again with a more extended meaning than MPH-stop 🛑
MPH-LINK STATUS INDICATION
The MPH-LINK STATUS INDICATION primitive is used by the L1 FSM on the Signaling Gateway to report the status (operational/non-operational) of a V5 link to V5 system management. This primitive is equivalent to the MPH-AI and MPH-DI primitives in V5.2 🚦
MPH-SA-BIT SET
The MPH-SA-BIT SET primitive is used by system management to request that the L1 FSM in the SG sets or resets the value of a specified Sa bit on the requested link. The SG uses it to report back to system management that this bit was successfully set or reset. For V5, this message is used for the V5 specific Link Identification procedure to set or reset the value of the Sa7 bit, or to confirm the successful setting of the Sa bit. The MPH-SA BIT SET REQUEST is equivalent to the MPH-ID and MPH-NOR primitives in V5.2 🔁
MPH-SA-BIT STATUS
The MPH-SA-BIT STATUS primitives are used by system management in the MGC to request that the L1 FSM in the SG reports the status of a specified Sa bit on the requested link. The SG uses them to report (indicate) the status of this bit back to system management. For V5, these messages are used for the V5 specific Link Identification procedure to request or report the status of the Sa7 bit. This is equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2 🔍
Because V5 System Management and V5 Layer1/Layer2 are separated in the V5UA backhaul architecture, it may be necessary to report error conditions of the SG's V5 stack to V5 System Management. For that purpose, a brand new primitive is defined 🚨
MDL-ERROR INDICATION
The MDL-ERROR INDICATION primitive is used to indicate an error condition to V5 System Management. The only valid reason for this primitive is 'Overload', which indicates an overload condition of the C-channel on the SG. This reason is not defined in the V5/Q.921 standards, so it's a V5UA original 😤💀
2. Conventions 📖
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [7]. These are the official key words, so read them carefully, bestie 🫶
3. SCTP Stream Management 🌊
A single SCTP stream SHOULD be used for grouping all of the following protocols together: BCC, Link Control, Control and PSTN protocol on a specific C-channel. A separate SCTP stream SHOULD be used for the Protection protocol on a specific C-channel. One SCTP stream SHOULD be used for all ISDN user ports on a specific C-channel. One single stream SHOULD NOT be used to carry data of more than one C-channel 🚫
In addition, one separate SCTP stream SHOULD be used for all MPH (link related) messages. Stream organization is everything 🧚
4. Proposed V5.2 Backhaul Architecture 🏗️
****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+
|V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+
| | | |V5UA| |V5UA |
| | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+Figure 1: V5.2 Backhaul Architecture
AN - Access Network NIF - Nodal Interworking Function SCTP - Stream Control Transmission Protocol
4.1. V5UA Message Header 🎀
The original IUA message header must be modified for V5UA. Here's the original header for the integer formatted Interface Identifier, the before pic 📸
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 2: Original IUA Message Header
V5UA glows up the IUA Message Header by putting the Envelope Function Address (EFA) into the Spare field ✨. Here's the V5UA format for the integer formatted Interface Identifier, the after pic 🦋
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 (0x81) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | EFA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: V5UA Message Header (Integer-based Interface identifier)
The EFA is defined by the V5 standard. It identifies a C-path, which is a 13-bit number ranging from 0 to 8191 (decimal). An EFA uniquely identifies one of the five V5.2 protocols, or an ISDN agent attached to an AN. Here's the list of possible EFA values as defined by V5 📋
Definition Value
---------- ------
ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176
CONTROL_PROTOCOL 8177
BCC_PROTOCOL 8178
PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA SHALL be set to ZERO and SHALL be ignored by the receiver. For all other messages, the DLCI SHALL be set as defined in the V5.2 standard [2]. Don't skip this part, it's giving rules 🙅♀️
The Interface Identifier SHALL follow the naming conventions for the Interface Identifier as defined below 🏷️
4.2. V5 Naming Conventions for Interface Identifier ✨
okay so V5 is strict about this one 💅 V5 System Management has to keep track of the state of every link on a V5 interface. For things like protection switching and bearer channel allocation on those links, system management needs the full picture of which signaling and bearer channels live on each link 🔍
IUA identifies C-channels by endpoints that aren't tied to any specific link 🙃 There's no naming convention, so there's no guarantee that a C-channel is actually on the link it says it's on. And V5 requires the MGC to receive status reports for all links 📊. It also defines a link identification procedure so that AN and LE are talking about the same link when they address it with a Link Control Protocol message 🫶
Without a clear link-to-channel association, V5.2 just wouldn't make sense 💀 So to fix this, a naming convention MUST be used for V5UA 🔥
The integer formatted Interface Identifier 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier | Chnl ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Link Identifier: the identifier for an E1 link on the SG, and it's 27 bits 🦋 It MUST be unique on the SG. This Link Identifier MUST match the Link Identifier used in the Link Management Messages defined later in this document 💜
- Chnl ID: the Channel Identifier, 5 bits 🌸 It equals the time-slot number of the addressed time slot. The possible values are 15, 16 and 31, which are the time slots for C-channels on a V5 interface ✨ For Link Management Messages, Chnl ID MUST be set to 0. Everything else is reserved for future use 🙈
If the text formatted interface identifier is used, it SHALL be coded as the hex representation of the integer formatted interface identifier, written as a variable length string 🎀
4.3. V5 Additions to IUA Boundary Primitives 🧚
Some V5 interface boundary primitives look a lot like the Q.921/Q.931 boundary primitive messages that IUA already defines, but they get handled differently 👀 So we need a way to tell them apart, and that's what the Message Class parameter is for 💅
For all V5 interface boundary primitives, there's a brand new Message Class:
14 V5 Boundary Primitives Transport
Messages (V5PTM)The other valid message classes for V5UA (IUA uses these too) are:
0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) MessagesThe Q.921/Q.931 boundary primitive messages that V5.2 reuses as V5PTM messages are:
1 Data Request Message (MGC -> SG)
2 Data Indication Message (SG -> MGC)
3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC)All of these are defined in a similar way to the QPTM messages 🌈 On top of that, there are some new boundary primitive messages:
11 Link Status Start Reporting (MGC -> SG)
12 Link Status Stop Reporting (MGC -> SG)
13 Link Status Indication (SG -> MGC)
14 Sa-Bit Set Request (MGC -> SG)
15 Sa-Bit Set Confirm (SG -> MGC)
16 Sa-Bit Status Request (MGC -> SG)
17 Sa-Bit Status Indication (SG -> MGC)
18 Error Indication (SG -> MGC)4.4. Link Status Messages (Start Reporting, Stop Reporting, Indication) 📊
Link Status Messages are how V5 System Management on the MGC and the L1 FSM on the SG keep tabs on the status of a particular E1 link 👑 This is needed whether or not that E1 link carries any C-channels, so it's basically always a thing 💖
Every Link Status Message contains the V5UA Message Header ✨ The Link Identifier part of the Interface Identifier tells you which physical link on the SG the message is about. For all link status messages, the Chnl ID SHALL be set to '0' and SHALL be ignored by the receiver 🙈
The integer used for the Link Identifier only has local significance, and the SG and MGC agree on it between them 🤝 It MUST be unique for every V5 link on the SG 🔥
V5 standards say V5 System Management needs to know the status of the links on all active V5 interfaces 🫶 The Link Status Start Reporting Message is how System Management on the MGC asks the L1 FSM on the SG to start reporting on a particular link 🦋
V5 system management SHALL send this Message on interface activation for all links on the interface. The SG SHALL respond immediately to this request with a Link Status Indication message, and then it SHALL send a Link Status Indication message on every later change to the link status. The SG has no other way to figure out whether a link is on an active interface, so this message SHALL always be sent on interface startup 🚀
If the L1 FSM in the SG gets a Link Status Start Reporting Message for a link that's already active (meaning the link status is already being reported to System Management), the SG SHALL immediately report the actual status of that link by sending a Link Status Indication Message. After that, the SG SHALL carry on with the automatic link status reporting described above 💅
To stop reporting on a link, for example at interface deactivation, System Management sends a Link Status Stop Reporting Message to the L1 FSM 🛑 The SG will immediately stop reporting the status of that link and will assume the link is out of service. It MUST NOT respond in any way to this message 🙈
The SG has no other way of knowing that an interface got deactivated, so this message SHALL be sent on interface deactivation for all links on the interface. When it arrives, the SG SHALL take L2 down on that link 📉
If the L1 FSM in the SG gets a Link Status Stop Reporting Message for a link that isn't active (meaning the link status isn't being reported to System Management), the SG SHALL ignore the message 🤷♀️
The Link Status Start/Stop Reporting Messages contain the common message header, followed by the V5UA message header. That's it, they don't carry any additional parameters 🎀
The Link Status Indication Message is what the L1 FSM in the SG sends back in response to a Link Status Start Reporting Message, to tell you the status of that link 📡 Once the L1 FSM has received a Link Status Start Reporting Message, it SHALL automatically send a Link Status Indication Message every time the status of that link changes. It SHALL not stop this reporting until it receives a Link Status Stop Report Message from System Management 💜
The Link Status Indication Message contains the common message header, followed by the V5UA message header. On top of that, it includes this link status parameter:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x82) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The valid values for Link Status are in this table:
Define Value Description
OPERATIONAL 0x0 Link operational
NON-OPERATIONAL 0x1 Link not operational4.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request, Status Indication) 🔐
Sa-Bit Messages are how V5 System Management on the MGC and the L1 FSM on the SG set and read the status of Sa bits on E1 links 🧚 For V5, the only thing that's required is setting and reading the Sa7 bit, which is what the Link Identification procedure uses according to the V5 standards [3] 💅
All Sa-Bit Messages SHALL contain the V5UA message header 📨 The Link Identifier part of the Interface Identifier tells you which physical link on the SG the message is addressing. For all link status messages, the Chnl ID SHALL be set to '0' and SHALL be ignored by the receiver 🙈
The Link Identifier MUST be the same one used in the Interface Identifier that says which link a C-channel is on 🔗
The Sa-Bit Set Request message sets the value of the specified Sa-Bit on the defined link 🎀 In normal operation, the Sa7 bit is ONE. For the Link Identification procedure, it gets set to ZERO 🦋
A Sa-Bit Set Request for the Sa7 bit with Bit Value ZERO corresponds to the V5 defined primitive MPH-ID ✨ A Sa-Bit Set Request for the Sa7 bit with Bit Value ONE corresponds to the V5 defined primitive MPH-NOR 💜
The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set Confirm message once the bit has been set 🫶 This message doesn't correspond to any V5 defined primitive 🤷♀️
The Sa-Bit Status Request message is how system management asks the L1 FSM for the status of the specified Sa-Bit on the defined link 🔍 A Sa-Bit Status Request for the Sa7 bit corresponds to the V5 defined primitive MPH-IDR 👑
The L1 FSM answers a Sa-Bit Status Request with a Sa-Bit Status Indication message, which reports the current setting of the bit 📡 A Sa-Bit Status Indication for the Sa7 bit with Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. A Sa-Bit Status Indication for the Sa7 bit with Bit Value ONE corresponds to the V5 defined primitive MPH-Elg 🌈
All Sa-Bit Messages contain this additional parameter:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x83) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIT ID | Bit Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The valid values for Bit Value are in this table:
Define Value Description
ZERO 0x0 Bit value ZERO
ONE 0x1 Bit value ONEThe only valid value for BIT ID is in this table:
Define Value Description
Sa7 0x7 Addresses the Sa7 bitThere are no other valid values for V5UA 🙅♀️ All other values are reserved for future use 🔮
For the Sa-Bit Status Request and Set Confirm messages, the BIT Value SHALL be set to '0' by the sender and SHALL be ignored by the receiver 🫶
4.6. Error Indication Message 🚨
The Error Indication Message is how the V5 stack on the SG tells the V5 System Management in the MGC that something's wrong on its end. Think of it as the SG sending a little "help, I'm struggling" text 🥺
The only valid reason for this message is Overload. 🫶 The SG SHOULD send an Error Indication with reason Overload for a C-channel if it can't process all the Layer 3 messages on that C-channel in a timely manner. That's the overload condition of the C-channel, and it's giving stressed energy 😭
The Error Indication message SHALL contain the V5UA message header. ✨
The Interface Identifier points at the affected C-channel. SAPI, TEI and EFA SHALL all be set to '0', and the receiver SHALL ignore them 🙈
The Error Indication message also has one extra parameter:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x84) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here are the valid values for Error Reason:
Define Value Description
OVERLOAD 0x1 C-channel is in overload stateAnd that's literally it. There are no other valid values for V5UA. All other values are reserved for future use 🔮
5. Procedures 💅
5.1. V5 Layer 1 failure ⚡
Okay, so the normal way to handle a V5 Layer 1 failure is described in the V5 standards [2,3], and it goes like this:
- The L1 FSM detects the V5 Layer 1 failure. It tells V5 System management about it by sending an MPH-DI primitive for the affected link.
- V5 System management tells V5 Layer 2 about the V5 Layer 1 outage by sending an MPH-Layer_1 Failure Ind primitive.
BUT here's the twist 🌀 Since V5 Layer 1/2 and V5 System Management aren't living in the same place anymore in the backhaul architecture, it doesn't make sense to tell V5 Layer 2 about the Layer 1 failure through V5 system management. Instead, V5 Layer 2 SHALL be notified directly by V5 Layer 1 on the SG 🫶 V5 Layer 1 SHALL report the outage to V5 system management by sending a Link Status Indication message with status NON-OPERATIONAL, which corresponds to an MPH-DI primitive as defined by the V5.2 standard. And V5 system management SHALL NOT send an MPH-Layer_1 Failure Ind primitive to V5 Layer 2 in response to this message. No double-texting here, bestie 💀
5.2. Loss of V5UA peer 💔
If an SCTP failure is detected or the heartbeat is lost, the following procedure SHALL be performed.
When loss of the V5UA peer gets reported to the V5UA layer, the ASP SHALL behave as if it had received a Link Status Indication (non-operational) for all links on this SG.
The ASP SHALL keep trying to re-establish the connection continuously 🔁 Once the connection is back, the ASP SHALL send a Link Status Start Reporting message to the SG for all links on active V5 interfaces on the SG. Main character comeback arc 👑
Here's the message flow for re-establishing the connection, shown for one active link on the SG:
ASP SG
| |
| -------- Link Status Start Reporting ---------> |
| |
| <------ Link Status Ind (operational) --------- |
| |And if the association can be re-established before the V5UA layer gets notified, communication SHALL proceed as usual and no other action SHALL be taken by the ASP. Smooth, no drama 🌸
5.3. C-channel overload on SG 🥵
If the SG detects an overload condition on a C-channel, it SHOULD indicate this by sending an Error Indication message with the reason Overload to the MGC. The MGC SHOULD then take appropriate actions to clear this overload condition.
The SG SHALL resend the Error Indication message with the reason Overload for as long as the overload condition persists. An interval of 120 seconds for resending this message is RECOMMENDED ⏱️
6. Examples 🧚
6.1. Link Identification Procedure (successful) 🔍
The Link Identification Procedures themselves are described by the V5.2 standard [3].
Here's a message flow example for an LE initiated Link Identification procedure over V5UA. An active association between the ASP and the SG is set up before these message flows, and the V5 interface is already in service:
ASP SG
| |
| ------ Data Request (LnkCtrl: FE-IDReq) ------> |
| <-- Data Indication (LnkCtrl Ack: FE-IDReq) --- |
| |
| <---- Data Indication (LnkCtrl: FE-IDAck) ----- |
| ---- Data Request (LnkCtrl Ack: FE-IDAck) ----> |
| |
| ------ Sa-Bit Status Request ( Sa7 ) ---------> |
| <--- Sa-Bit Status Indication ( Sa7, ZERO ) --- |
| |
| ------- Data Request (LnkCtrl: FE-IDRel) -----> |
| <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- |
| |The next example also shows a Link Identification procedure, but this time the AN starts it. Again, the ASP association and the V5 interface are already in service:
ASP SG
| |
| <---- Data Indication (LnkCtrl: FE-IDReq) ----- |
| -- Data Request (LnkCtrl Ack: FE-IDReq) ------> |
| |
| ---------- Sa-Bit Set Req ( Sa7, ZERO ) ------> |
| <--------- Sa-Bit Set Conf (Sa7) -------------- |
| |
| ------- Data Request (LnkCtrl: FE-IDAck) -----> |
| <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- |
| |
| <---- Data Indication (LnkCtrl: FE-IDRel) ----- |
| ---- Data Request (LnkCtrl Ack: FE-IDRel) ----> |
| |
| ------------ Sa-Bit Set Req ( Sa7, ONE ) -----> |
| <----------- Sa-Bit Set Conf (Sa 7) ----------- |
| |7. Security Considerations 🔐
Okay, security is SERIOUS, so pay attention 🚨 The security considerations discussed in the 'Security Considerations for SIGTRAN Protocols' [5] document apply to this document. Read that one too, no skipping 🙏
8. IANA Considerations 📋
8.1. SCTP Payload Protocol Identifiers 🏷️
IANA has assigned a V5UA value for the Payload Protocol Identifier in the SCTP DATA chunk. The following SCTP Payload Protocol identifier is registered:
V5UA "6"The SCTP Payload Protocol identifier value "6" SHOULD be included in each SCTP DATA chunk to show that SCTP is carrying the V5UA protocol. The value "0" (unspecified) is also allowed, but any other values MUST not be used. This Payload Protocol Identifier isn't directly used by SCTP, but it MAY be used by certain network entities to identify the type of information being carried in a Data chunk 🧃
The User Adaptation peer MAY use the Payload Protocol Identifier as a way of working out additional information about the data SCTP is presenting to it. ✨
8.2. V5UA Port Number 🔌
IANA has registered SCTP (and UDP/TCP) Port Number 5675 for V5UA 💖
9. Acknowledgements 🫶
The authors would like to thank Fahir Ergincan, Milos Pujic, Graeme Currie, Berthold Jaekle, Ken Morneault and Lyndon Ong for their valuable comments and suggestions. Thank you, besties 🥹💜
10. References 📚
10.1. Normative References
- [1] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
- [2] ETSI EN 300 324-1 (1999): V interfaces at the digital Local Exchange (LE); V5.1 interface for the support of Access Network (AN); Part 1: V5.1 interface specification.
- [3] ETSI EN 300 347-1 (1999): V interfaces at the digital Local Exchange (LE); V5.2 interface for the support of Access Network (AN); Part 1: V5.2 interface specification.
- [4] ETSI ETS 300 125 (1991) : DSS1 protocol; User-Network interface data link layer specification; (Standard is based on : ITU Q.920, Q.921).
- [5] Loughney, J., Tuexen, M., Ed. and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, May 2004.
10.2. Informative References
- [6] 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.
- [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
11. Authors' Addresses 🖋️
Dr. Eva Weilandt
Conti Temic microelectronic GmbH
An der B31
88090 Immenstaad
Germany
Phone: +49 7545 8-2917
EMail: eva.weilandt@temic.comSanjay Rao
Nortel Networks
35 Davis Drive
Research Triangle Park, NC 27709
USA
Phone: +1-919-991-2251
EMail: rsanjay@nortelnetworks.comNeeraj Khanchandani
Nortel Networks
35 Davis Drive
Research Triangle Park, NC 27709
USA
Phone: +1-919-991-2274
EMail: neerajk@nortelnetworks.com12. Full Copyright Statement ©️
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain 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 regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 💜🎀
📦 where this page comes from
- ietf: rfc3807 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms