RFC 6320
Protocol for Access Node Control Mechanism in Broadband Networks
RFC 6320 🎀 Protocol for Access Node Control Mechanism in Broadband Networks
okay bestie, RFC 6320 is giving Standards Track energy 🔥 That means it's the real deal, not a draft experiment. It was published in October 2011 and its ISSN is 2070-1721 ✨
The authors are S. Wadhwa (Alcatel-Lucent), J. Moisand (Juniper Networks), T. Haag (Deutsche Telekom), N. Voigt (Nokia Siemens Networks), and T. Taylor, Ed. (Huawei Technologies). The "Ed." just means that T. Taylor was the editor 🫶
The title block doesn't list anything this document obsoletes or updates, so there's nothing to add there 💅
Abstract 🦋
okay so this doc describes the Access Node Control Protocol (ANCP) 💖 ANCP runs between a Network Access Server (NAS) and an Access Node (for example, a Digital Subscriber Line Access Multiplexer (DSLAM)) inside a multi-service reference architecture. Its whole job is handling Quality of Service, service, and subscriber operations 🌈 The use cases are written up in RFC 5851, so go check that out if you want the backstory 📚
Beyond the base protocol, this doc also specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. Honestly iconic 👑 The design also lets other documents add protocol extensions if other use cases or access technologies need them. Future-proof, periodt ✨
ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) from RFC 3292 🍓 but it got so many modifications and extensions that the two protocols are not interoperable 💀 That's why ANCP got its own version number, so nobody mixes them up 🙈
Status of This Memo 🌸
This is an Internet Standards Track document 💅
This doc comes from the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🧚
For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6320 🔗
Copyright Notice 💜
Copyright (c) 2011 IETF Trust and the people listed as document authors. All rights reserved 🌈
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date. Please actually read those, bestie, because they explain your rights and restrictions for this doc 🫶 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License ⭐
This doc might contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. Some of the people who own the copyright on that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 So unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🦋
Table of Contents 💖
1. Introduction ....................................................5
1.1. Historical Note ............................................6
1.2. Requirements Language ......................................6
1.3. Terminology ................................................6
2. Broadband Access Aggregation ....................................8
2.1. ATM-Based Broadband Aggregation ............................8
2.2. Ethernet-Based Broadband Aggregation .......................9
3. Access Node Control Protocol -- General Aspects ................10
3.1. Protocol Version ..........................................10
3.2. ANCP Transport ............................................10
3.3. Encoding of Text Fields ...................................11
3.4. Treatment of Reserved and Unused Fields ...................12
3.5. The ANCP Adjacency Protocol ...............................12
3.5.1. ANCP Adjacency Message Format ......................12
3.5.2. ANCP Adjacency Procedures ..........................18
3.6. ANCP General Message Formats ..............................29
3.6.1. The ANCP Message Header ............................29
3.6.2. The ANCP Message Body ..............................36
3.7. General Principles for the Design of ANCP Messages ........37
4. Generally Useful ANCP Messages and TLVs ........................38
4.1. Provisioning Message ......................................38
4.2. Generic Response Message ..................................39
4.3. Target TLV ................................................41
4.4. Command TLV ...............................................41
4.5. Status-Info TLV ...........................................42
5. Introduction to ANCP Capabilities for Digital
Subscriber Lines (DSLs) ........................................43
5.1. DSL Access Line Identification ............................44
5.1.1. Control Context (Informative) ......................44
5.1.2. TLVs for DSL Access Line Identification ............45
6. ANCP-Based DSL Topology Discovery ..............................48
6.1. Control Context (Informative) .............................48
6.2. Protocol Requirements .....................................50
6.2.1. Protocol Requirements on the AN Side ...............50
6.2.2. Protocol Requirements on the NAS Side ..............50
6.3. ANCP Port Up and Port Down Event Message Descriptions .....51
6.4. Procedures ................................................52
6.4.1. Procedures on the AN Side ..........................52
6.4.2. Procedures on the NAS Side .........................53
6.5. TLVs for DSL Line Attributes ..............................53
6.5.1. DSL-Line-Attributes TLV ............................53
6.5.2. DSL-Type TLV .......................................54
6.5.3. Actual-Net-Data-Rate-Upstream TLV ..................54
6.5.4. Actual-Net-Data-Rate-Downstream TLV ................54
6.5.5. Minimum-Net-Data-Rate-Upstream TLV .................55
6.5.6. Minimum-Net-Data-Rate-Downstream TLV ...............55
6.5.7. Attainable-Net-Data-Rate-Upstream TLV ..............55
6.5.8. Attainable-Net-Data-Rate-Downstream TLV ............55
6.5.9. Maximum-Net-Data-Rate-Upstream TLV .................56
6.5.10. Maximum-Net-Data-Rate-Downstream TLV ..............56
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV ......56
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV ....56
6.5.13. Maximum-Interleaving-Delay-Upstream TLV ...........57
6.5.14. Actual-Interleaving-Delay-Upstream TLV ............57
6.5.15. Maximum-Interleaving-Delay-Downstream TLV .........57
6.5.16. Actual-Interleaving-Delay-Downstream ..............57
6.5.17. DSL-Line-State TLV ................................58
6.5.18. Access-Loop-Encapsulation TLV .....................58
7. ANCP-Based DSL Line Configuration ..............................59
7.1. Control Context (Informative) .............................59
7.2. Protocol Requirements .....................................61
7.2.1. Protocol Requirements on the NAS Side ..............61
7.2.2. Protocol Requirements on the AN Side ...............61
7.3. ANCP Port Management (Line Configuration) Message Format ..62
7.4. Procedures ................................................64
7.4.1. Procedures on the NAS Side .........................64
7.4.2. Procedures on the AN Side ..........................64
7.5. TLVs for DSL Line Configuration ...........................64
7.5.1. Service-Profile-Name TLV ...........................65
8. ANCP-Based DSL Remote Line Connectivity Testing ................65
8.1. Control Context (Informative) .............................65
8.2. Protocol Requirements .....................................66
8.2.1. Protocol Requirements on the NAS Side ..............66
8.2.2. Protocol Requirements on the AN Side ...............66
8.3. Port Management (OAM) Message Format ......................67
8.4. Procedures ................................................68
8.4.1. NAS-Side Procedures ................................68
8.4.2. AN-Side Procedures .................................69
8.5. TLVs for the DSL Line Remote Connectivity Testing
Capability ................................................70
8.5.1. OAM-Loopback-Test-Parameters TLV ...................70
8.5.2. Opaque-Data TLV ....................................71
8.5.3. OAM-Loopback-Test-Response-String TLV ..............71
9. IANA Considerations ............................................71
10. IANA Actions ..................................................72
10.1. ANCP Message Type Registry ...............................72
10.2. ANCP Result Code Registry ................................73
10.3. ANCP Port Management Function Registry ...................74
10.4. ANCP Technology Type Registry ............................75
10.5. ANCP Command Code Registry ...............................75
10.6. ANCP TLV Type Registry ...................................75
10.7. ANCP Capability Type Registry ............................77
10.8. Joint GSMP / ANCP Version Registry .......................77
11. Security Considerations .......................................77
12. Contributors ..................................................79
13. Acknowledgements ..............................................79
14. References ....................................................79
14.1. Normative References .....................................79
14.2. Informative References ...................................80to be continued 🧵 part 1 wraps here, bestie, and the Introduction and everything after it are coming up next 💖
1. Introduction ✨
Okay bestie, so this document defines a brand new protocol called the Access Node Control Protocol (ANCP) 💖. Its whole job is to set up a control plane between a service-oriented layer 3 edge device (the Network Access Server, NAS) and a layer 2 Access Node (e.g., Digital Subscriber Line Access Multiplexer, DSLAM) so they can handle quality of service (QoS), services, and subscriptions 🎀. The requirements for ANCP and the context it works in are covered in [RFC5851], so go read that if you want the backstory 🦋.
ANCP provides its services to control applications running in the AN and the NAS, respectively. Check out Figure 1 to see how it all fits together 🌸. Writing the control applications is out of scope for this document, but we include some informative partial descriptions so you can see the context for how the protocol works 🧚.
Access Node Network Access Server
+--------------------+ +--------------------+
| +----------------+ | | +----------------+ |
| | AN Control | | | | NAS Control | |
| | Application | | | | Application | |
| +----------------+ | | +----------------+ |
| +----------------+ | | +----------------+ |
| | ANCP Agent | | ANCP Messages | | ANCP Agent | |
| | (AN side) |<----------------------->| (NAS side) | |
| +----------------+ | | +----------------+ |
+--------------------+ +--------------------+
Figure 1: Architectural Context for the Access Node Control ProtocolThroughout the doc, we describe the information flows between the control applications and ANCP. The point of these descriptions is to clarify where this spec ends and, for example, [TR-147] begins 💅. There's no intention to limit how tightly the control application and the protocol implementation are integrated, so do what slays for your setup 💜.
This specification covers ANCP transport over TCP/IP. TCP encapsulation for ANCP is defined in Section 3.2 🎀.
Here's how the document is laid out 📖:
- Sections 1.2 and 1.3 introduce some terminology that'll be useful for the rest of the doc.
- Section 2 describes the access networks where ANCP will typically be deployed.
- Section 3 specifies the generally applicable aspects of ANCP.
- Section 4 specifies some messages and TLVs meant for use by multiple capabilities spanning multiple technologies.
- Section 5 and the three following sections describe and specify the ANCP implementation of three capabilities that apply to controlling DSL access technology: topology discovery, line configuration, and remote line connectivity testing.
- Section 9 is the IANA Considerations section. It defines a number of new ANCP-specific registries, plus the joint GSMP/ANCP version registry mentioned below 🔥.
- Section 11 covers the security considerations for ANCP, starting with the requirements stated in [RFC5713]. Stay tuned, this part is serious 🙈.
1.1. Historical Note
Initial implementations of the protocol that became ANCP were based on the General Switch Management Protocol version 3 (GSMPv3) [RFC3292]. The ANCP charter required the Working Group to develop its protocol based on those implementations. In the end, ANCP introduced so many extensions and modifications to GSMPv3 that the two protocols are not interoperable 💀. Still, even though this specification has no normative dependencies on [RFC3292], you can see the mark of ANCP's origins in the various unused fields within the ANCP message header 🦋.
Early in ANCP's development, the team decided to use the same TCP port and encapsulation as GSMPv3. By the time ANCP was finished, it was too late to reverse that call because of existing implementations 😭. So an ANCP peer needs a way to quickly tell ANCP apart from GSMP during initial adjacency negotiations. That's handled by a joint registry of GSMP and ANCP version numbers. GSMP has version numbers 1 through 3. ANCP has the initial version number 50 ✨.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💅.
1.3. Terminology
This section repeats some definitions from [RFC5851], but it also adds definitions for terms used only in this document 🌈.
Access Node (AN): [RFC5851] Network device, usually located at a service provider central office or street cabinet that terminates access (local) loop connections from subscribers. In case the access loop is a Digital Subscriber Line (DSL), the Access Node provides DSL signal termination and is referred to as a DSL Access Multiplexer (DSLAM).
Network Access Server (NAS): [RFC5851] Network element that aggregates subscriber traffic from a number of Access Nodes. The NAS is an enforcement point for policy management and IP QoS in the access network. It is also referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS) 👑.
Home Gateway (HGW): Network element that connects subscriber devices to the Access Node and the access network. In the case of DSL, the Home Gateway is a DSL network termination that may operate either as a layer 2 bridge or as a layer 3 router. In the latter case, such a device is also referred to as a Routing Gateway (RG) 🏠.
ANCP agent: A logical entity that implements ANCP in the Access Node (AN-side) or NAS (NAS-side) 🧚.
Access Node control adjacency: (modified from [RFC5851]) The relationship between the AN-side ANCP agent and the NAS-side ANCP agent for the purpose of exchanging Access Node Control Protocol messages. The adjacency may be either up or down, depending on the result of the Access Node Control adjacency protocol operation 🔥.
ANCP capability: A specific set of ANCP messages, message content, and procedures required to implement a specific use case or set of use cases. Some ANCP capabilities are applicable to just one access technology while others are technology independent. The capabilities applicable to a given ANCP adjacency are negotiated during adjacency startup 🎀.
Type-Length-Value (TLV): A data structure consisting of a 16-bit type field, a sixteen-bit length field, and a variable-length value field padded to the nearest 32-bit word boundary, as described in Section 3.6.2. The value field of a TLV can contain other TLVs. An IANA registry is maintained for values of the ANCP TLV Type field 🍓.
Net data rate: [RFC5851] Defined by ITU-T G.993.2 [G.993.2], Section 3.39, i.e., the portion of the total data rate that can be used to transmit user information (e.g., ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g., trellis coding in the case of DSL). It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation and non-zero for 64/65 encapsulation 🧮.
Line rate: [RFC5851] Defined by ITU-T G.993.2. It contains the complete overhead including Reed-Solomon and trellis coding ⭐.
DSL multi-pair bonding: Method for bonding (or aggregating) multiple xDSL access lines into a single bidirectional logical link, henceforth referred to in this document as "DSL bonded circuit". DSL "multi-pair" bonding allows an operator to combine the data rates on two or more copper pairs, and deliver the aggregate data rate to a single customer. ITU-T recommendations G.998.1 [G.998.1] and G.998.2 [G.998.2], respectively, describe ATM- and Ethernet-based multi-pair bonding 🌸.
2. Broadband Access Aggregation 🌐
2.1. ATM-Based Broadband Aggregation
The end-to-end DSL network consists of network service provider (NSP) and application service provider (ASP) networks, regional/access network, and customer premises network. Figure 2 shows ATM broadband access network components 💖.
The regional/access network consists of the regional network, Network Access Server (NAS), and the access network as shown in Figure 2. Its primary function is to provide end-to-end transport between the customer premises and the NSP or ASP 🎀.
The Access Node terminates the DSL signal. It may be in the form of a DSLAM in the central office, a remote DSLAM, or a Remote Access Multiplexer (RAM). The Access Node is the first point in the network where traffic on multiple DSL access lines will be aggregated onto a single network 🦋.
The NAS performs multiple functions in the network. The NAS is the aggregation point for subscriber traffic. It provides aggregation capabilities (e.g., IP, PPP, ATM) between the Regional/Access Network and the NSP or ASP. These include traditional ATM-based offerings and newer, more native IP-based services. This includes support for Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services encapsulated over an appropriate layer 2 transport 🔥.
Beyond aggregation, the NAS is also the enforcement point for policy management and IP QoS in the regional/access networks. To allow IP QoS support over an existing non-IP-aware layer 2 access network without using multiple layer 2 QoS classes, a mechanism based on hierarchical scheduling is used. This mechanism, defined in [TR-059], preserves IP QoS over the ATM network between the NAS and the Routing Gateway (RG) at the edge of the subscriber network, by carefully controlling downstream traffic in the NAS, so that significant queuing and congestion do not occur farther down the ATM network. This is achieved by using a Diffserv-aware hierarchical scheduler in the NAS that will account for downstream trunk bandwidths and DSL synchronization rates 👑.
[RFC5851] provides detailed definitions of the functions of each network element in the broadband reference architecture 🧚.
Access Customer
<--- Aggregation --> <------- Premises ------->
Network Network
+------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber||
| | | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Regional | | +---+ | +------+ | |+-----+ +----------+|
|Broadband| | ...Wait, I need to paste that exactly. Here's the correct block:
Access Customer
<--- Aggregation --> <------- Premises ------->
Network Network
+------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ |
NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband| | +---+ | +------+ | |+-----+ +----------+|
ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+
---+ | | +---+ | +--------------------------+
| | | +---+ | |+-----+ +---+ +----------+|
+---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber||
+---+ ||Modem| +---+ |Devices ||
|+-----+ +----------+|
+--------------------------+
HGW: Home Gateway
NAS: Network Access Server
Figure 2: ATM Broadband Aggregation Topology2.2. Ethernet-Based Broadband Aggregation 🌸
okay so the Ethernet aggregation network is built on the Ethernet bridging and switching concepts from IEEE 802 💅 It gives you traffic aggregation, class of service distinction, and customer separation and traceability, which is honestly iconic. VLAN tagging is the standard virtualization mechanism here. It's defined in [IEEE802.1Q] and enhanced by [IEEE802.1ad]. The aggregation devices are "provider edge bridges" defined in [IEEE802.1ad] ✨
Stacked VLAN tags are one way to build the equivalent of "virtual paths" and "virtual circuits" in the aggregation network 🦋 The "outer" VLAN can act as a kind of "virtual path" between a given DSLAM and a given NAS. "Inner" VLAN tags make a "virtual circuit" for each DSL line. That's the 1:1 VLAN allocation model 💖 The other option is to bridge sessions from multiple subscribers behind a DSLAM into one single VLAN in the aggregation network. That's the N:1 VLAN allocation model 🧚 Section 1.6 of [TR-101] has quick definitions of both, and Section 2.5.1 goes into way more detail 🫶
3. Access Node Control Protocol -- General Aspects ✨
this section lays out the parts of the Access Node Control Protocol (ANCP) that apply pretty much everywhere 🌈
3.1. Protocol Version 🎀
ANCP messages carry an 8-bit protocol version field 💜 For the version this document specifies, that field MUST be set to 50. no notes, no exceptions 💅
3.2. ANCP Transport 🦋
this document specifies TCP / IPsec+IKEv2 / IP as the transport for ANCP messages 🔥 For more on IPsec and IKEv2, check Section 11. This section only covers the TCP side of things. Other specifications may bring in extra transports later on 👑
- ATM access: a separate permanent virtual circuit (PVC) can be set up as a control channel that carries IP between the NAS and the AN for ANCP messages. It MAY be configured this way 🌸
- Ethernet access/aggregation: the typical move is sending ANCP messages over a dedicated Ethernet virtual LAN (VLAN) with its own VLAN identifier (VLAN ID) 🍓
When ANCP messages go over TCP, they MUST use an encapsulation: a 4-byte header prepended to the ANCP message, shown in Figure 3 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (0x880C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ANCP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Encapsulation of ANCP Messages over TCP/IP
here's how the encapsulating header fields work 🧁
- Identifier (16 bits): this identifies a GSMP or ANCP message. It MUST be set to
0x880C🌟 - Length (16 bits): the total length of the ANCP message in bytes. The 4-byte encapsulating header is not counted 💅
The Access Node MUST initiate the TCP session to the NAS, using destination port 6068 🫶
why does it work this way? 🙈 It avoids static address provisioning on the NAS for every AN it serves. It's way easier to configure an AN with the single IP address of the NAS that serves it. genius, honestly 😭
The NAS MUST listen on port 6068 for incoming connections from the Access Nodes 🧚
if there's an ANCP transport protocol failure, all pending ANCP messages headed for the disconnected recipient SHOULD be discarded until the transport connection is back up 💀
3.3. Encoding of Text Fields ✨
all text fields in ANCP use UTF-8 encoding [RFC3629] 🌈 US-ASCII characters look exactly the same when coded as UTF-8 as they do when coded according to [US_ASCII], so no drama there 🦋
when you pull text fields out of a message, the ANCP agent MUST NOT assume the fields are zero-terminated. don't trust the null byte, bestie 💅
3.4. Treatment of Reserved and Unused Fields 🌸
ANCP messages have a bunch of fields that are unused or reserved 🍓 Some are always unused, usually because they were inherited from GSMPv3 and aren't useful in the ANCP context. Others are reserved in this spec but kept around for future ANCP extensions 🔮 Both reserved and unused fields MUST be set to zeroes by the sender, and MUST be ignored by the receiver. Zero drama, full vibes 💖
unused bits in a flag field show up as x in the figures. The rule above (sender sets zero, receiver ignores) applies to those unused bits too 🎀
3.5. The ANCP Adjacency Protocol 🦋
ANCP uses the adjacency protocol to synchronize the NAS and the Access Nodes and keep the ANCP session alive 🫶 Once the TCP connection is up, adjacency protocol messages MUST be exchanged as described in this section. Any ANCP messages that aren't adjacency protocol messages MUST NOT be sent until the adjacency protocol has reached synchronization. no skipping the line, periodt 👑
3.5.1. ANCP Adjacency Message Format 💜
the adjacency message format is shown in Figure 4 below ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType |P Flag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | # of Caps | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capability Fields ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: ANCP Adjacency Message Format
the fields of the adjacency message, one by one 🧚
- Version (8 bits): the ANCP version, which is subject to negotiation. This is the key parameter for telling ANCP messages apart from GSMP messages that arrive on the same port 🔑
- Message Type (8 bits): always has the value
10(adjacency protocol) 🌸 - Timer (8 bits): used to negotiate the timer value for the adjacency protocol with the peer. It's the nominal time between periodic adjacency protocol messages, and it stays constant for the whole ANCP session ⏰ The Timer field is in units of 100 ms, with a default value of 250 (i.e., 25 seconds) 💅
- M flag (1 bit): used in the SYN message so the NAS doesn't sync up with another NAS, and the AN doesn't sync up with another AN 🫶 In a SYN message, the NAS always sets it to 1 and the AN always sets it to 0. In other adjacency message types, the sender always sets it to 0 and the receiver ignores it 🙈
- Code (7 bits): the adjacency protocol message type. It MUST have one of the following values:
Code = 1: SYN;
Code = 2: SYNACK;
Code = 3: ACK;
Code = 4: RSTACK.- Sender Name (48 bits): for SYN, SYNACK, and ACK messages, this is the identifier of the entity sending the message. It's a 48-bit value that's unique within the device's operational context ✨ A 48-bit IEEE 802 Media Access Control (MAC) address can be used here if one is available. If Ethernet encapsulation is in use, the Sender Name MUST be the Source Address from the MAC header 💖 For RSTACK messages, this field gets set to the value of the Receiver Name from the incoming message that triggered the RSTACK 🧁
- Receiver Name (48 bits): for SYN, SYNACK, and ACK messages, this is the name of the entity the sender thinks is at the far end of the link. If the sender doesn't know that name, this field SHOULD be set to zero 🌈 For RSTACK messages, it gets set to the value of the Sender Name from the incoming message that triggered the RSTACK 🦋
- Sender Port (32 bits): for SYN, SYNACK, and ACK messages, this is the local port number of the link the message is sent across 🔌 For RSTACK messages, it's set to the value of the Receiver Port from the incoming message that triggered the RSTACK 🎀
- Receiver Port (32 bits): for SYN, SYNACK, and ACK messages, this is what the sender believes the local port number for the link is, as allocated by the entity at the far end 🧚 If the sender doesn't know that port number, this field SHOULD be set to zero 🫶 For RSTACK messages, it's set to the value of the Sender Port from the incoming message that triggered the RSTACK 💅
- PType (4 bits): says whether partitions are used and how the Partition ID gets negotiated. Here's the type of partition being requested 👑
0 - no partition;
1 - fixed partition request;
2 - fixed partition assigned.- P Flag (4 bits): indicates the type of partition request 🌟
1 - new adjacency;
2 - recovered adjacency.If the peers disagree on the value of the P Flag, the lower value wins 🙃
- Sender Instance (24 bits): for SYN, SYNACK, and ACK messages, this is the sender's instance number for the link to the peer 🔁 It's how you spot when the link comes back up after going down, or when the entity at the other end of the link changes. The instance number is a 24-bit number that's guaranteed to be unique within the recent past, and it changes when the link or node comes back up after going down ✨ Zero is not a valid instance number 🙅♀️ For RSTACK messages, the Sender Instance field gets set to the value of the Receiver Instance field from the incoming message that triggered the RSTACK 💜
Okay so the Partition ID is the field that ties a message to one specific partition on the AN, and bestie, the value gets negotiated during the adjacency procedure 🧚. The AN gets the final say, but it will absolutely consider a request from the NAS 💅. If the AN doesn't support partitions, this field MUST be 0. Otherwise it MUST be non-zero ✨.
Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages, this is what the sender thinks the current instance number for the link is, and that number was handed out by the entity at the far end 🦋. If the sender doesn't know the current instance number at the far end, this field SHOULD be set to zero 🙈. For the RSTACK message, the Receiver Instance is set to whatever the Sender Instance was in the incoming message that triggered the RSTACK 💜.
Reserved (8 bits): Reserved for a future version of this spec. Future us will thank us 🔮.
# of Caps (8 bits): How many Capability fields are coming up next 🎀.
Total Length (16 bits): The total number of bytes taken up by those Capability fields 📏.
Capability Fields: Each Capability field advertises one ANCP capability that the sender of the adjacency message supports 🌸. Agreeing on a shared set of capabilities for the ANCP session is described below 🤝. The detailed layout of a Capability field is in Figure 5, so check it out 👀.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Capability FieldHere's how the sub-fields work 💅:
- Capability Type (16 bits): Says exactly which capability is being supported. There's an IANA registry for these values, and the ones this document defines are listed below 📋.
- Capability Length (16 bits): How many bytes of data are in the Capability Data sub-field, not counting padding. If a capability has no data at all, this is zero 🫶.
- Capability Data (as indicated by Capability Length): The data that goes with the capability, as that capability defines it 🎁. If a capability has no data, this sub-field is absent (zero length). Otherwise the Capability Data sub-field MUST be padded with zeroes so it ends on a 4-byte word boundary 🧩. Being able to attach data means a capability can advertise more than just "yep, I have it" or "nope, don't have it," which is iconic flexibility 👑.
The following capabilities are defined for ANCP as applied to DSL access:
Capability Type: DSL Topology Discovery = 0x01- Access technology: DSL
- Length (in bytes): 0
- Capability Data: NULL
For the detailed protocol specification of this capability, see Section 6 🗺️.
Capability Type: DSL Line Configuration = 0x02- Access technology: DSL
- Length (in bytes): 0
- Capability Data: NULL
For the detailed protocol specification of this capability, see Section 7 ⚙️.
Capability Type: DSL Remote Line Connectivity Testing = 0x04- Access technology: DSL
- Length (in bytes): 0
- Capability Data: NULL
For the detailed protocol specification of this capability, see Section 8 🧪.
Okay, so besides the adjacency messages whose format is in Figure 6, the ANCP adjacency procedures also use the Adjacency Update message (also Figure 6) 📣. Its job is to tell the other NASs controlling the same AN partition when a particular NAS joins or loses an adjacency with that partition 👯.
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 | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Adjacency Update MessageThe Adjacency Update message is basically the same as the general ANCP message header from Section 3.6, but a few field settings are specific to this message 🧁. Here's the rundown:
- Version (8 bits): The ANCP version that was negotiated and is running on this adjacency 🔢.
- Message Type (8 bits): Always 85 💯.
- Result (4 bits): Set to Ignore (0) 🙃.
- Code (12 bits): Set to the total number of adjacencies currently established on this partition, from the AN's point of view 🔢.
- Partition ID (8 bits): The partition identifier of the partition this notification is being sent for 🏷️.
- Transaction Identifier (24 bits): MUST be set to 0 🔒.
- I (1 bit), SubMessage number (15 bits): Set as described in Section 3.6.1.7 📮.
- Length (16 bits): Set as described in Section 3.6.1.8 📏.
3.5.2. ANCP Adjacency Procedures ✨
3.5.2.1. Overview 🌈
The ANCP adjacency protocol works symmetrically between the NAS and the AN, so it's a true two-way friendship 🫂. When nothing goes wrong and there are no race conditions, each peer sends a SYN, gets a SYNACK back as an acknowledgement, and finishes setting up the adjacency by sending an ACK 🤝. Through that little dance, each peer learns the Name, Port, and Instance parameters that identify the other peer, and the two peers negotiate the Version, Timer, P Flag, and Partition ID parameters, plus the set of capabilities the adjacency will support 💖.
Once the adjacency is up, its liveness gets checked regularly 💓. The peers do an ACK message exchange at a rate set by the negotiated value of the Timer field ⏰.
If there's an inconsistency, loss of contact, or protocol violation, the peer that noticed can force a restart of the synchronization process by sending an RSTACK message to the other end 🚨.
Once an adjacency has been established, if more than one NAS has an adjacency to the same partition, the AN sends an Adjacency Update message to each of those NASs to let them know how many established adjacencies the partition currently supports 📣. Similarly, if an adjacency is lost, the AN sends an Adjacency Update message to each of the remaining adjacent NASs so they know the status changed 😭.
3.5.2.2. Adjacency Protocol State Machine 🎀
The adjacency protocol is described by the following rules and state tables 📖. It starts when each end sends a SYN as soon as the transport connection is established 🚀. If at any point the operations A, B, C, or "Verify Adjacent State" (defined below) detect a mismatch, a log SHOULD be generated, identifying the fields concerned along with the expected and received values for each 🕵️.
The rules and state tables use the following operations 🛠️:
- The "Record Adjacency State" operation is defined in Section 3.5.2.3.2.
- The "Verify Adjacency State" operation means checking that the contents of the incoming SYNACK message match the adjacency state values recorded earlier.
- The procedure "Reset the link" is defined as:
- Generate a new instance number for the link.
- Delete the peer verifier (set to zero the values of Sender Instance, Sender Port, and Sender Name previously stored by the "Record Adjacency State" operation).
- Send a SYN message (Section 3.5.2.3.1).
- Enter the SYNSENT state.
- The state tables use the following Boolean terms and operators:
- A. The Sender Instance in the incoming message matches the value stored from a previous message by the "Record Adjacency State" operation.
- B. The Sender Instance, Sender Port, Sender Name, and Partition ID fields in the incoming message match the values stored from a previous message by the "Record Adjacency State" operation.
- C. The Receiver Instance, Receiver Port, Receiver Name, and Partition ID fields in the incoming message match the values of the Sender Instance, Sender Port, Sender Name, and Partition ID currently sent in outgoing SYN, SYNACK, and ACK messages, except that the NAS always accepts the Partition ID value presented to it in a SYN or SYNACK message.
&&represents the logical AND operation.||represents the logical OR operation.!represents the logical negation (NOT) operation.
- A timer is required for the periodic generation of SYN, SYNACK, and ACK messages. The value of the timer is negotiated in the Timer field. The period of the timer is unspecified, but a value of 25 seconds is suggested. Since ANCP uses a reliable transport protocol, the timer is unlikely to expire in any state other than ESTAB 🕰️.
There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are 🎯:
Timer Expires: Reset Timer
If state = SYNSENT Send SYN
If state = SYNRCVD Send SYNACK
If state = ESTAB Send ACK
Packet Arrives:
If incoming message is an RSTACK:
If (A && C && !SYNSENT) Reset the link
Else discard the message.
If incoming message is a SYN, SYNACK, or ACK:
Response defined by the following state tables.
If incoming message is any other ANCP message and state != ESTAB:
Discard incoming message.
If state = SYNSENT Send SYN (Note 1)
If state = SYNRCVD Send SYNACK (Note 1)
Note 1: No more than two SYN or SYNACK messages should be sent
within any time period of length defined by the timer.State synchronization across a link is considered achieved once the protocol reaches the ESTAB state 🎉. Every ANCP message that arrives before synchronization is achieved gets discarded, unless it's an adjacency protocol message 🗑️.
3.5.2.2.1. State Tables 🎀
Okay bestie, here are the state tables! Each one shows what the protocol does when a message shows up in a given state. Each row is a Condition, the Action to take, and the New State you land in. 💖
State: SYNSENT 🦋
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+-----------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+===================================================================+State: SYNRCVD 🌸
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYNACK && C | Verify Adjacency State; Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| SYN | Record Adjacency State; Send SYNACK | SYNRCVD |
+-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && !(B && C)| Send RSTACK | SYNRCVD |
+===================================================================+State: ESTAB 👑
+===================================================================+
| Condition | Action | New State |
+=================+=====================================+===========+
| SYN || SYNACK | Send ACK (Note 2) | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (Note 3) | ESTAB |
+-----------------+-------------------------------------+-----------+
| ACK && !(B && C)| Send RSTACK | ESTAB |
+===================================================================+Note 2: No more than two ACKs should be sent within any time period of length defined by the timer. Thus, one ACK MUST be sent every time the timer expires. In addition, one further ACK may be sent between timer expirations if the incoming message is a SYN or SYNACK. This additional ACK allows the adjacency protocol to reach synchronization more quickly. 🧚
Note 3: No more than one ACK should be sent within any time period of length defined by the timer. 💅
3.5.2.3. The Adjacency Protocol SYN Message 🌈
3.5.2.3.1. Action by the Sender ✨
Okay so the SYN message gets sent following the state tables we just covered. When the sender fills in the individual fields, here's the tea:
Version: SHOULD be set to the highest version of ANCP that the sender supports. 💖Message Type: MUST be set to 10. 🎀Timer: SHOULD be set to the value configured in the AN or NAS sending the message. ⏰M Flag: MUST be set to 1 by the NAS, and 0 by the AN. 🦋Code: MUST be set to 1 (SYN). 🔥Sender Name: Set as described in Section 3.5.1. 💜Receiver Name: SHOULD be set to 0. 🌸Sender Port: Set as described in Section 3.5.1. 🫶Receiver Port: SHOULD be set to 0. ✨PType: Set according to the following rules:- Settings by the AN:
- 0 - the AN does not support partitions;
- 2 - the value of Partition ID contained in this message is assigned to the current partition.
- Settings by the NAS:
- 0 - the NAS leaves the decision on partitioning to the AN (RECOMMENDED setting);
- 1 - the NAS requests that the AN use the value of Partition ID contained in this message for the current partition. The NAS MAY use this setting even if it has already received a SYN message from the AN, provided that the AN has indicated support for partitions. The NAS MUST be prepared to use whatever value it receives in a subsequent SYN or SYNACK message, even if this differs from the requested value. 🙈
- Settings by the AN:
P Flag: Set to the mode of adjacency setup (new adjacency vs. recovered adjacency) requested by the sender.
⚠️ Warning, bestie: setting P Flag=1 runs the risk of state mismatch because ANCP does not provide the means for the NAS to audit the current state of the AN. 💀
Sender Instance: Set as described in Section 3.5.1. 🍓Partition ID: MUST be set to 0 if PType=0; otherwise, set to the assigned or requested partition identifier value. 🌈Receiver Instance: SHOULD be set to 0. 🦋# of Caps: MUST be set to the number of Capability fields that follow. 💅Total Length: MUST be set to the total number of bytes in the Capability fields that follow. 🧮Capability Fields: One Capability field MUST be present for each ANCP capability for which the sender wishes to advertise support. 👑
3.5.2.3.2. Action by the Receiver 🫶
So when the receiver gets a validly formed SYN message, it checks the Version field first. If that value isn't in the range of ANCP versions the receiver supports, the message MUST be silently ignored. The message also gets silently ignored if the M flag is 0 and the receiver is an AN, or if the M flag is 1 and the receiver is a NAS. If all those checks pass and the receiver is in ESTAB state, it sends back an ACK (as the ESTAB state table in Section 3.5.2.2.1 says). The contents of the ACK MUST reflect the adjacency state as previously recorded by the receiver. 💖
Otherwise, the receiver MUST perform the "Record Adjacency State" operation by recording the following fields:
Version: The supported Version value received in the SYN message. This value MUST be used for all subsequent ANCP messages sent during the life of the adjacency. 🎀Timer: The larger of the Timer value received in the SYN message and the value with which the receiver is configured. ⏰Sender Name: The value of the Sender Name field in the SYN message just received. 💜Receiver Name: The value used by the receiver in the Sender Name field of SYN, SYNACK, and ACK messages it sends in this adjacency. 🌸Sender Port: The value of the Sender Port field in the SYN message just received. 🫶Receiver Port: The value used by the receiver in the Sender Port field of SYN, SYNACK, and ACK messages it sends in this adjacency. ✨Sender Instance: The value of the Sender Instance field in the SYN message just received. 🍓P Flag: The lesser of the value determined by local policy and the value received in the SYN message. That is, preference is given to "0 - New adjacency" if there is a conflict. 🧚Partition ID: If the SYN receiver is the AN, this is set to 0 if the AN does not support partitions, or to the non-zero value of the partition identifier it chooses to assign otherwise. If the SYN receiver is the NAS, this is set to the value of the Partition ID field copied from the SYN. 🌈Receiver Instance: The value used by the receiver in the Sender Instance field of SYN, SYNACK, and ACK messages it sends in this adjacency. 🦋Capabilities: The set of ANCP capabilities that were offered in the SYN and are supported by the receiver. 👑
3.5.2.4. The Adjacency Protocol SYNACK Message 🌸
3.5.2.4.1. Action by the Sender 💅
The SYNACK gets sent in response to a successfully received SYN message, as the state tables indicate. The Version, Timer, P Flag, and Partition ID fields MUST be populated with the values recorded as part of adjacency state. The # of Caps, Total Length, and Capability fields MUST also be populated in line with the Capabilities recorded as part of adjacency state. The remaining fields of the SYNACK message MUST be populated as follows:
Message Type: MUST be 10. 🎀M flag: MUST be set to 0. 🦋Code: MUST be 2 (SYNACK). 🔥PType: MUST be 0 if the Partition ID value is 0, or 2 if the Partition ID value is non-zero. 🧚Sender Name: MUST be set to the Receiver Name value recorded as part of adjacency state. 💜Receiver Name: MUST be set to the Sender Name value recorded as part of adjacency state. 🌸Sender Port: MUST be set to the Receiver Port value recorded as part of adjacency state. 🫶Receiver Port: MUST be set to the Sender Port value recorded as part of adjacency state. ✨Sender Instance: MUST be set to the Receiver Instance value recorded as part of adjacency state. 🍓Receiver Instance: MUST be set to the Sender Instance value recorded as part of adjacency state. 🌈
If the set of capabilities recorded in the adjacency state is empty, then after sending the SYNACK the sender MUST raise an alarm to management, halt the adjacency procedure, and tear down the TCP session if it is not being used by another adjacency. The sender MAY also terminate the IPsec security association if no other adjacency is using it. 🚨
3.5.2.4.2. Action by the Receiver 🦋
As the state tables show, the receiver of a SYNACK first checks that the Receiver Name, Receiver Port, and Receiver Instance values match the Sender Name, Sender Port, and Sender Instance values it sent in the SYN message that's being acknowledged. The AN also checks that the PType and Partition ID match. If any of these checks fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1. 🙅♀️
The receiver next checks whether the set of capabilities provided in the SYNACK is empty. If so, the receiver MUST raise an alarm to management and halt the adjacency procedure. 💀
Assuming the SYNACK passes these checks, two cases come up. The first possibility is that the receiver has already recorded adjacency state. That happens if the SYNACK is received while the receiver is in SYNRCVD state. In this case, the Version, Timer, Sender Name, Sender Port, Sender Instance, P Flag, and capability-related fields in the SYNACK MUST match those recorded as part of adjacency state. If a mismatch is detected, the receiver sends an RSTACK. This is the "Verify Adjacency State" procedure shown in the SYNRCVD state table. 🔍
If, on the other hand, the SYNACK is received while the receiver is in SYNSENT state, the receiver MUST record session state as described in Section 3.5.2.3.2. 📝
In either case, if the receiver is the NAS, it MUST accept the Partition ID value provided in the SYNACK, updating its recorded adjacency state if necessary. 👑
3.5.2.5. The Adjacency Protocol ACK Message 💜
3.5.2.5.1. Actions by the Sender 🌷
As the state tables indicate, the ACK message gets sent in a bunch of different situations. The main-line usages are as a response to a SYNACK, which leads directly to the ESTAB state, and as a periodic test of liveness once the ESTAB state has been reached. 💓
The sender MUST populate the ACK from recorded adjacency state, exactly as described in Section 3.5.2.4.1. The only difference is that Code MUST be set to 3 (ACK). 🫶
3.5.2.5.2. Actions by the Receiver
okay so the receiver's job is spelled out by the state tables 💅 on top of checks B and C, the receiver SHOULD also make sure the rest of the ACK matches the adjacency state it recorded 🔍. if that check fails, the receiver MUST send an RSTACK, see Section 3.5.2.6.1 🚨
once the adjacency is up, either peer can start an ACK exchange to check that the other side is still alive 💖 the state tables limit how often ACKs can go out, so it's ideal to have only one of these exchanges in any one interval ✨ so if a peer gets an ACK while in ESTAB state, it MUST reply the way the state tables say, but it SHOULD NOT start another ACK exchange in that same interval 🫶 to make that work, the receiver MUST reset its timer whenever it gets an ACK in ESTAB state ⏰
two exchanges can still happen because of race conditions, so don't panic if you see it 🙈
3.5.2.6. The Adjacency Protocol RSTACK Message
3.5.2.6.1. Action by the Sender
the RSTACK goes out when the state tables say there's an error 🚫 usually it kicks off adjacency negotiations all over again, though it takes a few extra steps when the original sender of the RSTACK is in ESTAB state 🔄
as Section 3.5.1 says, the Sender Name, Port, and Instance fields in the RSTACK MUST be copied from the Receiver Name, Port, and Instance fields of the message that caused it 📋 and the Receiver identifier fields in the RSTACK MUST be copied from the matching Sender identifier fields of the message that triggered it 🪞
if the sender has adjacency state recorded, the Version, Timer, PType, P Flag, Partition ID, and capability-related fields SHOULD be set based on that recorded state 🗂️ if it doesn't, they SHOULD be whatever the sender would put in a SYN message 🌸 and the Message Type MUST be 10, the M flag MUST be 0, and Code MUST be 4 (RSTACK) 🎀
3.5.2.6.2. Action by the Receiver
the receiver of an RSTACK MAY try to figure out what went wrong by comparing its own adjacency state with the RSTACK contents 🕵️♀️ but honestly, the main job of the RSTACK is to kick off the actions described in Section 3.5.2.2 🦋
3.5.2.7. Loss of Synchronization
loss of synchronization MAY be declared if, after sync is achieved, either of these happens 😱
- no valid ANCP messages arrive for longer than three times the value of the
Timerfield negotiated in the adjacency protocol messages, or - a mismatch in adjacency state is detected.
in either case, the peer that notices MUST send an RSTACK to the other peer, as Section 3.5.2.6.1 directs, to start resynchronization 🔁
while a switch is re-establishing sync with a controller, it SHOULD keep its connection state and hold off on deciding whether to reset it until sync is back 🧚 once sync is re-established, the decision about resetting the connection state SHOULD be based on the negotiated value of the P Flag 👑
3.6. ANCP General Message Formats
this section covers the general format of ANCP messages other than the adjacency messages 💜 check out Figure 7 ✨
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 | Message Type | Result| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ANCP General Message Format3.6.1. The ANCP Message Header
here's the full rundown on each field in the ANCP general message header 📝
3.6.1.1. Version Field (8 bits)
this field carries the version of ANCP that the peers agreed on for the session during adjacency negotiation 🤝
3.6.1.2. Message Type Field (8 bits)
this field tells you which ANCP message type it is 🏷️ message type values are registered in an IANA registry 📚
3.6.1.3. Result Field (4 bits)
in requests, the Result field says when a response is needed 📬 ANCP specifies which Result value each request message type should have 💅 in responses, the Result field is either Success (0x3) or Failure (0x4), depending on what happened 🎀
- Ignore:
Res = 0x0. treat this field as a "no operation" and follow the response procedures for the received message type 🙈 - Nack:
Res = 0x1. a response is expected for this request only if something fails while the message contents or the directives inside it are being processed 🚧 - AckAll:
Res = 0x2. a response to the message is requested in every case 📣 - Success:
Res = 0x3. this marks a response, and the request ran successfully ✅ theResult Codefor a success is usually 0, but it MAY be other values for certain message types 🌈 - Failure:
Res = 0x4. this marks a response, and the request did not run successfully ❌ the receiver of the response SHOULD take further action based on theResult Codevalue and any diagnostic data in a Status-Info TLV included in the response 🫶
3.6.1.4. Result Code Field (12 bits) ✨
okay so this field is where the response tells you what actually happened 💅 It's mostly for passing an error code in a failure response, but it can also share extra info in a success response or an event message 🎀 In a request message the Result Code field isn't used, so it MUST be set to 0x0 (No result) 🫶
A bunch of Result Code values are specified below 🌸 Any extra Result Code values added through extensions or updates to this document MUST come with the following info:
- Result Code value;
- One-line description;
- Where condition detected (control application or ANCP agent);
- Further description (if any);
- Required additional information in the response message;
- Target (control application or ANCP agent at the peer that sent the original request);
- Action RECOMMENDED for the receiving ANCP agent.
On top of any suggested action in the text below, a count of how many times a given non-zero Result Code value was received SHOULD be provided for management 📊 And if an action involves re-sending a request, a given request SHOULD NOT be re-sent more than once 🙅
This document specifies the following Result Code values 👑
Result Code value: 0x2 🦋
- One-line description: Invalid request message
- Where condition detected: ANCP agent
- Further description: The request was a properly formed message that violates the protocol through its timing or direction of transmission. The most likely reason for this outcome in the field will be a race condition.
- Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
- Target: ANCP agent at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: The original request MAY be re-sent once only after a short delay. Inform the control application with appropriate identification of the failed transaction if the second attempt fails or no second attempt is made.
Result Code value: 0x6 🌈
- One-line description: One or more of the specified ports are down
- Where condition detected: Control application
- Further description (if any): This Result Code value indicates a state mismatch between the NAS and AN control applications, possibly due to a race condition.
- Required additional information in the response message: If the request identified multiple access lines or the response is a Generic Response message, then the response MUST contain a Status-Info TLV encapsulating TLV(s) containing the line identifier(s) of the access lines that are not operational.
- Target: Control application at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: Indicate the error and forward the line identifier(s) to the control application.
Result Code value: 0x13 🧚
- One-line description: Out of resources
- Where condition detected: ANCP protocol layer or control application
- Further description (e.g., memory exhausted): This Result Code value MUST be reported only by the AN, and indicates a condition that is probably unrelated to specific access lines (although it may be related to the specific request).
- Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
- Target: ANCP agent at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: If the NAS receives this Result Code value from multiple requests for the same AN in a short interval, it SHOULD reduce the rate at which it sends requests in proportion to the rate at which requests are failing with Result Code = 19. It MAY retry individual requests. If only a specific request is failing with Result Code = 19, the ANCP agent in the NAS MAY request the control application to decompose the request into simpler components if this is possible.
Result Code value: 0x51 🍓
- One-line description: Request message type not implemented
- Where condition detected: ANCP agent
- Further description: This could indicate a mismatch in protocol version or capability state. It is also possible that support of a specific message is optional within some ANCP capability.
- Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
- Target: ANCP agent at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: If the receiver of this Result Code value expects that support of the message type concerned is mandatory according to the capabilities negotiated for the session, it MAY re-send the message in case the message was corrupted in transit the first time. If that fails, and use of the message type cannot be avoided, the ANCP agent MAY reset the adjacency by sending an RSTACK adjacency message as described in Section 3.5.2.6.1, where Sender and Receiver Name, Port, and Instance are taken from recorded adjacency state. If a reset does not eliminate the problem, the receiving ANCP agent SHOULD raise an alarm to management and then cease to operate.
Result Code value: 0x53 💜
- One-line description: Malformed message
- Where condition detected: ANCP agent
- Further description: This could be the result of corruption in transit, or an error in implementation at one end or the other.
- Required additional information in the response message: None, if the response message is of the same type as the request. As specified in Section 4.2, if the response message is a Generic Response message.
- Target: ANCP agent at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: The request SHOULD be re-sent once to eliminate the possibility of in-transit corruption.
Result Code value: 0x54 🎀
- One-line description: Mandatory TLV missing
- Where condition detected: ANCP agent
- Further description: None
- Required additional information in the response message: The response message MUST contain a Status-Info message that encapsulates an instance of each missing mandatory TLV, where the length is set to zero and the value field is empty (i.e., only the 4-byte TLV header is present).
- Target: ANCP agent at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: Re-send the message with the missing TLV(s), if possible. Otherwise, report the error to the control application with an indication of the missing information required to construct the missing TLV(s).
Result Code value: 0x55 🫧
- One-line description: Invalid TLV contents
- Where condition detected: ANCP agent
- Further description: The contents of one or more TLVs in the request do not match the specifications provided for the those TLVs.
- Required additional information in the response message: The response MUST contain a Status-Info TLV encapsulating the erroneous TLVs copied from the original request.
- Target: ANCP agent at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: Correct the error and re-send the request, if possible. Otherwise, report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
Result Code value: 0x500 💅
- One-line description: One or more of the specified ports do not exist
- Where condition detected: Control application
- Further description (if any): This may indicate a configuration mismatch between the AN and the NAS or Authentication, Authorization, and Accounting (AAA).
- Required additional information in the response message: If the request identified multiple access lines or the response is a Generic Response message, then the response MUST contain a Status-Info TLV encapsulating TLV(s) containing the rejected line identifier(s).
- Target: Control application at the peer that sent the original request
- Action RECOMMENDED for the receiving ANCP agent: Indicate the error and forward the line identifiers to the control application.
3.6.1.5. Partition ID (8 bits) 🌷
The Partition ID field MUST contain the value that was negotiated for Partition ID during the adjacency procedure as described above 🤝
3.6.1.6. Transaction ID (24 bits) 🔁
okay the Transaction ID is set by the sender of a request message so the response can be matched back up to the original request 🫶 Unless otherwise specified for a given message type, the Transaction ID in request messages MUST be set to a value in the range (1, 2^24 - 1). When used in this manner, the Transaction ID sequencing MUST be maintained independently for each message type within each ANCP adjacency. Furthermore, it SHOULD be incremented by 1 for each new message of the given type, cycling back to 1 after running the full range. For event messages, the Transaction ID SHOULD be set to zero ✨
Unless otherwise specified, the default behavior for all ANCP responses is that the value of the Transaction ID MUST be copied from the corresponding request message 💖
3.6.1.7. I Flag and SubMessage Number (1 + 15 bits) 🦋
In GSMPv3, these provide a mechanism for message fragmentation. Because ANCP uses TCP transport, this mechanism is unnecessary. An ANCP agent MUST set the I Flag and subMessage Number fields to 1 to signify "no fragmentation" 🌈
3.6.1.8. Length (16 bits) 📏
This field MUST be set to the length of the ANCP message in bytes, including its header fields and message body but excluding the 4-byte encapsulating header defined in Section 3.2 🎀
3.6.2. The ANCP Message Body 💖
okay so the payload of an ANCP message is a total chameleon 🦎. What's inside depends on the capability it's being used for. But the general shape is always the same: zero or more fixed fields first, then a bunch of Type-Length-Value (TLV) structures stacked on top 🎀
Here's what a TLV looks like (Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: General TLV FormatOkay, here's the breakdown of the fields ✨
- Type (16 bits) 🏷️: this is an unsigned value that tells you which TLV you're looking at and what kind of stuff is inside it. There's an IANA registry set up for ANCP TLV Type codes.
- Length (16 bits) 📏: this is the number of bytes of data in the Value field, not counting any padding that's needed to get the TLV to a 4-byte word boundary (see "Value" below). If a TLV holds other TLVs, any padding inside those contained TLVs MUST be included in the value of Length. Depending on how the TLV is specified, Length can be zero, a constant for every instance of that TLV, or a varying quantity.
- Value (variable) 🎁: this is the actual data the TLV carries, if it carries any at all. The Value field in each TLV MUST be padded with zeroes as needed to line up with a 4-byte word boundary. The Value field of a TLV MAY include fixed fields and/or other TLVs.
Unless otherwise specified, TLVs MAY be added to a message in any order. If the recipient of a message doesn't understand a particular TLV, it MUST silently ignore it 🙈
A bunch of TLVs get specified in the rest of this document, so stay tuned 🦋
3.7. General Principles for the Design of ANCP Messages 🧠
ANCP gives you two ways to set up request/response interaction. Let's go:
- a. The same message type is used for both the request message and the response message. The Result and Result Code field settings are what tell the request and the response apart.
- b. The request and the response use two different message types.
The first approach shows up in the protocol specs in Section 8.4, and the second one shows up in Section 6.4. This section is here to give you more detail on that second approach, so people can use this messaging construct when they build new ANCP extensions 💅
As Section 3.6 mentioned, every ANCP message except adjacency messages shares the same common header format. When the response has a different message type than the request, the request's specification will usually say the Result field is set to Ignore (0x0), and it'll spell out exactly when the receiver should generate a response and which message type to use for it 📝
The Transaction ID field is how you tell apart multiple request messages of the same type and link a response back to its request 🔗 Specs for applications that don't need response correlation SHOULD say that the Transaction ID MUST be set to zero in requests. Applications that do need response correlation SHOULD look at the Transaction ID behavior described in Section 3.6.1.
The spec for a response message SHOULD say, in every case, that the Transaction Identifier MUST be set to whatever the corresponding request had. That's how the requester can figure out whether correlation is needed, based on whether it set a non-zero or zero value for the Transaction ID 🎯
4. Generally Useful ANCP Messages and TLVs ✨
This section defines two messages and a handful of TLVs that could be useful across multiple capabilities. Sometimes the content is kind of under-specified on purpose, since the individual capabilities are supposed to fill in the missing details 🌸
4.1. Provisioning Message 📦
The Provisioning message is sent by the NAS to the AN to provision information of global scope (basically, stuff that isn't tied to specific access lines) on the AN. It has the format shown in Figure 9. Support for the Provisioning message is OPTIONAL, unless the ANCP agent claims support for a capability that requires using it 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of the Provisioning MessageThe header field settings listed below are REQUIRED in the Provisioning message. Every other header field MUST be set as Section 3.6.1 specifies. Which TLVs go in the Provisioning message gets decided in the spec of whichever capabilities use it. The Provisioning message MAY be used to carry data for more than one capability at once, as long as those capabilities can coexist and have all been negotiated during adjacency establishment 🤝
Message Type: MUST be set to 93.Result: MUST be set to 0x0 (Ignore).Result Code: MUST be set to zero.Transaction ID: MUST be populated with a non-zero value, chosen the way Section 3.6.1.6 describes.
If the AN can process the message successfully and accept all the provisioning directives in it, the AN MUST NOT send any response. Silence is golden here 🤫
Unless a particular capability says otherwise, if the AN fails to process the message successfully, it MUST send a Generic Response message (Section 4.2) that indicates failure and includes appropriate diagnostic information 😭
4.2. Generic Response Message 🚨
This section defines the Generic Response message. The Generic Response message MAY be specified as the right response to a message defined in an ANCP extension, instead of a more specific response message. As a rule of thumb, using the Generic Response as a response makes sense when no data needs to go back to the peer besides a result (success or failure), plus, in the case of a failure, a code for the reason and a limited amount of diagnostic data 💁♀️ Depending on the use case, the Generic Response message MAY be sent by either the NAS or the AN.
Support for the Generic Response message, both as sender and as receiver, is REQUIRED for all ANCP agents, no matter which capabilities they support. Non-negotiable, bestie 💜
The AN or NAS MAY send a Generic Response message indicating a failure condition on its own, without being tied to a specific request, before closing the adjacency because of that failure. In this case, the sender MUST set the Transaction ID field in the header and the Message Type field within the Status-Info TLV to zeroes. The receiver MAY record the information in the Status-Info TLV for management use 📊
The format of the Generic Response message is shown in Figure 10.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access line identifying TLV(s) |
+ (copied from original request) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV |
~ (Section 4.5) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this
figure.
Figure 10: Structure of the Generic Response MessageThe header fields specified in this document are listed below. Every other field in the ANCP general message header MUST be set as Section 3.6.1 specifies 🎀
Message Type: MUST be set to 91.Result: MUST be set to 0x3 (Success) or 0x4 (Failure).Result Code: MUST be set to zero for success, or an appropriate non-zero value for failure.Transaction ID: MUST be copied from the message this message is responding to.
If the original request applied to a specific access line or set of lines, the TLVs identifying the line(s) and possibly the user MUST be copied into the Generic Response message at the top level 🧾
The Status-Info TLV MAY be present in a success response, to give a warning as defined for a specific request message type. It MUST be present in a failure response. See Section 4.5 for a detailed description of the Status-Info TLV. Its actual contents depend on the request message type being responded to and on the value of the Result Code field 🔍
To prevent an infinite loop of error responses, if the Generic Response message is itself in error, the receiver MUST NOT generate an error response in return. No error-ception loops allowed 🙅♀️💀
4.3. Target TLV ✨
Type: 0x1000 to 0x1020 depending on the specific content. Only 0x1000 has been assigned in this specification (see below). Support of any specific variant of the Target TLV is OPTIONAL unless the ANCP agent claims support for a capability that requires its use. 🎀
Description: okay so the Target TLV (0x1000 - 0x1020) is basically the general-purpose way to represent different kinds of objects. Very versatile, very main character 💅
Length: Variable, depending on the specific object type. 🌸
Value: Target information as defined for each object type. The Value field MAY consist of sub-TLVs. 🧚
TLV Type 0x1000 is assigned to a variant of the Target TLV that represents a single access line and wraps one or more sub-TLVs identifying the target. Figure 11 is an example of the TLV format for a single port identified by an Access-Loop-Circuit-ID TLV (0x0001) (Section 5.1.2.1). It's giving precise and it's giving clean 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example of Target TLV for Single Access Line4.4. Command TLV 🍓
Type: 0x0011
Description: the Command TLV (0x0011) is the general way to wrap one or more command directives inside a TLV-oriented message. What the command actually means gets defined for each message type that uses it. So every message type that carries the Command TLV is expected to spell out what its payload means 📝 (reusing specs is totally allowed when it makes sense, no cap). Support of any specific variant of the Command TLV is OPTIONAL unless the ANCP agent claims support for a capability that requires its use. 💖
Length: Variable, depending on the specific contents. ✨
Value: Command information as defined for each message type. The field MAY include sub-TLVs. The contents of this TLV MUST be specified as one "command" or alternatively a sequence of one or more "commands", each beginning with a 1-byte Command Code and possibly including other data following the Command Code. An IANA registry has been established for Command Code values. This document reserves the Command Code value 0 as an initial entry in the registry. 🔥
4.5. Status-Info TLV 🫶
Name: Status-Info
Type: 0x0106
Description: the Status-Info TLV is the general container for warning or error diagnostics about commands and/or requests. Think of it as the bestie who explains why something went wrong 🙈 It supplements the Result Code field in the ANCP general header. The specifications for individual message types MAY indicate the use of this TLV in responses, especially for failures. As mentioned above, the Generic Response message will usually include an instance of the Status-Info TLV. Support of the Status-Info TLV, both as sender and as receiver, is REQUIRED for all ANCP agents, regardless of what capabilities they support. 👑
Length: Variable, depending on the specific contents. 🌈
Value: the following fixed fields. On top of those, sub-TLVs MAY be appended to give even more diagnostic info. 🧚
- Reserved (8 bits): See Section 3.4 for handling of reserved fields.
- Msg Type (8 bits): Message Type of the request that this TLV is giving diagnostics for.
- Error Message Length (16 bits): Number of bytes in the error message, excluding padding, but including the language tag and delimiter. This MAY be zero if no error message is provided.
- Error Message: Human-readable string giving info about the warning or error condition. The initial characters of the string MUST be a language tag as described in [RFC5646], terminated by a colon (":"). The actual text string follows the delimiter. The field is padded at the end with zeroes as necessary to extend it to a 4-byte word boundary.
Section 3.6.1.4 gives recommendations for what TLVs to add in the Status-Info TLV for particular values of the message header Result Code field. 💅
Figure 12 illustrates the Status-Info TLV. 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4-byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Status-Info TLV5. Introduction to ANCP Capabilities for Digital Subscriber Lines (DSLs) 💜
DSL is a hugely deployed access technology for Broadband Access for Next Generation Networks. Specs like [TR-059], [TR-058], and [TR-092] describe possible architectures for these access networks. Their scope covers voice, video, and data services. 🌐
The next three sections of this document specify basic ANCP capabilities for controlling Access Nodes that serve DSL access (Tech Type = 0x05). The same ANs could be serving other access technologies (e.g., Metro-Ethernet, Passive Optical Networking, WiMax), in which case the AN will also have to support the corresponding other-technology-specific capabilities. Those additional capabilities are outside the scope of the present document. 🎀
5.1. DSL Access Line Identification 🌸
Most ANCP messages involve actions relating to a specific access line, so it's necessary to describe how access lines get identified within those messages. This section defines four TLVs for that purpose and gives an informative description of how they're used. ✨
5.1.1. Control Context (Informative) 🧠
Three types of identification are described in [TR-101] and provided for in the TLVs defined in this section:
- identification of an access line by its logical appearance on the user side of the Access Node;
- identification of an access line by its logical appearance on the NAS side of the Access Node; and
- identification down to the user or host level as a supplement to access line identification in one of the other two forms.
All of these identifiers originate with the AN control application, during the process of DSL topology discovery. The control application chooses which identifiers to use and the values to put into them on a line-by-line basis, based on AN configuration and deployment considerations. 🦋
Aside from ANCP signalling, access line identification is also used in DHCP ([RFC2131], [RFC3315]) transactions involving hosts served by DSL. Either the AN or the NAS can serve as a DHCP relay node. [TR-101] requires the AN or NAS in this role to add access line identification in Option 82 (Information) ([RFC3046], with its IPv6 equivalent in [RFC4649]) to each DHCP request it forwards to the DHCP server. It's desirable for efficiency that the identification used in this signalling be the same as the identification used in ANCP messages. 💅
From the point of view of ANCP itself, the identifiers are opaque. From the point of view of the AN control application, the syntax for the user-side access line identifier is the same as specified in Section 3.9.3 of [TR-101] for DHCP Option 82. The syntax for the ASCII form of the NAS-side access line identifier will be similar. 🫶
Access line identification by logical appearance on the user side of the Access Node will always identify a DSL access line uniquely. Identification by the logical appearance on the NAS side of the Access Node is unique only if there is a one-to-one mapping between the appearances on the two sides and no identity-modifying aggregation between the AN and the NAS. In other cases, and in particular in the case of Ethernet aggregation using the N:1 VLAN model, the user-side access line identification is necessary, but the NAS-side identification is potentially useful information that lets the NAS build up a picture of the aggregation network topology. 🌈
Additional identification down to the user or host level is intended to supplement rather than replace either of the other two forms of identification. 🍓
Sections 3.8 and 3.9 of [TR-101] are contradictory on this point. It is assumed here that Section 3.9 is meant to be authoritative. 🙈
The user-level identification takes the form of an administered string that is, again, opaque at the ANCP level. 🔥
The NAS control application will use the identifying information it receives from the AN directly for some purposes. For examples, see the introductory part of Section 3.9 of [TR-101]. For other purposes, the NAS will build a mapping between the unique access line identification provided by the AN, the additional identification of the user or host (where provided), and the IP interface on a particular host. For access lines with static IP address assignment, that mapping could be configured instead. ⭐
5.1.2. TLVs for DSL Access Line Identification 🎀
okay bestie, this is the section with the actual TLVs for DSL line identification 🦋 it's normative, so this is where ANCP agents get their marching orders ✨ the Access-Loop-Circuit-ID TLV names an access line by its logical appearance on the user side of the Access Node 💖 then there are two alternatives, the Access-Aggregation-Circuit-ID-ASCII TLV and the Access-Aggregation-Circuit-ID-Binary TLV, which name an access line by its logical appearance on the NAS side of the Access Node 🫶 ngl it's pretty unlikely an AN uses both of those, either for the same line or different lines, since they carry equivalent info 💅 and finally, the Access-Loop-Remote-ID TLV holds an operator-configured string that uniquely identifies the user on the associated access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101] 🌸
ANCP agents conforming to this section MUST satisfy the following requirements:
- ANCP agents MUST be able to build and send the Access-Loop-Circuit-ID TLV, the Access-Loop-Remote-ID TLV, and either the Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation-Circuit-ID-Binary TLV (implementation choice), when passed the associated information from the AN control application. 🧚
- ANCP agents MUST be able to receive all four TLV types, extract the relevant information, and pass it to the control application. 💜
- If the Access-Loop-Remote-ID TLV is present in a message, it MUST be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-Binary TLV with two VLAN identifiers. 🎀
bestie, pay attention to this one 👀 the Access-Loop-Remote-ID TLV is not enough to identify an access line uniquely on its own 🙈 as I said above, an Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-Binary TLV with two VLAN identifiers may or may not identify an access line uniquely, but that's up to the control application to decide ✨
- If the Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-Binary TLV is present in a message with just one VLAN identifier, it MUST be accompanied by an Access-Loop-Circuit-ID TLV. 🦋
5.1.2.1. Access-Loop-Circuit-ID TLV
Type: 0x0001
Description: a locally administered, human-readable string generated by or configured on the Access Node 🌈 it identifies the corresponding access loop logical port on the user side of the Access Node 💅
Length: up to 63 bytes
Value: ASCII string
5.1.2.2. Access-Loop-Remote-ID TLV
Type: 0x0002
Description: an operator-configured string that uniquely identifies the user on the associated access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101] 💖
Length: up to 63 bytes
Value: ASCII string
5.1.2.3. Access-Aggregation-Circuit-ID-Binary TLV
Type: 0x0006
Description: okay this TLV identifies, or partially identifies, a specific access line by its logical circuit identifier on the NAS side of the Access Node 🔥
For Ethernet access aggregation, where a per-subscriber (stacked) VLAN can be applied (1:1 model as defined in [TR-101]), the TLV contains two value fields. Each field carries a 12-bit VLAN identifier (which is part of the VLAN tag defined by [IEEE802.1Q]). The first field MUST carry the inner VLAN identifier, while the second field MUST carry the outer VLAN identifier. 🎀
When the N:1 VLAN model is used, only one VLAN tag is available. For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV contains a single value field, which MUST carry the 12-bit VLAN identifier derived from the single available VLAN tag. 🌸
In the case of an ATM aggregation network, where the DSLAM is directly connected to the NAS (without an intermediate ATM switch), the Virtual Path Identifier (VPI) and Virtual Circuit Identifier (VCI) on the DSLAM uplink correspond uniquely to the DSL access line on the DSLAM. The Access-Aggregation-Circuit-ID-Binary TLV MAY be used to carry the VPI and VCI. The first value field of the TLV MUST carry the VCI, while the second value field MUST carry the VPI. 🦋
Each identifier MUST be placed in the low-order bits of its respective 32-bit field, with the higher-order bits set to zero. The ordering of the bits of the identifier MUST be the same as when the identifier is transmitted on the wire to identify an Ethernet frame or ATM cell. 🧚
The Access-Aggregation-Circuit-ID-Binary is illustrated in Figure 13. 👑
Length: 4 or 8 bytes
Value: one or two 32-bit binary fields.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0006 | Length = 4 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single VLAN Identifier, inner VLAN identifier, or VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer VLAN identifier or VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: The Access-Aggregation-Circuit-ID-Binary TLV 🌷
5.1.2.4. Access-Aggregation-Circuit-ID-ASCII TLV
Type: 0x0003
Description: this TLV carries the ASCII equivalent of the Access-Aggregation-Circuit-ID-Binary TLV 💜 as mentioned in the previous section, the AN control application will use a format similar to the one specified in Section 3.9.3 of [TR-101] for the format of the "circuit-id" 🎀
As an extension to the present document, the Access Node could convey to the NAS the characteristics (e.g., bandwidth) of the uplink on the Access Node. This TLV, or the binary equivalent defined above, then serves the purpose of uniquely identifying the uplink whose characteristics are being defined. The present document does not specify the TLVs needed to convey the uplink characteristics. 🌈
Length: up to 63 bytes
Value: ASCII string
6. ANCP-Based DSL Topology Discovery 🧚
Section 3.1 of [RFC5851] describes the requirements for the DSL Topology Discovery capability. 💖
6.1. Control Context (Informative) 🦋
The AN control application in the DSLAM requests ANCP to send a DSL-specific Port Up message to the NAS under the following circumstances:
- when a new adjacency with the NAS is established, for each DSL loop that is synchronized at that time;
- subsequent to that, whenever a DSL access line resynchronizes; and
- whenever the AN control application wishes to signal that a line attribute has changed.
The AN control application in the DSLAM requests ANCP to send a DSL-specific Port Down message to the NAS under the following circumstances:
- when a new adjacency with the NAS is established, for each DSL loop that is provisioned but not synchronized at that time;
- whenever a DSL access line that is equipped in an AN but administratively disabled is signaled as "IDLE"; and
- subsequent to that, whenever a DSL access line loses synchronization.
The AN control application passes information to identify the DSL loop to ANCP to include in the Port Up or Port Down message, along with information relating to DSL access line attributes. 🌸
In the case of bonded copper loops to the customer premise (as per DSL multi-pair bonding described by [G.998.1] and [G.998.2]), the AN control application requests that ANCP send DSL-specific Port Up and Port Down messages for the aggregate "DSL bonded circuit" (represented as a single logical port) as well as the individual DSL access lines of which it is comprised. The information relating to DSL access line attributes that is passed by the AN control application is aggregate information. 🫶
ANCP generates the DSL-specific Port Up or Port Down message and transfers it to the NAS. ANCP on the NAS side passes an indication to the NAS control application that a DSL Port Up or Port Down message has been received, along with the information contained in the message. 🔥
The NAS control application updates its view of the DSL access line state, performs any required accounting operations, and uses any included line attributes to adjust the operation of its queuing/scheduling mechanisms as they apply to data passing to and from that DSL access line. 👑
Figure 14 summarizes the interaction. ✨
1. Home Access NAS
Gateway Node
-----------> -------------------------->
DSL Port Up (Event message)
Signal (default line parameters)
2. Home Access NAS
Gateway Node
-----------> -------------------------->
DSL Port Up (Event message)
Resynch (updated line parameters)
3. Home Access NAS
Gateway Node
-----------> -------------------------->
Loss of Port Down (Event message)
DSL Signal (selected line parameters)Figure 14: ANCP Message Flow for DSL Topology Discovery 🌈
6.2. Protocol Requirements 🎀
The DSL topology discovery capability is assigned capability type 0x0001. No capability data is associated with this capability. 💅
6.2.1. Protocol Requirements on the AN Side 🦋
The AN-side ANCP agent MUST be able to create DSL-specific Port Up and Port Down messages according to the format specified in Section 6.3. 🧚
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. 💖
The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Up and Port Down messages as they are specified in Section 6.4. 🌸
6.2.2. Protocol Requirements on the NAS Side 🫶
The NAS-side ANCP agent MUST be able to receive and validate DSL-specific Port Up and Port Down messages according to the format specified in Section 6.3. 🔥
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. 👑
The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Up and Port Down messages as they are specified in Section 6.4. ✨
6.3. ANCP Port Up and Port Down Event Message Descriptions ✨
okay bestie, here's the layout for the ANCP Port Up and Port Down Event messages 🎀 Figure 15 is giving diagram energy, so check it out:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (20 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSL-Line-Attributes TLV |
~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: Format of the ANCP Port Up and Port Down Event Messages for DSL Topology Discovery
Quick heads up on the general header: see Section 3.6.1 for the ANCP general message header. The Message Type field MUST be set to 80 for Port Up and 81 for Port Down. The 4-bit Result field MUST be set to zero (signifying Ignore). The 12-bit Result Code field and the 24-bit Transaction Identifier field MUST also be set to zeroes. Other fields in the general header MUST be set as described in Section 3.6. 💅
The five-word Unused field is a historical leftover 🙈 and the handling of unused/reserved fields is described in Section 3.4.
The remaining message fields belong to the "extension block" and work like this:
- Extension Flags (8 bits): The flag bits denoted by
xare currently unspecified and reserved. - Message Type (8 bits): Has the same value as in the general header (i.e., 80 or 81).
- Tech Type (8 bits): MUST be set to
0x05(DSL). - Reserved (8 bits): Set as described in Section 3.4.
- # of TLVs (16 bits): The number of TLVs that follow, not counting TLVs encapsulated within other TLVs.
- Extension Block Length (16 bits): The total length of the TLVs carried in the extension block in bytes, including any padding within individual TLVs.
- TLVs: One or more TLVs to identify a DSL access line and zero or more TLVs to define its characteristics.
NOTE: TLVs MAY be in a different order from what is shown in the figure, so don't panic if yours look a little different 🫶
6.4. Procedures 🌸
6.4.1. Procedures on the AN Side
The AN-side ANCP agent creates and transmits a DSL-specific Port Up or Port Down message when the AN control application asks for one and gives it the info needed to build a valid message. It is RECOMMENDED that the Access Node use a dampening mechanism per DSL access line to control the rate at which state changes are communicated to the NAS. Main character energy, controlling the flow 👑
At the top level, the extension block within a DSL-specific Port Up or Port Down message MUST include TLVs from Section 5.1.2 to identify the DSL access line.
TLVs presenting DSL access line attributes (i.e., the TLVs specified in Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV. When the DSL-Line-Attributes TLV is present in a message, it MUST contain at least one such TLV and will generally contain more than one. In the Port Up message, the DSL-Line-Attributes TLV MUST be present. In the Port Down message, the DSL-Line-Attributes TLV MAY be present. ✨
6.4.2. Procedures on the NAS Side
The NAS-side ANCP agent MUST be prepared to receive Port Up and Port Down messages for a given DSL access line or logical port at any time after negotiation of an adjacency has been completed. It is possible for two Port Up messages in succession to be received for the same DSL access line without an intervening Port Down message, and vice versa. Expect the unexpected, bestie 🦋
The NAS-side ANCP agent SHOULD validate each message against the specifications given in Section 6.3 and the TLV specifications given in Sections 5.1.2 and 6.5. If it finds an error, it MAY generate a Generic Response message containing an appropriate Result Code value. If it does so, the message MUST contain copies of all of the identifier TLVs from Section 5.1.2 that were present in the Port Up or Port Down message. The message MUST also contain a Status-Info TLV that in turn contains other information appropriate to the message header Result Code value as described in Section 3.6.1.4. Receipts, please 🧾💜
6.5. TLVs for DSL Line Attributes 🧚
As specified above, the DSL-Line-Attributes TLV is inserted into the Port Up or Port Down message at the top level. The remaining TLVs defined below are encapsulated within the DSL-Line-Attributes TLV. It's literally a TLV inside a TLV, iconic 🍓
6.5.1. DSL-Line-Attributes TLV
- Type:
0x0004 - Description: This TLV encapsulates attribute values for a DSL access line serving a subscriber.
- Length: Variable (up to 1023 bytes)
- Value: One or more encapsulated TLVs corresponding to DSL access line attributes. The DSL-Line-Attributes TLV MUST contain at least one TLV when it is present in a Port Up or Port Down message. The actual contents are determined by the AN control application.
6.5.2. DSL-Type TLV
- Type:
0x0091 - Description: Indicates the type of transmission system in use.
- Length: 4 bytes
- Value: 32-bit unsigned integer, where:
ADSL1 = 1ADSL2 = 2ADSL2+ = 3VDSL1 = 4VDSL2 = 5SDSL = 6OTHER = 0
6.5.3. Actual-Net-Data-Rate-Upstream TLV
- Type:
0x0081 - Description: Actual upstream net data rate on a DSL access line.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.4. Actual-Net-Data-Rate-Downstream TLV
- Type:
0x0082 - Description: Actual downstream net data rate on a DSL access line.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.5. Minimum-Net-Data-Rate-Upstream TLV
- Type:
0x0083 - Description: Minimum upstream net data rate desired by the operator.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.6. Minimum-Net-Data-Rate-Downstream TLV
- Type:
0x0084 - Description: Minimum downstream net data rate desired by the operator.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.7. Attainable-Net-Data-Rate-Upstream TLV
- Type:
0x0085 - Description: Maximum net upstream rate that can be attained on the DSL access line.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.8. Attainable-Net-Data-Rate-Downstream TLV
- Type:
0x0086 - Description: Maximum net downstream rate that can be attained on the DSL access line.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.9. Maximum-Net-Data-Rate-Upstream TLV
- Type:
0x0087 - Description: Maximum net upstream data rate desired by the operator.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.10. Maximum-Net-Data-Rate-Downstream TLV
- Type:
0x0088 - Description: Maximum net downstream data rate desired by the operator.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV
- Type:
0x0089 - Description: Minimum net upstream data rate desired by the operator in low power state.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV
- Type:
0x008A - Description: Minimum net downstream data rate desired by the operator in low power state.
- Length: 4 bytes
- Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.13. Maximum-Interleaving-Delay-Upstream TLV
- Type:
0x008B - Description: Maximum one-way interleaving delay.
- Length: 4 bytes
- Value: Time in ms as a 32-bit unsigned integer
6.5.14. Actual-Interleaving-Delay-Upstream TLV
- Type:
0x008C - Description: Value corresponding to the interleaver setting.
- Length: 4 bytes
- Value: Time in ms as a 32-bit unsigned integer
6.5.15. Maximum-Interleaving-Delay-Downstream TLV
- Type:
0x008D - Description: Maximum one-way interleaving delay.
- Length: 4 bytes
- Value: Time in ms as a 32-bit unsigned integer
6.5.16. Actual-Interleaving-Delay-Downstream
- Type:
0x008E - Description: Value corresponding to the interleaver setting.
- Length: 4 bytes
- Value: Time in ms as a 32-bit unsigned integer
6.5.17. DSL-Line-State TLV
- Type:
0x008F - Description: The state of the DSL access line.
- Length: 4 bytes
- Value: 32-bit unsigned integer, where:
SHOWTIME = 1IDLE = 2SILENT = 3
6.5.18. Access-Loop-Encapsulation TLV
- Type:
0x0090 - Description: The data link protocol and, optionally, the encapsulation overhead on the access loop. When this TLV is present, at least the data link protocol MUST be indicated. The encapsulation overhead MAY be indicated. The Access Node MAY choose to not convey the encapsulation on the access loop by specifying values of 0 (NA) for the two encapsulation fields.
- Length: 3 bytes
- Value: The 3 bytes (most to least significant) and valid set of values for each byte are defined as follows:
- Byte 1: Data Link
ATM AAL5 = 0ETHERNET = 1
- Byte 2: Encapsulation 1
NA = 0Untagged Ethernet = 1Single-tagged Ethernet = 2Double-tagged Ethernet = 3
- Byte 3: Encapsulation 2
NA = 0PPPoA LLC = 1PPPoA Null = 2IPoA LLC = 3IPoA Null = 4Ethernet over AAL5 LLC with FCS = 5Ethernet over AAL5 LLC without FCS = 6Ethernet over AAL5 NULL with FCS = 7Ethernet over AAL5 NULL without FCS = 8
- Byte 1: Data Link
The Access-Loop-Encapsulation TLV is illustrated in Figure 16, and yes, it's a whole vibe 💖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0090 | Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data link | Encaps 1 | Encaps 2 | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: The Access-Loop-Encapsulation TLV
7. ANCP-Based DSL Line Configuration 💜
The use case for ANCP-based DSL Line Configuration is described in Section 3.2 of [RFC5851]. Okay, that's the whole vibe, and it's iconic 🌈
7.1. Control Context (Informative) ✨
Okay so picture this, bestie 🫶 When topology info reports a brand-new DSL access line, or a subscriber starts a session (via PPP or DHCP), RADIUS/AAA sends the service parameters down to the NAS control application so they can be set on the access line. The NAS control application passes that request to the NAS-side agent, which sends the info to the AN in a Port Management (line configuration) message. Then the AN-side agent hands it up to the AN control application, which applies it to the line. 💅 Figure 17 shows the whole flow.
Home Access NAS RADIUS/AAA
Gateway Node Policy Server
-----------> --------------->
DSL Port Up message)
Signal (line parameters)
--------------------------------> -------------->
PPP/DHCP Session Authentication &
authorization
<----------------
Port Management message
(line configuration)
Figure 17: Message Flow - ANCP Mapping for Initial Line ConfigurationThe NAS could also update the line configuration after a subscriber service change (for example, when the policy server triggers it). 🌸 Figure 18 shows that one.
User Home Access NAS
Gateway Node
-------------------------->
PPP/DHCP Session
----------------------------------------------------> Web portal,
Service on demand OSS, etc.
|
<----------- RADIUS/AAA
Change of Policy Server
authorization
<------------
Port Management
message
(new profile)
OSS: Operations Support System
Figure 18: Message Flow - ANCP Mapping for Updated Line Configuration7.2. Protocol Requirements ✨
The DSL access line configuration capability is assigned capability type 0x0002. No capability data is associated with this one, so no extra data to worry about 🎀
7.2.1. Protocol Requirements on the NAS Side 🌈
The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (line configuration) messages in the format given in Section 7.3. 💖
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. No skipping! 🙈
The NAS-side ANCP agent MUST follow the NAS-side procedures for DSL-specific Port Management (line configuration) messages as they are specified in Section 7.4. ✨
7.2.2. Protocol Requirements on the AN Side 🦋
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. Same energy as the NAS side, periodt 💅
The AN-side ANCP agent MUST be able to receive and validate DSL-specific Port Management (line configuration) messages in the format given in Section 7.3. 🧚
The AN-side ANCP agent MUST follow the AN-side procedures for DSL-specific Port Management (line configuration) messages as specified in Section 7.4. 👑
7.3. ANCP Port Management (Line Configuration) Message Format 🎀
Here's the DSL line config Port Management message, and it's giving layout 😭 It looks like this (Figure 19):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (12 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=8 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Line configuration TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this
figure.
Figure 19: Port Management Message for DSL Line ConfigurationCheck out the ANCP general header in Section 3.6, bestie 🧚 The Message Type field MUST be set to 32. The 12-bit Result Code field MUST be set to 0x0. The 4-bit Result field MUST be set to either 0x1 (Nack) or 0x2 (AckAll), depending on what the NAS policy says. The 24-bit Transaction Identifier field MUST be set to a positive value. Every other general header field MUST be set as described in Section 3.6. 💜
For the unused and reserved fields, look at Section 3.4. It's the handling guide, no cap 🍓
Now the remaining message fields, one by one:
Function(8 bits): The action to perform. For line configuration, Function MUST be set to8(Configure Connection Service Data). This action asks the Access Node (aka the DSLAM) to apply the service config data in the line configuration TLVs to the DSL access line that the access line identifying TLVs point to. 🔥X-Function(8 bits): Qualifies the action set by Function. For DSL access line config, this field MUST be set to0. 🌸Extension Flags(8 bits): The flag bits marked 'x' before the Message Type field are reserved for future use. 🌈Message Type(8 bits): Same value as in the general header, which is32. ⭐Reserved(16 bits): Reserved for future use. 🦋# of TLVs(16 bits): The number of TLVs that follow, not counting TLVs nested inside other TLVs. 🎀Extension Block Length(16 bits): The total length, in bytes, of the TLVs in the extension block, including any padding inside individual TLVs. 🧚TLVs: Two or more TLVs that identify a DSL access line and configure its service data. 👑
Other ANCP capabilities, whether DSL-specific or technology-independent, MAY reuse the Port Management message for service configuration. 🫶 If the fixed fields match the settings we just covered, the same Port Management message used for DSL line config MAY also carry TLVs for other capabilities that apply to that same DSL access line. Lowkey genius 🧠✨
Using the Port Management message for configuration MAY also be generalized to other access technologies, as long as those capabilities specify access line identifiers that fit those technologies in place of the identifiers defined in Section 5.1.2. 🌈
7.4. Procedures 💅
Service configuration MAY be performed on an access line regardless of its current state. Iconic, no restrictions 👑
7.4.1. Procedures on the NAS Side 🎀
When the NAS control application asks for it, and the NAS-side agent has the info it needs, the NAS-side agent MUST create and send a Port Management message with the fixed fields set as described in the previous section. 💖 The message MUST contain one or more TLVs that identify an access line, following the requirements of Section 5.1.2. The NAS MUST also include one or more TLVs that configure the line's service parameters. Right now Section 7.5 only defines one of those, Service-Profile-Name, but other TLVs MAY be added by ANCP extensions. 🦋
7.4.2. Procedures on the AN Side 🧚
The AN-side ANCP agent MUST be prepared to receive Port Management (line configuration) messages for a given DSL access line or logical port at any time after an adjacency has been negotiated. ✨
The AN-side ANCP agent SHOULD validate each message against the specifications in Section 7.3 and the TLV specifications in Sections 5.1.2 and 7.5. If it finds an error, it MUST return a Port Management response message that copies the Port Management request exactly as it was received, except the Result header field is set to 0x04 (Failure) and the Result Code field is set to the appropriate value. 😭 The AN-side agent MAY add a Status-Info TLV (Section 4.5) to give more detail about the error, especially if Section 3.6.1.4 recommends it for the given Result Code value. If it does add one, the various length fields and the # of TLVs field in the message MUST be adjusted to match. 🫶
7.5. TLVs for DSL Line Configuration 🌸
Right now, only the following TLV is specified for DSL access line configuration. More TLVs may be defined in a future version of this specification, or in ANCP extensions for individual service attributes of a DSL access line (for example, rates, interleaving delay, or a multicast channel entitlement access-list). 💜
7.5.1. Service-Profile-Name TLV 🍓
Type: 0x0005
Description: A reference to a pre-configured profile on the DSLAM that holds service-specific data for the subscriber. 🌈
Length: Up to 64 bytes
Value: An ASCII string containing the profile name, which the NAS learns from a policy server after a subscriber is authorized. 🔥
8. ANCP-Based DSL Remote Line Connectivity Testing 🦋
The use case and requirements for ANCP-Based DSL remote line connectivity testing are specified in Section 3.3 of [RFC5851]. Okay, testing is coming up next and I am SO ready 🧚💖
8.1. Control Context (Informative) 💅
okay so the NAS control application is the one that kicks off a remote connectivity test for a given access line 🦋 It can bring its own loop count and timeout parameters, plus some opaque data for its own use. The loop count is how many test messages or cells get used, and the timeout is the longest the NAS control app is willing to wait for a result ⏳
The request rides in a Port Management (Operations, Administration, and Maintenance, OAM) message 📨 If the NAS supplied test parameters, the AN uses those. If not, the AN control app falls back to its default test parameters 🫶 If the NAS's loop count is outside the valid range, the AN doesn't run the test at all. It sends back a result saying the test failed due to an invalid parameter 💀 If the test runs longer than the timeout (default or NAS-provided), the AN control app can return a failure result that says timeout, or it can just… not reply 🙈 The AN control app can also attach a human-readable string describing the results, whether it passed or failed. If it does, that string goes in the response. Responses always carry back whatever opaque data the NAS sent, if any 💜
Figure 20 summarizes the whole interaction 👑
+-------------+ +-----+ +-------+ +----------------+
|Radius/AAA |----|NAS |------| DSLAM |----------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ |Routing Gateway)|
+----------------+
Port Management Message
(Remote Loopback ATM loopback
Trigger Request) or EFM Loopback
1. ----------------> 2. -------->
<-------+
3. <---------------
Port Management Message
(Remote Loopback Test Response)
CPE: Customer Premises Equipment
EFM: Ethernet First MileFigure 20: Message Flow for ANCP-Based OAM
8.2. Protocol Requirements 🌸
The DSL remote line connectivity testing capability is assigned capability type 0x0004. No capability data is associated with this capability ✨
8.2.1. Protocol Requirements on the NAS Side 💖
The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (OAM) messages according to the format in Section 8.3. That's a must-have, bestie 💅
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
The NAS-side ANCP agent MUST follow the NAS-side procedures for DSL-specific Port Management (OAM) messages, as specified in Section 8.4. 🎀
8.2.2. Protocol Requirements on the AN Side 🧚
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2.
The AN-side ANCP agent MUST be able to receive and validate DSL-specific Port Management (OAM) messages according to the format in Section 8.3.
The AN-side ANCP agent MUST follow the AN-side procedures for DSL-specific Port Management (OAM) messages, as specified in Section 8.4. 🔥
8.3. Port Management (OAM) Message Format 🎀
The Port Management message for DSL access line testing has the same format as the one for DSL access line configuration (see Section 7.3), with a few differences 👀
- The
Resultfield in the request SHOULD be set to AckAll (0x2), so the NAS can actually receive the info from a successful test response 🧾 - The
Functionfield MUST be set to 9 (Remote Loopback). TheX-Functionfield stays at 0 🙌 - The appended TLVs in the extension value field are testing-related TLVs now, not subscriber service info 📦
The Port Management (OAM) message is illustrated in Figure 21 ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 3.6.1) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unused (12 bytes) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (2 bytes) | Function=9 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access line identifying TLV(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Testing-related TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+NOTE: TLVs MAY be in a different order from what is shown in this figure. 🙃
Figure 21: Port Management Message for DSL Line Remote Connectivity Testing
8.4. Procedures 🦋
From ANCP's point of view, it's permissible to attempt line connectivity testing regardless of the state of the line. Just know that testing could fail in some states because of technology limitations 🫶
8.4.1. NAS-Side Procedures 💅
When the NAS control application asks for it and the NAS-side agent has the info it needs, the agent creates and sends a Port Management (OAM) request with the fixed fields set the way the previous section described 🚀 The message MUST contain one or more TLVs that identify an access line, following the requirements of Section 5.1.2 🔒 The NAS MAY include the Opaque-Data TLV and/or the OAM-Loopback-Test-Parameters TLV (defined in Section 8.5) to configure the loopback test for that line 🧚
8.4.2. AN-Side Procedures 🌈
The AN-side ANCP agent SHOULD validate each message against the specifications in Section 8.3 and the TLV specifications in Sections 5.1.2 and 8.5. If it finds an error, it MUST return a Port Management response that copies the Port Management request as it was received, but with the Result header field set to 0x04 (Failure) and the Result Code field set to the appropriate value. Result Code value 0x509 (described below) MAY apply, along with the other Result Code values documented in Section 3.6.1.4. Result Code value 0x509 SHOULD be used if the OAM-Loopback-Test-Parameters TLV is present with an invalid value of the Count field. The AN-side agent MAY add a Status-Info TLV (Section 4.5) to provide further information on the error, particularly if this is recommended in Section 3.6.1.4 for the given Result Code value. If it does so, the various length fields and the # of TLVs field within the message MUST be adjusted accordingly 📏
If the received message passes validation, the AN-side ANCP agent extracts the information from the TLVs and presents it to the AN control application. It MUST NOT generate an immediate response to the request. Instead, it MUST wait for the AN control application to indicate that the response should be sent 🙅♀️
When the AN control application asks for it and has the necessary info, the AN-side agent creates and sends a Port Management (OAM) response to the original request. The Result field MUST be set to Success (0x3) or Failure (0x4), and the Result Code field SHOULD be set to one of the following values, as indicated by the AN control application 🧾
0x500: Specified access line does not exist. See the documentation of Result Code0x500in Section 3.6.1.4 for more information. TheResultheader field MUST be set to Failure (0x4).0x501: Loopback test timed out. TheResultheader field MUST be set to Failure (0x4).0x503: DSL access line status showtime0x504: DSL access line status idle0x505: DSL access line status silent0x506: DSL access line status training0x507: DSL access line integrity error0x508: DSLAM resource not available. TheResultheader field MUST be set to Failure (0x04).0x509: Invalid test parameter. TheResultheader field MUST be set to Failure (0x4).
All other fields of the request, including the TLVs, MUST be copied into the response unchanged, except that in a successful response the OAM-Loopback-Test-Parameters TLV MUST NOT appear. If the AN control application has provided the necessary information, the AN-side agent MUST also include an instance of the OAM-Loopback-Test-Response-String TLV in the response. periodt 💖
8.5. TLVs for the DSL Line Remote Connectivity Testing Capability 👑
The following TLVs have been defined for use with the DSL access line testing capability 🌸
8.5.1. OAM-Loopback-Test-Parameters TLV ✨
Type: 0x0007
Description: Parameters intended to override the default values for this loopback test.
Length: 2 bytes
Value: Two unsigned 1-byte fields, described below (listed in order of most to least significant).
- Byte 1: Count. Number of loopback cells/messages that should be generated on the local loop as part of the loopback test. The Count value SHOULD be greater than 0 and less than or equal to 32.
- Byte 2: Timeout. Upper bound on the time in seconds that the NAS will wait for a response from the DSLAM. The value 0 MAY be used to indicate that the DSLAM MUST use a locally determined value for the timeout.
The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 22 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0007 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Timeout | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 22: The OAM-Loopback-Test-Parameters TLV
8.5.2. Opaque-Data TLV 🫧
Type: 0x0008
Description: An 8-byte opaque field used by the NAS control application for its own purposes (e.g., response correlation). The procedures in Section 8.4.2 ensure that if it is present in the request, it is copied unchanged to the response.
Length: 8 bytes
Value: Two 32-bit unsigned integers.
8.5.3. OAM-Loopback-Test-Response-String TLV ✨
okay bestie, this TLV is the operator's little souvenir 🎀 💅
- Type:
0x0009 - Length: up to
128bytes - Value: a UTF-8 encoded string of text
The Description is what makes this one iconic 💖 It's a nicely formatted string with useful details about the test, and the NAS shows it to the operator exactly as it came from the DSLAM. The NAS does zero manipulation or interpretation. No editing, no "helpful" rewriting, just pure pass-through 🫶
9. IANA Considerations 🌸
This section lists the IANA actions. ngl it's a lot of registry drama, but here's the lineup:
- establishment of the following new ANCP registries:
- ANCP Message Types;
- ANCP Result Codes;
- ANCP Port Management Functions;
- ANCP Technology Types;
- ANCP Command Codes;
- ANCP TLV Types;
- ANCP Capabilities.
- establishment of a new joint GSMP/ANCP version registry;
- addition of ANCP as another user of TCP port
6068in the port number registry available fromhttp://www.iana.org. The current user is GSMP.
All of these get explained in detail below, except for the port registration. The last bullet already gives everything you need for that one, so it's giving efficiency 🧚
10. IANA Actions 👑
10.1. ANCP Message Type Registry 🦋
IANA made a brand new registry called ANCP Message Types. New entries can be added by Standards Action, as defined by [RFC5226]. The values for Message Type MAY range from 0 to 255, but new Message Types SHOULD be assigned values sequentially from 90 onwards (noting that 91 and 93 are already taken). Here's the starting roster:
+--------------+--------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------+-----------+
| 10 | Adjacency Protocol | RFC 6320 |
| 32 | Port Management | RFC 6320 |
| 80 | Port Up | RFC 6320 |
| 81 | Port Down | RFC 6320 |
| 85 | Adjacency Update | RFC 6320 |
| 91 | Generic Response | RFC 6320 |
| 93 | Provisioning | RFC 6320 |
+--------------+--------------------+-----------+10.2. ANCP Result Code Registry 🍓
IANA also made the ANCP Result Codes registry. Anyone documenting a new Result Code MUST include the following information:
- Result Code value (as assigned by IANA);
- One-line description;
- Where condition detected (control application or ANCP agent);
- Further description (if any);
- Required additional information in the response message;
- Target (control application or ANCP agent at the peer that sent the original request);
- Action RECOMMENDED for the receiving ANCP agent.
The values are written in hexadecimal and MAY range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is allocated by IETF Review, as defined by [RFC5226]. IANA SHOULD allocate new Result Code values from this range sequentially, beginning at 0x100. The range 0x1000 onwards is allocated by Specification Required, as defined by [RFC5226]. IANA SHOULD allocate new Result Code values from this range sequentially, beginning at 0x1000. The initial contents of the ANCP Message Types registry are as follows:
+------------+------------------------------------------+-----------+
| Result | One-line description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x0 | No result | RFC 6320 |
| 0x2 | Invalid request message | RFC 6320 |
| 0x6 | One or more of the specified ports are | RFC 6320 |
| | down | |
| 0x13 | Out of resources | RFC 6320 |
| 0x51 | Request message type not implemented | RFC 6320 |
| 0x53 | Malformed message | RFC 6320 |
| 0x54 | Mandatory TLV missing | RFC 6320 |
| 0x55 | Invalid TLV contents | RFC 6320 |
| 0x500 | One or more of the specified ports do | RFC 6320 |
| | not exist | |
| 0x501 | Loopback test timed out | RFC 6320 |
| 0x502 | Reserved | RFC 6320 |
| 0x503 | DSL access line status showtime | RFC 6320 |
| 0x504 | DSL access line status idle | RFC 6320 |
| 0x505 | DSL access line status silent | RFC 6320 |
| 0x506 | DSL access line status training | RFC 6320 |
| 0x507 | DSL access line integrity error | RFC 6320 |
| 0x508 | DSLAM resource not available | RFC 6320 |
| 0x509 | Invalid test parameter | RFC 6320 |
+------------+------------------------------------------+-----------+10.3. ANCP Port Management Function Registry 🧚
IANA created the ANCP Port Management Function registry, starting with the entries below. New additions come by Standards Action, as defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD assign values sequentially beginning with 1, taking account of the values already assigned below.
NOTE: Future extensions of ANCP may need to establish sub-registries of permitted X-Function values for specific values of Function.
+----------------+-----------------------------------+-----------+
| Function Value | Function Name | Reference |
+----------------+-----------------------------------+-----------+
| 0 | Reserved | RFC 6320 |
| 8 | Configure Connection Service Data | RFC 6320 |
| 9 | Remote Loopback | RFC 6320 |
+----------------+-----------------------------------+-----------+10.4. ANCP Technology Type Registry 🌈
IANA created the ANCP Technology Type registry, where additions come by Expert Review, as defined by [RFC5226]. Each Technology Type MUST designate a distinct access transport technology. Values may range from 0 to 255. IANA SHOULD assign new values sequentially beginning at 2, taking account of the values already assigned below. The initial entries look like this:
+-----------------+-------------------------------+-----------+
| Tech Type Value | Tech Type Name | Reference |
+-----------------+-------------------------------+-----------+
| 0 | Not technology dependent | RFC 6320 |
| 1 | Passive Optical Network (PON) | RFC 6320 |
| 5 | Digital Subscriber Line (DSL) | RFC 6320 |
| 255 | Reserved | RFC 6320 |
+-----------------+-------------------------------+-----------+10.5. ANCP Command Code Registry ⭐
IANA created the ANCP Command Code registry, with additions by Standards Action, as defined by [RFC5226]. Values may range from 0 to 255. IANA SHOULD assign new values sequentially beginning with 1. There's just one entry to start:
+--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+
| 0 | Reserved | RFC 6320 |
+--------------------+-----------------------------+-----------+10.6. ANCP TLV Type Registry 💜
IANA created the ANCP TLV Type registry. Values are written in hexadecimal and may range from 0x0000 to 0xFFFF. Additions in the range 0x0000 to 0x1FFF are by IETF Review, as defined by [RFC5226]. IANA SHOULD assign new values in this range sequentially, beginning at 0x100, taking account of the assignments already made below. Additions in the range 0x2000 to 0xFFFF are by Specification Required, again as defined by [RFC5226]. IANA SHOULD assign new values in this range sequentially, beginning at 0x2000. In both cases, the documentation of the TLV MUST provide:
- a TLV name following the convention used for the initial entries (capitalized words separated by hyphens);
- a brief description of the intended use;
- a precise description of the contents of each fixed field, including its length, type, and units (if applicable);
- identification of any mandatory encapsulated TLVs;
- an indication of whether optional TLVs may be encapsulated, with whatever information is available on their identity (could range from a general class of information to specific TLV names, depending on the nature of the TLV being defined).
The initial entries are as follows:
+----------+--------------------------------------------+-----------+
| Type Code| TLV Name | Reference |
+----------+--------------------------------------------+-----------+
| 0x0000 | Reserved | RFC 6320 |
| 0x0001 | Access-Loop-Circuit-ID | RFC 6320 |
| 0x0002 | Access-Loop-Remote-ID | RFC 6320 |
| 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFC 6320 |
| 0x0004 | DSL-Line-Attributes | RFC 6320 |
| 0x0005 | Service-Profile-Name | RFC 6320 |
| 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFC 6320 |
| 0x0007 | OAM-Loopback-Test-Parameters | RFC 6320 |
| 0x0008 | Opaque-Data | RFC 6320 |
| 0x0009 | OAM-Loopback-Test-Response-String | RFC 6320 |
| 0x0011 | Command | RFC 6320 |
| 0x0081 | Actual-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0082 | Actual-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0083 | Minimum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0084 | Minimum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0085 | Attainable-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0086 | Attainable-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0087 | Maximum-Net-Data-Rate-Upstream | RFC 6320 |
| 0x0088 | Maximum-Net-Data-Rate-Downstream | RFC 6320 |
| 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstream | RFC 6320 |
| 0x008A | Minimum-Net-Low-Power-Data-Rate-Downstream | RFC 6320 |
| 0x008B | Maximum-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008C | Actual-Interleaving-Delay-Upstream | RFC 6320 |
| 0x008D | Maximum-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008E | Actual-Interleaving-Delay-Downstream | RFC 6320 |
| 0x008F | DSL-Line-State | RFC 6320 |
| 0x0090 | Access-Loop-Encapsulation | RFC 6320 |
| 0x0091 | DSL-Type | RFC 6320 |
| 0x0106 | Status-Info | RFC 6320 |
| 0x1000 | Target (single access line variant) | RFC 6320 |
| 0x1001 - | Reserved for Target variants | RFC 6320 |
| 0x1020 | | |
+----------+--------------------------------------------+-----------+10.7. ANCP Capability Type Registry ✨
okay bestie, IANA made a brand new ANCP Capability Type registry 🗂️💖 Any additions go in through Standards Action, the process defined in [RFC5226]. Values can be anywhere from 0 to 255, and IANA SHOULD hand them out one after another starting at 5 🔢 Every capability's spec MUST say which Technology Type value it goes with, and it MUST also say whether that capability comes with any capability data 📋 Normally a capability gets defined in the same document that explains how it's implemented in protocol terms, so it's all in one place 🦋 Here are the starter entries, no cap they're iconic:
+-------+------------------------+--------+-------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+------------------------+--------+-------------+-----------+
| 0 | Reserved | | | RFC 6320 |
| 1 | DSL Topology Discovery | 5 | No | RFC 6320 |
| 2 | DSL Line Configuration | 5 | No | RFC 6320 |
| 3 | Reserved | | | RFC 6320 |
| 4 | DSL Line Testing | 5 | No | RFC 6320 |
+-------+------------------------+--------+-------------+-----------+10.8. Joint GSMP / ANCP Version Registry 🌈
IANA also made a joint GSMP / ANCP Version registry 💜 New entries come in by Standards Action as defined in [RFC5226], and values range from 0 to 255 again 🫶 The General Switch Management Protocol (GSMP) side MUST be assigned in order, picking up at 4 for the next version 🔥 The Access Network Control Protocol (ANCP) side MUST be assigned in order too, starting at 50 for the current version ✨ Here's the starting lineup:
+---------+----------------+-----------+
| Version | Description | Reference |
+---------+----------------+-----------+
| 1 | GSMP Version 1 | RFC 1987 |
| 2 | GSMP Version 2 | RFC 2297 |
| 3 | GSMP Version 3 | RFC 3292 |
| 50 | ANCP Version 1 | RFC 6320 |
+---------+----------------+-----------+11. Security Considerations 🔐💀
okay this part is SERIOUS, bestie 😭 ANCP security is covered in [RFC5713], and Section 8 of that document lists a bunch of security requirements. The ones that apply to ANCP itself got copied over into this document, so here they are, no cap:
- The protocol solution MUST offer authentication of the AN to the NAS.
- The protocol solution MUST offer authentication of the NAS to the AN.
- The protocol solution MUST allow authorization to take place at the NAS and the AN.
- The protocol solution MUST offer replay protection.
- The protocol solution MUST provide data-origin authentication.
- The protocol solution MUST be robust against denial-of-service (DoS) attacks. In this context, the protocol solution MUST consider a specific mechanism for the DoS that the user might create by sending many IGMP messages.
- The protocol solution SHOULD offer confidentiality protection.
- The protocol solution SHOULD ensure that operations in default configuration guarantee a low number of AN/NAS protocol interactions.
Most of these requirements are about secure transport for ANCP 🚚 DoS robustness is partly a transport thing and partly a protocol design thing 🧠 Keeping the number of AN/NAS protocol interactions low in default mode is purely protocol design, bestie 💅
For secure transport, either IPsec with IKEv2 (refs below) or TLS [RFC5246] will meet the requirements above 🦋 BUT the team rejected TLS 💀 The deciding point was a protocol design detail that didn't exist yet when [RFC5713] was written 📜 The ANCP adjacency is a huge DoS target. If someone shuts the adjacency down, then either the AN clears its state while it waits to re-establish the adjacency, or the AN's and NAS's views of the state on the AN can drift apart and mismatch 😭 There are two ways to take an adjacency down: modify messages so the ANCP agents decide they're no longer synchronized, or attack the underlying TCP session 🙈 TLS protects message contents but NOT the TCP connection, so you need either IPsec or the TCP authentication option [RFC5925] for that 🔒 Which is why the conclusion is that ANCP MUST run over IPsec with IKEv2 for authentication and key management 👑
Here's the deeper dive 🤓 The ANCP stack MUST include IPsec [RFC4301] running in transport mode, since the AN and NAS are the endpoints of the path 🛤️ The Encapsulating Security Payload (ESP) [RFC4303] MUST be used so the data confidentiality requirement gets met 🎀 ESP MUST be configured for the combination of confidentiality, integrity, and anti-replay capability ✨ The traffic flow confidentiality service of ESP is unnecessary and, honestly, unworkable for ANCP 🙅♀️
IKEv2 [RFC5996] is ALSO REQUIRED, to meet the mutual authentication and authorization requirements 🫶 The NAS and AN MAY be in different trust domains, so using certificates for mutual authentication could be the most practical move 🧚 But that's up to the operator(s) involved, bestie 🍓
The AN MUST play the role of initiator of the IKEv2 conversation 🎬
12. Contributors 💜
Swami Subramanian was an early member of the authors' team 🌸 The ANCP Working Group is super grateful to Roberta Maglione, who was a design team member and the primary editor of this document for two years before stepping down 🫶
13. Acknowledgements 🌟
The authors want to thank everyone who dropped comments or inputs on this document 💖 They acknowledge the inputs from Wojciech Dec, Peter Arberg, Josef Froehler, Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic 🦋 They also got further comments from Mykyta Yevstifeyev, Brian Carter, Ben Campbell, Alexey Melnikov, Adrian Farrel, Robert Sparks, Peter St. Andre, Sean Turner, Dan Romascanu, Brian Carter, and Michael Scott 🎀 Iconic group of people, fr fr 👑
14. References 📚
14.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
- [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
14.2. Informative References
- [G.993.2] "ITU-T Recommendation G.993.2, Very high speed digital subscriber line transceivers 2 (VDSL2)", 2006.
- [G.998.1] "ITU-T Recommendation G.998.1, ATM-based multi-pair bonding", 2005.
- [G.998.2] "ITU-T Recommendation G.998.2, Ethernet-based multi-pair bonding,", 2005.
- [IEEE802.1Q] IEEE, "IEEE 802.1Q-2005, IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Revision", 2005.
- [IEEE802.1ad] IEEE, "IEEE 802.1ad-2005, Amendment to IEEE 802.1Q-2005. IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Revision - Amendment 4: Provider Bridges", 2005.
- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
- [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
- [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010.
- [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
- [TR-058] Broadband Forum, "TR-058, Multi-Service Architecture & Framework Requirements", September 2003.
- [TR-059] Broadband Forum, "TR-059, DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", September 2003.
- [TR-092] Broadband Forum, "TR-092, Broadband Remote access server requirements document", 2005.
- [TR-101] Broadband Forum, "TR-101, Architecture & Transport: Migration to Ethernet Based DSL Aggregation", 2005.
- [TR-147] Broadband Forum, "TR-147, Layer 2 Control Mechanism For Broadband Multi-Service Architectures", 2008.
- [US_ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X.34, 1986.
Authors' Addresses 🏡
Sanjay Wadhwa
Alcatel-Lucent
701 E Middlefield Rd
Mountain View, CA 94043-4079
USA
EMail: sanjay.wadhwa@alcatel-lucent.com
Jerome Moisand
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
EMail: jmoisand@juniper.net
Thomas Haag
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt 64295
Germany
EMail: haagt@telekom.de
Norbert Voigt
Nokia Siemens Networks
Siemensallee 1
Greifswald 17489
Germany
EMail: norbert.voigt@nsn.com
Tom Taylor (editor)
Huawei Technologies
1852 Lorraine Ave
Ottawa
Canada
EMail: tom111.taylor@bell.netThat's the whole spec, bestie! 🌈✨ You just made it through ANCP's IANA registries, its security section, and every reference 💅 Iconic behaviour. Periodt 👑
📦 where this page comes from
- ietf: rfc6320 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms