RFC 8772
The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)
RFC 8772 🎀 The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)
Okay bestie, this one is an Informational RFC from the Independent Submission stream, published in May 2020 ✨. It's RFC 8772 with ISSN 2070-1721. The authors are S. Hu (China Mobile), D. Eastlake 3rd (Futurewei Technologies), F. Qin (China Mobile), T. Chua (Singapore Telecommunications), and D. Huang (ZTE) 🫶. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 💅
Abstract
So a Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router, and it's where all the subscriber traffic gets aggregated 🌸. Control and User Plane Separation (CUPS) for a BNG makes things more flexible and scalable, but the User Plane (UP) and the Control Plane (CP) have to talk to each other a lot, lowkey a LOT 😭. China Mobile, Huawei Technologies, and ZTE built a simple CUPS control channel protocol for that conversation: the Simple Control and User Plane Separation Protocol (S-CUSP) 🦋. This document is where S-CUSP gets defined.
This document is not an IETF standard and it doesn't have IETF consensus, so no pressure 🙈. S-CUSP is shared here so the Internet community can easily get the spec, diagnose stuff, and make sure different implementations actually work together 🧚
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes ✨
This is a contribution to the RFC Series, independent of any other RFC stream 💜. The RFC Editor chose to publish it at their discretion, and they make no statement about whether it's good to implement or deploy. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, so see Section 2 of RFC 7841 for the details 💅
Information about the current status of this document, any errata, and how to send feedback on it can be found at https://www.rfc-editor.org/info/rfc8772 🌈
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document 📜
Table of Contents
1. Introduction
2. Terminology
2.1. Implementation Requirement Keywords
2.2. Terms
3. BNG CUPS Overview
3.1. BNG CUPS Motivation
3.2. BNG CUPS Architecture Overview
3.3. BNG CUPS Interfaces
3.3.1. Service Interface (Si)
3.3.2. Control Interface (Ci)
3.3.3. Management Interface (Mi)
3.4. BNG CUPS Procedure Overview
4. S-CUSP Protocol Overview
4.1. Control Channel Procedures
4.1.1. S-CUSP Session Establishment
4.1.2. Keepalive Timer and DeadTimer
4.2. Node Procedures
4.2.1. UP Resource Report
4.2.2. Update BAS Function on Access Interface
4.2.3. Update Network Routing
4.2.4. CGN Public IP Address Allocation
4.2.5. Data Synchronization between the CP and UP
4.3. Subscriber Session Procedures
4.3.1. Create Subscriber Session
4.3.2. Update Subscriber Session
4.3.3. Delete Subscriber Session
4.3.4. Subscriber Session Events Report
5. S-CUSP Call Flows
5.1. IPoE
5.1.1. DHCPv4 Access
5.1.2. DHCPv6 Access
5.1.3. IPv6 Stateless Address Autoconfiguration (SLAAC) Access
5.1.4. DHCPv6 and SLAAC Access
5.1.5. DHCP Dual-Stack Access
5.1.6. L2 Static Subscriber Access
5.2. PPPoE
5.2.1. IPv4 PPPoE Access
5.2.2. IPv6 PPPoE Access
5.2.3. PPPoE Dual-Stack Access
5.3. WLAN Access
5.4. L2TP
5.4.1. L2TP LAC Access
5.4.2. L2TP LNS IPv4 Access
5.4.3. L2TP LNS IPv6 Access
5.5. CGN (Carrier Grade NAT)
5.6. L3 Leased Line Access
5.6.1. Web Authentication
5.6.2. User Traffic Trigger
5.7. Multicast Service Access
6. S-CUSP Message Formats
6.1. Common Message Header
6.2. Control Messages
6.2.1. Hello Message
6.2.2. Keepalive Message
6.2.3. Sync_Request Message
6.2.4. Sync_Begin Message
6.2.5. Sync_Data Message
6.2.6. Sync_End Message
6.2.7. Update_Request Message
6.2.8. Update_Response Message
6.3. Event Message
6.4. Report Message
6.5. CGN Messages
6.5.1. Addr_Allocation_Req Message
6.5.2. Addr_Allocation_Ack Message
6.5.3. Addr_Renew_Req Message
6.5.4. Addr_Renew_Ack Message
6.5.5. Addr_Release_Req Message
6.5.6. Addr_Release_Ack Message
6.6. Vendor Message
6.7. Error Message
7. S-CUSP TLVs and Sub-TLVs
7.1. Common TLV Header
7.2. Basic Data Fields
7.3. Sub-TLV Format and Sub-TLVs
7.3.1. Name Sub-TLVs
7.3.2. Ingress-CAR Sub-TLV
7.3.3. Egress-CAR Sub-TLV
7.3.4. If-Desc Sub-TLV
7.3.5. IPv6 Address List Sub-TLV
7.3.6. Vendor Sub-TLV
7.4. Hello TLV
7.5. Keepalive TLV
7.6. Error Information TLV
7.7. BAS Function TLV
7.8. Routing TLVs
7.8.1. IPv4 Routing TLV
7.8.2. IPv6 Routing TLV
7.9. Subscriber TLVs
7.9.1. Basic Subscriber TLV
7.9.2. PPP Subscriber TLV
7.9.3. IPv4 Subscriber TLV
7.9.4. IPv6 Subscriber TLV
7.9.5. IPv4 Static Subscriber Detect TLV
7.9.6. IPv6 Static Subscriber Detect TLV
7.9.7. L2TP-LAC Subscriber TLV
7.9.8. L2TP-LNS Subscriber TLV
7.9.9. L2TP-LAC Tunnel TLV
7.9.10. L2TP-LNS Tunnel TLV
7.9.11. Update Response TLV
7.9.12. Subscriber Policy TLV
7.9.13. Subscriber CGN Port Range TLV
7.10. Device Status TLVs
7.10.1. Interface Status TLV
7.10.2. Board Status TLV
7.11. CGN TLVs
7.11.1. Address Allocation Request TLV
7.11.2. Address Allocation Response TLV
7.11.3. Address Renewal Request TLV
7.11.4. Address Renewal Response TLV
7.11.5. Address Release Request TLV
7.11.6. Address Release Response TLV
7.12. Event TLVs
7.12.1. Subscriber Traffic Statistics TLV
7.12.2. Subscriber Detection Result TLV
7.13. Vendor TLV
8. Tables of S-CUSP Codepoints
8.1. Message Types
8.2. TLV Types
8.3. TLV Operation Codes
8.4. Sub-TLV Types
8.5. Error Codes
8.6. If-Type Values
8.7. Access-Mode Values
8.8. Access Method Bits
8.9. Route-Type Values
8.10. Access-Type Values
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses1. Introduction ✨
A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router, and it's the aggregation point for subscriber traffic 🌸. To get centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, the CU-separated (CP/UP-separated) BNG framework is described in a technical report [TR-384] from the Broadband Forum (BBF) 💖. The CU-separated service CP handles user access authentication and sets the forwarding entries in UPs, and it can be virtualized and centralized 🧚. The routing control and forwarding plane, which is the BNG UP (local), can be spread across the infrastructure. Other structures can be supported too, like the CP and UP both being virtual, or both being physical 🦋
Note: In this document, the terms "user" and "subscriber" are used interchangeably 🙈
This document specifies the Simple CU Separation Protocol (S-CUSP) for communications over the BNG control channel between a BNG CP and a set of UPs 💅. S-CUSP is built to be flexible and extensible, so adding new messages and data items is easy if new requirements show up later 🌈
This document is not an IETF standard and doesn't have IETF consensus. S-CUSP was designed by China Mobile, Huawei Technologies, and ZTE 👑. It's presented here so the S-CUSP specification is conveniently available to the Internet community, which helps with diagnosis and interoperability 🫶
While this document is being written, the BBF is working on [WT-459], which will describe an architecture and requirements for CP and UP separation of a disaggregated BNG 🔥. Future work might show how the protocol in this document addresses those requirements, and it may change this specification to handle requirements that aren't covered yet 💜
2. Terminology ⭐
This section covers the implementation requirement keywords and the terms used in this document. S-CUSP messages are described here using Routing Backus-Naur Form (RBNF) as defined in [RFC5511] 🎀
2.1. Implementation Requirement Keywords 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🌸
2.2. Terms
This section lays out the terms we'll be using throughout this document, so everyone's on the same page 💖
AAA: Authentication Authorization Accounting. 🔐
ACK: Acknowledgement message. ✅
BAS: Broadband Access Server, also known as a BBRAS, BNG, or BRAS. 🌐
BNG: Broadband Network Gateway. A BNG (or Broadband Remote Access Server (BRAS)) routes traffic to and from broadband remote access devices such as digital subscriber line access multiplexers (DSLAM) on an Internet Service Provider's (ISP) network. BNG / BRAS can also be referred to as a BAS or BBRAS. 🦋
BRAS: Broadband Remote Access Server, also known as a BAS, BBRAS, or BNG. 🧚
CAR: Committed Access Rate. 🍓
CBS: Committed Burst Size. 💜
CGN: Carrier Grade NAT. 🌸
Ci: Control Interface. 🎀
CIR: Committed Information Rate. ✨
CoA: Change of Authorization. 🔄
CP: Control Plane. CP is a user control management component that supports the management of the UP's resources such as the user entry and forwarding policy. 👑
CU: Control Plane / User Plane. 🫶
CUSP: Control and User Plane Separation Protocol. 💅
DEI: Drop Eligibility Indicator as defined in [802.1Q]. A bit in a VLAN tag after the priority and before the VLAN ID. (This bit was formerly the CFI (Canonical Format Indicator).) 🌈
DHCP: Dynamic Host Configuration Protocol [RFC2131]. 🏠
dial-up: This refers to the initial connection messages when a new subscriber appears. The name is left over from when subscribers literally dialed up on a modem-equipped phone line but herein is applied to other initial connection techniques. Initial connection is frequently indicated by the receipt of packets over PPPoE [RFC2516] or IPoE. 📞
EMS: Element Management System. 🖥️
IPoE: IP over Ethernet. 🌙
L2TP: Layer 2 Tunneling Protocol [RFC2661]. 🚇
LAC: L2TP Access Concentrator. 🛣️
LNS: L2TP Network Server. 🏰
MAC: 48-bit Media Access Control address [RFC7042]. 🪪
MANO: Management and Orchestration. 🎛️
Mi: Management Interface. 📱
MSS: Maximum Segment Size. 📏
MRU: Maximum Receive Unit. 📦
NAT: Network Address Translation [RFC3022]. 🔀
ND: Neighbor Discovery. 👀
NFV: Network Function Virtualization. ☁️
NFVI: NFV Infrastructure. 🏗️
PBS: Peak Burst Size. 💥
PD: Prefix Delegation. 🎁
PIR: Peak Information Rate. 🚀
PPP: Point-to-Point Protocol [RFC1661]. 🔗
PPPoE: PPP over Ethernet [RFC2516]. 🔗💕
RBNF: Routing Backus-Naur Form [RFC5511]. 📝
RG: Residential Gateway. 🏡
S-CUSP: Simple Control and User Plane Separation Protocol. 💫
Subscriber: The remote user gaining network accesses via a BNG. 🙋♀️
Si: Service Interface. 🔌
TLV: Type-Length-Value. See Sections 7.1 and 7.3. 🧩
UP: User Plane. UP is a network edge and user policy implementation component. The traditional router's control plane and forwarding plane are both preserved on BNG devices in the form of a user plane. 🌊
URPF: Unicast Reverse Path Forwarding. 🪞
User: Equivalent to "customer" or "subscriber". 🛍️
VRF: Virtual Routing and Forwarding. 🗂️
3. BNG CUPS Overview ✨
3.1. BNG CUPS Motivation
Okay so, the world is changing fast, bestie. 🚀 New services like 4K TV and Internet of Things (IoT) are blowing up, and more and more people are signing up for home broadband. That creates some real challenges for BNGs, like:
Low resource utilization: The traditional BNG acts as both a gateway for user access authentication and accounting and also an IP network's Layer 3 edge. The mutually affecting nature of the tightly coupled control plane and forwarding plane makes it difficult to achieve the maximum performance of either plane. 😩
Complex management and maintenance: Because there are so many traditional BNGs, configuring each device in a network is very tedious when deploying global service policies. As the network expands and new services are introduced, this deployment mode will cease to be feasible as it is unable to manage services effectively and to rectify faults rapidly. 💀
Slow service provisioning: The coupling of the CP and the forwarding plane, in addition to being a distributed network control mechanism, means that any new technology has to rely heavily on the existing network devices. 🐢
The framework for a cloud-based BNG with CU separation to address these challenges for fixed networks is described in [TR-384]. The main idea of CU separation is to extract and centralize the user management functions of multiple BNG devices, forming a unified and centralized CP. ✨ The traditional router's CP and forwarding plane are both preserved on BNG devices in the form of a UP. 💖
3.2. BNG CUPS Architecture Overview
The functions in a traditional BNG can be divided into two parts: (1) the user access management function and (2) the routing function. The user access management function can be deployed as a centralized module or device, called the BNG Control Plane (BNG-CP). The routing function, which includes routing control and the forwarding engine, can be deployed in the form of the BNG User Plane (BNG-UP). 🧠
Figure 1 shows the architecture of a CU-separated BNG: 👀
+------------------------------------------------------------------+
| Neighboring policy and resource management systems |
| |
| +-------------+ +-----------+ +---------+ +----------+ |
| | AAA Server | |DHCP Server| | EMS | | MANO | |
| +-------------+ +-----------+ +---------+ +----------+ |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| CU-separated BNG system |
| +--------------------------------------------------------------+ |
| | +----------+ +----------+ +------++------++-----------+ | |
| | | Address | |Subscriber| | AAA ||Access|| UP | | |
| | |management| |management| | || mgt ||management | | |
| | +----------+ +----------+ +------++------++-----------+ | |
| | CP | |
| +--------------------------------------------------------------+ |
| |
| |
| |
| +---------------------------+ +--------------------------+ |
| | +------------------+ | | +------------------+ | |
| | | Routing control | | | | Routing control | | |
| | +------------------+ | ... | +------------------+ | |
| | +------------------+ | | +------------------+ | |
| | |Forwarding engine | | | |Forwarding engine | | |
| | +------------------+ UP | | +------------------+ UP| |
| +---------------------------+ +--------------------------+ |
+------------------------------------------------------------------+
Figure 1: Architecture of a CU-Separated BNGAs shown in Figure 1, the BNG-CP could be virtualized and centralized, which provides benefits such as centralized session management, flexible address allocation, high scalability for subscriber management capacity, cost-efficient redundancy, etc. The functional components inside the BNG-CP can be implemented as Virtual Network Functions (VNFs) and hosted in an NFVI. ☁️🌸
The UP management module in the BNG-CP centrally manages the distributed BNG-UPs (e.g., load balancing), as well as the setup, deletion, and maintenance of channels between CPs and UPs. Other modules in the BNG-CP, such as address management, AAA, etc., are responsible for the connection with external subsystems in order to fulfill those services. Note that the UP SHOULD support both physical and virtual network functions. For example, network functions related to BNG-UP L3 forwarding can be disaggregated and distributed across the physical infrastructure, and the other CP management functions in the CU-separated BNG can be moved into the NFVI for virtualization [TR-384]. 🧩
The details of the CU-separated BNG's function components are as follows: 📋
The CP is responsible for the following:
- Address management: Unified address pool management and CGN subscriber address traceability management. 🏷️
- AAA: This component performs Authentication, Authorization, and Accounting, together with RADIUS/Diameter. The BNG communicates with the AAA server to check whether the subscriber who sent an access request has network access authority. Once the subscriber goes online, this component (together with the Service Control component) implements accounting, data capacity limitation, and QoS enforcement policies. 🔐
- Subscriber management: User entry management and forwarding policy management. 👑
- Access management: Process user dial-up packets, such as PPPoE, DHCP, L2TP, etc. 📞
- UP management: Management of UP interface status and the setup, deletion, and maintenance of channels between CP and UP. 🔗
The UP is responsible for the following:
- Routing control functions: Responsible for instantiating routing forwarding plane (e.g., routing, multicast, MPLS, etc.). 🛤️
- Routing and service forwarding plane functions: Responsibilities include traffic forwarding, QoS, and traffic statistics collection. 🚦
- Subscriber detection: Responsible for detecting whether a subscriber is still online. 👋
3.3. BNG CUPS Interfaces ✨
Okay so, the CP and UP need a way to chat with each other, and there are three interfaces doing that job. bestie, we've got the Service Interface (Si), the Control Interface (Ci), and the Management Interface (Mi), all shown in Figure 2 🦋
+-----------------------------------+
| |
| BNG-CP |
| |
+--+--------------+--------------+--+
| | |
1. Service | 2. Control | 3. Management|
Interface | Interface | Interface |
(Si) | (Ci) | (Mi) |
| | |
| ___|___ |
| ___( )___ |
_|______( )______|_
( )
( Network/Internet )
(________ ________)
| (___ ___) |
| (_______) |
| | |
| | |
+--+--------------+--------------+--+
| |
| BNG-UP |
| |
+-----------------------------------+
Figure 2: Interfaces between the CP and UP of the BNG3.3.1. Service Interface (Si) 💜
So for a traditional BNG (the kind without CU separation), the user dial-up signals get terminated and processed right there by the CP of the BNG. 🙈 But once the CP and UP are split apart, there needs to be a way to relay those signals between them.
That's where the Si comes in! It's used to set up tunnels between the CP and UP, and those tunnels are in charge of relaying the PPPoE-, IPoE-, and L2TP-related control packets that arrive from a Residential Gateway (RG). An appropriate tunnel type is Virtual eXtensible Local Area Network (VXLAN) [RFC7348]. 🌸
The detailed definition of Si is out of scope for this document, so we're leaving that one for another day 🫶
3.3.2. Control Interface (Ci) 🔥
The CP uses the Ci to deliver subscriber session states, network routing entries, and so on to the UP (see Section 6.2.7). Then the UP uses this same interface to send back subscriber service statistics, subscriber detection results, and etc. to the CP (see Sections 6.3 and 6.4). It's giving two-way communication, honestly 💅 A carrying protocol for this interface is specified in this document.
3.3.3. Management Interface (Mi) 🎀
The Network Configuration Protocol (NETCONF) [RFC6241] is the protocol used on the Mi between a CP and UP. ✨ It's used to configure the parameters of the Ci, Si, access interfaces, and QoS/ACL Templates. Implementations are expected to make use of existing YANG models where possible, but new YANG models specific to S-CUSP will need to be defined. The definitions of the parameters that can be configured are out of scope for this document 🧚
3.4. BNG CUPS Procedure Overview 🍓
Here's the big picture of the main BNG CUPS procedures, laid out as numbered sequences in Figure 3. It's a high-level view, so don't worry, we'll zoom in later 🔍
RG UP CP AAA
| |Establish S-CUSP Channel| |
| 1|<---------------------->| |
| | | |
| | Report board interface | |
| | information | |
| 2|------to CP via Ci----->| |
| | | |
| | Update BAS function | |
| 3| request/response | |
| |<-----on UP via Ci----->| |
| | | |
| | Update network routing | |
| | request/response | |
| 4|<------- via Ci-------->| |
| Online Req | | |
5.1|-------------->| | |
| | Relay the Online Req | |
| 5.2|-----to CP via Si------>| Authentication|
| | | Req/Rep |
| | 5.3|<------------->|
| | Send the Online Rep | |
| 5.4|<----to UP via Si-------| |
| | | |
| | Create subscriber | |
| | session on UP | |
| 5.5|<--------via Ci-------->| |
| Online Rep | | |
5.6|<--------------| | |
| | | CoA Request |
| | 6.1|<--------------|
| | Update session on UP | |
| 6.2|<--------via Ci-------->| |
| | | CoA Response |
| Offline Req | 6.3|-------------->|
7.1|-------------->| | |
| | Relay the Offline Req | |
| 7.2|------to CP via Si----->| |
| | | |
| | Send the Offline Rep | |
| 7.3|<-----to UP via Si------| |
| Offline Rep | | |
7.4|<--------------| | |
| | Delete session on UP | |
| 7.5|<--------via Ci-------->| |
| | | |
| | Event report | |
| 8|---------via Ci-------->| |
| | | |
| | Data synchronization | |
| 9|<--------via Ci-------->| |
| | | |
| | CGN address allocation | |
| 10|<--------via Ci-------->| |
| | | |
Figure 3: BNG CUPS Procedures Overview(1) S-CUSP session establishment: This is step one of the BNG CUPS procedures, bestie 🌈 Once the Ci parameters are configured on a UP, it starts setting up S-CUSP sessions with the specified CPs. The detailed definition of S-CUSP session establishment can be found in Section 4.1.1.
(2) Board and interface report: Once the S-CUSP session is established between the UP and a CP, the UP reports status information on its boards and subscriber-facing interfaces to the CP. A board can also be called a Line/Service Process Unit (LPU/SPU) card. The subscriber-facing interfaces are the ones that connect the access network nodes (e.g., Optical Line Terminal (OLT), DSLAM, etc.). The CP can use this info to enable the Broadband Access Server (BAS) function (e.g., IPoE, PPPoE, etc.) on the specified interfaces. See Sections 4.2.1 and 7.10 for more details on resource reporting. 📡
(3) BAS function enable: This is where the BAS function gets turned on for the specified interfaces of a UP. ⭐
(4) Subscriber network route advertisement: The CP allocates one or more IP address blocks to a UP. Each address block contains a series of IP addresses, and those IP addresses get handed out to subscribers dialing up from the UP. So that other nodes in the network can figure out how to reach the subscribers, the CP needs to tell the UP to advertise the routes that can reach those IP addresses to the network. Main character routing energy 🦋
(5) Complete dial-up call flow (5.1-5.6): This is the full call flow of a subscriber dial-up (as defined in Section 4.3.1). When a UP gets a dial-up request, it relays the request packet to a CP through the Si. The CP parses the request, and if everything is OK, it sends an authentication request to the AAA server to authenticate the subscriber. Once the subscriber passes authentication, the AAA server sends a positive response back to the CP. Then the CP sends the dial-up response packet to the UP, and the UP forwards that response to the subscriber (RG). At the same time, the CP creates a subscriber session on the UP so the subscriber can access the network 🥳 The process may be a bit different for different access types, but the high-level process is similar. For each access type, the detailed process can be found in Section 5.
(6) Updating an existing session (6.1-6.3): This is the sequence for updating an existing subscriber session. The AAA server initiates a Change of Authorization (CoA) and sends the CoA to the CP. The CP then updates the session according to the CoA. See Section 4.3.2 for more detail on CP messages updating UP tables. 💫
(7) Deleting an existing session (7.1-7.5): This is the sequence for deleting an existing subscriber session 💀 When a UP receives an Offline Request, it relays the request to a CP through the Si. The CP sends a response back to the UP through the Si, and the UP then forwards the Offline Response to the subscriber. After that, the CP deletes the session on the UP through the Ci.
(8) Event reports: Event reports include the following two parts (more detail can be found in Section 4.3.4). Both are reported using the Event message:
- 8.1. Subscriber Traffic Statistics Report
- 8.2. Subscriber Detection Result Report
(9) Data synchronization: See Section 4.2.5 for more detail on CP and UP synchronization. 🫧
(10) CGN address allocation: See Section 4.2.4 for more detail on CGN address allocation. 🌷
4. S-CUSP Protocol Overview 👑
4.1. Control Channel Procedures 💖
4.1.1. S-CUSP Session Establishment ✨
Okay so a UP is always attached to a CP, and that CP is the one that bosses it around 👑. For hot-standby or cold-standby setups, a UP gets two CPs: a master CP and a standby CP. How a UP gets matched up with its CPs is handled by dynamic configuration 🎀.
Once a UP knows who its CPs are, it starts setting up S-CUSP sessions with them, like this 💅
UP CP
| TCP Session Establishment |
|<------------------------------->|
| |
| Hello (version, capability) |
|-------------------------------->|
| |
| Hello (version, capability) |
|<--------------------------------|
| |
Figure 4: S-CUSP Session EstablishmentSession establishment happens in two steps, and honestly they're very cute together 🦋:
- Set up a TCP connection (3-way handshake) [RFC793] between the CP and the UP, using a configured port from the dynamic port range (49152-65535).
- Set up an S-CUSP session on top of that TCP connection.
Once TCP is up, the CP and the UP initialize the S-CUSP session. This is when they negotiate the version and the Keepalive timers 🧚.
The version info lives in the Hello TLV (see Section 7.4), and it rides along inside Hello messages (see Section 6.2.1). Here's the tea ☕: a CP can support multiple versions, but a UP can only support one. So the versions have to overlap, and the negotiation is really just checking whether a version works for both sides 🫶. If a CP or UP gets a Hello that doesn't show a version both of them support, it fires back a Hello with an Error Information TLV to tell its peer about the Version-Mismatch error, and session establishment fails 💀.
Keepalive negotiation happens by putting a Keepalive TLV inside the Hello message. That TLV has a Keepalive timer and a DeadTimer field. The CP and UP have to agree on both the Keepalive Timer and the DeadTimer. If they don't agree, a follow-up Hello with an Error Information TLV gets sent to the peer, and session establishment fails 😭.
So the S-CUSP session establishment phase fails in two situations: the CP and UP disagree on the version or keepalive parameters, or one of them doesn't answer before the Establishment timer runs out 🙈. When that happens, the TCP connection gets closed right away. Retries are allowed, but an implementation SHOULD use an exponential backoff retry procedure for session establishment, so it doesn't spam the other side 🌸.
These are the S-CUSP session timer values you need to configure. Check out Table 1 👑:
+---------------------+------------------+---------------+
| Timer Name | Range in Seconds | Default Value |
+=====================+==================+===============+
| Establishment Timer | 1-32767 | 45 |
+---------------------+------------------+---------------+
| Keepalive Timer | 0-255 | 30 |
+---------------------+------------------+---------------+
| DeadTimer | 1-32767 | 4 * Keepalive |
+---------------------+------------------+---------------+
Table 1: S-CUSP Session Timers4.1.2. Keepalive Timer and DeadTimer 💜
Once an S-CUSP session is up, a UP or CP might want to double-check that its S-CUSP peer is still there. That's what these timers are for 🍓.
Each end of an S-CUSP session runs a Keepalive timer. It restarts that timer every single time it sends a message on the session. When the timer runs out, it sends a Keepalive message. So a message goes out at least as often as the Keepalive timer's reset value, unless that value is the special value zero, which I'll explain below 🌈.
Each end also runs a DeadTimer, and it restarts that DeadTimer whenever a message comes in on the session. If the DeadTimer expires at one end, that end declares the session dead and the session gets closed. The exception is when their DeadTimer is set to the special value zero, which means the session will never time out 🫶.
The minimum Keepalive timer value is 1 second, and it's measured in 1-second units. The RECOMMENDED default value is 30 seconds. The recommended default for the DeadTimer is four times the Keepalive timer value used by the remote peer. Like I said, the timers can be turned off by setting them to zero ✨.
The Keepalive timer and DeadTimer get negotiated through the Keepalive TLV that rides in the Hello message.
4.2. Node Procedures 🎀
4.2.1. UP Resource Report 📡
Once an S-CUSP session is set up between a CP and a UP, the UP reports the state info for its boards and its access-facing interfaces to the CP, as shown in Figure 5 💖. These Report messages are unacknowledged, and they're assumed to be delivered because the session runs over TCP 🦋.
The CP can use that info to activate or enable the BAS functions (e.g., IPoE, PPPoE, etc.) on the specified interfaces 💅.
The UP resource report can also kick off a UP warm-standby process. In the warm-standby case, if a UP fails, the CP can start a warm-standby process. It does that by moving the online subscriber sessions over to a standby UP, and then directing the affected subscribers to reach the Internet through that standby UP 🚑.
UP CP
| Report Board Status |
|------to CP via Ci----->|
| |
| Report Interface Status|
|------to CP via Ci----->|
| |
Figure 5: UP Board and Interface ReportBoard status info is carried in the Board Status TLV (Section 7.10.2), and interface status info is carried in the Interface Status TLV (Section 7.10.1). Both the Board Status and Interface Status TLVs ride inside the Report message (Section 6.4) 🌸.
4.2.2. Update BAS Function on Access Interface 🔧
Once the CP has collected a UP's interface status, it can activate, deactivate, or modify the BAS functions on specified interfaces. It does this with the Update_Request and Update_Response message exchanges (Section 6.2), which carry the BAS Function TLV (Section 7.7) 👑.
UP CP
| Update BAS Function |
| Request |
|<-----on UP via Ci-------|
| |
| Update BAS Function |
| Response |
|------on UP via Ci------>|
| |
Figure 6: Update BAS Function4.2.3. Update Network Routing 🗺️
The CP allocates one or more address blocks to a UP. Each address block contains a series of IP addresses. Those IP addresses get assigned to subscribers who dial up to the UP 💕. So other nodes in the network can figure out how to reach those subscribers, the CP has to install the routes on the UP, and it has to tell the UP to advertise those routes to the network 🦋.
UP CP
| Subscriber network route|
| update request |
|<------- via Ci----------|
| |
| Subscriber network route|
| update response |
|-------- via Ci--------->|
| |
Figure 7: Update Network RoutingThe Update_Request and Update_Response message exchanges, which carry the IPv4/IPv6 Routing TLVs (Section 7.8), are what update the subscriber's network routing information 💜.
4.2.4. CGN Public IP Address Allocation 🌐
The following sequences (Figure 8) describe the procedures for CGN address management. There are three independent procedures: one for CGN address allocation request/response, one for CGN address renewal request/response, and one for CGN address release request/response 🍓.
The allocate/renew/release procedures are built for the case where the CGN function runs on the UP. In that setup, the UP has to map subscriber private IP addresses to public IP addresses. That mapping happens locally on the UP whenever a subscriber dials up. This means the UP has to ask the CP for public IPv4 address blocks for its CGN subscribers 🙌.
When a public IP address is allocated to a UP, there's a lease time (e.g., one day). Before that lease time runs out, the UP can ask the CP to renew the IP address lease. This happens through the exchange of the Addr_Renew_Req and Addr_Renew_Ack messages ⏰.
If a public IP address won't be used anymore, the UP SHOULD release it by sending an Addr_Release_Req message to the CP 🧹.
If the CP wants to withdraw addresses it previously leased to a UP, it uses the same procedures as above. The Oper code (see Section 7.1) in the IPv4/IPv6 Routing TLV (see Section 7.8) determines whether the request is an update or a withdraw 🔁.
The relevant messages are defined in Section 6.5 📝.
UP CP
| CGN Address Allocation |
| Request |
1.1|-------- via Ci--------->|
| CGN Address Allocation |
| Response |
1.2|<------- via Ci----------|
| |
| CGN Address Renew |
| Request |
2.1|-------- via Ci--------->|
| CGN Address Renew |
| Response |
2.2|<------- via Ci----------|
| |
| CGN Address Release |
| Request |
3.1|-------- via Ci--------->|
| CGN Address Release |
| Response |
3.3|<------- via Ci----------|
| |
Figure 8: CGN Public IP Address Allocation4.2.5. Data Synchronization between the CP and UP ✨
Okay so for a CU-separated BNG, the UP keeps running on whatever state it already has installed, even if the CP fails or the session between the UP and CP drops. Main character UP energy 👑🫶
Sometimes the CP and UP have to sync their state, like when a CP fails and the UP gets switched over to a different CP 🔄💅
The sync goes both ways, bestie 🦋 One direction is UP → CP, and the info there is mostly about the board/interface status of the UP. The other direction is CP → UP, where the subscriber sessions, subscriber network routes, L2TP tunnels, etc. get pushed down to the UP 🌸
Sync starts with a Sync_Request message. The receiver replies with a Sync_Begin to say "okay, we're starting" (1), and then kicks off the actual sync with Sync_Data messages (2). When everything's done, a Sync_End gets sent 🎀✨
Figure 9 shows how the data sync goes between a UP and a CP:
UP CP
| Synchronization Request |
|<------- via Ci----------|
| |
| Synchronization Begin |
|-------- via Ci--------->|
| |
| Board/Interface Report |
|-------- via Ci--------->|
| |
| Synchronization End |
|-------- via Ci--------->|
| |
1) Synchronization from UP to CP
UP CP
| Synchronization Request |
|-------- via Ci--------->|
| |
| Synchronization Begin |
|<-------- via Ci---------|
| |
| Synchronizes |
|Subscriber Session States|
| Network Route Entries |
|<------- via Ci----------|
| |
| Synchronization End |
|<-------- via Ci---------|
| |
2) Synchronization from CP to UP
Figure 9: Data Synchronization4.3. Subscriber Session Procedures 🧚
A subscriber session is a bundle of forwarding states, policies, and security rules that get applied to the subscriber. It's what actually forwards the subscriber's traffic in a UP 💜 To spin one up on a UP, a bunch of hardware resources (e.g., NP, TCAM, etc.) has to be allocated to the session as part of its initiation 🔥
Subscriber session stuff covers creation, update, deletion, and statistics reporting. The subsections below give you the high-level tea ☕💅
4.3.1. Create Subscriber Session 🎀
This sequence (Figure 10) walks through the DHCP IPv4 dial-up process. It's an example of how a subscriber session gets created. (An example for IPv6 appears in Section 5.1.2. 🦋)
RG UP CP AAA
| Online Request| | |
1|-------------->| | |
| |Relay the Online Request| |
| 2|-----to CP via Si------>| Authentication|
| | | Req/Rep |
| | 3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | Accounting |
| | 6|<------------->|
| | Send Online Response | |
| 7|<----to UP via Si-------| |
| | | |
|Online Response| | |
8|<--------------| | |
| | | |
Figure 10: Creating a Subscriber SessionIt all starts with an Online Request (step 1) from the RG, like a DHCP Discovery packet 📦 When the UP gets that Online Request from the RG, it tunnels it over to the CP through the Si (step 2). A tunneling technology is what implements the Si 🚇
When the CP gets the Online Request from the UP, it sends an authentication request to the AAA server so it can authenticate and authorize the subscriber (step 3) 🔐 Once a positive reply comes back from the AAA server, the CP starts building the subscriber session. Relevant resources (e.g., IP address, bandwidth, etc.) get allocated to the subscriber, and policies and security rules get generated for them 🌈 Then the CP sends a request to create the session to the UP through the Ci (step 4), and it expects a response from the UP to confirm it's been created (step 5) ✅
Last but not least, the CP tells the AAA server to start accounting (step 6). At the same time, an Online Response (like a DHCP Ack packet) goes to the UP through the Si (step 7). The UP then forwards that Online Response to the RG (step 8) 💖
And that's the subscriber activation process, periodt 💅✨
4.3.2. Update Subscriber Session 🔄
Here's the numbered sequence (Figure 11) for updating a subscriber session:
UP CP AAA
| | CoA Request |
| 1|<--------------|
| Session Update Request | |
2|<--------via Ci---------| |
| | |
| Session Update Response| |
3|---------via Ci-------->| |
| | CoA Response |
| 4|-------------->|
| | |
Figure 11: Updating a Subscriber SessionOnce a subscriber session exists on a UP, it may need new parameters (e.g., bandwidth, QoS, policies, etc.) 🎀 This update is triggered by a Change of Authorization (CoA) request message sent by the AAA server 👑 The CP then updates the session on the UP with the new parameters through the Ci 🦋
4.3.3. Delete Subscriber Session 🗑️
The call flow below shows how S-CUSP handles a subscriber Offline Request 💀
RG UP CP
|Offline Request | |
1|--------------->| |
| | Relay the Offline |
| | Request |
| 2|------to CP via Si----->|
| | |
| | Send the Offline |
| | Response |
| 3|<-----to UP via Si------|
|Offline Response| |
4|<---------------| |
| | Session Delete |
| | Request |
| |<--------via Ci---------|
| | Session Delete |
| | Response |
| |---------via Ci-------->|
| | |
Figure 12: Deleting a Subscriber SessionKinda like session creation, when a UP gets an Offline Request from an RG, it tunnels that request to a CP through the Si 🚇
When the CP gets the Offline Request, it withdraws/releases the resources (e.g., IP address, bandwidth) that were allocated to the subscriber 🧹 Then it sends a reply to the UP through the Si, and the UP forwards that reply to the RG. At the same time, the CP deletes all the status of the session on the UP through the Ci. Bye bye session 👋✨
4.3.4. Subscriber Session Events Report 📊
UP CP
| Statistic/Detect Report|
|---------via Ci-------->|
| |
Figure 13: Events ReportWhen a session is up on a UP, the UP periodically reports statistics and subscriber detection results for that session to the CP 📈💜
5. S-CUSP Call Flows 🌈
The subsections below give you an overview of the various "dial-up" interactions over the Si, followed by an overview of how the CP sets information in the UP using S-CUSP over the Ci 💅
S-CUSP messages are described in this document using Routing Backus Naur Form (RBNF), as defined in [RFC5511] 🧠🫶
5.1. IPoE 🎀
5.1.1. DHCPv4 Access
okay so here's the DHCPv4 flow, and it's giving full choreography 💃 Figure 14 shows every step, bestie 🎀
RG UP CP AAA
| DHCP Discovery| | |
1|-------------->| | |
| |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Send the DHCP Offer | |
| 4|<----to UP via Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request | |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| | | |
| DHCP ACK | | |
12|<--------------| | |
| | | |
Figure 14: DHCPv4 AccessS-CUSP handles steps 8 and 9 🫶
Once the AAA server says a subscriber is authenticated and authorized ✅, the CP makes a brand-new subscriber session on the UP. The way it happens is by sending an Update_Request message over to the UP. Slay 💅
Here's how the Update_Request message is written in RBNF:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]The UP answers with an Update_Response message 💖 and that one looks like this:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]5.1.2. DHCPv6 Access
Now for DHCPv6 🧚 Figure 15 has the whole sequence:
RG UP CP AAA
| Solicit | | |
1|-------------->| | |
| | Relay the Solicit | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Send the Advertise | |
| 4|<----to UP via Si-------| |
| Advertise | | |
5|<--------------| | |
| | | |
| Request | | |
6|-------------->| | |
| | Relay the Request | |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci-------->| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send Reply | |
| 11|<----to UP via Si-------| |
| Reply | | |
12|<--------------| | |
| | | |
Figure 15: DHCPv6 AccessSteps 1-7 are just the normal DHCP IPv6 access process, nothing fancy 🌸 The subscriber creation kicks off when a DHCP IPv6 request message shows up. Getting that message means the subscriber already got through AAA authentication and authorization 🔑 After that, the CP builds a subscriber session on the UP by sending an Update_Request message (that's step 8).
The Update_Request message goes like this:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]The UP replies with an Update_Response message (step 9) 🦋 Its format is:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.1.3. IPv6 Stateless Address Autoconfiguration (SLAAC) Access
Last one, and it's a cute one 🍓 Figure 16 shows the IPv6 SLAAC access process:
RG UP CP AAA
| RS | | |
1|-------------->| | |
| | Relay the Router | |
| | Solicit (RS) | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send Router Advertise | |
| | (RA) | |
| 6|<----to UP via Si-------| |
| RA | | |
7|<--------------| | |
| | | |
| NS | | |
8|-------------->| | |
| | Relay the Neighbor | |
| | Solicit (NS) | |
| 9|-----to CP via Si------>| |
| | | Accounting |
| | 10|<------------->|
| | Send a Neighbor | |
| | Advertise (NA) | |
| 11|<----to UP via Si-------| |
| NA | | |
12|<--------------| | |
| | | |
Figure 16: IPv6 SLAAC AccessIt all starts with a Router Solicit (RS) from an RG, which the UP tunnels over to the CP 📡 After AAA authentication and authorization, the CP creates a subscriber session on the UP. That happens by sending an Update_Request message to the UP (step 4).
The Update_Request message is written as follows:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]The UP replies with an Update_Response message (step 5) ✨ and the format is:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>Okay so this part picks up right where we left off, bestie 🎀 We're in 5.1.4. DHCPv6 and SLAAC Access and then zooming into 5.1.5. DHCP Dual-Stack Access 💅
5.1.4. DHCPv6 and SLAAC Access
5.1.4. DHCPv6 and SLAAC Access
Okay so this is the flow for the DHCPv6 and SLAAC access process, and it's giving main character energy 🧚 Check out Figure 17 below, it's literally the whole story in one diagram 💜
RG UP CP AAA
| RS | | |
1|-------------->| | |
| | Relay the RS | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send RA | |
| 6|<----to UP via Si-------| |
| RA | | |
7|<--------------| | |
| | | |
|DHCPv6 Solicit | | |
8|-------------->| | |
| | Relay DHCPv6 Solicit | |
| 9|-----to CP via Si------>| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 10|<--------via Ci---------| |
| | | |
| | Update Subscriber | |
| | Session Response | |
| 11|---------via Ci-------->| |
| | | Accounting |
| | 12|<------------->|
| | Send DHCPv6 Reply | |
| 13|<----to UP via Si-------| |
| | | |
| DHCPv6 Reply | | |
14|<--------------| | |
| | | |
Figure 17: DHCPv6 and SLAAC AccessWhen a subscriber passes AAA authentication, the CP will create a subscriber session on the UP 🔐 This is achieved by sending an Update_Request message to the UP (step 4).
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]The UP will reply with an Update_Response message (step 5). The format of the Update_Response is as follows:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>After receiving a DHCPv6 Solicit, the CP will update the subscriber session by sending an Update_Request message with new parameters to the UP (step 10) ✨
The format of the Update_Request message is as follows:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]The UP will reply with an Update_Response message (step 11). The format of the Update_Response is as follows:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.1.5. DHCP Dual-Stack Access
5.1.5. DHCP Dual-Stack Access
Now the DHCP dual-stack access is a combo of DHCP IPv4 and DHCP IPv6 access, so it's giving double the vibes 🦋 Here's the whole sequence in Figure 18 🌈
RG UP CP AAA
| DHCP Discovery| | |
1|-------------->| | |
| |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA |
| | | Req/Resp |
| | 3|<------------->|
| | Send the DHCP Offer | |
| 4|<----to UP via Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request| |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci-------->| |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| DHCP ACK | | |
12|<--------------| | |
| RS | | |
13|-------------->| | |
| | Relay the RS | |
| 14|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 15|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 16|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 17|---------via Ci-------->| |
| | | |
| | Send the RA | |
| 18|<----to UP via Si-------| |
| RA | | |
19|<--------------| | |
|DHCPv6 Solicit | | |
20|-------------->| | |
| | Relay DHCPv6 Solicit | |
| 21|-----to CP via Si------>| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 22|<--------via Ci---------| |
| | Update Subscriber | |
| | Session Response | |
| 23|---------via Ci-------->| |
| | | Accounting |
| | 24|<------------->|
| | Send DHCPv6 Reply | |
| 25|<----to UP via Si-------| |
| DHCPv6 Reply | | |
26|<--------------| | |
| | | |
Figure 18: DHCP Dual-Stack AccessThe DHCP dual-stack access includes three sets of Update_Request/Update_Response exchanges to create/update a DHCPv4/v6 subscriber session 💖 Let's break them down, bestie:
- Create a DHCPv4 session (steps 8 and 9):
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]- Create a DHCPv6 session (steps 16 and 17):
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>- Update DHCPv6 session (steps 22 and 23):
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>Okay bestie, let's get into the L2 static subscriber access flow 🦋✨ It's giving layer 2 realness, and I'm obsessed with how it works 💅
5.1.6. L2 Static Subscriber Access
Hmm, I'll pick up cleanly from here, so let me rewrite the section body. No repeated headings, just the vibes 🫶
5.1.6. L2 Static Subscriber Access
L2 static subscriber access processes are as follows:
RG UP CP AAA
| | Static Subscriber | |
| | Detection Req. | |
| 1|<-----to UP via Ci------| |
| | Static Subscriber | |
| | Detection Rep. | |
| 2|------to UP via Ci----->| |
| ARP/ND(REQ) | | |
3.1|<--------------| | |
| ARP/ND(ACK) | | |
3.2|-------------->| | |
| | Relay the ARP/ND | |
| 3.3|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3.4|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 3.5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 3.6|---------via Ci-------->| |
| ARP/ND(REQ) | | |
4.1|-------------->| | |
| | Relay the ARP/ND | |
| 4.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 4.3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4.4|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 4.5|---------via Ci-------->| |
| ARP/ND(ACK) | | |
4.6|<--------------| | |
| IP Traffic | | |
5.1|-------------->| | |
| | Relay the IP Traffic | |
| 5.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 5.3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 5.4|<--------via Ci-------->| |
| | Create Subscriber | |
| | Session Response | |
| 5.5|---------via Ci-------->| |
| ARP/ND(REQ) | | |
5.6|<--------------| | |
| ARP/ND(ACK) | | |
5.7|-------------->| | |
| | | |Figure 19: L2 Static Subscriber Access
For L2 static subscriber access, the process starts with a CP installing a static subscriber detection list on a UP. The list determines which subscribers will be detected. That is implemented by exchanging Update_Request and Update_Response messages between CP and UP. The formats of the messages are as follows:
<Update_Request Message> ::= <Common Header>
<IPv4 Static Subscriber Detect TLVs>
<IPv6 Static Subscriber Detect TLVs>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>For L2 static subscriber access, there are three ways to trigger the access process:
- Triggered by UP (steps 3.1-3.6): This assumes that the UP knows the IP address, the access interface, and the VLAN of the RG. The UP will actively trigger the access flow by sending an ARP/ND packet to the RG. If the RG is online, it will reply with an ARP/ND to the UP. The UP will tunnel the ARP/ND to the CP through the Si. The CP then triggers the authentication process. If the authentication result is positive, the CP will create a corresponding subscriber session on the UP.
- Triggered by RG ARP/ND (steps 4.1-4.6): Most of the process is the same as option 1 (triggered by UP). The difference is that the RG will actively send the ARP/ND to trigger the process.
- Triggered by RG IP traffic (steps 5.1-5.7): This is for the case where the RG has the ARP/ND information, but the subscriber session on the UP is lost (e.g., due to failure on the UP or the UP restarting). That means the RG may keep sending IP packets to the UP. The packets will trigger the UP to start a new access process.
From a subscriber session point of view, the procedures and the message formats for the three cases above are the same, as follows.
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.2. PPPoE
5.2.1. IPv4 PPPoE Access
Figure 20 shows the IPv4 PPPoE access call flow.
RG UP CP AAA
| PPPoE Disc | PPPoE Disc | |
1|<------------->|<---------via Si------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | Accounting |
| | 7|<------------->|
| | | |Figure 20: IPv4 PPPoE Access
In the above sequence, steps 1-4 are the standard PPPoE call flow. The UP is responsible for redirecting the PPPoE control packets to the CP or RG. The PPPoE control packets are transmitted between the CP and UP through the Si.
After the PPPoE call flow, if the subscriber passed the AAA authentication and authorization, the CP will create a corresponding session on the UP through the Ci. The formats of the messages are as follows:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]5.2.2. IPv6 PPPoE Access 💖
Okay so bestie, this is the IPv6 PPPoE access call flow, and it's giving main character energy 👑 Figure 21 lays out the whole sequence for you, so let's go through it 🦋
RG UP CP AAA
| PPPoE Disc | PPPoE Disc | |
1|<------------->|<--------via Si-------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IP6CP | PPP IP6CP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
7|<------------->|<---------via Si------->| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | Update Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
7'|<------------->|<---------via Si------->| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 8'|<---------via Ci--------| |
| | Update Subscriber | |
| | Session Response | |
| 9'|---------via Ci-------->| |
| | | Accounting |
| | 10'|<------------->|
| | | |
Figure 21: IPv6 PPPoE AccessSteps 1-4 are the standard PPPoE call flow, so if you know that one you're already winning ✨ The UP is in charge of redirecting the PPPoE control packets to the CP or RG 🫶 and those control packets travel between the CP and UP through the Si 🌸
After the PPPoE call flow is done, if the subscriber passed the AAA authentication and authorization 🎀, the CP creates a matching session on the UP through the Ci 💅 The messages look like this:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>Then the RG kicks off an ND/DHCPv6 negotiation with the CP (see steps 7 and 7') 🧚 and after that it triggers an update (steps 8-9 and 8'-9') to the subscriber session 💜 The update messages are formatted like so:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.2.3. PPPoE Dual-Stack Access 🌈
Okay this one is the combo meal 🍓 Figure 22 shows IPv4 and IPv6 PPPoE access call flows running together, and honestly it's so iconic 😭
RG UP CP AAA
|PPPoE Discovery| PPPoE Discovery | |
1|<------------->|<---------via Si------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create v4 Subscriber | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create v4 Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | Accounting |
| | 7|<------------->|
| PPP IP6CP | PPP IP6CP | |
4'|<------------->|<---------via Si------->| |
| | | |
| | Create V6 Subscriber | |
| | Session Request | |
| 5'|<--------via Ci---------| |
| | Create v6 Subscriber | |
| | Session Response | |
| 6'|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
8|<------------->|<---------via Si------->| |
| | | |
| | Update v6 Subscriber | |
| | Session Request | |
| 9|<---------via Ci--------| |
| | Update v6 Subscriber | |
| | Session Response | |
| 10|---------via Ci-------->| |
| | | Accounting |
| | 7'|<------------->|
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
8'|<------------->|<---------via Si------->| |
| | | |
| | Update v6 Subscriber | |
| | Session Request | |
| 9'|<--------via Ci---------| |
| | Update v6 Subscriber | |
| | Session Response | |
| 10'|---------via Ci-------->| |
| | | Accounting |
| | 7"|<------------->|
| | | |
Figure 22: PPPoE Dual-Stack AccessPPPoE dual stack is just IPv4 PPPoE and IPv6 PPPoE access mixed together 💫 The process is the same as above ✨ Here are the message formats 🦋
(1) Create an IPv4 PPPoE subscriber session (steps 5-6) 💜:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>](2) Create an IPv6 PPPoE subscriber session (steps 5'-6') 🌸:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>(3) Update the IPv6 PPPoE subscriber session (steps 9-10 and 9'-10') 🎀:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.3. WLAN Access 📶✨
okay so bestie, here's the WLAN access call flow, and it's giving full choreography 💃 every single step has a number so you can follow along.
RG UP CP AAA Web Server
| DHCP | | | |
| Discovery | | | |
1|------------>| | | |
| | DHCP Discovery | | |
| 2|-----via Si---->| AAA | |
| | DHCP Offer |<-------->| |
| 3|<----via Si-----| | |
| DHCP Offer | | | |
4|<------------| | | |
| DHCP Request| | | |
5|------------>| | | |
| | DHCP Request | | |
| 6|-----via Si---->| | |
| | | | |
| | Create Session | | |
| | Request | | |
| 7|<----via Ci-----| | |
| | Create Session | | |
| | Response | | |
| 8|----via Ci----->| | |
| | | | |
| | DHCP ACK | | |
| 9|<----via Si-----| | |
| DHCP ACK | | | |
10|<------------| | | |
| | | | |
| Subscriber | | | |
| HTTP Traffic| | | |
11|------------>|--> | | |
| | | Web URL | | |
| Traffic | | Redirect | | |
| Redirection | | | | |
12|<------------|<-+ | | |
| |
13|-----------------Redirect to Web Server------------->|
| |
14|<----------------Push HTTP Log-in Page---------------|
| |
15|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 16|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 17|<-------->| |
| | | | |
| | Update Session | | |
| | Request | | |
| 18|<----via Ci-----| | |
| | Update Session | | |
| | Response | | |
| 19|-----via Ci---->| | |
| | | | |
Figure 23: WLAN Accessso WLAN access kicks off with the DHCP dial-up process (steps 1-6) 🌸 then the CP makes a subscriber session on the UP (steps 7-8) 💅 and the session creation messages look like this:
IPv4 Case: 🎀
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]IPv6 Case: 🦋
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>after step 10 the RG gets an IP address 🥹 and its very first HTTP packet gets redirected to a web server for subscriber authentication (steps 11-17). 👀 once the web auth comes back positive, the CP updates the subscriber session with these message exchanges:
IPv4 Case: 💜
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]IPv6 Case: 🧚
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.4. L2TP 🫧
5.4.1. L2TP LAC Access 🌈
ok this one is lowkey iconic 😭 here's the whole L2TP LAC access flow:
RG UP(LAC) CP(LAC) AAA LNS
| PPPoE | PPPoE | | |
| Discovery | Discovery | | |
1|<---------->|<---via Si--->| | |
| | | | |
| PPP LCP | PPP LCP | | |
2|<---------->|<---via Si--->| | |
| | | AAA | |
|PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| |
3|<---------->|<---via Si--->|<------>| |
| | | | |
| PPP IPCP | PPP IPCP | | |
4|<---------->|<---via Si--->| | |
| | | | |
| | L2TP Tunnel | | |
| | Negotiation | | |
| | SCCRQ/ | | |
| | SCCRP/ | | |
| | SCCCN | | |
| 5|<---via Si--->| | |
| | /\ |
| | || Forward |
| | \/ |
| |<-----------via Routing---------->|
| | |
| | L2TP Session | | |
| | Negotiation | | |
| | ICRQ/ | | |
| | ICRP/ | | |
| | ICCN | | |
| 6|<---via Si--->| | |
| | /\ |
| | || Forward |
| | \/ |
| |<-----------via Routing---------->|
| | |
| | Create | | |
| | Subscriber | | |
| | Session Req | | |
| 7|<---via Ci----| | |
| | Create | | |
| | Subscriber | | |
| | Session Rep | | |
| 8|----via Ci--->| | |
| | | | |
| |
| PAP/CHAP (Triggered by LNS) |
9|<-----------------via Routing----------------->|
| |
Figure 24: L2TP LAC Accessso steps 1-4 are just a standard PPPoE access process 🫶 after that, the LAC-CP starts negotiating an L2TP session and tunnel with the LNS 🚀 once that negotiation is done, the CP creates an L2TP LAC subscriber session on the UP with this message:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<L2TP-LAC Subscriber TLV>
<L2TP-LAC Tunnel TLV>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>period, that's the whole plot 🎬👑
5.4.2. L2TP LNS IPv4 Access 🌸
Okay so this is where the BNG wears its LNS hat 🎀 and gets split into two pieces, an LNS-CP and an LNS-UP 🫶. Here's the full sequence, bestie, and it's giving very organized energy 💅.
RG LAC UP(LNS) AAA CP(LNS)
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | L2TP Tunnel | L2TP Tunnel |
| | Negotiation | Negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP Session | L2TP Session |
| | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create Subscriber |
| | | Session Request |
| | 6|<-----via Ci-------|
| | | Create Subscriber |
| | | Session Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| |
| PPP IPCP |
10|<--------------------------------------------->|
| |
| | | Update Subscriber |
| | | Session Request |
| | 11|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 12|------via Ci------>|
| | | |
Figure 25: L2TP LNS IPv4 AccessIn this case, the BNG is running as an LNS and separated into LNS-CP and LNS-UP 🦋. Steps 1-5 finish the normal L2TP dial-up process 📞. When the L2TP session and tunnel negotiations are finished, the LNS-CP will create an L2TP LNS subscriber session on the LNS-UP ✨. The format of the messages is as follows:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]After that, the LNS-CP will trigger a AAA authentication 🔐. If the authentication result is positive, a PPP IP Control Protocol (IPCP) process will follow 🌈, and then the CP will update the session with the following message exchanges:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]5.4.3. L2TP LNS IPv6 Access 🧚
RG LAC UP(LNS) AAA CP(LNS)
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | L2TP Tunnel | L2TP Tunnel |
| | Negotiation | Negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP Session | L2TP Session |
| | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create Subscriber |
| | | Session Request |
| | 6|<-----via Ci-------|
| | | Create Subscriber |
| | | Session Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| | | | |
| |
| PPP IP6CP |
10|<--------------------------------------------->|
| |
| | | Update Subscriber |
| | | Session Request |
| | 11|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 12|------via Ci------>|
| | |
| ND Negotiation | ND Negotiation |
13|<------------------------->|<-----via Si------>|
| | |
| | | Update Subscriber |
| | | Session Request |
| | 14|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 15|------via Ci------>|
| | | |
Figure 26: L2TP LNS IPv6 AccessSteps 1-12 are the same as L2TP LNS IPv4 access 💜. Steps 1-5 finish the normal L2TP dial-up process 📞. When the L2TP session and tunnel negotiations are finished, the LNS-CP will create an L2TP LNS subscriber session on the LNS-UP 🎀. The format of the messages is as follows:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>After that, the LNS-CP will trigger a AAA authentication 🔐. If the authentication result is positive, a PPP IP6CP process will follow 🌈, and then the CP will update the session with the following message exchanges:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>Then, an ND negotiation will be triggered by the RG 🫧. After the ND negotiation, the CP will update the session with the following message exchanges:
<Update_Request Message> ::= <Common Header>
<L2TP-LAC Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.5. CGN (Carrier Grade NAT) 🌸
Okay so CGN is the one where the UP and CP team up to hand out shared public addresses. Bestie, the diagram is giving main character energy 💅
RG UP CP AAA
| | Public Address Block | |
| | Allocation Request | |
| 1|<--------via Ci-------->| |
| | Public Address Block | |
| | Allocation Reply | |
| 2|---------via Ci-------->| |
| Subscriber | | |
| Access Request| Subscriber | |
3|-------------->| Access Request | |
| 4|----------via Si------->| |
| | | AAA |
| | Subscriber | Req/Rep |
| Subscriber | Access Reply 5|<------------->|
| Access Reply 6|<---------via Si--------| |
7|<--------------| | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| | (with NAT information) | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | | with source |
| | | information |
| | 10|<------------->|
| | | Public IP + |
| | | Port Range |
| | | to Private IP|
| | | Mapping |
| | | |
Figure 27: CGN AccessSo steps 1-2 are the first bit: the CP hands the UP one or more CGN address blocks ✨. The two of them chat using these messages:
<Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV>
<Addr_Allocation_Ack Message> ::= <Common Header>
<Address Allocation Response TLV>Steps 3-9 are the general dial-up vibe for CGN mode 🎀. The specific flavours (IPoE, PPPoE, L2TP, etc.) get their own sections up above, so go check those out 🦋.
Also, if a subscriber is a CGN subscriber, once their session is created or updated, the UP reports the NAT information back to the CP 🫶. It does this by carrying the Subscriber CGN Port Range TLV in the Update_Response message.
5.6. L3 Leased Line Access 🧚
5.6.1. Web Authentication 🌈
Lowkey the most dramatic one so far 😭
RG UP CP AAA Web Server
| User traffic| | | |
1|------------>| | | |
| | User traffic | | |
| 2|-----via Si---->| AAA | |
| | | Req/Rep | |
| | 3|<-------->| |
| | Create Session | | |
| | Request | | |
| 4|<----via Ci-----| | |
| | Create Session | | |
| | Response | | |
| 5|----via Ci----->| | |
| | | | |
| HTTP traffic| | | |
6|------------>| | | |
| | | | |
| Redirect to | | | |
| Web URL | | | |
7|<------------| | | |
| | | | |
| |
8|-----------------Redirected to Web Server----------->|
| |
9|<----------------Push HTTP Log-in Page---------------|
| |
10|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 11|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 12|<-------->| |
| | | | |
| | Update Session | | |
| | Request | | |
| 13|<----via Ci-----| | |
| | Update Session | | |
| | Response | | |
| 14|----via Ci----->| | |
| | | | |
Figure 28: Web Authentication-Based L3 Leased Line AccessSo here's the tea. IP traffic from the RG is what kicks the CP into checking the RG 🕵️♀️. It looks at the source IP and chats with the AAA server. Once the RG passes, the CP sets up a matching subscriber session on the UP with these exchanges:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>Then the HTTP traffic from the RG gets redirected to a web server so the web auth can wrap up 🌸. Once that's passed, the CP kicks off another AAA authentication 💜. After that, the CP updates the session with these exchanges:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.6.2. User Traffic Trigger 🦋
This one is more of a "wait, who are you?" moment 👀
RG UP CP AAA
| | L3 access | |
| | control list | |
| 1|<----via Ci-----| |
| User | | |
| traffic | | |
2|------------>| | |
| | User traffic | |
| 3|-----via Si---->| |
| | | AAA |
| | | Req/Rep |
| | 4|<-------->|
| | | |
| | Create Session | |
| | Request | |
| 5|<----via Ci-----| |
| | Create Session | |
| | Response | |
| 6|----via Ci----->| |
| | | |
Figure 29: User Traffic Triggered L3 Leased Line AccessIn this case, the CP must install an access control list on the UP 🔥. The UP uses that list to decide whether or not an RG is legal. If the traffic comes from a legal RG, it gets redirected to the CP through the Si. The CP then triggers an AAA interchange with the AAA server 💅. After that, the CP creates a matching subscriber session on the UP with these exchanges:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>5.7. Multicast Service Access ✨
okay so multicast access is giving "the CP does the heavy lifting" 💅 Here's the flow in Figure 30:
RG UP CP AAA
| User Access | User Access | AAA |
| Request | Request | Req/Rep |
1|<----------->|<----via Si---->|<-------->|
| | | |
| | Create Session | |
| | Request | |
| 2|<----via Ci---->| |
| | | |
| | Create Session | |
| | Response | |
| 3|----via Ci----->| |
| | | |
| Multicast | | |
| negotiation | | |
4|<----------->| | |
| | | |
Figure 30: Multicast AccessMulticast access starts when the RG sends a user access request 🦋 That request gets redirected to the CP by the Si. Then the CP and the AAA server do a follow-up AAA interchange. Once authentication is done, the CP creates a multicast subscriber session on the UP using the messages below.
For IPv4, the Subscriber Policy TLV carries a Multicast-ProfileV4 sub-TLV:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<Subscriber Policy TLV>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]For IPv6, it's the same vibe, but the Subscriber Policy TLV carries a Multicast-ProfileV6 sub-TLV instead:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<Subscriber Policy TLV>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>6. S-CUSP Message Formats 🎀
okay bestie, every S-CUSP message is a common header plus a body made up entirely of TLVs 🧚 If a receiver gets a message with an unknown message type or a missing mandatory TLV, it MUST trigger an Error message (see Section 6.7) or a Response message with an Error Information TLV (see Section 7.6). Optional TLVs are the flexible ones. They may or may not be there, and the message formats in this document wrap them in square brackets so you can spot them 👑
This section covers the common S-CUSP message header and lists the defined messages. Multi-byte fields use network byte order 💜
6.1. Common Message Header 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Resv | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: S-CUSP Message Common HeaderVer(4 bits): the major version of the protocol. This document specifies version 1. Different major versions can have pretty different message structures and formats, but theVerfield is always in the same spot at the start of each message. A successful S-CUSP session needs the CP and the UP to both use the same major version, so this one matters 🫶Resv(4 bits): reserved. It MUST be sent as zero and ignored on receipt.Message-Type(8 bits): the message types defined in this document are listed in Section 8.1.Message-Length(16 bits): the total length of the S-CUSP message, including the common header, in bytes, as an unsigned integer.Transaction-ID(16 bits): used to identify requests, and it gets echoed back in any matching ACK/Response/Error message 🎀 It is RECOMMENDED that successive messages use a monotonically increasing value that wraps back to zero after0xFFFF. The content is an opaque value, so the receiver MUST NOT use it for anything except echoing it back in a matching response and, optionally, logging it 🙈
6.2. Control Messages 🦋
This document defines the following control messages:
+------+-----------------+------------------------------------+
| Type | Name | Notes and TLVs that can be carried |
+======+=================+====================================+
| 1 | Hello | Hello TLV, Keepalive TLV |
+------+-----------------+------------------------------------+
| 2 | Keepalive | A common header with the Keepalive |
| | | message type |
+------+-----------------+------------------------------------+
| 3 | Sync_Request | Synchronization request |
+------+-----------------+------------------------------------+
| 4 | Sync_Begin | Synchronization starts |
+------+-----------------+------------------------------------+
| 5 | Sync_Data | Synchronization data: TLVs |
| | | specified in Section 7 |
+------+-----------------+------------------------------------+
| 6 | Sync_End | End synchronization |
+------+-----------------+------------------------------------+
| 7 | Update_Request | TLVs specified in Sections 7.6-7.9 |
+------+-----------------+------------------------------------+
| 8 | Update_Response | TLVs specified in Sections 7.6-7.9 |
+------+-----------------+------------------------------------+
Table 2: Control Messages6.2.1. Hello Message 👋
The Hello message is the one that kicks off S-CUSP session establishment and version negotiation. You can read all the details in Section 4.1.1 🧚
<Hello Message> ::= <Common Header>
<Hello TLV>
<Keepalive TLV>
[<Error Information TLV>]The return code and negotiation result ride along in the Error Information TLV. Here's what they mean:
0: Success. Version negotiation success.1: Failure. Malformed message received.2: TLV-Unknown. One or more of the TLVs was not understood.1001: Version-Mismatch. The version negotiation fails. The S-CUSP session establishment phase fails.1002: Keepalive Error. The keepalive negotiation fails. The S-CUSP session establishment phase fails.1003: Timer Expires. The establishment timer expired. Session establishment phase fails.
6.2.2. Keepalive Message 💜
Each end of an S-CUSP session sends a Keepalive message periodically. It's basically the "you still there?" text 🫶 It's used to check whether the peer is still alive. The procedures are in Section 4.1.2.
<Keepalive Message> ::= <Common Header>6.2.3. Sync_Request Message 🍓
The Sync_Request message asks an S-CUSP peer to synchronize. Either the CP or the UP can ask its peer to sync data 💅
<Sync_Request Message> ::= <Common Header>A Sync_Request message may get a Sync_Begin message back from its peer. Sync_Begin is defined in Section 6.2.4.
6.2.4. Sync_Begin Message 🌈
Sync_Begin is the reply to a Sync_Request. It tells the requester whether synchronization can start 🙌
<Sync_Begin Message> ::= <Common Header>
<Error Information TLV>The return codes live in the Error Information TLV:
0: Success. Be ready to synchronize.1: Failure. Malformed message received.2: TLV-Unknown. One or more of the TLVs was not understood.2001: Synch-NoReady. The data to be synchronized is not ready.2002: Synch-Unsupport. The data synchronization is not supported.
6.2.5. Sync_Data Message ✨
Sync_Data carries the data being synchronized between the CP and the UP. It has the same function and format as Update_Request. The big difference is that a Sync_Data message never gets an ACK. If it causes an error, you get a Sync_End message instead 🥺
There are two scenarios:
- Synchronization from UP to CP: the resource data gets synced to the CP.
<Sync_Data Message> ::= <Common Header>
[<Interface Status TLV>]
[<Board Status TLV>]- Synchronization from CP to UP: all subscriber sessions get synced to the UP. The Subscriber TLVs here are the ones in Section 7.9. Which TLVs you actually send depends on the session data being synced. The process is the same as creating a specific session, so check Section 5 for more details 🌸
<Sync_Data Message> ::= <Common Header>
[<IPv4 Routing TLV>]
[<IPv6 Routing TLV>]
[<Subscriber TLVs>]6.2.6. Sync_End Message 🎀
Sync_End marks the end of a synchronization process 🏁
<Sync_End Message> ::= <Common Header>
<Error Information TLV>The return/error codes:
0: Success. Synchronization finished.1: Failure. Malformed message received.2: TLV-Unknown. One or more of the TLVs was not understood.
6.2.7. Update_Request Message 🦋
Update_Request is the multipurpose one. It can create, update, and delete subscriber sessions on a UP 💖
For session operations, the Oper field in the carried TLVs decides what happens. As defined in Section 7.1, the Oper field can be set to Update or Delete when a TLV rides in an Update_Request message. Update means create or update a subscriber session. Delete means please delete the matching session 😭
<Update_Request Message> ::= <Common Header>
[<IPv4 Routing TLV>]
[<IPv6 Routing TLV>]
[<Subscriber TLVs>]The Subscriber TLVs are the ones in Section 7.9. Every Update_Request gets an Update_Response back, which is defined in Section 6.2.8 ✨
6.2.8. Update_Response Message 💅
okay so the Update_Response message is the reply to an Update_Request, bestie 🫶 its whole job is to confirm the update or reject it if something went wrong 🙅♀️ here's the shape:
<Update_Response Message> ::= <Common Header>
[<Subscriber CGN Port Range TLV>]
<Error Information TLV>The return/error codes live inside the Error Information TLV, and they're listed here 📋✨
0: Success.
1: Failure. Malformed message received.
2: TLV-Unknown. One or more of the TLVs was not understood.
3001: Pool-Mismatch. The corresponding address pool cannot be
found.
3002: Pool-Full. The address pool is fully allocated, and no
address segment is available.
3003: Subnet-Mismatch. The address pool subnet cannot be found.
3004: Subnet-Conflict. Subnets in the address pool have been
classified into other clients.
4001: Update-Fail-No-Res. The forwarding table fails to be delivered
because the forwarding resources are insufficient.
4002: QoS-Update-Success. The QoS policy takes effect.
4003: QoS-Update-Sq-Fail. Failed to process the queue in the QoS
policy.
4004: QoS-Update-CAR-Fail. Processing of the CAR in the QoS policy
fails.
4005: Statistic-Fail-No-Res. Statistics processing failed due to
insufficient statistics resources.6.3. Event Message 📊
the Event message is how we report subscriber session traffic statistics and detection info 🌸 the format goes like this:
<Event Message> ::= <Common Header>
[<Subscriber Traffic Statistics Report TLV>]
[<Subscriber Detection Result Report TLV>]6.4. Report Message 🛰️
the Report message is for reporting board and interface status on a UP 🧚 format:
<Report Message> ::= <Common Header>
[<Board Status TLVs>]
[<Interface Status TLVs>]6.5. CGN Messages 🌈
this doc defines the following resource allocation messages, and here they are in one neat table 💖
+------+---------------------+-----------------------------+
| Type | Message Name | TLV that is carried |
+======+=====================+=============================+
| 200 | Addr_Allocation_Req | Address Allocation Request |
+------+---------------------+-----------------------------+
| 201 | Addr_Allocation_Ack | Address Allocation Response |
+------+---------------------+-----------------------------+
| 202 | Addr_Renew_Req | Address Renewal Request |
+------+---------------------+-----------------------------+
| 203 | Addr_Renew_Ack | Address Renewal Response |
+------+---------------------+-----------------------------+
| 204 | Addr_Release_Req | Address Release Request |
+------+---------------------+-----------------------------+
| 205 | Addr_Release_Ack | Address Release Response |
+------+---------------------+-----------------------------+
Table 3: Resource Allocation Messages6.5.1. Addr_Allocation_Req Message 🎀
the Addr_Allocation_Req message is how you ask for CGN address allocation 🙏 format:
<Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV>6.5.2. Addr_Allocation_Ack Message 🦋
the Addr_Allocation_Ack message is the reply to an Addr_Allocation_Req message ✨ format:
<Addr_Allocation_Ack Message> ::= <Common Header>
<Address Allocation Response TLV>6.5.3. Addr_Renew_Req Message 🔁
the Addr_Renew_Req message is used to ask for an address renewal 💜 format:
<Addr_Renew_Req Message> ::= <Common Header>
<Address Renewal Request TLV>6.5.4. Addr_Renew_Ack Message 🌷
the Addr_Renew_Ack message answers an Addr_Renew_Req message 🫧 this is its format. (Heads up, the original spec writes the name Addr_Renew_Req in this message's own description. That's the spec's wording, not mine, so I've left it exactly as written.)
<Addr_Renew_Ack Message> ::= <Common Header>
<Address Renewal Response TLV>6.5.5. Addr_Release_Req Message 🗝️
the Addr_Release_Req message is used to request an address release 🕊️ format:
<Addr_Release_Req Message> ::= <Common Header>
<Address Release Request TLV>6.5.6. Addr_Release_Ack Message 🍓
the Addr_Release_Ack message is the response to an Addr_Release_Req message 💅 format:
<Addr_Release_Ack Message> ::= <Common Header>
<Address Release Response TLV>6.6. Vendor Message 🏷️
the Vendor message, together with the Vendor TLV and Vendor sub-TLV, can be used by vendors to extend S-CUSP 🧩 its Message-Type is 11 💜 and if the receiver doesn't recognize the message, an Error message gets sent back to the sender 🙅♀️
the format of the Vendor message is:
<Vendor Message> ::= <Common Header>
<Vendor TLV>
[<any other TLVs as specified by the vendor>]6.7. Error Message 🚨
the Error message exists to send critical error info back to the sender 😭 if a receiver doesn't support the type of message it got, it MUST return an Error message to the sender 🚨
the format of the Error message is:
<Error Message> ::= <Common Header>
<Error Information TLV>7. S-CUSP TLVs and Sub-TLVs 🎀
this section covers three things, bestie 👑
- the format of the TLVs that show up in S-CUSP messages,
- the format of the sub-TLVs that live inside the values of some TLVs, and
- the format of some basic data fields that appear inside TLVs or sub-TLVs.
check Section 8 for a full list of every defined TLV and sub-TLV 📚
7.1. Common TLV Header 🌸
S-CUSP messages are the common header from Section 6.1 followed by TLVs, and those TLVs follow the format in this section ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper | TLV-Type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Common TLV Header- Oper (4 bits): for Message-Types that operate on a data set, the Oper field is read as Update, Delete, or Reserved, as laid out in Section 8.3. For every other Message-Type, the Oper field MUST be sent as zero and ignored on receipt 🫶
- TLV-Type (12 bits): the type of a TLV. It decides how the Value field gets interpreted and formatted. See Section 8.2 🧁
- TLV-Length (2 bytes): the length of the Value portion of the TLV in bytes, as an unsigned integer 📏
- Value (variable length): the chunk of the TLV whose size TLV-Length tells you about. It's made of fields, often using one of the basic data field types (see Section 7.2) and sub-TLVs (see Section 7.3) 💖
7.2. Basic Data Fields 🧱
this section pins down the binary format of several standard basic data fields that get reused across the rest of the spec 🤓
- STRING: 0 to 255 octets. It's encoded as a sub-TLV (see Section 7.3) so its length is included. S-CUSP uses this type to hold convenient labels that network operators can use to configure and debug their networks and to read S-CUSP messages 🏷️ subscribers won't normally see these labels. They're normally read as ASCII [RFC20] 🔤
- MAC-Addr: 6 octets. Ethernet MAC address [RFC7042] 🖥️
- IPv4-Address: 8 octets. 4 octets of the IPv4 address value, followed by a 4-octet address mask in the format XXX.XXX.XXX.XXX 🌐
- IPv6-Address: 20 octets. 16 octets of the IPv6 address, followed by a 4-octet integer n in the range of 0 to 128. That integer gives the address mask as the one's complement of 2**(128-n) - 1 🌌
- VLAN ID: 2 octets. Laid out as follows [802.1Q]: 🎀
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRI |D| VLAN-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PRI: Priority. Default value 7 🔥
- D: Drop Eligibility Indicator (DEI). Default value 0 🙈
- VLAN-ID: an unsigned integer in the range 1-4094. (0 and 4095 are not valid VLAN IDs [802.1Q].) 🚫
7.3. Sub-TLV Format and Sub-TLVs 🧩
sometimes the Value portion of a TLV (see Section 7.1) holds one or more sub-TLVs, and they're formatted like this 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 33: Sub-TLV Header- Type (2 bytes): the type of a sub-TLV. The Type field decides how the Value field gets interpreted and formatted. Sub-TLV type values mean the same thing no matter which TLV type they're nested in. See Section 8.4 🎯
- Length (2 bytes): the length of the Value portion of the sub-TLV in bytes, as an unsigned integer 📐
- Value (variable length): the Value portion of the sub-TLV, sized by Length 💜
the sub-TLVs currently specified are defined in the following subsections 🌈
7.3.1. Name Sub-TLVs ✨
okay bestie, this one's giving "name tag energy" 🏷️ these name sub-TLVs carry the name of whatever object they're attached to. each one is anywhere from 1 to 255 octets long 💖 and the value is a STRING that gets padded with zero octets until its length is a multiple of 4 🎀 (very neat, very tidy, very me)
Here's the whole lineup in Table 4 💅
+------+---------------------+------------------------------------+
| Type | Sub-TLV Name | Meaning |
+======+=====================+====================================+
| 1 | VRF-Name | The name of a VRF |
+------+---------------------+------------------------------------+
| 2 | Ingress-QoS-Profile | The name of an ingress QoS profile |
+------+---------------------+------------------------------------+
| 3 | Egress-QoS-Profile | The name of an egress QoS profile |
+------+---------------------+------------------------------------+
| 4 | User-ACL-Policy | The name of an ACL policy |
+------+---------------------+------------------------------------+
| 5 | Multicast-ProfileV4 | The name of an IPv4 multicast |
| | | profile |
+------+---------------------+------------------------------------+
| 6 | Multicast-ProfileV6 | The name of an IPv6 multicast |
| | | profile |
+------+---------------------+------------------------------------+
| 9 | NAT-Instance | The name of a NAT instance |
+------+---------------------+------------------------------------+
| 10 | Pool-Name | The name of an address pool |
+------+---------------------+------------------------------------+
Table 4: Name Sub-TLVs7.3.2. Ingress-CAR Sub-TLV 🚦
so the Ingress-CAR sub-TLV is all about the upstream Committed Access Rate (CAR) parameters that you're authorized for 🌸 its sub-TLV type is 7 and its sub-TLV length is 16 🦋 the layout is in Figure 34 below, bestie 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Ingress-CAR Sub-TLVhere's what each field means 🫶
- CIR (4 bytes): Guaranteed rate in bits/second.
- PIR (4 bytes): Burst rate in bits/second.
- CBS (4 bytes): The token bucket in bytes.
- PBS (4 bytes): Burst token bucket in bytes.
all of these are unsigned integers 🔢 if you want the deeper dive on CIR, PIR, CBS, and PBS, go check [RFC2698] 📚
7.3.3. Egress-CAR Sub-TLV 🌈
same energy as the ingress one, just flipped 🔄 the Egress-CAR sub-TLV carries the authorized downstream Committed Access Rate (CAR) parameters ✨ its sub-TLV type is 8 and its sub-TLV length is 16 octets 💜 the value part looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: Egress-CAR Sub-TLVthe fields are the same as before 💅
- CIR (4 bytes): Guaranteed rate in bits/second.
- PIR (4 bytes): Burst rate in bits/second.
- CBS (4 bytes): The token bucket in bytes.
- PBS (4 bytes): Burst token bucket in bytes.
all unsigned integers again, and the CIR, PIR, CBS, and PBS details are in [RFC2698] 🎀
7.3.4. If-Desc Sub-TLV 🧚
the If-Desc sub-TLV is how you designate an interface 🦋 it's optional, and it can ride along in any TLV that has an If-Index or Out-If-Index field 💖 it works as a locally unique identifier inside a BNG, so it's basically a little ID card for the interface 🪪
its sub-TLV type is 11 and its sub-TLV length is 12 octets 🌸 the format depends on the If-Type (see Section 8.6) 👀 here are both layouts:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (1-5)| Chassis | Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Slot | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc Sub-TLV (Physical Port)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (6-7) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logic-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc Sub-TLV (Virtual Port)
Figure 36: If-Desc Sub-TLV Formatsand here's the breakdown 🫶
- If-Type: 8 bits in length. The value of this field indicates the type of an interface. The If-Type values defined in this document are listed in Section 8.6.
- Chassis (8 bits): Identifies the chassis that the interface belongs to.
- Slot (16 bits): Identifies the slot that the interface belongs to.
- Sub-Slot (16 bits): Identifies the sub-slot the interface belongs to.
- Port Number (16 bits): An identifier of a physical port/interface (e.g., If-Type: 1-5). It is locally significant within the slot/sub-slot.
- Sub-Port Number (32 bits): An identifier of the sub-port. Locally significant within its "parent" port (physical or virtual).
- Logic-ID (32 bits): An identifier of a virtual interface (e.g., If-Type: 6-7).
7.3.5. IPv6 Address List Sub-TLV 🌷
the IPv6 Address List sub-TLV is used to convey one or more IPv6 addresses 💜 it gets carried inside the IPv6 Subscriber TLV 🎀 its sub-TLV type is 12, and its sub-TLV length is variable 🦋
here's the value part layout 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: IPv6 Address List Sub-TLV- IPv6 Address (IPv6-Address): Each IP Address is of type IP-Address and carries an IPv6 address and length.
7.3.6. Vendor Sub-TLV 🎁
the Vendor sub-TLV lives inside the Value portion of the Vendor TLV (see Section 7.13) 💖 its big job is a Sub-Type that effectively extends the sub-TLV type in the sub-TLV header, and it also gives you versioning for Vendor sub-TLVs 🔥
the value part is laid out like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (other as specified by vendor) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: Vendor Sub-TLVthe fields work like this 🫶
- Sub-TLV type: 13.
- Sub-TLV length: Variable.
- Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865].
- Sub-Type (2 bytes): Used by the vendor to distinguish multiple different sub-TLVs.
- Sub-Type-Version (2 bytes): Used by the vendor to distinguish different versions of a vendor-defined sub-TLV Sub-Type.
- Value: As specified by the vendor.
once the Vendor-ID is recognized, vendor code handles the sub-TLV, so the rest of it can be organized however the vendor wants 🌈 but it's desirable for a vendor to be able to define multiple different Vendor sub-TLVs and to keep track of versions of its vendor-defined sub-TLVs, so it is RECOMMENDED that the vendor assigns a Sub-Type value for each of its sub-TLVs that's different from the other Sub-Type values that vendor has already used 💅 and when a vendor changes a vendor-defined sub-TLV in a way that could be incompatible with a previous definition, the vendor SHOULD increase the value in the Sub-Type-Version field 🦋✨
⚠️ heads up: keep the Sub-Type and Sub-Type-Version numbers straight, because that's how the vendor's sub-TLVs stay distinguishable and versioned 💜
7.4. Hello TLV 🎀
okay so the Hello TLV rides along in the Hello message for version and capabilities negotiation 🫶 it's basically the "hey, what do you speak?" moment between peers. It tells you the S-CUSP sub-version and capabilities the sender supports. Here's the value part layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerSupported |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: Hello TLVWhere:
- TLV type: 100.
- TLV length: 12 octets.
- VerSupported: 32 bits in length. It's a bit map of the Sub-Versions of S-CUSP that the sender supports. This document specifies Sub-Version zero of Major Version 1, that is, Version 1.0. The VerSupported field MUST be nonzero. The VerSupported bits are numbered from 0 as the most significant bit. Bit 0 indicates support of Sub-Version zero, bit 1 indicates support of Sub-Version one, etc. 💜
- Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS [RFC2865].
- Capabilities: 32 bits in length. Flags that indicate the support of particular capabilities by the sender of the Hello. No capabilities are defined in this document, so implementations of the version specified herein will set this field to zero. The Capabilities field of the Hello TLV MUST be checked before any other TLVs in the Hello because capabilities defined in the future might extend existing TLVs or permit new TLVs. ⭐
After the Hello messages are exchanged, the CP and UP each do a logical AND of the Sub-Version they support, and separately do a logical AND of their Capabilities fields. Main character negotiation energy 👑
If the result of the AND of the Sub-Versions is zero, then no session can be established and the connection gets torn down 💀 That's the hard no. If the result is nonzero, the session uses the highest Sub-Version supported by both the CP and the UP ✨
For example, say one side supports Sub-Versions 1, 3, 4, and 5 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 (VerSupported = 0x38000000). Then 3 and 4 are the Sub-Versions in common, and 4 is the highest one both sides support. So Sub-Version 4 is what gets used for the negotiated session 🦋
The logical AND of the Capabilities bits shows which extra capabilities both sides support. If the result is zero, there are no such capabilities, so none can be used during the session. If it's nonzero, it shows the extra capabilities that can be used during the session. The CP and the UP MUST NOT use a capability unless both advertise support. no shortcuts, periodt 🙅♀️
7.5. Keepalive TLV 💓
The Keepalive TLV is carried in the Hello message, and it gives you the timing info for this feature. Here's the value part:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive | DeadTimer | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: Keepalive TLVWhere:
- TLV type: 102.
- TLV length: 4 octets.
- Keepalive (8 bits): Indicates the maximum interval (in seconds) between two consecutive S-CUSP messages sent by the sender of the message containing this TLV, as an unsigned integer. The minimum value for the Keepalive field is 1 second. When set to 0, once the session is established, no further Keepalive messages are sent to the remote peer. A RECOMMENDED value for the Keepalive frequency is 30 seconds. 🌸
- DeadTimer (8 bits in length): Specifies the amount of time, as an unsigned integer number of seconds, after which the S-CUSP peer can declare the session with the sender of the Hello message to be down, if no S-CUSP message has been received. The DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive. 🍓
- Reserved: The Reserved bits MUST be sent as zero and ignored on receipt. 🫧
7.6. Error Information TLV 🚨
The Error Information TLV is a common TLV that can show up in lots of responses (like the Update_Response message) and ACK messages (like the Addr_Allocation_Ack message). Its whole job is to tell you about an error in the S-CUSP message you just got. Here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message-Type | Reserved | TLV-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Error Information TLVWhere:
- TLV type: 101.
- TLV length: 8 octets.
- Message-Type (1 byte): This parameter is the message type of the message containing an error.
- Reserved (1 byte): MUST be sent as zero and ignored on receipt.
- TLV-Type (2 bytes): Indicates which TLV caused the error.
- Error Code: 4 bytes in length. Indicates the specific Error Code (see Section 8.5). 🙈
7.7. BAS Function TLV 🧚
The BAS Function TLV is how a CP controls the access mode, authentication methods, and other related functions of an interface on a UP. The value part looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Mode | Auth-Method4 | Auth-Method6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: BAS Function TLVWhere:
- TLV type: 1.
- TLV length: Variable.
- If-Index: 4 bytes in length, a unique identifier of an interface of a BNG.
- Access-Mode: 1 byte in length. Indicates the access mode of the interface. The defined values are listed in Section 8.7.
- Auth-Method4: 1 byte in length. Indicates the authentication on this interface for the IPv4 scenario. This field is defined as a bitmap. The bits defined in this document are listed in Section 8.8. Other bits are reserved and MUST be sent as zero and ignored on receipt. 🔐
- Auth-Method6: 1 byte in length. Indicates the authentication on this interface for the IPv6 scenario. This field is defined as a bitmap. The bits defined in this document are listed in Section 8.8. Other bits are reserved and MUST be sent as zero and ignored on receipt. 🔐
- Sub-TLVs: The IF-Desc sub-TLV can be carried.
- If-Desc sub-TLV: Carries the interface information.
The Flags field is laid out like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 43: Interface FlagsWhere, bit by bit:
- F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a subscriber to go online.
- 1: Enabled.
- 0: Disabled.
- S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a subscriber to go online.
- 1: Enabled.
- 0: Disabled.
- A (ARP Trigger) bit: Indicates whether ARP packets can trigger a subscriber to go online.
- 1: Enabled.
- 0: Disabled.
- N (ND Trigger) bit: Indicates whether ND packets can trigger a subscriber to go online.
- 1: Enabled.
- 0: Disabled.
- I (IPoE-Flow-Check): Used for UP detection.
- 1: Enable traffic detection.
- 0: Disable traffic detection.
- P (PPP-Flow-Check) bit: Used for UP detection.
- 1: Enable traffic detection.
- 0: Disable traffic detection.
- X (ARP-Proxy) bit: Indicates whether ARP proxy is enabled on the interface.
- 1: The interface is enabled with ARP proxy and can process ARP requests across different network ports and VLANs.
- 0: The ARP proxy is not enabled on the interface, and only the ARP requests of the same network port and VLAN are processed.
- Y (ND-Proxy) bit: Indicates whether ND proxy is enabled on the interface.
- 1: The interface is enabled with ND proxy and can process ND requests across different network ports and VLANs.
- 0: The ND proxy is not enabled on the interface, and only the ND requests of the same network port and VLAN are processed.
- MBZ: Reserved bits that MUST be sent as zero and ignored on receipt. ✨
7.8. Routing TLVs 🛣️
Typically, once an S-CUSP session is up between a UP and a CP, the CP allocates one or more blocks of IP addresses to the UP. Those addresses get handed out to subscribers who dial-up (as defined in Section 4.3.1) to the UP. So other nodes in the network can figure out how to reach those addresses, the CP needs to install one or more routes that reach them on the UP, and tell the UP to advertise those routes to the network. It's a whole chain of "you go here, then you tell everyone" 📣
The Routing TLVs are how a CP tells a UP about updates to network routing information. They can be carried in the Update_Request message and the Sync_Data message. 🦋
7.8.1. IPv4 Routing TLV ✨
okay bestie, this TLV is the one that carries IPv4 routing info around 🛣️🦋 it's giving "here's everything you need to know about a route, all in one packet" 💅
Here's the layout, no cap:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 44: IPv4 Routing TLVWhere:
- TLV type: 7.
- TLV length: Variable.
- User-ID: 4 bytes in length. This field carries the user identifier. It is filled with all Fs when a non-user route is delivered to the UP. 🌸
- Dest-Address (IPv4-Address type): Identifies the destination address. 🎀
- Next-Hop (IPv4-Address type): Identifies the next-hop address. 🧚
- Out-If-Index (4 bytes): Indicates the interface index. 💜
- Cost (4 bytes): The cost value of the route. 💖
- Tag (4 bytes): The tag value of the route. 🍓
- Route-Type (2 bytes): The value of this field indicates the route type. The values defined in this document are listed in Section 8.9. ✨
- Advertise-Flag: 1 bit shown as "A" in the figure above (Figure 44). Indicates whether the UP should advertise the route. The following flag values are defined:
0: Not advertised.1: Advertised.
- Sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried.
- VRF-Name sub-TLV: Indicates which VRF the route belongs to.
- If-Desc sub-TLV: Carries the interface information.
- Reserved: The Reserved field MUST be sent as zero and ignored on receipt. 🙈
7.8.2. IPv6 Routing TLV 🌈
this one is the IPv6 twin of the last TLV, and it's serving the same main character energy but for the newer address family 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 45: IPv6 Routing TLVWhere:
- TLV type: 8.
- TLV length: Variable.
- User-ID: 4 bytes in length. This field carries the user identifier. This field is filled with all Fs when a non-user route is delivered to the UP. 🌸
- IPv6 Dest-Address (IPv6-Address type): Identifies the destination address. 🎀
- IPv6 Next-Hop (IPv6-Address type): Identifies the next-hop address. 🧚
- Out-If-Index (4 bytes): Indicates the interface index. 💜
- Cost (4 bytes): This is the cost value of the route. 💖
- Tag (4 bytes): The tag value of the route. 🍓
- Route-Type (2 bytes): The value of this field indicates the route type. The values defined in this document are listed in Section 8.9. ✨
- Advertise-Flag: 1 bit shown as "A" in the figure above (Figure 45). Indicates whether the UP should advertise the route. The following flags are defined:
0: Not advertised.1: Advertised.
- Sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried.
- VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs.
- If-Desc sub-TLV: Carries the interface information.
- Reserved: The Reserved field MUST be sent as zero and ignored on receipt. 🙈
7.9. Subscriber TLVs 💅
the Subscriber TLVs are the ones a CP uses to send the basic info about a user over to a UP, so the UP knows who's who 🫶
7.9.1. Basic Subscriber TLV 🎀
this is the everyday one for every kind of access subscriber. it rides along inside an Update_Request message 💌
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Oper-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Type |Sub-Access-Type| Account-Type | Address Family|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect-Times | Detect-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 46: Basic Subscriber TLVWhere:
- TLV type: 2.
- TLV length: Variable.
- User-ID (4 bytes): The identifier of a subscriber. 🌸
- Session-ID (4 bytes): Session ID of a PPPoE subscriber. The value zero identifies a non-PPPoE subscriber. 🧚
- User-MAC (MAC-Addr type): The MAC address of a subscriber. 💜
- Oper-ID (1 byte): Indicates the ID of an operation performed by a user. This field is carried in the response from the UP. 💖
- Reserved (1 byte): MUST be sent as zero and ignored on receipt. 🙈
- Access-Type (1 byte): Indicates the type of subscriber access. Values defined in this document are listed in Section 8.10. 🍓
- Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP relay is used.
0: Reserved.1: PPP Relay (for LAC).2: PPP termination (for LNS).
- Account-Type (1 byte): Indicates whether traffic statistics are collected independently.
0: Collects statistics on IPv4 and IPv6 traffic of terminals independently.1: Collects statistics on IPv4 and IPv6 traffic of terminals.
- Address Family (1 byte): The type of IP address.
1: IPv4.2: IPv6.3: Dual stack.
- C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. The default value of PRI is 7, the value of DEI is 0, and the value of VID is 1-4094. The PRI value can also be obtained by parsing terminal packets. 🎀
- P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that for C-VID. ✨
- Detect-Times (2 bytes): Number of detection timeout times. The value 0 indicates that no detection is performed. ⏰
- Detect-Interval (2 bytes): Detection interval in seconds. 🦋
- If-Index (4 bytes): Interface index. 💅
- Sub-TLVs: The VRF-Name sub-TLV and If-Desc sub-TLV can be carried.
- VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs.
- If-Desc sub-TLV: Carries the interface information.
- Reserved: The Reserved field MUST be sent as zero and ignored on receipt. 🙈
7.9.2. PPP Subscriber TLV 🌸
this one carries a user's PPP info from a CP over to a UP. it shows up in an Update_Request message whenever PPPoE or L2TP access is in play 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSS-Value | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 47: PPP Subscriber TLVWhere:
- TLV type: 3.
- TLV length: 12 octets.
- User-ID (4 bytes): The identifier of a subscriber. 🌸
- MSS-Value (2 bytes): Indicates the MSS value (in bytes). 🎀
- MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled.
0: Disabled.1: Enabled.
- MRU (2 bytes): PPPoE local MRU (in bytes). 💜
- Magic-Number (4 bytes): Local magic number in PPP negotiation packets. 💖
- Peer-Magic-Number (4 bytes): Remote peer magic number. 🍓
- Reserved: The Reserved fields MUST be sent as zero and ignored on receipt. 🙈
7.9.3. IPv4 Subscriber TLV ✨
Okay bestie, this one is the IPv4 Subscriber TLV 💖 It carries IPv4 info for a BNG user, and it rides along in an Update_Request message whenever IPv4 IPoE or PPPoE access is in use 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway-IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 48: IPv4 Subscriber TLVSo here's the breakdown 🎀
- TLV type:
4. - TLV length: Variable.
User-ID(4 bytes): the identifier of a subscriber 🧚User-IPv4(IPv4-Address): the subscriber's IPv4 address.Gateway-IPv4(IPv4-Address): the subscriber's gateway address.Portal-Force (P)(1 bit): push advertisement 🌸0: Off.1: On.
Web-Force (W)(1 bit): push IPv4 Web 🍓0: Off.1: On.
Echo-Enable (E)(1 bit): UP returns ARP Req or PPP Echo 🫶0: Off.1: On.
IPv4-URPF (U)(1 bit): the User Unicast Reverse Path Forwarding (URPF) flag 💅0: Off.1: On.
MTU(2 bytes): the MTU value. The default value is1500.VRF-Name Sub-TLV: tells you which VRF the subscriber belongs to 👑Reserved: the Reserved field MUST be sent as zero and ignored on receipt. No exceptions, periodt 🙈
7.9.4. IPv6 Subscriber TLV 🦋
The IPv6 Subscriber TLV is the IPv6 version of that energy 🌈 It carries IPv6 info for a BNG user and shows up in an Update_Request message when IPv6 IPoE or PPPoE access is used. The layout is a bit thicker because it has to hold a whole list of addresses ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User PD-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway ND-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Link-Local-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name Sub-TLV (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 49: IPv6 Subscriber TLVThe field rundown 🎀
- TLV type:
5. - TLV length: Variable.
User-ID(4 bytes): the identifier of a subscriber 🧚User PD-Addresses(IPv6 Address List): a list of Prefix Delegation (PD) addresses for the subscriber.User ND-Addresses(IPv6 Address List): a list of Neighbor Discovery (ND) addresses for the subscriber.User Link-Local-Address(IPv6-Address): the subscriber's link-local address 🌸IPv6 Interface ID(8 bytes): the identifier of an IPv6 interface.Portal-Force1 bit (P): push advertisement 🍓0: Off.1: On.
Web-Force1 bit (W): push IPv6 Web 💜0: Off.1: On.
Echo-Enable1 bit (E): the UP returns ARP Req or PPP Echo 🫶0: Off.1: On.
IPv6-URPF1 bit (U): the User Reverse Path Forwarding (URPF) flag 💅0: Off.1: On.
MTU(2 bytes): the MTU value. The default value is1500.VRF-Name Sub-TLV: the VRF the subscriber belongs to 👑Reserved: the Reserved field MUST be sent as zero and ignored on receipt 🙈
7.9.5. IPv4 Static Subscriber Detect TLV 🧚
This one is for static access subscribers. It's carried in an Update_Request message when IPv4 static access on a UP needs to be enabled, so think of it as the "hey, turn this on" signal 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 50: IPv4 Static Subscriber TLVThe breakdown 🎀
- TLV type:
9. - TLV length: Variable.
If-Index(4 bytes): the interface index of the interface the subscriber will dial up from 🌈C-VID(VLAN-ID): the inner VLAN ID. The value0means the VLAN ID is invalid. A valid value is1-4094.P-VID(VLAN-ID): the outer VLAN ID. The value0means the VLAN ID is invalid. The format is the same as that of the C-VID. A valid value is1-4094.User Address(IPv4-Addr): the user's IPv4 address.Gateway Address(IPv4-Addr): the gateway's IPv4 address.User-MAC(MAC-Addr type): the MAC address of the subscriber.Sub-TLVs: the VRF-Name and If-Desc sub-TLVs may be carried ⭐VRF-Name sub-TLV: tells you which VRF the subscriber belongs to.If-Desc sub-TLV: carries the interface information.
Reserved: the Reserved field MUST be sent as zero and ignored on receipt 💀
7.9.6. IPv6 Static Subscriber Detect TLV 💜
Same vibe as the IPv4 static one, just for IPv6 ✨ It gets carried in an Update_Request message when it's needed to enable IPv6 static subscriber detection on a UP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 51: IPv6 Static Subscriber Detect TLVThe breakdown 🎀
- TLV type:
10. - TLV length: Variable.
If-Index(4 bytes): the interface index of the interface the subscriber will dial up from 🌸C-VID(VLAN-ID): the inner VLAN ID. The value0means the VLAN ID is invalid. A valid value is1-4094.P-VID(VLAN-ID): the outer VLAN ID. The value0means the VLAN ID is invalid. The format is the same as that the of C-VID. A valid value is1-4094.User Address(IPv6-Address type): the subscriber's IPv6 address.Gateway Address(IPv6-Address type): the gateway's IPv6 address.User-MAC(MAC-Addr type): the MAC address of the subscriber.Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carriedVRF-Name sub-TLV: tells you which VRF the subscriber belongs to 👑If-Desc sub-TLV: carries the interface information.
Reserved: the Reserved field MUST be sent as zero and ignored on receipt 🫶
7.9.7. L2TP-LAC Subscriber TLV 🦋
This is the L2TP-LAC Subscriber TLV, and it's for subscribers using L2TP LAC access. It's carried in an Update_Request message whenever L2TP LAC access is in use. It's the most compact one of the bunch, which is honestly a 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 52: L2TP-LAC Subscriber TLVThe breakdown 🎀
- TLV type:
11. - TLV length:
12octets. User-ID(4 bytes): the identifier of a user/subscriber 🧚Local-Tunnel-ID(2 bytes): the local ID of the L2TP tunnel.Local-Session-ID(2 bytes): the local session ID with the L2TP tunnel 🌈Remote-Tunnel-ID(2 bytes): the identifier of the L2TP tunnel at the remote endpoint.Remote-Session-ID(2 bytes): the session ID of the L2TP tunnel at the remote endpoint 🍓
7.9.8. L2TP-LNS Subscriber TLV ✨
okay so the L2TP-LNS Subscriber TLV exists to carry the info for an L2TP LNS access subscriber 🫶 it shows up in an Update_Request message whenever L2TP LNS access is in use 💅
The TLV value part looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 53: L2TP-LNS Subscriber TLVHere's the breakdown 🧚
- TLV type: 12.
- TLV length: 12 octets.
- User-ID (4 bytes): The identifier of a user/subscriber.
- Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
- Local-Session-ID (2 bytes): The local session ID with the L2TP tunnel.
- Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at the remote endpoint.
- Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at the remote endpoint.
7.9.9. L2TP-LAC Tunnel TLV 🦋
the L2TP-LAC Tunnel TLV is for carrying info about the L2TP LAC tunnel 🌸 it gets sent in the Update_Request message when L2TP LAC access is used, so it's giving "tunnel details, served" 🍓
the TLV value part looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 54: L2TP-LAC Tunnel TLVThe fields, bestie 💜
- TLV type: 13.
- TLV length: Variable.
- Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
- Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel.
- Source-Port (2 bytes): The source UDP port number of an L2TP subscriber.
- Dest-Port (2 bytes): The destination UDP port number of an L2TP subscriber.
- Source-IP (IPv4/v6): The source IP address of the tunnel.
- Dest-IP (IPv4/v6): The destination IP address of the tunnel.
- VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel belongs.
7.9.10. L2TP-LNS Tunnel TLV 🌈
the L2TP-LNS Tunnel TLV is the LNS-side twin of the one we just did 👯♀️ it carries info about the L2TP LNS tunnel and shows up in the Update_Request message when L2TP LNS access is used. same energy, different side of the tunnel 🎀
the TLV value part:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 55: L2TP-LNS Tunnel TLVThe breakdown 💅
- TLV type: 14.
- TLV length: Variable.
- Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
- Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel.
- Source-Port (2 bytes): The source UDP port number of an L2TP subscriber.
- Dest-Port (2 bytes): The destination UDP port number of an L2TP subscriber.
- Source-IP (IPv4/v6): The source IP address of the tunnel.
- Dest-IP (IPv4/v6): The destination IP address of the tunnel.
- VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel belongs.
7.9.11. Update Response TLV 🫧
the Update Response TLV is how the operation result of an update request gets sent back 🔁 it rides in the Update_Response message, responding to the Update_Request message. it's literally the "did it work??" reply ✨
the value part of this TLV is formatted like so:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-Trans-ID | Oper-Code | Oper-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 56: Update Response TLVWhere it's at 🧚
- TLV type: 302.
- TLV length: 12.
- User-ID (4 bytes): A unique identifier of a user/subscriber.
- User-Trans-ID (1 byte): In the case of dual-stack access or when modifying a session, User-Trans-ID is used to identify a user operation transaction. It is used by the CP to correlate a response to a specific request.
- Oper-Code (1 byte): Operation code.
- 1: Update.
- 2: Delete.
- Oper-Result (1 byte): Operation Result.
- 0: Success.
- Others: Failure.
- Error-Code (4 bytes): Operation failure cause code. For details, see Section 8.5.
- Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
7.9.12. Subscriber Policy TLV 📜
the Subscriber Policy TLV carries the policies that get applied to a subscriber 🎀 it's carried in the Update_Request message, so it's the "here's how to treat this user" card 👑
the TLV value part looks like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-Priority | E-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 57: Subscriber Policy TLVThe breakdown, periodt 💖
- TLV type: 6.
- TLV length: Variable.
- User-ID (4 bytes): The identifier of a user/subscriber.
- Ingress-Priority (1 byte): Indicates the upstream priority. The value range is 0~7.
- Egress-Priority (1 byte): Indicates the downstream priority. The value range is 0~7.
- Sub-TLVs: The sub-TLVs that are present can occur in any order.
- Ingress-CAR sub-TLV: Upstream CAR.
- Egress-CAR sub-TLV: Downstream CAR.
- Ingress-QoS-Profile sub-TLV: Indicates the name of the QoS-Profile that is the profile in the upstream direction.
- Egress-QoS-Profile sub-TLV: Indicates the name of the QoS-Profile that is the profile in the downstream direction.
- User-ACL-Policy sub-TLV: All ACL user policies, including v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, v4SpecialACL, and v6SpecialACL.
- Multicast-Profile4 sub-TLV: IPv4 multicast policy name.
- Multicast-Profile6 sub-TLV: IPv6 multicast policy name.
- NAT-Instance sub-TLV: Indicates the instance ID of a NAT user.
- Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
7.9.13. Subscriber CGN Port Range TLV 🌸
the Subscriber CGN Port Range TLV carries the NAT public address and port range 🌐 it gets carried in the Update_Response message when CGN is used. the vibe is very "here's your address and your slice of ports" ✨
the value part:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT-Port-Start | NAT-Port-End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 58: Subscriber CGN Port Range TLVThe details 🦋
- TLV type: 15.
- TLV length: 12 octets.
- User-ID (4 bytes): The identifier of a user/subscriber.
- NAT-Port-Start (2 bytes): The start port number.
- NAT-Port-End (2 bytes): The end port number.
- NAT-Address (4 bytes): The NAT public network address.
7.10. Device Status TLVs 🔌
okay the TLVs in this section are for reporting interface and board-level info from the UP to the CP 🧠 it's the hardware gossip, bestie 🫶
7.10.1. Interface Status TLV ✨
Okay bestie, the Interface Status TLV 📡 is how a UP tells the CP what's going on with one of its interfaces. It rides along in a Report message, so it's basically a status update with main character energy 💅.
The value part looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC-Address (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC-Address (lower part) | Phy-State | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 59: Interface Status TLV
Here's the breakdown 🎀:
- TLV type:
200. - TLV length: Variable.
- If-Index (4 bytes): Indicates the interface index.
- MAC-Address (MAC-Addr type): Interface MAC address.
- Phy-State (1 byte): Physical status of the interface.
0: Down.1: Up.
- MTU (4 bytes): Interface MTU value.
- Sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried.
- Reserved: The Reserved field MUST be sent as zero and ignored on receipt. 🙈
7.10.2. Board Status TLV 🌸
The Board Status TLV is the board version of that vibe 🧚. It carries the status information of a board on a UP, and it's carried in a Report message.
Here's the value part:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board-Type | Board-State | Reserved | Chassis |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot | Sub-Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 60: Board Status TLV
Where:
- TLV type:
201. - TLV length: 8 octets.
- Chassis (1 byte): The chassis number of the board.
- Slot (16 bits): The slot number of the board.
- Sub-Slot (16 bits): The sub-slot number of the board.
- Board-Type (1 byte): The type of board used.
1: CGN Service Process Unit (SPU) board.2: Line Process Unit (LPU) board.
- Board-State (1 byte): Indicates whether there are issues with the board.
0: Normal.1: Abnormal.
- Reserved: The Reserved field MUST be sent as zero and ignored on receipt. 💖
7.11. CGN TLVs 🦋
7.11.1. Address Allocation Request TLV 💜
The Address Allocation Request TLV is how you ask the CP for an address 🙋♀️. You also carry a Pool-Name sub-TLV so the CP knows which address pool to pull from. This TLV rides in the Addr_Allocation_Req message.
The value part looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 61: Address Allocation Request TLV
Where:
- TLV type:
400. - TLV length: Variable.
- Pool-Name sub-TLV: Indicates from which address pool to allocate address.
7.11.2. Address Allocation Response TLV 🎀
This is the CP's reply to that request, and it comes back in the Addr_Allocation_Ack message 💌. It tells you the result of the allocation.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 62: Address Allocation Response TLV
Where:
- TLV type:
401. - TLV length: Variable.
- Lease Time (4 bytes): Duration of address lease in seconds.
- Client-IP (IPv4-Address type): The allocated IPv4 address and mask.
- Error-Code (4 bytes): Indicates success or an error.
0: Success.1: Failure.3001: Pool-Mismatch. The corresponding address pool cannot be found.3002: Pool-Full. The address pool is fully allocated, and no address segment is available.
- Pool-Name sub-TLV: Indicates from which address pool the address is allocated.
7.11.3. Address Renewal Request TLV 🌈
When your lease is about to run out, this is how you ask for a renewal 🔁. It's carried in the Addr_Renew_Req message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 63: Address Renewal Request TLV
Where:
- TLV type:
402. - TLV length: Variable.
- Client-IP (IPv4-Address type): The IPv4 address and mask to be renewed.
- Pool-Name sub-TLV: Indicates from which address pool to renew the address.
7.11.4. Address Renewal Response TLV ⭐
This one brings back the result of the renewal request, and it's carried in the Addr_Renew_Ack message ✨.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 64: Address Renewal Response TLV
Where:
- TLV type:
403. - TLV length: Variable.
- Client-IP (IPv4-Address type): The renewed IPv4 address and mask.
- Error-Code (4 bytes): Indicates success or an error:
0: Success.1: Failure.3001: Pool-Mismatch. The corresponding address pool cannot be found.3002: Pool-Full. The address pool is fully allocated, and no address segment is available.3003: Subnet-Mismatch. The address pool subnet cannot be found.3004: Subnet-Conflict. Subnets in the address pool have been assigned to other clients.
- Pool-Name sub-TLV: Indicates from which address pool to renew the address.
7.11.5. Address Release Request TLV 🫶
Done with an address? This TLV is how you release an IPv4 address 🕊️. It's carried in the Addr_Release_Req message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 65: Address Release Request TLV
Where:
- TLV type:
404. - TLV length: Variable.
- Client-IP (IPv4-Address type): The IPv4 address and mask to be released.
- Pool-Name sub-TLV: Indicates from which address pool to release the address.
7.11.6. Address Release Response TLV 🍓
Last but not least, this is the reply to a release request. It comes back in the Addr_Release_Ack message and tells you how the release went 💅.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 66: Address Release Response TLV
Where:
- TLV type:
405. - TLV length: Variable.
- Client-IP (IPv4-Address type): The released IPv4 address and mask.
- Error-Code (4 bytes): Indicates success or an error.
0: Success. Address release success.1: Failure. Address release failed.3001: Pool-Mismatch. The corresponding address pool cannot be found.3003: Subnet-Mismatch. The address cannot be found.3004: Subnet-Conflict. The address has been allocated to another subscriber.
- Pool-Name sub-TLV: Indicates from which address pool to release the address.
7.12. Event TLVs 🔥
7.12.1. Subscriber Traffic Statistics TLV ✨
okay so the Subscriber Traffic Statistics TLV is how we send back the traffic stats for a user/subscriber 📊💖 it's giving "here's exactly what this person has been up to." the value part has this layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 67: Subscriber Traffic Statistics TLV
Where:
- TLV type:
300. - TLV length:
72octets. User-ID(4 bytes): The subscriber identifier.Statistics-Type(4 bytes): Traffic type. It can be one of the following options:0: IPv4 traffic.1: IPv6 traffic.2: Dual-stack traffic.
Ingress Packets(8 bytes): The number of the packets in the upstream direction.Ingress Bytes(8 bytes): The bytes of the upstream traffic.Ingress Loss Packets(8 bytes): The number of the lost packets in the upstream direction.Ingress Loss Bytes(8 bytes): The bytes of the lost upstream packets.Egress Packets(8 bytes): The number of the packets in the downstream direction.Egress Bytes(8 bytes): The bytes of the downstream traffic.Egress Loss Packets(8 bytes): The number of the lost packets in the downstream direction.Egress Loss Bytes(8 bytes): The bytes of the lost downstream packets.
7.12.2. Subscriber Detection Result TLV 🦋
the Subscriber Detection Result TLV returns the detection result of a subscriber. Subscriber detection is a function that checks whether or not a subscriber is online 👀 the result can be used by the CP to decide how to handle the subscriber session (e.g., delete the session if detection failed). 💅
the format of this TLV value part is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect-Type | Detect-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 68: Subscriber Detection Result TLV
Where:
- TLV type:
301. - TLV length:
8octets. User-ID(4 bytes): The subscriber identifier.Detect-Type(1 byte): Type of traffic detected.0: IPv4 detection.1: IPv6 detection.2: PPP detection.
Detect-Result(1 byte): Indicates whether the detection was successful.0: Indicates that the detection is successful.1: Detection failure. The UP needs to report only when the detection fails.
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
7.13. Vendor TLV 🌈
the Vendor TLV shows up as the first TLV in the Vendor message (Section 6.6). it gives you a Sub-Type that basically extends the message type in the message header, provides for versioning of vendor TLVs, and can hold sub-TLVs. so cute 🎀
the value part of the Vendor TLV is laid out like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 69: Vendor TLV
Where:
- TLV type:
1024. - TLV length: Variable.
Vendor-ID(4 bytes): Vendor ID as defined in RADIUS [RFC2865].Sub-Type(2 bytes): Used by the vendor to distinguish multiple different vendor messages.Sub-Type-Version(2 bytes): Used by the vendor to distinguish different versions of a vendor-defined message Sub-Type.Sub-TLVs(variable): Sub-TLVs as specified by the vendor.
since vendor code handles the TLV once the Vendor-ID field is recognized, the rest of the TLV values can be organized however the vendor wants 🧚 but it's desirable for a vendor to define multiple different vendor messages and keep track of the different versions of its vendor-defined messages. so it is RECOMMENDED that the vendor assign a Sub-Type value for each vendor message it defines, different from the other Sub-Type values that vendor has used. 🍓 also, when modifying a vendor-defined message in a way that could be incompatible with a previous definition, the vendor SHOULD increase the value it is using in the Sub-Type-Version field. 💜
8. Tables of S-CUSP Codepoints 👑
this section has tables of the S-CUSP codepoints, especially message types, TLV types, TLV operation codes, sub-TLV types, and error codes. in most cases, references point to the relevant sections elsewhere in this document. 📚
8.1. Message Types 🦋
Table 5: Message Types
+---------+---------------------+--------------------------+
| Type | Name | Section of This Document |
+=========+=====================+==========================+
| 0 | Reserved | |
+---------+---------------------+--------------------------+
| 1 | Hello | 6.2.1 |
+---------+---------------------+--------------------------+
| 2 | Keepalive | 6.2.2 |
+---------+---------------------+--------------------------+
| 3 | Sync_Request | 6.2.3 |
+---------+---------------------+--------------------------+
| 4 | Sync_Begin | 6.2.4 |
+---------+---------------------+--------------------------+
| 5 | Sync_Data | 6.2.5 |
+---------+---------------------+--------------------------+
| 6 | Sync_End | 6.2.6 |
+---------+---------------------+--------------------------+
| 7 | Update_Request | 6.2.7 |
+---------+---------------------+--------------------------+
| 8 | Update_Response | 6.2.8 |
+---------+---------------------+--------------------------+
| 9 | Report | 6.4 |
+---------+---------------------+--------------------------+
| 10 | Event | 6.3 |
+---------+---------------------+--------------------------+
| 11 | Vendor | 6.6 |
+---------+---------------------+--------------------------+
| 12 | Error | 6.7 |
+---------+---------------------+--------------------------+
| 13-199 | Unassigned | |
+---------+---------------------+--------------------------+
| 200 | Addr_Allocation_Req | 6.5.1 |
+---------+---------------------+--------------------------+
| 201 | Addr_Allocation_Ack | 6.5.2 |
+---------+---------------------+--------------------------+
| 202 | Addr_Renew_Req | 6.5.3 |
+---------+---------------------+--------------------------+
| 203 | Addr_Renew_Ack | 6.5.4 |
+---------+---------------------+--------------------------+
| 204 | Addr_Release_Req | 6.5.5 |
+---------+---------------------+--------------------------+
| 205 | Addr_Release_Ack | 6.5.6 |
+---------+---------------------+--------------------------+
| 206-254 | Unassigned | |
+---------+---------------------+--------------------------+
| 255 | Reserved | |
+---------+---------------------+--------------------------+8.2. TLV Types ✨
okay bestie, this is the big list of every TLV type 📋💖 each row is a different kind of info that can ride along in a message, from BNG access functions 🎀 to subscriber stats 📊 to address allocation 🌸. the reserved and unassigned ranges are just holding spots for later 🫶
+-----------+-------------+-----------------------------------+
| Type | Name | Usage Description |
+===========+=============+===================================+
| 0 | Reserved | - |
+-----------+-------------+-----------------------------------+
| 1 | BAS | Carries the BNG access functions |
| | Function | to be enabled or disabled on |
| | | specified interfaces. |
+-----------+-------------+-----------------------------------+
| 2 | Basic | Carries the basic information |
| | Subscriber | about a BNG subscriber. |
+-----------+-------------+-----------------------------------+
| 3 | PPP | Carries the PPP information about |
| | Subscriber | a BNG subscriber. |
+-----------+-------------+-----------------------------------+
| 4 | IPv4 | Carries the IPv4 address of a BNG |
| | Subscriber | subscriber. |
+-----------+-------------+-----------------------------------+
| 5 | IPv6 | Carries the IPv6 address of a BNG |
| | Subscriber | subscriber. |
+-----------+-------------+-----------------------------------+
| 6 | Subscriber | Carries the policy information |
| | Policy | applied to a BNG subscriber. |
+-----------+-------------+-----------------------------------+
| 7 | IPv4 | Carries the IPv4 network routing |
| | Routing | information. |
+-----------+-------------+-----------------------------------+
| 8 | IPv6 | Carries the IPv6 network routing |
| | Routing | information. |
+-----------+-------------+-----------------------------------+
| 9 | IPv4 Static | Carries the IPv4 static |
| | Subscriber | subscriber detect information. |
| | Detect | |
+-----------+-------------+-----------------------------------+
| 10 | IPv6 Static | Carries the IPv6 static |
| | Subscriber | subscriber detect information. |
| | Detect | |
+-----------+-------------+-----------------------------------+
| 11 | L2TP-LAC | Carries the L2TP LAC subscriber |
| | Subscriber | information. |
+-----------+-------------+-----------------------------------+
| 12 | L2TP-LNS | Carries the L2TP LNS subscriber |
| | Subscriber | information. |
+-----------+-------------+-----------------------------------+
| 13 | L2TP-LAC | Carries the L2TP LAC tunnel |
| | Tunnel | subscriber information. |
+-----------+-------------+-----------------------------------+
| 14 | L2TP-LNS | Carries the L2TP LNS tunnel |
| | Tunnel | subscriber information. |
+-----------+-------------+-----------------------------------+
| 15 | Subscriber | Carries the public IPv4 address |
| | CGN Port | and related port range of a BNG |
| | Range | subscriber. |
+-----------+-------------+-----------------------------------+
| 16-99 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 100 | Hello | Used for version and Keepalive |
| | | timers negotiation. |
+-----------+-------------+-----------------------------------+
| 101 | Error | Carried in the Ack of the control |
| | Information | message. Carries the processing |
| | | result, success, or error. |
+-----------+-------------+-----------------------------------+
| 102 | Keepalive | Carried in the Hello message for |
| | | Keepalive timers negotiation. |
+-----------+-------------+-----------------------------------+
| 103-199 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 200 | Interface | Interfaces status reported by the |
| | Status | UP including physical interfaces, |
| | | sub-interfaces, trunk interfaces, |
| | | and tunnel interfaces. |
+-----------+-------------+-----------------------------------+
| 201 | Board | Board information reported by the |
| | Status | UP including the board type and |
| | | in-position status. |
+-----------+-------------+-----------------------------------+
| 202-299 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 300 | Subscriber | User traffic statistics. |
| | Traffic | |
| | Statistics | |
+-----------+-------------+-----------------------------------+
| 301 | Subscriber | User detection information. |
| | Detection | |
| | Result | |
+-----------+-------------+-----------------------------------+
| 302 | Update | The processing result of a |
| | Response | subscriber session update. |
+-----------+-------------+-----------------------------------+
| 303-299 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 400 | Address | Request address allocation. |
| | Allocation | |
| | Request | |
+-----------+-------------+-----------------------------------+
| 401 | Address | Address allocation response. |
| | Allocation | |
| | Response | |
+-----------+-------------+-----------------------------------+
| 402 | Address | Request for address lease |
| | Renewal | renewal. |
| | Request | |
+-----------+-------------+-----------------------------------+
| 403 | Address | Response to a request for |
| | Renewal | extending an IP address lease. |
| | Response | |
+-----------+-------------+-----------------------------------+
| 404 | Address | Request to release the address. |
| | Release | |
| | Request | |
+-----------+-------------+-----------------------------------+
| 405 | Address | Ack of a message releasing an IP |
| | Release | address. |
| | Response | |
+-----------+-------------+-----------------------------------+
| 406-1023 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 1024 | Vendor | As implemented by the vendor. |
+-----------+-------------+-----------------------------------+
| 1039-4095 | Unassigned | - |
+-----------+-------------+-----------------------------------+
Table 6: TLV Types8.3. TLV Operation Codes 🔥
okay so these codes live in the Oper field up in the header of some TLVs 🎀 if you want the full story on that field, go check Section 7.1 🦋
+------+------------+
| Code | Operation |
+======+============+
| 0 | Reserved |
+------+------------+
| 1 | Update |
+------+------------+
| 2 | Delete |
+------+------------+
| 3-15 | Unassigned |
+------+------------+
Table 7: TLV Operation
Codes8.4. Sub-TLV Types 🌈
for the sub-TLV details, see Section 7.3 💅
+----------+---------------------+--------------------------+
| Type | Name | Section of This Document |
+==========+=====================+==========================+
| 0 | Reserved | |
+----------+---------------------+--------------------------+
| 1 | VRF Name | 7.3.1 |
+----------+---------------------+--------------------------+
| 2 | Ingress-QoS-Profile | 7.3.1 |
+----------+---------------------+--------------------------+
| 3 | Egress-QoS-Profile | 7.3.1 |
+----------+---------------------+--------------------------+
| 4 | User-ACL-Policy | 7.3.1 |
+----------+---------------------+--------------------------+
| 5 | Multicast-ProfileV4 | 7.3.1 |
+----------+---------------------+--------------------------+
| 6 | Multicast-ProfileV6 | 7.3.1 |
+----------+---------------------+--------------------------+
| 7 | Ingress-CAR | 7.3.2 |
+----------+---------------------+--------------------------+
| 8 | Egress-CAR | 7.3.3 |
+----------+---------------------+--------------------------+
| 9 | NAT-Instance | 7.3.1 |
+----------+---------------------+--------------------------+
| 10 | Pool-Name | 7.3.1 |
+----------+---------------------+--------------------------+
| 11 | If-Desc | 7.3.4 |
+----------+---------------------+--------------------------+
| 12 | IPv6-Address List | 7.3.5 |
+----------+---------------------+--------------------------+
| 13 | Vendor | 7.3.6 |
+----------+---------------------+--------------------------+
| 12-64534 | Unassigned | |
+----------+---------------------+--------------------------+
| 65535 | Reserved | |
+----------+---------------------+--------------------------+
Table 8: Sub-TLV Types8.5. Error Codes
Okay so bestie, this is the error code table 🚨💅 It's giving "every failure has a name," and honestly iconic. Each row is a value, a name, and a remark about what it means. Here's the whole thing:
+-----------------+-----------------------+-------------------------+
| Value | Name | Remarks |
+=================+=======================+=========================+
| 0 | Success | Success |
+-----------------+-----------------------+-------------------------+
| 1 | Failure | Malformed message |
| | | received. |
+-----------------+-----------------------+-------------------------+
| 2 | TLV-Unknown | One or more of the |
| | | TLVs was not |
| | | understood. |
+-----------------+-----------------------+-------------------------+
| 3 | TLV-Length | The TLV length is |
| | | abnormal. |
+-----------------+-----------------------+-------------------------+
| 4-999 | Unassigned | Unassigned basic |
| | | error codes. |
+-----------------+-----------------------+-------------------------+
| 1000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 1001 | Version-Mismatch | The version |
| | | negotiation fails. |
| | | Terminate. The |
| | | subsequent service |
| | | processes |
| | | corresponding to the |
| | | UP are suspended. |
+-----------------+-----------------------+-------------------------+
| 1002 | Keepalive Error | The keepalive |
| | | negotiation fails. |
+-----------------+-----------------------+-------------------------+
| 1003 | Timer Expires | The establishment |
| | | timer expired. |
+-----------------+-----------------------+-------------------------+
| 1004-1999 | Unassigned | Unassigned error |
| | | codes for version |
| | | negotiation. |
+-----------------+-----------------------+-------------------------+
| 2000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 2001 | Synch-NoReady | The data to be |
| | | smoothed is not |
| | | ready. |
+-----------------+-----------------------+-------------------------+
| 2002 | Synch-Unsupport | The request for |
| | | smooth data is not |
| | | supported. |
+-----------------+-----------------------+-------------------------+
| 2003-2999 | Unassigned | Unassigned data |
| | | synchronization |
| | | error codes. |
+-----------------+-----------------------+-------------------------+
| 3000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 3001 | Pool-Mismatch | The corresponding |
| | | address pool cannot |
| | | be found. |
+-----------------+-----------------------+-------------------------+
| 3002 | Pool-Full | The address pool is |
| | | fully allocated, and |
| | | no address segment |
| | | is available. |
+-----------------+-----------------------+-------------------------+
| 3003 | Subnet-Mismatch | The address pool |
| | | subnet cannot be |
| | | found. |
+-----------------+-----------------------+-------------------------+
| 3004 | Subnet-Conflict | Subnets in the |
| | | address pool have |
| | | been classified into |
| | | other clients. |
+-----------------+-----------------------+-------------------------+
| 3005-3999 | Unassigned | Unassigned error |
| | | codes for address |
| | | allocation. |
+-----------------+-----------------------+-------------------------+
| 4000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 4001 | Update-Fail-No-Res | The forwarding table |
| | | fails to be |
| | | delivered because |
| | | the forwarding |
| | | resources are |
| | | insufficient. |
+-----------------+-----------------------+-------------------------+
| 4002 | QoS-Update-Success | The QoS policy takes |
| | | effect. |
+-----------------+-----------------------+-------------------------+
| 4003 | QoS-Update-Sq-Fail | Failed to process |
| | | the queue in the QoS |
| | | policy. |
+-----------------+-----------------------+-------------------------+
| 4004 | QoS-Update-CAR-Fail | Processing of the |
| | | CAR in the QoS |
| | | policy fails. |
+-----------------+-----------------------+-------------------------+
| 4005 | Statistic-Fail-No-Res | Statistics |
| | | processing failed |
| | | due to insufficient |
| | | statistics |
| | | resources. |
+-----------------+-----------------------+-------------------------+
| 4006-4999 | Unassigned | Unassigned |
| | | forwarding table |
| | | delivery error |
| | | codes. |
+-----------------+-----------------------+-------------------------+
| 5000-4294967295 | Reserved | |
+-----------------+-----------------------+-------------------------+
Table 9: Error Codes8.6. If-Type Values
Defined values of the If-Type field in the If-Desc sub-TLV (see Section 7.3.4) are as follows. It's the interface type hall of fame 🦋✨
+-------+--------------------+
| Value | Meaning |
+=======+====================+
| 0 | Reserved |
+-------+--------------------+
| 1 | Fast Ethernet (FE) |
+-------+--------------------+
| 2 | GE |
+-------+--------------------+
| 3 | 10GE |
+-------+--------------------+
| 4 | 100GE |
+-------+--------------------+
| 5 | Eth-Trunk |
+-------+--------------------+
| 6 | Tunnel |
+-------+--------------------+
| 7 | VE |
+-------+--------------------+
| 8-254 | Unassigned |
+-------+--------------------+
| 255 | Reserved |
+-------+--------------------+
Table 10: If-Type Values8.7. Access-Mode Values
Defined values of the Access-Mode field in the BAS Function TLV (see Section 7.7) are as follows. Last table of the part, and it's a cute one 🌸🎀
+-------+---------------------+
| Value | Meaning |
+=======+=====================+
| 0 | Layer 2 subscriber |
+-------+---------------------+
| 1 | Layer 3 subscriber |
+-------+---------------------+
| 2 | Layer 2 leased line |
+-------+---------------------+
| 3 | Layer 3 leased line |
+-------+---------------------+
| 4-254 | Unassigned |
+-------+---------------------+
| 255 | Reserved |
+-------+---------------------+
Table 11: Access-Mode Values8.8. Access Method Bits 🦋
okay so the Auth-Method4 and Auth-Method6 fields in the BAS Function TLV (see Section 7.7) are bit fields, so each bit is its own little flag 🎀 Here's what each bit means:
+------+-------------------------+
| Bit | Meaning |
+======+=========================+
| 0x01 | PPPoE authentication |
+------+-------------------------+
| 0x02 | DOT1X authentication |
+------+-------------------------+
| 0x04 | Web authentication |
+------+-------------------------+
| 0x08 | Web fast authentication |
+------+-------------------------+
| 0x10 | Binding authentication |
+------+-------------------------+
| 0x20 | Reserved |
+------+-------------------------+
| 0x40 | Reserved |
+------+-------------------------+
| 0x80 | Reserved |
+------+-------------------------+
Table 12: Auth-Method4 Values
+------+-------------------------+
| Bit | Meaning |
+======+=========================+
| 0x01 | PPPoE authentication |
+------+-------------------------+
| 0x02 | DOT1X authentication |
+------+-------------------------+
| 0x04 | Web authentication |
+------+-------------------------+
| 0x08 | Web fast authentication |
+------+-------------------------+
| 0x10 | Binding authentication |
+------+-------------------------+
| 0x20 | Reserved |
+------+-------------------------+
| 0x40 | Reserved |
+------+-------------------------+
| 0x80 | Reserved |
+------+-------------------------+
Table 13: Auth-Method6 Values8.9. Route-Type Values 🗺️
so the Route-Type field in the IPv4 and IPv6 Routing TLVs (see Sections 7.8.1 and 7.8.2) comes with a list of values this document defines. Here they are:
+---------+---------------------------------+
| Value | Meaning |
+=========+=================================+
| 0 | User host route |
+---------+---------------------------------+
| 1 | Radius authorization FrameRoute |
+---------+---------------------------------+
| 2 | Network segment route |
+---------+---------------------------------+
| 3 | Gateway route |
+---------+---------------------------------+
| 4 | Radius authorized IP route |
+---------+---------------------------------+
| 5 | L2TP LNS side user route |
+---------+---------------------------------+
| 6-65534 | Unassigned |
+---------+---------------------------------+
| 65535 | Reserved |
+---------+---------------------------------+
Table 14: Route-Type Values8.10. Access-Type Values 💖
okay this one is the Access-Type field in the Basic Subscriber TLV (see Section 7.9.1). These are the values this document defines, and honestly the list is giving main character energy 💅
+--------+---------------------------------------------------------+
| Value | Meaning |
+========+=========================================================+
| 0 | Reserved |
+--------+---------------------------------------------------------+
| 1 | PPP access (PPP [RFC1661]) |
+--------+---------------------------------------------------------+
| 2 | PPP over Ethernet over ATM access (PPPoEoA) |
+--------+---------------------------------------------------------+
| 3 | PPP over ATM access (PPPoA [RFC3336]) |
+--------+---------------------------------------------------------+
| 4 | PPP over Ethernet access (PPPoE [RFC2516]) |
+--------+---------------------------------------------------------+
| 5 | PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) |
+--------+---------------------------------------------------------+
| 6 | PPP over LNS access (PPPoLNS) |
+--------+---------------------------------------------------------+
| 7 | IP over Ethernet DHCP access (IPoE_DHCP) |
+--------+---------------------------------------------------------+
| 8 | IP over Ethernet EAP authentication access (IPoE_EAP) |
+--------+---------------------------------------------------------+
| 9 | IP over Ethernet Layer 3 access (IPoE_L3) |
+--------+---------------------------------------------------------+
| 10 | IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) |
+--------+---------------------------------------------------------+
| 11 | Layer 2 Leased Line access (L2_Leased_Line) |
+--------+---------------------------------------------------------+
| 12 | Layer 2 VPN Leased Line access (L2VPN_Leased_Line) |
+--------+---------------------------------------------------------+
| 13 | Layer 3 Leased Line access (L3_Leased_Line) |
+--------+---------------------------------------------------------+
| 14 | Layer 2 Leased line Sub-User access |
| | (L2_Leased_Line_SUB_USER) |
+--------+---------------------------------------------------------+
| 15 | L2TP LAC tunnel access (L2TP_LAC) |
+--------+---------------------------------------------------------+
| 16 | L2TP LNS tunnel access (L2TP_LNS) |
+--------+---------------------------------------------------------+
| 17-254 | Unassigned |
+--------+---------------------------------------------------------+
| 255 | Reserved |
+--------+---------------------------------------------------------+
Table 15: Access-Type Values9. IANA Considerations 🌸
tea time: this document has no IANA actions. Nothing to register here 🫶
10. Security Considerations 🚨
⚠️ okay, this one is SERIOUS bestie, so read it carefully 😭
The Service, Control, and Management Interfaces between the CP and UP might be across the general Internet or some other hostile environment. If an adversary can block or corrupt messages, or slip in spurious ones on any of these interfaces, they get the power to stop subscribers from reaching network services, knock out existing subscriber sessions, divert traffic, mess up accounting statistics, and generally cause total chaos 💀 The damage wouldn't necessarily stay limited to one or a few subscribers. It could disrupt routing, deny service to one or more instances of the CP, or cause other widespread interference. And if the adversary knows the details of the UP equipment and what its forwarding rules can do, they may be able to get a copy of most or all user data sent to an address of their choosing, which means eavesdropping 🙈
So, appropriate protections MUST be implemented to provide integrity, authenticity, and secrecy of traffic over those interfaces. Whether that protection is used is up to the network operator. See [RFC6241] for Mi/NETCONF security. Security on the Si depends on the tunneling protocol in use, which is out of scope for this document. Security for the Ci, which is where S-CUSP flows, is discussed further below.
S-CUSP messages do not provide security on their own 🥺 So if these messages are exchanged in an environment where security matters, that security MUST be provided by another protocol such as TLS 1.3 [RFC8446] or IPsec. TLS 1.3 is the mandatory-to-implement protocol for interoperability. Which security protocol gets used on the Ci is determined by configuration. Those security protocols don't always need to be used, and lesser precautions might be appropriate because, in some cases, the communication between the CP and UP happens in a benign environment 🌈
11. References 📚
11.1. Normative References 🎀
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, DOI 10.17487/RFC2661, August 1999,
<https://www.rfc-editor.org/info/rfc2661>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.11.2. Informative References 📚
okay so these are the background reads 🤓 not required to implement the thing, but they explain where the ideas come from. the list is long bestie, so here we go 💅
- [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2018, DOI 10.1109/IEEESTD.2018.8403927, July 2018,
<https://doi.org/10.1109/IEEESTD.2018.8403927>. - [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>. - [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. - [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999,
<https://www.rfc-editor.org/info/rfc2516>. - [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
<https://www.rfc-editor.org/info/rfc2698>. - [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>. - [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 3336, DOI 10.17487/RFC3336, December 2002,
<https://www.rfc-editor.org/info/rfc3336>. - [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009,
<https://www.rfc-editor.org/info/rfc5511>. - [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013,
<https://www.rfc-editor.org/info/rfc7042>. - [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. - [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. - [TR-384] Broadband Forum, "Cloud Central Office Reference Architectural Framework", BBF TR-384, January 2018.
- [WT-459] Broadband Forum, "Control and User Plane Separation for a Disaggregated BNG", BBF WT-459, 2019.
Acknowledgements 🫶
big thank yous to these legends for their helpful comments and suggestions 💜
- Loa Andersson
- Greg Mirsky
Contributors 💖
these people helped build this spec and deserve all the flowers 🌸
Zhenqiang Li
China Mobile
32 Xuanwumen West Ave
Xicheng District
Beijing
100053
China
Email: lizhenqiang@chinamobile.com
Mach(Guoyi) Chen
Huawei Technologies
Huawei Bldg., No. 156 Beiqing Road
Beijing
100095
China
Email: mach.chen@huawei.com
Zhouyi Yu
Huawei Technologies
Email: yuzhouyi@huawei.com
Chengguang Niu
Huawei Technologies
Email: chengguang.niu@huawei.com
Zitao Wang
Huawei Technologies
Email: wangzitao@huawei.com
Jun Song
Huawei Technologies
Email: song.jun@huawei.com
Dan Meng
H3C Technologies
No. 1 Lixing Center
No. 8 Guangxun South Street
Chaoyang District
Beijing
100102
China
Email: mengdan@h3c.com
Hanlei Liu
H3C Technologies
No. 1 Lixing Center
No. 8 Guangxun South Street
Chaoyang District
Beijing
100102
China
Email: hanlei_liu@h3c.com
Victor Lopez
Telefonica
Spain
Email: victor.lopezalvarez@telefonica.comAuthors' Addresses 🦋
and finally, the authors themselves, where you can find them 🧚
Shujun Hu
China Mobile
32 Xuanwumen West Ave
Xicheng District
Beijing
100053
China
Email: hushujun@chinamobile.com
Donald Eastlake 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Fengwei Qin
China Mobile
32 Xuanwumen West Ave
Xicheng District
Beijing
100053
China
Email: qinfengwei@chinamobile.com
Tee Mong Chua
Singapore Telecommunications Limited
31 Exeter Road, #05-04 Comcentre Podium Block
SINGAPORE 239732
Singapore
Email: teemong@singtel.com
Daniel Huang
ZTE
Email: huang.guangping@zte.com.cnthat's the whole spec bestie, we made it 🌈✨👑
📦 where this page comes from
- ietf: rfc8772 2020-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms