idnits 2.17.1 draft-chz-simple-cu-separation-bng-protocol-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2019) is 1650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Hu 2 Intended status: Informational China Mobile 3 D. Eastlake 4 Futurewei Technologies 5 F. Qin 6 China Mobile 7 T. Chua 8 Singapore Telecommunications 9 D. Huang 10 ZTE 11 Expires: April 18, 2020 October 19, 2019 13 The China Mobile, Huawei, and ZTE BNG 14 Simple Control and User Plane Separation Protocol (S-CUSP) 15 draft-chz-simple-cu-separation-bng-protocol-06 17 Abstract 19 A Broadband Network Gateway (BNG) in a fixed wireline access network 20 is an Ethernet-centric IP edge router and the aggregation point for 21 subscriber traffic. Control Plane (CP) and User Plane (UP) Separation 22 (CUPS) for such a BNG improves flexibility and scalability but 23 requires various communication between the UP and the CP. China 24 Mobile, Huawei Technologies, and ZTE have developed a simple CUPS 25 control channel Protocol (S-CUSP) to support such communication. 27 This document is not an IETF standard and does not have IETF 28 consensus. S-CUSP is presented here to make its specification 29 conveniently available to the Internet community to enable diagnosis 30 and interoperability. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Distribution of this document is unlimited. Comments should be sent 38 to the authors. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 51 Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 Table of Contents 56 1. Introduction...........................................6 57 2. Terminology............................................7 58 2.1. Implementation Requirement Keywords................7 59 2.2. Terms..............................................7 60 3. BNG CUPS Overview.....................................10 61 3.1. BNG CUPS Motivation...............................10 62 3.2. BNG CUPS Architecture Overview....................10 63 3.3. BNG CUPS Interfaces...............................12 64 3.3.1. Service Interface...............................13 65 3.3.2. Control Interface...............................14 66 3.3.3. Management Interface............................14 67 3.4. BNG CUPS Procedure Overview.......................14 68 4. S-CUSP Protocol Overview..............................18 69 4.1. Control Channel Related Procedures................18 70 4.1.1. S-CUSP Session Establishment....................18 71 4.1.2. Keepalive Timer and DeadTimer...................19 72 4.2. Node Related Procedures...........................20 73 4.2.1. UP Resource Report..............................20 74 4.2.2. Update BAS Function on Access Interface.........21 75 4.2.3. Update Network Routing..........................21 76 4.2.4. CGN Public IP Address Allocation................22 77 4.2.5. Data Synchronization between the CP and UP......23 78 4.3. Subscriber Session Related Procedures.............24 79 4.3.1. Create Subscriber Session.......................25 80 4.3.2. Update Subscriber Session.......................26 81 4.3.3. Delete Subscriber Session.......................27 82 4.3.4. Subscriber Session Events Report................27 83 5. S-CUSP Call Flows.....................................29 84 5.1. IPoE..............................................29 85 5.1.1. DHCPv4 Access...................................29 86 5.1.2. DHCPv6 Access...................................30 87 5.1.3. IPv6 SLAAC Access...............................32 88 5.1.4. DHCPv6 + SLAAC Access...........................33 89 5.1.5. DHCP Dual Stack Access..........................35 90 5.1.6. L2 Static Subscriber Access.....................37 91 5.2. PPPoE.............................................40 92 5.2.1. IPv4 PPPoE Access...............................40 93 5.2.2. IPv6 PPPoE Access...............................41 94 5.2.3. PPPoE Dual Stack Access.........................43 95 5.3. WLAN Access.......................................45 96 5.4. L2TP..............................................48 97 5.4.1. L2TP LAC Access.................................48 98 5.4.2. L2TP LNS IPv4 Access............................49 99 5.4.3. L2TP LNS IPv6 Access............................51 100 5.5. CGN (Carrier Grade NAT)...........................54 101 5.6. L3 Leased Line Access.............................55 102 5.6.1. Web Authentication..............................55 103 5.6.2. User Traffic Trigger............................57 104 5.7. Multicast Service Access..........................59 106 Table of Contents (continued) 108 6. S-CUSP Message Formats................................61 109 6.1. Common Message Header.............................61 110 6.2. Control Messages..................................62 111 6.2.1. Hello Message...................................62 112 6.2.2. Keepalive Message...............................63 113 6.2.3. Sync_Request Message............................63 114 6.2.4. Sync_Begin Message..............................64 115 6.2.5. Sync_Data Message...............................64 116 6.2.6. Sync_End Message................................65 117 6.2.7. Update_Request Message..........................65 118 6.2.8. Update_Response Message.........................66 119 6.3. Event Message.....................................67 120 6.4. Report Message....................................67 121 6.5. CGN Messages......................................67 122 6.5.1. Addr_Allocation_Req Message.....................67 123 6.5.2. Addr_Allocation_Ack Message.....................68 124 6.5.3. Addr_Renew_Req Message..........................68 125 6.5.4. Addr_Renew_Ack Message..........................68 126 6.5.5. Addr_Release_Req Message........................68 127 6.5.6. Addr_Release_Ack Message........................68 128 6.6. Vendor Message....................................69 129 6.7 Error Message.......................................69 130 7. S-CUSP TLVs and Sub-TLVs..............................70 131 7.1. Common TLV Header.................................70 132 7.2. Basic Data Fields.................................71 133 7.3. Sub-TLV Format and Sub-TLVs.......................72 134 7.3.1. Name sub-TLVs...................................72 135 7.3.2. Ingress-CAR sub-TLV.............................73 136 7.3.3. Egress-CAR sub-TLV..............................73 137 7.3.4. If-Desc sub-TLV.................................74 138 7.3.5. IPv6 Address List sub-TLV.......................76 139 7.3.6. Vendor sub-TLV..................................76 140 7.4. The Hello TLV.....................................77 141 7.5. The Keepalive TLV.................................79 142 7.6. The Error Information TLV.........................80 143 7.7. BAS Function TLV..................................80 144 7.8. Routing TLVs......................................82 145 7.8.1. IPv4 Routing TLV................................83 146 7.8.2. IPv6 Routing TLV................................84 147 7.9. Subscriber TLVs...................................86 148 7.9.1. Basic Subscriber TLV............................86 149 7.9.2. PPP Subscriber TLV..............................88 150 7.9.3. IPv4 Subscriber TLV.............................89 151 7.9.4. IPv6 Subscriber TLV.............................91 152 7.9.5. IPv4 Static Subscriber Detect TLV...............92 153 7.9.6. IPv6 Static Subscriber Detect TLV...............93 154 7.9.7. L2TP-LAC Subscriber TLV.........................95 155 7.9.8. L2TP-LNS Subscriber TLV.........................95 156 7.9.9. L2TP-LAC Tunnel TLV.............................96 158 Table of Contents (continued) 160 7.9.10. L2TP-LNS Tunnel TLV............................97 161 7.9.11. Update Response TLV............................98 162 7.9.12. Subscriber Policy TLV..........................99 163 7.9.13. Subscriber CGN Port Range TLV.................101 164 7.10. Device Status TLVs..............................101 165 7.10.1. Interface Status TLV..........................102 166 7.10.2. Board Status TLV..............................102 167 7.11. CGN TLVs........................................103 168 7.11.1. Address Allocation Request TLV................103 169 7.11.2. Address Allocation Response TLV...............104 170 7.11.3. Address Renewal Request TLV...................105 171 7.11.4. The Address Renewal Response TLV..............106 172 7.11.5. Address Release Request TLV...................107 173 7.11.6. The Address Release Response TLV..............107 174 7.12. Event TLVs......................................108 175 7.12.1. Subscriber Traffic Statistics TLV..............109 176 7.12.2. Subscriber Detection Result TLV...............110 177 7.13. Vendor TLV......................................111 178 8. Implementation Status................................113 179 8.1. Implementations..................................113 180 8.1.1. Huawei Technologies............................113 181 8.1.2. ZTE............................................114 182 8.1.3. H3C............................................114 183 8.2. Hackathon........................................114 184 8.3. EANTC Testing....................................115 185 9. Tables of S-CUSP Codepoints..........................116 186 9.1. Message Types....................................116 187 9.2. TLV Types........................................116 188 9.3. TLV Operation Codes..............................118 189 9.4. Sub-TLV Types....................................119 190 9.5. Error Codes......................................119 191 9.6. If-Type Values...................................120 192 9.7. Access-Mode Values...............................121 193 9.8. Access Method Bits...............................121 194 9.9. Route-Type Values................................122 195 9.10. Access-Type Values..............................122 197 10. IANA Considerations.................................123 198 11. Security Considerations.............................124 200 Contributors.............................................125 201 Acknowledgements.........................................127 203 Normative References.....................................128 204 Informative References...................................129 206 Authors' Addresses.......................................131 208 1. Introduction 210 A Broadband Network Gateway (BNG) in a fixed wireline access network 211 is an Ethernet-centric IP edge router, and the aggregation point for 212 subscriber traffic. To provide centralized session management, 213 flexible address allocation, high scalability for subscriber 214 management capacity, and cost-efficient redundancy, the Control/User 215 (CU) separated BNG framework is described in technical report 216 [TR-384] from the Broadband Forum (BBF). The CU separated service 217 Control Plane (CP), which is responsible for user access 218 authentication and setting forwarding entries in User Planes (UPs), 219 can be virtualized and centralized. The routing control and 220 forwarding plane, i.e., the BNG user plane (local), can be 221 distributed across the infrastructure. Other structures can also be 222 supported such as both CP and UP being virtual or both being 223 physical. 225 Note: In this document, the terms "user" and "subscriber" are used 226 interchangeably. 228 This document specifies the Simple CU Separation BNG control channel 229 Protocol (S-CUSP) for communications between a BNG Control Plane (CP) 230 and a set of User Planes (UPs). S-CUSP is designed to be flexible 231 and extensible so as to allow for easy addition of messages and data 232 items, should further requirements be expressed in the future. 234 This document is not an IETF standard and does not have IETF 235 consensus. S-CUSP was designed by China Mobile, Huawei Technologies, 236 and ZTE. It is presented here to make the S-CUSP specification 237 conveniently available to the Internet community to enable diagnosis 238 and interoperability. 240 At the time of writing this document, the Broadband Forum (BBF) is 241 working to produce [WT-459] that will describe an architecture and 242 requirements for a control and user plane separation of a 243 disaggregated BNG. Future work may attempt to show how the protocol 244 described in this document addresses those requirements and may 245 modify this specification to handle unaddressed requirements. 247 2. Terminology 249 This section specifies implementation requirement keywords and terms 250 used in this document. S-CUSP messages are described in this document 251 using Routing Backus-Naur Form (RBNF) as defined in [RFC5511]. 253 2.1. Implementation Requirement Keywords 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 257 "OPTIONAL" in this document are to be interpreted as described in BCP 258 14 [RFC2119] [RFC8174] when, and only when, they appear in all 259 capitals, as shown here. 261 2.2. Terms 263 This section specifies terms used in this document. 265 AAA: Authentication Authorization Accounting. 267 ACK: Acknowledgement message. 269 BAS: Broadband Access Server (BRAS, BNG). 271 BNG: Broadband Network Gateway. A broadband remote access server 272 (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic 273 to and from broadband remote access devices such as digital 274 subscriber line access multiplexers (DSLAM) on an Internet 275 Service Provider's (ISP) network. BRAS can also be referred to 276 as a Broadband Network Gateway (BNG). 278 BRAS: BRoadband Access Server (BNG). 280 CAR: Committed Access Rate. 282 CBS: Committed Burst Size. 284 CGN: Carrier Grade NAT. 286 Ci: Control Interface. 288 CIR: Committed Information Rate. 290 CoA: Change of Authorization. 292 CP: Control Plane. 294 CP is a user control management component which supports the 295 management of the UP's resources such as the user entry and 296 forwarding policy. 298 CPE: Customer Premises Equipment. 300 CU: Control-plane / User-plane. 302 CUSP: Control and User plane Separation Protocol. 304 DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the 305 priority and before the VLAN ID. (This bit was formerly the CFI 306 (Canonical Format Indicator).) [802.1Q] 308 DHCP: Dynamic Host Configuration Protocol [RFC2131]. 310 dial-up: This refers to the initial connection messages when a new 311 subscriber appears. The name is left over from when subscribers 312 literally dialed up on a modem equipped phone line but herein is 313 applied to other initial connection techniques. Initial 314 connection is frequently indicated by the receipt of packets over 315 PPPoE [RFC2516] or IPoE. 317 EMS: Element Management System. 319 IPoE: IP over Ethernet. 321 L2TP: Layer 2 Tunneling Protocol [RFC2661]. 323 LAC: L2TP Access Concentrator. 325 LNS: L2TP Network Server. 327 MAC: 48-bit Media Access Control address [RFC7042]. 329 MANO: Management and Orchestration. 331 Mi: Management Interface. 333 MSS: Maximum Segment Size. 335 MRU: Maximum Receive Unit. 337 NAT: Network Address Translation [RFC3022]. 339 ND: Neighbor Discovery. 341 NFV: Network Function Virtualization. 343 NFVI: NFV Infrastructure 345 PBS: Peak Burst Size. 347 PD: Prefix Delegation. 349 PIR: Peak Information Rate. 351 PPP: Point to Point Protocol [RFC1661]. 353 PPPoE: PPP over Ethernet [RFC2516]. 355 RBNF: Routing Backus-Naur Form [RFC5511]. 357 RG: Residential Gateway. 359 S-CUSP: Simple Control and User Plane Separation Protocol. 361 Subscriber: The remote user gaining network accesses via a BNG. 363 Si: Service Interface. 365 TLV: Type, Length, Value. See Sections 7.1 and 7.3. 367 UP: User Plane. UP is a network edge and user policy implementation 368 component. The traditional router's Control Plane and Forwarding 369 Plane are both preserved on BNG devices in the form of a user 370 plane. 372 URPF: Unicast Reverse Path Forwarding. 374 User: Equivalent to "customer" or "subscriber". 376 VRF: Virtual Routing and Forwarding. 378 3. BNG CUPS Overview 380 3.1. BNG CUPS Motivation 382 The rapid development of new services, such as 4K TV, IoT, etc., and 383 increasing numbers of home broadband service users present some new 384 challenges for BNGs such as: 386 Low resource utilization: The traditional BNG acts as both a gateway 387 for user access authentication and accounting and an IP network's 388 Layer 3 edge. The mutually affecting nature of the tightly 389 coupled control plane and forwarding plane makes it difficult to 390 achieve the maximum performance of either plane. 392 Complex management and maintenance: Due to the large numbers of 393 traditional BNGs, configuring each device in a network is very 394 tedious when deploying global service policies. As the network 395 expands and new services are introduced, this deployment mode 396 will cease to be feasible as it is unable to manage services 397 effectively and rectify faults rapidly. 399 Slow service provisioning: The coupling of control plane and 400 forwarding plane, in addition to a distributed network control 401 mechanism, means that any new technology has to rely heavily on 402 the existing network devices. 404 The framework for a cloud-based BNG with Control Plane and User Plane 405 (CU) separation to address these challenges for fixed networks is 406 described in [TR-384]. The main idea of CU separation is to extract 407 and centralize the user management functions of multiple BNG devices, 408 forming a unified and centralized Control Plane (CP). And the 409 traditional router's Control Plane and Forwarding Plane are both 410 preserved on BNG devices in the form of a User Plane (UP). 412 3.2. BNG CUPS Architecture Overview 414 The functions in a traditional BNG can be divided into two parts: one 415 is the user access management function, the other is the router 416 function. The user management function can be deployed as a 417 centralized module or device, called the BNG Control Plane (BNG-CP). 418 The other functions, such as the router function and forwarding 419 engine, can be deployed in the form of the BNG User Plane (BNG-UP). 421 The following figure shows the architecture of CU separated BNG: 423 +------------------------------------------------------------------+ 424 | Neighboring policy and resource management systems | 425 | | 426 | +-------------+ +-----------+ +---------+ +----------+ | 427 | |AAA Server| |DHCP Server| | EMS | | MANO | | 428 | +-------------+ +-----------+ +---------+ +----------+ | 429 +------------------------------------------------------------------+ 431 +------------------------------------------------------------------+ 432 | CU-separated BNG system | 433 | +--------------------------------------------------------------+ | 434 | | +----------+ +----------+ +------++------++-----------+ | | 435 | | | Address | |Subscriber| | AAA ||Access|| UP | | | 436 | | |management| |management| | || Mgt ||management | | | 437 | | +----------+ +----------+ +------++------++-----------+ | | 438 | | CP | | 439 | +--------------------------------------------------------------+ | 440 | | 441 | | 442 | | 443 | +---------------------------+ +--------------------------+ | 444 | | +------------------+ | | +------------------+ | | 445 | | | Routing control | | | | Routing control | | | 446 | | +------------------+ | ... | +------------------+ | | 447 | | +------------------+ | | +------------------+ | | 448 | | |Forwarding engine | | | |Forwarding engine | | | 449 | | +------------------+ UP | | +------------------+ UP| | 450 | +---------------------------+ +--------------------------+ | 451 +------------------------------------------------------------------+ 453 Figure 1: Architecture of CU Separated BNG 455 As shown in Figure 1, the BNG Control Plane could be virtualized and 456 centralized, which provides benefits such as centralized session 457 management, flexible address allocation, high scalability for 458 subscriber management capacity, and cost-efficient redundancy, etc. 459 The functional components inside the BNG Service Control Plane can be 460 implemented as Virtual Network Functions (VNFs) and hosted in a 461 Network Function Virtualization Infrastructure (NFVI). 463 The User Plane Management module in the BNG Control Plane centrally 464 manages the distributed BNG User Planes (e.g., load balancing), as 465 well as the setup, deletion, and maintenance of channels between 466 Control Planes and User Planes. Other modules in the BNG control 467 plane, such as address management, AAA, etc., are responsible for the 468 connection with external subsystems in order to fulfill those 469 services. Note that the User Plane SHOULD support both physical and 470 virtual network functions. For example, BNG user plane L3 forwarding 471 related network functions can be disaggregated and distributed across 472 the physical infrastructure. And the other control plane and 473 management plane functions in the CU Separation BNG can be moved into 474 the NFVI for virtualization [TR-384]. 476 The details of CU separated BNG's function components are as 477 following: 479 The Control Plane is responsible for the following: 481 1. Address management: unified address pool management and CGN 482 subscriber address traceability management. 484 2. AAA: This component performs Authentication, Authorization and 485 Accounting, together with RADIUS/DIAMETER. The BNG communicates 486 with the AAA server to check whether the subscriber who sent an 487 Access-Request has network access authority. Once the subscriber 488 goes online, this component together with the Service Control 489 component implement accounting, data capacity limitation, and QoS 490 enforcement policies. 492 3. Subscriber management: user entry management and forwarding 493 policy management. 495 4. Access management: process user dial-up packets, such as PPPoE, 496 DHCP, L2TP, etc. 498 5. UP management: management of UP interface status, and the setup, 499 deletion, and maintenance of channels between CP and UP. 501 The User Plane is responsible for the following: 503 1. Routing control functions: responsible for constructing routing 504 forwarding plane (e.g., routing, multicast, MPLS, etc.). 506 2. Routing and Service Forwarding plane functions: responsible 507 including traffic forwarding, QoS and traffic statistics 508 collection. 510 Subscriber detection: responsible for detecting whether a subscriber 511 is still online. 513 3.3. BNG CUPS Interfaces 515 Three interfaces defined below support the communication between the 516 Control Plane and User Plane. These are referred to as the Service 517 Interface (Si), Control Interface (Ci), and Management Interface (Mi) 518 as shown in Figure 2. 520 +-----------------------------------+ 521 | | 522 | BNG-CP | 523 | | 524 +--+--------------+--------------+--+ 525 | | | 526 1. Service | 2. Control | 3. Management| 527 Interface | Interface | Interface | 528 (Si) | (Ci) | (Mi) | 529 | | | 530 | ___|___ | 531 | ___( )___ | 532 _|______( )______|_ 533 ( ) 534 ( Network/Internet ) 535 (________ ________) 536 | (___ ___) | 537 | (_______) | 538 | | | 539 | | | 540 +--+--------------+--------------+--+ 541 | | 542 | BNG-UP | 543 | | 544 +-----------------------------------+ 546 Figure 2: Interfaces Between the CP and UP of the BNG 548 3.3.1. Service Interface 550 For a traditional BNG (without CU separation), the user dial-up 551 signals are terminated and processed by the control plane of a BNG. 552 When the CP and UP of a BNG are separated, there needs to be a way to 553 relay these signals between the CP and the UP. 555 The Service Interface (Si) is used to establish tunnels between the 556 CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, 557 and L2TP related control packets that are received from a Residential 558 Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN 559 [RFC7348]. 561 The detailed definition of Si is out of scope for this document. 563 3.3.2. Control Interface 565 The CP uses the Control Interface to deliver subscriber session 566 states, network routing entries, etc. to the UP (see Section 6.2.7)). 567 The UP uses this interface to report subscriber service statistics, 568 subscriber detection results, etc. to the CP (see Sections 6.3 and 569 6.4). A carrying protocol for this interface is specified in this 570 document. 572 3.3.3. Management Interface 574 NETCONF [RFC6241] is the protocol used on the Management Interface 575 between a CP and UP. It is used to configure the parameters of the 576 Control Interface, Service Interface, the Access interfaces and 577 QoS/ACL Templates. It is expected that implementations will make use 578 of existing YANG models where possible, but that new YANG models 579 specific to S-CUSP will need to be defined. The definitions of the 580 parameters that can be configured are out of scope for this document. 582 3.4. BNG CUPS Procedure Overview 584 The following numbered sequences (Figure 3) gives a high-level view 585 of the main BNG CUPS procedures. 587 RG UP CP AAA 588 | | | | 589 | |Establish S-CUSP Channel| | 590 | 1|<---------------------->| | 591 | | | | 592 | | Report Board | | 593 | | interface | | 594 | | information | | 595 | 2|------to CP via Ci----->| | 596 | | | | 597 | | Update BAS function | | 598 | 3| request / response | | 599 | |<-----on UP via Ci----->| | 600 | | | | 601 | | Update network routing | | 602 | | request / response | | 603 | 4|<------- via Ci-------->| | 604 | | | | 605 | Online Req | | | 606 5.1|-------------->| | | 607 | | Relay the Online Req | | 608 | 5.2|-----to CP via Si------>| Authentication| 609 | | | Req/Rep | 610 | | 5.3|<------------->| 611 | | Send the Online Rep | | 612 | 5.4|<----to UP via Si-------| | 613 | Online Rep | | | 614 5.5|<--------------| | | 615 | | Create subscriber | | 616 | | session on UP | | 617 | 5.6|<--------via Ci-------->| | 618 | | | CoA Request | 619 | | 6.1|<--------------| 620 | | Update session on UP | | 621 | 6.2|<--------via Ci-------->| | 622 | | | CoA Response | 623 | | 6.3|-------------->| 624 | | | | 625 | Offline Req | | | 626 7.1|-------------->| | | 627 | | Relay the Offline Req | | 628 | 7.2|------to CP via Si----->| | 629 | | | | 630 | | Send the Offline Rep | | 631 | 7.3|<-----to UP via Si------| | 632 | Offline Rep | | | 633 7.4|<--------------| | | 634 | | Delete session on UP | | 635 | 7.5|<--------via Ci-------->| | 636 | | | | 637 | | Event report | | 638 | 8|---------via Ci-------->| | 639 | | | | 640 | | Data Synchronization | | 641 | 9|<--------via Ci-------->| | 642 | | | | 643 | | CGN Address Allocation | | 644 | 10|<--------via Ci-------->| | 645 | | | | 647 Figure 3: BNG CUPS Procedures Overview 649 1. S-CUSP session establishment: This is the first step of BNG CUPS 650 procedures. Once the Control Interface parameters are configured 651 on a UP, it will start to setup S-CUSP sessions with the 652 specified CPs. The detailed definition of S-CUSP session 653 establishment can be found in Section 4.1.1. 655 2. Board and interface report: Once the S-CUSP session is 656 established between the UP and a CP, the UP will report status 657 information on the boards and subscriber-facing interfaces of 658 this UP to the CP. A board can also be called a Line/Service 659 Process Unit (LPU/SPU) card. The subscriber-facing interfaces 660 refer to the interfaces that connect the Access Network nodes 661 (e.g., OLT: Optical Line Terminal, DSLAM: Digital Subscriber Line 662 Access Multiplexer, etc.). The CP can use this information to 663 enable the Broadband Access Service (BAS) function (e.g., IPoE, 664 PPPoE, etc.) on the specified interfaces. See Sections 4.2.1 and 665 7.10 for more details on Resource reporting. 667 3. BAS (Broadband Access Service) function enable: To enable the BAS 668 function on the specified interfaces of a UP. 670 4. Subscriber network route advertisement: The CP will allocate one 671 or more IP address blocks to a UP. Each address block contains a 672 series of IP addresses. Those IP addresses will be allocated to 673 subscribers who are dialing up from the UP. To enable other nodes 674 in the network to learn how to reach the subscribers, the CP 675 needs to notify the UP to advertise to the network the routes 676 that can reach those IP addresses. 678 5. 5.1-5.6 is a complete call flow of a subscriber dial-up (as 679 defined in Section 2.1) process. When a UP receives a dial-up 680 request, it will relay the request packet to a CP through the 681 Service Interface. The CP will parse the request. If everything 682 is OK, it will send an authentication request to the AAA server 683 to authenticate the subscriber. Once the subscriber passes the 684 authentication, the AAA server will return a positive response to 685 the CP. Then the CP will send the dial-up response packet to the 686 UP, and the UP will forward the response packet to the subscriber 687 (RG). At the same time, the CP will create a subscriber session 688 on the UP, which enables the subscriber to access the network. 689 For different access types, the process may be a bit different. 690 But the high-level process is similar. For each access type, the 691 detail process can be found in Section 5. 693 6. 6.1-6.3 is the sequence when updating an existing subscriber 694 session. The AAA server initiates a Change of Authorization (CoA) 695 and sends the CoA to the CP. The CP will then update the session 696 according to the CoA. See Section 4.3.2 for more detail on CP 697 messages updating UP tables. 699 7. 7.1-7.5 is the sequence for deleting an existing subscriber 700 session. When a UP receives an offline request, it will relay the 701 request to a CP through the Service Interface. The CP will send 702 back a response to the UP through the Service Interface. The UP 703 will then forward the offline response to the subscriber. Then 704 the CP will delete the session on the UP through the Control 705 Interface. 707 8. Event reports include the following two parts (more detail can be 708 found in Section 4.3.4) Both are reported using the Event 709 message. 711 8.1. Subscriber Traffic Statistics Report 712 8.2. Subscriber Detection Result Report 714 9. Data synchronization: See Sections 4.2.5 for more detail on CP 715 and UP Synchronization. 717 10. CGN address allocation: See Sections 4.2.4 for more detail on CGN 718 Address Allocation. 720 4. S-CUSP Protocol Overview 722 4.1. Control Channel Related Procedures 724 4.1.1. S-CUSP Session Establishment 726 A UP is associated with a CP and is controlled by that CP. In the 727 case of a hot-standby or cold-standby, a UP is associated with two 728 CPs, one called the Master CP and the other called the Standby CP. 729 The association between a UP and its CPs is implemented by dynamic 730 configuration. 732 Once a UP knows its CPs, the UP starts to establish S-CUSP sessions 733 with those CPs, as shown in Figure 4. 735 UP CP 736 | | 737 | TCP Session Establishment | 738 |<------------------------------->| 739 | | 740 | HELLO (version, capability) | 741 |-------------------------------->| 742 | | 743 | HELLO (version, capability) | 744 |<--------------------------------| 745 | | 747 Figure 4: S-CUSP Session Establishment 749 The S-CUSP session establishment consists of two successive steps: 751 1. Establishment of a TCP [RFC793] connection (3-way handshake) 752 between the CP and the UP using a configured port from the 753 dynamic port range (49152-65535). 755 2. Establishment of an S-CUSP session over the TCP connection. 757 Once the TCP connection is established, the CP and the UP initialize 758 the S-CUSP session during which the version and Keepalive timers are 759 negotiated. 761 The version information (Hello TLV, see Section 7.4) is carried 762 within Hello messages (see Section 6.2.1). A CP can support multiple 763 versions, but a UP can only support one version. So, the version 764 negotiation is based on whether a version can be supported by both 765 the CP and the UP. For a CP or UP, if a Hello message is received 766 that does not indicate a version supported by both, a subsequent 767 Hello message with an Error Information TLV will be sent to the peer 768 to notify the peer of the "Version-Mismatch" error and the session 769 establishment phase fails. 771 Keepalive negotiation is performed by carrying a Keepalive TLV in the 772 Hello message. The Keepalive TLV includes a Keepalive timer and Dead 773 Timer field. The CP and UP have to agree on the Keepalive Timer and 774 Dead Timer. Otherwise, a subsequent Hello message with an Error 775 Information TLV will be sent to its peer and the session 776 establishment phase fails. 778 The S-CUSP session establishment phase fails if the CP or UP disagree 779 on the version and keepalive parameters or if one of the CP or UP 780 does not answer after the expiration of the Establishment timer. 781 When the S-CUSP session establishment fails, the TCP connection is 782 promptly closed. Successive retries are permitted, but an 783 implementation SHOULD make use of an exponential back-off session 784 establishment retry procedure. 786 The S-CUSP session timer values that need to be configured are 787 summarized in the table below. 789 Timer Range in Default 790 Name seconds Value 791 ------------- ------- ------- 792 Establishment Timer 1-32767 45 793 Keepalive Timer 0-255 30 794 DeadTimer 1-32767 4 * Keepalive 796 4.1.2. Keepalive Timer and DeadTimer 798 Once an S-CUSP session has been established, a UP or CP may want to 799 know that its S-CUSP peer is still connected. 801 Each end of an S-CUSP session runs a Keepalive timer. It restarts 802 the timer every time it sends a message on the session. When the 803 timer expires, it sends a Keepalive message. Thus, a message is 804 transmitted at least as often as the value the Keepalive timer is 805 reset to, unless, as explained below, that value is the special value 806 zero. 808 Each end of a S-CUSP session also run a DeadTimer, and restarts that 809 DeadTimer whenever a message is received on the session. If the 810 DeadTimer at an end of the session expires, that end declares the 811 session dead and the session will be closed, unless their DeadTimer 812 is set to the special value zero in which case the session will not 813 time out. 815 The minimum value of the Keepalive timer is 1 second, and it is 816 specified in units of 1 second. The RECOMMENDED default value is 30 817 seconds. The recommended default for the DeadTimer is four times the 818 value of the Keepalive timer used by the remote peer. As above, the 819 timers may be disabled by setting them to zero. 821 The Keepalive timer and DeadTimer are negotiated through the 822 Keepalive TLV carried in the Hello Message. 824 4.2. Node Related Procedures 826 4.2.1. UP Resource Report 828 Once an S-CUSP session has been established between a CP and an UP, 829 the UP reports the state information of the Boards and access-facing 830 interfaces on the UP to the CP, as shown in Figure 5. Report messages 831 are unacknowledged and are assumed to be delivered because the 832 session runs over TCP. 834 The CP can use that information to activate/enable the Broadband 835 Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the 836 specified interfaces. 838 In addition, the UP resource report may trigger a UP warm-standby 839 process. In the case of warm-standby, a failure on a UP may trigger 840 the CP to start a warm-standby process, by moving the on-line 841 subscriber sessions to a standby UP and then direct the affected 842 subscribers to access the Internet through the standby UP. 844 UP CP 845 | | 846 | Report Board Status | 847 |------to CP via Ci----->| 848 | | 849 | Report Interface Status| 850 |------to CP via Ci----->| 851 | | 853 Figure 5: UP Board and Interface Report 855 Board status information is carried in the Board Status TLV (Section 856 7.10.2) and Interface status information is carried in Interface 857 Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are 858 carried in the Report Message (Section 6.4). 860 4.2.2. Update BAS Function on Access Interface 862 Once the CP collects the interface status of a UP, it will 863 activate/de-activate/modify the BAS functions on specified interfaces 864 through the Update_Request and Update_Response message (Section 6.2) 865 exchanges, carrying the BAS Function TLV (Section 7.7). 867 UP CP 868 | | 869 | Update BAS function | 870 | Request | 871 |<-----on UP via Ci-------| 872 | | 873 | Update BAS function | 874 | Response | 875 |------on UP via Ci------>| 876 | | 878 Figure 6: Update BAS Function 880 4.2.3. Update Network Routing 882 The CP will allocate one or more address blocks to a UP. Each address 883 block contains a series of IP addresses. Those IP addresses will be 884 assigned to subscribers who are dialing up to the UP. To enable the 885 other nodes in the network to learn how to reach the subscribers, the 886 CP needs to install the routes on the UP and notify the UP to 887 advertise the routes to the network. 889 UP CP 890 | | 891 | Subscriber network route| 892 | update request | 893 |<------- via Ci----------| 894 | | 895 | Subscriber network route| 896 | update response | 897 |-------- via Ci--------->| 898 | | 900 Figure 7: Update Network Routing 902 The Update Request and Response Message exchanges, carrying the 903 IPv4/IPv6 Routing Information TLVs (Section 7.8), update the 904 subscriber's network routing information. 906 4.2.4. CGN Public IP Address Allocation 908 The following sequences describe the CGN address management related 909 procedures. Three independent procedures are defined, one each for 910 CGN address allocation request/response, CGN address renewal 911 request/response, and CGN address release request/response. 913 CGN address allocation/renew/release procedures are designed for the 914 case where the CGN function is running on the UP. The UP has to map 915 the subscriber private IP addresses to a public IP addresses, and 916 such mapping is performed by the UP locally when a subscriber dials- 917 up. That means the UP has to ask for public IPv4 address blocks for 918 CGN subscribers from the CP. 920 In addition, when a public IP address is allocated to a UP, there 921 will be a lease time (e.g., one day). Before the lease time expires, 922 the UP can ask for renewal of the IP address lease from the CP. It is 923 achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack 924 messages. 926 If the public IP address will not be used anymore, the UP SHOULD 927 release the address by sending an Addr_Release_Req message to the CP. 929 If the CP wishes to withdraw addresses that it has previously leased 930 to a UP, it uses the same procedures as above. The "Oper" code in 931 the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the 932 request is an update or withdraw. 934 The relevant messages are defined in Section 6.5. 936 UP CP 937 | | 938 | CGN Address Allocation | 939 | Request | 940 1.1|-------- via Ci--------->| 941 | CGN Address Allocation | 942 | Response | 943 1.2|<------- via Ci----------| 944 | | 945 | CGN Address Renew | 946 | Request | 947 2.1|-------- via Ci--------->| 948 | CGN Address Renew | 949 | Response | 950 2.2|<------- via Ci----------| 951 | | 952 | CGN Address Release | 953 | Request | 954 3.1|-------- via Ci--------->| 955 | CGN Address Release | 956 | Response | 957 3.3|<------- via Ci----------| 958 | | 960 Figure 8: CGN Public IP Address Allocation 962 4.2.5. Data Synchronization between the CP and UP 964 For a CU separated BNG, the UP will continue to function using the 965 state that has been installed in it even if the CP fails or the 966 session between the UP and CP fails. 968 Under some circumstances, it is necessary to synchronize state 969 between the CP and UP, for example if a CP fails and the UP is 970 switched to a different CP. 972 Synchronization includes two directions. One direction is from UP to 973 CP; in that case, the synchronization information is mainly about the 974 board/interface status of the UP. The other direction is from CP to 975 UP; in that case, the subscriber sessions, subscriber network routes, 976 L2TP tunnels, etc. will be synchronized to the UP. 978 The synchronization is triggered by a Sync_Request message, to which 979 the receiver will (1) reply with a Sync_Begin message to notify the 980 requester that synchronization will begin, and (2) then start the 981 synchronization using the Sync_Data message. When synchronization 982 finished, a Sync_End message will be sent. 984 The following figure shows the process of data synchronization 985 between a UP and a CP. 987 UP CP 988 | | 989 | Synchronization Request | 990 |<------- via Ci----------| 991 | | 992 | Synchronization Begin | 993 |-------- via Ci--------->| 994 | | 995 | Board/Interface Report | 996 |-------- via Ci--------->| 997 | | 998 | Synchronization End | 999 |-------- via Ci--------->| 1000 | | 1001 1) Synchronization from UP to CP 1003 UP CP 1004 | | 1005 | Synchronization Request | 1006 |-------- via Ci--------->| 1007 | | 1008 | Synchronization Begin | 1009 |<-------- via Ci---------| 1010 | | 1011 | Synchronizes | 1012 |Subscriber Session States| 1013 | Network Route Entries | 1014 |<------- via Ci----------| 1015 | | 1016 | Synchronization End | 1017 |<-------- via Ci---------| 1018 | | 1019 2) Synchronization from CP to UP 1021 Figure 9: Data Synchronization 1023 4.3. Subscriber Session Related Procedures 1025 A subscriber session consists of a set of forwarding states, 1026 policies, and security rules that are applied to the subscriber. It 1027 is used for forwarding subscriber traffic in a UP. To initialize a 1028 session on a UP, A collection of hardware resources (e.g., NP, TCAM 1029 etc.) have to be allocated to a session on a UP as part of its 1030 initiation. 1032 Subscriber session related procedures include subscriber session 1033 create, update, delete, and statistics report. The following sub- 1034 sections give a high-level view of the procedures. 1036 4.3.1. Create Subscriber Session 1038 The below sequence describes the DHCP IPv4 dial-up process. It is an 1039 example that shows how a subscriber session is created. (An example 1040 for IPv6 appears in Section 5.1.2.) 1042 RG UP CP AAA 1043 | | | | 1044 | Online Request| | | 1045 1|-------------->| | | 1046 | |Relay the Online Request| | 1047 | 2|-----to CP via Si------>| Authentication| 1048 | | | Req/Rep | 1049 | | 3|<------------->| 1050 | | Create subscriber | | 1051 | | session Request | | 1052 | 4|<--------via Ci---------| | 1053 | | | | 1054 | | Create subscriber | | 1055 | | session Response | | 1056 | 5|---------via Ci-------->| | 1057 | | | | 1058 | | | Accounting | 1059 | | 6|<------------->| 1060 | | | | 1061 | | Send Online Response | | 1062 | 7|<----to UP via Si-------| | 1063 | | | | 1064 |Online Response| | | 1065 12|<--------------| | | 1066 | | | | 1068 Figure 10: Subscriber Session Create 1070 The request starts from an Online Request message (step 1) from the 1071 RG (for example, a DHCP Discovery packet). When the UP receives the 1072 Online Request from the RG, it will tunnel the Online Request to the 1073 CP through the Service Interface (Step 2). A tunneling technology 1074 implements the Service Interface. 1076 When the CP receives the Online Request from the UP, it will send an 1077 authentication request to the AAA server to authenticate and 1078 authorize the subscriber (step 3). When a positive reply is received 1079 from the AAA server, the CP starts to create a subscriber session for 1080 the request. Relevant resources (e.g., IP address, bandwidth, etc.) 1081 will be allocated to the subscriber. Policies and security rules will 1082 be generated for the subscriber. Then the CP sends a request to 1083 create a session to the UP through the Control Interface (Ci) (step 1084 4), and a response is expected from the UP to confirm the creation 1085 (step 5). 1087 Finally, the CP will notify the AAA server to start accounting (step 1088 6). At the same time, an Online Response message (for example, a 1089 DHCP Ack packet) will be sent to the UP through the Si (step 7). And 1090 the UP will forward the Online Response to the RG (step 8). 1092 That completes the subscriber activation process. 1094 4.3.2. Update Subscriber Session 1096 The following numbered sequence shows the process of updating the 1097 subscriber session. 1099 UP CP AAA 1100 | | COA Request | 1101 | 1|<--------------| 1102 | Session update Request | | 1103 2|<--------via Ci---------| | 1104 | | | 1105 | Session update Response| | 1106 3|---------via Ci-------->| | 1107 | | COA Response | 1108 | 4|-------------->| 1109 | | | 1111 Figure 11: Subscriber Session Update 1113 When a subscriber session has been created on a UP, there may be 1114 requirements to update the session with new parameters (e.g., 1115 Bandwidth, QoS, policies, etc.). 1117 This procedure is triggered by a Change of Authorization (COA) 1118 request message sent by the AAA server. The CP will update the 1119 session on the UP according to the new parameters through the Control 1120 Interface. 1122 4.3.3. Delete Subscriber Session 1124 The below call flow shows how S-CUPS deals with a subscriber offline 1125 request. 1127 RG UP CP 1128 | | | 1129 |Offline Request | | 1130 1|--------------->| | 1131 | | Relay the Offline | 1132 | | Request | 1133 | 2|------to CP via Si----->| 1134 | | | 1135 | | Send the Offline | 1136 | | Response | 1137 | 3|<-----to UP via Si------| 1138 |Offline Response| | 1139 4|<---------------| | 1140 | | Session delete | 1141 | | Request | 1142 | |<--------via Ci---------| 1143 | | Session delete | 1144 | | Response | 1145 | |---------via Ci-------->| 1146 | | | 1148 Figure 12: Subscriber Session Delete 1150 Similar to the session creation process, when a UP receives an 1151 offline request from an RG, it will tunnel the request to a CP 1152 through the Si. 1154 When the CP receives the offline request, it will withdraw/release 1155 the resources (e.g., IP address, bandwidth) that have been allocated 1156 to the subscriber. Then, it sends a reply to the UP through the 1157 Service Interface and the UP will forward the reply to the RG. At 1158 the same time, it will delete all the status of the session on the UP 1159 through the Ci. 1161 4.3.4. Subscriber Session Events Report 1163 UP CP 1164 | | 1165 | Statistic/Detect report| 1166 |---------via Ci-------->| 1167 | | 1169 Figure 13: Events Report 1171 When a session is created on a UP, the UP will periodically report 1172 statistics information and detect results of the session to the CP. 1174 5. S-CUSP Call Flows 1176 The subsections below give an overview of various "dial-up" 1177 interactions over the Service Interface followed by an overview of 1178 the setting of information in the UP by the CP using S-CUSP over the 1179 Control Interface. 1181 S-CUSP messages are described in this document using Routing Backus 1182 Naur Form (RBNF) as defined in [RFC5511]. 1184 5.1. IPoE 1186 5.1.1. DHCPv4 Access 1188 The following sequence shows detailed procedures for DHCPv4 access. 1190 RG UP CP AAA 1191 | | | | 1192 | DHCP Discovery| | | 1193 1|-------------->| | | 1194 | |Relay the DHCP Discovery| | 1195 | 2|-----to CP via Si------>| AAA | 1196 | | | Req/Rep | 1197 | | 3|<------------->| 1198 | | | | 1199 | | Send the DHCP Offer | | 1200 | 4|<----to UP vis Si-------| | 1201 | DHCP Offer | | | 1202 5|<--------------| | | 1203 | DHCP Request | | | 1204 6|-------------->| | | 1205 | | Relay the DHCP Request| | 1206 | 7|-----to CP via Si------>| | 1207 | | | | 1208 | | Create subscriber | | 1209 | | session Request | | 1210 | 8|<--------via Ci---------| | 1211 | | Create subscriber | | 1212 | | session Response | | 1213 | 9|---------via Ci-------->| | 1214 | | | Accounting | 1215 | | 10|<------------->| 1216 | | | | 1217 | | Send DHCP ACK | | 1218 | 11|<----to UP via Si-------| | 1219 | | | | 1220 | DHCP ACK | | | 1221 12|<--------------| | | 1222 | | | | 1224 Figure 14: DHCPv4 Access 1226 The S-CUSP protocol implements steps 8 and 9. 1228 After a subscriber is authenticated and authorized by the AAA server, 1229 the CP creates a new subscriber session on the UP. This is achieved 1230 by sending an Update_Request message to the UP. 1232 The format of the Update_Request message is shown as follows using 1233 RBNF: 1235 ::= 1236 1237 1238 1239 [] 1241 The UP will reply with an Update_Response message, the format of the 1242 Update_Response message is as follows: 1244 ::= 1245 1246 [] 1248 5.1.2. DHCPv6 Access 1250 The following sequence shows detailed procedures for DHCPv6 access. 1252 RG UP CP AAA 1253 | | | | 1254 | Solicit | | | 1255 1|-------------->| | | 1256 | | Relay the Solicit | | 1257 | 2|-----to CP via Si------>| AAA | 1258 | | | Req/Rep | 1259 | | 3|<------------->| 1260 | | | | 1261 | | Send the Advertise | | 1262 | 4|<----to UP vis Si-------| | 1263 | Advertise | | | 1264 5|<--------------| | | 1265 | | | | 1266 | Request | | | 1267 6|-------------->| | | 1268 | | Relay the Request | | 1269 | 7|-----to CP via Si------>| | 1270 | | | | 1271 | | | | 1272 | | Create subscriber | | 1273 | | session Request | | 1274 | 8|<--------via Ci-------->| | 1275 | | | | 1276 | | Create subscriber | | 1277 | | session Response | | 1278 | 9|---------via Ci-------->| | 1279 | | | | 1280 | | | Accounting | 1281 | | 10|<------------->| 1282 | | | | 1283 | | Send Reply | | 1284 | 11|<----to UP via Si-------| | 1285 | | | | 1286 | Reply | | | 1287 12|<--------------| | | 1288 | | | | 1290 Figure 15: DHCPv6 Access 1292 Steps 1-7 are a standard DHCP IPv6 access process. The subscriber 1293 creation is triggered by a DHCP IPv6 request message. When this 1294 message is received, it means that the subscriber has passed the AAA 1295 authentication and authorization. Then the CP will create a 1296 subscriber session on the UP. This is achieved by sending an 1297 Update_Request message to the UP (Step 8). 1299 The format of the Update_Request message is as follows: 1301 ::= 1302 1303 1304 1305 [] 1307 The UP will reply with an Update_Response message (Step 9). The 1308 format of the Update_Response message is as follows: 1310 ::= 1311 1313 5.1.3. IPv6 SLAAC Access 1315 The following flow shows the IPv6 SLAAC access process. 1317 RG UP CP AAA 1318 | | | | 1319 | RS | | | 1320 1|-------------->| | | 1321 | | Relay the Router | | 1322 | | Solicit (RS) | | 1323 | 2|-----to CP via Si------>| AAA | 1324 | | | Req/Rep | 1325 | | 3|<------------->| 1326 | | | | 1327 | | Create subscriber | | 1328 | | session Request | | 1329 | 4|<--------via Ci---------| | 1330 | | | | 1331 | | Create subscriber | | 1332 | | session Response | | 1333 | 5|---------via Ci-------->| | 1334 | | | | 1335 | | Send Router Advertise | | 1336 | | (RA) | | 1337 | 6|<----to UP vis Si-------| | 1338 | RA | | | 1339 7|<--------------| | | 1340 | | | | 1341 | NS | | | 1342 8|-------------->| | | 1343 | | Relay the Neighbor | | 1344 | | Solicit (NS) | | 1345 | 9|-----to CP via Si------>| | 1346 | | | | 1347 | | | Accounting | 1348 | | 10|<------------->| 1349 | | | | 1350 | | Send a Neighbor | | 1351 | | Advertise (NA) | | 1352 | 11|<----to UP via Si-------| | 1353 | | | | 1354 | NA | | | 1355 12|<--------------| | | 1356 | | | | 1358 Figure 16: IPv6 SLAAC Access 1360 It starts with a Router Solicit (RS) request from an RG that is 1361 tunneled to the CP by the UP. After the AAA authentication and 1362 authorization, the CP will create a subscriber session on the UP. 1364 This is achieved by sending an Update_Request message to the UP (step 1365 4). 1367 The format of the Update_Request message is as follows: 1369 ::= 1370 1371 1372 1373 [] 1375 The UP will reply with an Update_Response message (step 5), the 1376 format of the Update_Response message is as follows: 1378 ::= 1379 1381 5.1.4. DHCPv6 + SLAAC Access 1383 The following call flow shows the DHCP IPv6 and SLAAC access process. 1385 RG UP CP AAA 1386 | | | | 1387 | RS | | | 1388 1|-------------->| | | 1389 | | Relay the Router | | 1390 | | Solicit (RA) | | 1391 | 2|-----to CP via Si------>| AAA | 1392 | | | Req/Rep | 1393 | | 3|<------------->| 1394 | | | | 1395 | | Create subscriber | | 1396 | | session Request | | 1397 | 4|<--------via Ci---------| | 1398 | | | | 1399 | | Create subscriber | | 1400 | | session Response | | 1401 | 5|---------via Ci-------->| | 1402 | | | | 1403 | | Send Router Advertise | | 1404 | | (RA) | | 1405 | 6|<----to UP vis Si-------| | 1406 | RA | | | 1407 7|<--------------| | | 1408 | | | | 1409 |DHCPv6 Solicit | | | 1410 8|-------------->| | | 1411 | | Relay DHCPv6 Solicit | | 1412 | 9|-----to CP via Si------>| | 1413 | | | | 1414 | | Update subscriber | | 1415 | | session Request | | 1416 | 10|<--------via Ci---------| | 1417 | | | | 1418 | | Update subscriber | | 1419 | | session Response | | 1420 | 11|---------via Ci-------->| | 1421 | | | | 1422 | | | Accounting | 1423 | | 12|<------------->| 1424 | | | | 1425 | | Send DHCPv6 Reply | | 1426 | 13|<----to UP via Si-------| | 1427 | | | | 1428 | DHCPv6 Reply | | | 1429 14|<--------------| | | 1430 | | | | 1432 Figure 17: DHCPv6 + SLAAC Access 1434 When a subscriber passes AAA authentication, the CP will create a 1435 subscriber session on the UP. This is achieved by sending an 1436 Update_Request message to the UP (step 4). 1438 ::= 1439 1440 1441 1442 [] 1444 The UP will reply with an Update_Response message (step 5). The 1445 format of the Update_Response is as follows: 1447 ::= 1448 1450 After receiving a DHCPv6 Solicit, the CP will update the subscriber 1451 session by sending an Update_Request message with new parameters to 1452 the UP (Step 10). 1454 The format of the Update_Request message is as follows: 1456 ::= 1457 1458 1459 1460 [] 1462 The UP will reply with an Update_Response message (step 11). The 1463 format of the Update_Response is as follows: 1465 ::= 1466 1468 5.1.5. DHCP Dual Stack Access 1470 The following sequence is a combination of DHCP IPv4 and DHCP IPv6 1471 access processes. 1473 RG UP CP AAA 1474 | | | | 1475 | DHCP Discovery| | | 1476 1|-------------->| | | 1477 | |Relay the DHCP Discovery| | 1478 | 2|-----to CP via Si------>| AAA | 1479 | | | Req/Resp | 1480 | | 3|<------------->| 1481 | | | | 1482 | | Send the DHCP Offer | | 1483 | 4|<----to UP vis Si-------| | 1484 | DHCP Offer | | | 1485 5|<--------------| | | 1486 | DHCP Request | | | 1487 6|-------------->| | | 1488 | | Relay the DHCP Request| | 1489 | 7|-----to CP via Si------>| | 1490 | | | | 1491 | | Create subscriber | | 1492 | | session Request | | 1493 | 8|<--------via Ci-------->| | 1494 | | Create subscriber | | 1495 | | session Response | | 1496 | 9|---------via Ci-------->| | 1497 | | | Accounting | 1498 | | 10|<------------->| 1499 | | Send DHCP ACK | | 1500 | 11|<----to UP via Si-------| | 1501 | | | | 1502 | DHCP ACK | | | 1503 12|<--------------| | | 1504 | RS | | | 1505 13|-------------->| | | 1506 | | Relay the Router | | 1507 | | Solicit (RA) | | 1508 | 14|-----to CP via Si------>| AAA | 1509 | | | Req/Rep | 1510 | | 15|<------------->| 1511 | | | | 1512 | | Create subscriber | | 1513 | | session Request | | 1514 | 16|<--------via Ci---------| | 1515 | | Create subscriber | | 1516 | | session Response | | 1517 | 17|---------via Ci-------->| | 1518 | | | | 1519 | | Send Router Advertise | | 1520 | | (RA) | | 1521 | 18|<----to UP vis Si-------| | 1522 | RA | | | 1523 19|<--------------| | | 1524 | | | | 1525 |DHCPv6 Solicit | | | 1526 20|-------------->| | | 1527 | | Relay DHCPv6 Solicit | | 1528 | 21|-----to CP via Si------>| | 1529 | | | | 1530 | | Update subscriber | | 1531 | | session Request | | 1532 | 22|<--------via Ci---------| | 1533 | | Update subscriber | | 1534 | | session Response | | 1535 | 23|---------via Ci-------->| | 1536 | | | Accounting | 1537 | | 24|<------------->| 1538 | | Send DHCPv6 Reply | | 1539 | 25|<----to UP via Si-------| | 1540 | DHCPv6 Reply | | | 1541 26|<--------------| | | 1542 | | | | 1544 Figure 18: DHCP Dual Stack Access 1546 The DHCP dual stack access includes three sets of Update_Request / 1547 Update_Response exchanges to create/update DHCPv4/v6 subscriber 1548 session. 1550 1. Create a DHCPv4 session (step 8 and 9) 1552 ::= 1553 1554 1555 1556 [] 1558 ::= 1559 1560 [] 1562 2. Create a DHCPv6 session (step 16 and 17) 1564 ::= 1565 1566 1567 1568 [] 1570 ::= 1571 1573 3. Update DHCPv6 session (step 22 and 23) 1575 ::= 1576 1577 1578 1579 [] 1581 ::= 1582 1584 5.1.6. L2 Static Subscriber Access 1586 L2 static subscriber access processes are as follows: 1588 RG UP CP AAA 1589 | | | | 1590 | | Static Subscriber | | 1591 | | Detection Req. | | 1592 | 1|<-----to UP via Ci------| | 1593 | | Static Subscriber | | 1594 | | Detection Rep. | | 1595 | 2|------to UP via Ci----->| | 1596 | ARP/ND(REQ) | | | 1597 3.1|<--------------| | | 1598 | ARP/ND(ACK) | | | 1599 3.2|-------------->| | | 1600 | | Relay the ARP/ND | | 1601 | 3.3|-----to CP via Si------>| AAA | 1602 | | | Req/Rep | 1603 | | 3.4|<------------->| 1604 | | Create subscriber | | 1605 | | session Request | | 1606 | 3.5|<--------via Ci---------| | 1607 | | Create subscriber | | 1608 | | session Response | | 1609 | 3.6|---------via Ci-------->| | 1610 | | | | 1611 | ARP/ND(REQ) | | | 1612 4.1|-------------->| | | 1613 | | Relay the ARP/ND | | 1614 | 4.2|-----to CP via Si------>| AAA | 1615 | | | Req/Rep | 1616 | | 4.3|<------------->| 1617 | | Create subscriber | | 1618 | | session Request | | 1619 | 4.4|<--------via Ci---------| | 1620 | | Create subscriber | | 1621 | | session Response | | 1622 | 4.5|---------via Ci-------->| | 1623 | ARP/ND(ACK) | | | 1624 4.6|<--------------| | | 1625 | | | | 1626 | IP Traffic | | | 1627 5.1|-------------->| | | 1628 | | Relay the IP Traffic | | 1629 | 5.2|-----to CP via Si------>| AAA | 1630 | | | Req/Rep | 1631 | | 5.3|<------------->| 1632 | | Create subscriber | | 1633 | | session Request | | 1634 | 5.4|<--------via Ci-------->| | 1635 | | Create subscriber | | 1636 | | session Response | | 1637 | 5.5|---------via Ci-------->| | 1638 | | | | 1639 | ARP/ND(REQ) | | | 1640 5.6|<--------------| | | 1641 | ARP/ND(ACK) | | | 1642 5.7|-------------->| | | 1643 | | | | 1645 Figure 19: L2 Static Subscriber Access 1647 For L2 static subscriber access, the process starts with a CP 1648 installing a static subscriber detection list on a UP. The list 1649 determines which subscribers will be detected. That is implemented 1650 by exchanging Update_Request and Update_Response messages between CP 1651 and UP. The format of the messages are as follows: 1653 ::= 1654 1655 1657 ::= 1658 1660 For L2 Static subscriber access, there are three ways to trigger the 1661 access process: 1663 1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP 1664 address, the access interface, and VLAN of the RG. The UP will 1665 actively trigger the access flow by sending an ARP/ND packet to 1666 the RG. If the RG is online, it will reply with an ARP/ND to the 1667 UP. The UP will tunnel the ARP/ND to the CP through the Si. The 1668 CP then triggers the authentication process. If the 1669 authentication result is positive. The CP will create a 1670 corresponding subscriber session on the UP. 1672 2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as 1673 option 1 (triggered by UP). The difference is that the RG will 1674 actively send the ARP/ND to trigger the process. 1676 3. Triggered by RG IP traffic (5.1-5.7): This is for the case where 1677 the RG has the ARP/ND information, but the subscriber session on 1678 the UP is lost (e.g., due to failure on the UP, or the UP 1679 restarted). That means the RG may keep sending IP packets to the 1680 UP. The packets will trigger the UP to start a new access 1681 process. 1683 From a subscriber session point of view, the procedures and the 1684 message formats for the above three cases are the same, as follows: 1686 IPv4 Case: 1687 ::= 1688 1689 1690 1691 [] 1693 ::= 1694 1695 [] 1697 IPv6 Case: 1698 ::= 1699 1700 1701 1702 [] 1704 ::= 1705 1707 5.2. PPPoE 1709 5.2.1. IPv4 PPPoE Access 1711 The following figure shows the IPv4 PPPoE access call flow. 1713 RG UP CP AAA 1714 | | | | 1715 | PPPoE Disc | PPPoE Disc | | 1716 1|<------------->|<---------via Si------->| | 1717 | | | | 1718 | PPP LCP | PPP LCP | | 1719 2|<------------->|<---------via Si------->| | 1720 | | | AAA | 1721 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1722 3|<------------->|<---------via Si------->|<------------->| 1723 | | | | 1724 | PPP IPCP | PPP IPCP | | 1725 4|<------------->|<---------via Si------->| | 1726 | | | | 1727 | | Create subscriber | | 1728 | | session Request | | 1729 | 5|<--------via Ci---------| | 1730 | | | | 1731 | | Create subscriber | | 1732 | | session Response | | 1733 | 6|---------via Ci-------->| | 1734 | | | | 1735 | | | Accounting | 1736 | | 7|<------------->| 1737 | | | | 1739 Figure 20: IPv4 PPPoE Access 1741 From the above sequence, step 1-4 are the standard PPPoE call flow. 1742 The UP is responsible for redirecting the PPPoE control packets to 1743 the CP or RG. The PPPoE control packets are transmitted between the 1744 CP and UP through the Si. 1746 After the PPPoE call flow, if the subscriber passed the AAA 1747 authentication and authorization, the CP will create a corresponding 1748 session on the UP through the Ci. The formats of the messages are as 1749 follows: 1751 ::= 1752 1753 1754 1755 1756 [] 1758 ::= 1759 1760 [] 1762 5.2.2. IPv6 PPPoE Access 1764 The following figure describes the IPv6 PPPoE access call flow. 1766 RG UP CP AAA 1767 | | | | 1768 | PPPoE Disc | PPPoE Disc | | 1769 1|<------------->|<--------via Si-------->| | 1770 | | | | 1771 | PPP LCP | PPP LCP | | 1772 2|<------------->|<---------via Si------->| | 1773 | | | AAA | 1774 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1775 3|<------------->|<---------via Si------->|<------------->| 1776 | | | | 1777 | PPP IP6CP | PPP IP6CP | | 1778 4|<------------->|<---------via Si------->| | 1779 | | | | 1780 | | Create subscriber | | 1781 | | session Request | | 1782 | 5|<--------via Ci---------| | 1783 | | | | 1784 | | Create subscriber | | 1785 | | session Response | | 1786 | 6|---------via Ci-------->| | 1787 | | | | 1788 | ND Negotiation| ND Negotiation | | 1789 7|<------------->|<---------via Si------->| | 1790 | | | | 1791 | | Update subscriber | | 1792 | | session Request | | 1793 | 8|<--------via Ci---------| | 1794 | | | | 1795 | | Update subscriber | | 1796 | | session Response | | 1797 | 9|---------via Ci-------->| | 1798 | | | | 1799 | | | Accounting | 1800 | | 10|<------------->| 1801 | | | | 1802 | DHCPv6 | DHCPv6 | | 1803 | Negotiation | Negotiation | | 1804 7'|<------------->|<---------via Si------->| | 1805 | | | | 1806 | | Update subscriber | | 1807 | | session Request | | 1808 | 8'|<---------via Ci--------| | 1809 | | | | 1810 | | Update subscriber | | 1811 | | session Response | | 1812 | 9'|---------via Ci-------->| | 1813 | | | | 1814 | | | Accounting | 1815 | | 10'|<------------->| 1816 | | | | 1818 Figure 21: IPv6 PPPoE Access 1820 From the above sequence, steps 1-4 are the standard PPPoE call flow. 1821 The UP is responsible for redirecting the PPPoE control packets to 1822 the CP or RG. The PPPoE control packets are transmitted between the 1823 CP and UP through the Si. 1825 After the PPPoE call flow, if the subscriber passed the AAA 1826 authentication and authorization, the CP will create a corresponding 1827 session on the UP through the Ci. The formats of the messages are as 1828 follows: 1830 ::= 1831 1832 1833 1834 1835 [] 1837 ::= 1838 1840 Then, the RG will initialize an ND/DHCPv6 negotiation process with 1841 the CP (see step 7 and 7'), after that, it will trigger an update 1842 (8-9, 8'-9') to the subscriber session. The formats of the update 1843 messages are as follows: 1845 ::= 1846 1847 1848 1849 1850 [] 1852 ::= 1853 1855 5.2.3. PPPoE Dual Stack Access 1857 The following figure shows a combination of IPv4 and IPv6 PPPoE 1858 access call flow. 1860 RG UP CP AAA 1861 | | | | 1862 |PPPoE Discovery| PPPoE Discovery | | 1863 1|<------------->|<---------via Si------->| | 1864 | | | | 1865 | PPP LCP | PPP LCP | | 1866 2|<------------->|<---------via Si------->| | 1867 | | | AAA | 1868 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1869 3|<------------->|<---------via Si------->|<------------->| 1870 | | | | 1871 | PPP IPCP | PPP IPCP | | 1872 4|<------------->|<---------via Si------->| | 1873 | | | | 1874 | | Create v4 subscriber | | 1875 | | session Request | | 1876 | 5|<--------via Ci---------| | 1877 | | Create v4 subscriber | | 1878 | | session Response | | 1879 | 6|---------via Ci-------->| | 1880 | | | Accounting | 1881 | | 7|<------------->| 1882 | PPP IP6CP | PPP IP6CP | | 1883 4'|<------------->|<---------via Si------->| | 1884 | | | | 1885 | | Create V6 subscriber | | 1886 | | session Request | | 1887 | 5'|<--------via Ci---------| | 1888 | | Create v6 subscriber | | 1889 | | session Response | | 1890 | 6'|---------via Ci-------->| | 1891 | | | | 1892 | ND Negotiation| ND Negotiation | | 1894 8|<------------->|<---------via Si------->| | 1895 | | | | 1896 | | Update v6 subscriber | | 1897 | | session Request | | 1898 | 9|<---------via Ci--------| | 1899 | | Update v6 subscriber | | 1900 | | session Response | | 1901 | 10|---------via Ci-------->| | 1902 | | | Accounting | 1903 | | 7'|<------------->| 1904 | DHCPv6 | DHCPv6 | | 1905 | Negotiation | Negotiation | | 1906 8'|<------------->|<---------via Si------->| | 1907 | | | | 1908 | | Update v6 subscriber | | 1909 | | session Request | | 1910 | 9'|<--------via Ci---------| | 1911 | | | | 1912 | | Update v6 subscriber | | 1913 | | session Response | | 1914 | 10'|---------via Ci-------->| | 1915 | | | | 1916 | | | Accounting | 1917 | | 7"|<------------->| 1918 | | | | 1920 Figure 22: PPPoE Dual Stack Access 1922 PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE 1923 access. The process is as above. The formats of the messages are as 1924 follows: 1926 1. Create an IPv4 PPPoE subscriber session (5-6) 1928 ::= 1929 1930 1931 1932 1933 [] 1935 ::= 1936 1937 [] 1939 2. Create an IPv6 PPPoE subscriber session (5'-6') 1941 ::= 1942 1943 1944 1945 1946 [] 1948 ::= 1949 1951 3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10') 1953 ::= 1954 1955 1956 1957 1958 [] 1960 ::= 1961 1963 5.3. WLAN Access 1965 The following figure shows the WLAN access call flow. 1967 RG UP CP AAA WEB Server 1968 | | | | | 1969 | DHCP | | | | 1970 | Discovery | | | | 1971 1|------------>| | | | 1972 | | DHCP | | | 1973 | | Discovery | | | 1974 | 2|-----via Si---->| AAA | | 1975 | | DHCP Offer |<-------->| | 1976 | 3|<----via Si-----| | | 1977 | DHCP Offer | | | | 1978 4|<------------| | | | 1979 | DHCP | | | | 1980 | Request | | | | 1981 5|------------>| | | | 1982 | | DHCP Request | | | 1983 | 6|-----via Si---->| | | 1984 | | | | | 1985 | | Create session | | | 1986 | | Request | | | 1987 | 7|<----via Ci-----| | | 1988 | | Create session | | | 1989 | | Response | | | 1990 | 8|----via Ci----->| | | 1991 | | | | | 1992 | | DHCP ACK | | | 1993 | 9|<----via Si-----| | | 1994 | | | | | 1995 | DHCP ACK | | | | 1996 10|<------------| | | | 1997 | | | | | 1998 | Subscriber | | | | 1999 | HTTP Traffic| | | | 2000 11|------------>|--> | | | 2001 | | | WEB URL | | | 2002 | Traffic | | Redirect | | | 2003 | Redirection | | | | | 2004 12|<------------|<-+ | | | 2005 | | | | 2006 | | 2007 13|-----------------Redirect to Web server------------->| 2008 | | 2009 14|<----------------Push HTTP log-in page---------------| 2010 | | 2011 15|-----------------User Authentication---------------->| 2012 | | 2013 | | | Portal Interchange | 2014 | | 16|<-------------------->| 2015 | | | | 2016 | | | AAA | | 2017 | | | Req/Rep | | 2018 | | 17|<-------->| | 2019 | | | | | 2020 | | Update session | | | 2021 | | Request | | | 2022 | 18|<----via Ci-----| | | 2023 | | | | | 2024 | | Update session | | | 2025 | | Response | | | 2026 | 19|-----via Ci---->| | | 2027 | | | | | 2029 Figure 23: WLAN Access 2031 WLAN access starts with the DHCP dial-up process (steps 1-6), after 2032 that the CP will create a subscriber session on the UP (steps 7-8). 2033 The formats of the session creation messages are as follows: 2035 IPv4 Case: 2036 ::= 2037 2038 2039 2040 [] 2042 ::= 2043 2044 [] 2046 IPv6 Case: 2047 ::= 2048 2049 2050 2051 [] 2053 ::= 2054 2056 After step 10, the RG will be allocated an IP address and its first 2057 HTTP packet will be redirected to a WEB server for subscriber 2058 authentication (steps 11-17). After the WEB authentication, if the 2059 result is positive, the CP will update the subscriber session by 2060 using the following message exchanges: 2062 IPv4 Case: ::= 2063 2064 2065 2066 [] 2068 ::= 2069 2070 [] 2072 IPv6 Case: ::= 2073 2074 2075 2076 [] 2078 ::= 2079 2081 5.4. L2TP 2083 5.4.1. L2TP LAC Access 2085 RG UP(LAC) CP(LAC) AAA LNS 2086 | | | | | 2087 | PPPoE | PPPoE | | | 2088 | Discovery | Discovery | | | 2089 1|<---------->|<---via Si--->| | | 2090 | | | | | 2091 | PPP LCP | PPP LCP | | | 2092 2|<---------->|<---via Si--->| | | 2093 | | | AAA | | 2094 |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| | 2095 3|<---------->|<---via Si--->|<------>| | 2096 | | | | | 2097 | PPP IPCP | PPP IPCP | | | 2098 4|<---------->|<---via Si--->| | | 2099 | | | | | 2100 | | L2TP tunnel | | | 2101 | | negotiation | | | 2102 | | SCCRQ/ | | | 2103 | | SCCRP/ | | | 2104 | | SCCCN | | | 2105 | 5|<---via Si--->| | | 2106 | | /\ | 2107 | | || forward | 2108 | | \/ | 2109 | |<-----------via routing---------->| 2110 | | | 2111 | | L2TP session | | | 2112 | | negotiation | | | 2113 | | ICRQ/ | | | 2114 | | ICRP/ | | | 2115 | | ICCN | | | 2116 | 6|<---via Si--->| | | 2117 | | /\ | 2118 | | || forward | 2119 | | \/ | 2120 | |<-----------via routing---------->| 2121 | | | 2122 | | Create | | | 2123 | | subscriber | | | 2124 | | session | | | 2125 | | Request | | | 2126 | 7|<---via Ci----| | | 2127 | | | | | 2128 | | Create | | | 2129 | | subscriber | | | 2130 | | session | | | 2131 | | Response | | | 2132 | 8|----via Ci--->| | | 2133 | | | | | 2134 | | 2135 | PAP/CHAP (Triggered by LNS) | 2136 9|<-----------------via routing?---------------->| 2137 | | 2139 Figure 24: L2TP-LAC Access 2141 Steps 1-4 are a standard PPPoE access process. After that, the LAC- 2142 CP starts to negotiate an L2TP session and tunnel with the LNS. 2143 After the negotiation, the CP will create an L2TP LAC subscriber 2144 session on the UP through the following messages: 2146 ::= 2147 2148 2149 2151 ::= 2152 2154 5.4.2. L2TP LNS IPv4 Access 2156 RG LAC UP(LNS) AAA CP(LNS) 2157 | | | | | 2158 | PPPoE | | | | 2159 | Discovery | | | | 2160 1|<---------->| | | | 2161 | | | | | 2162 | PPP LCP | | | | 2163 2|<---------->| | | 2164 | | AAA | | 2165 |PPP PAP/CHAP| Req/Rep | | 2166 3|<---------->|<--------------------->| | 2167 | | | 2168 | | | 2169 | | L2TP tunnel | L2TP tunnel | 2170 | | negotiation | negotiation | 2171 | | SCCRQ/ | SCCRQ/ | 2172 | | SCCRP/ | SCCRP/ | 2173 | | SCCCN | SCCCN | 2174 | 4|<------------>|<------via Si----->| 2175 | | | | 2176 | | L2TP session | L2TP session | 2177 | | negotiation | negotiation | 2178 | | ICRQ/ | ICRQ/ | 2179 | | ICRP/ | ICRP/ | 2180 | | ICCN | ICCN | 2181 | 5|<------------>|<------via Si----->| 2182 | | | | 2183 | | | Create | 2184 | | | subscriber | 2185 | | | session | 2186 | | | Request | 2187 | | 6|<-----via Ci-------| 2188 | | | Create | 2189 | | | subscriber | 2190 | | | session | 2191 | | | Response | 2192 | | 7|------via Ci------>| 2193 | | 2194 | PAP/CHAP (Triggered by LNS) | 2195 8|<--------------------------------------------->| 2196 | | 2197 | | | | AAA | 2198 | | | | Req/Rep | 2199 | | | 9|<-------->| 2200 | | | | 2201 | | 2202 | PPP IPCP | 2203 10|<--------------------------------------------->| 2204 | | 2205 | | | Update | 2206 | | | subscriber | 2207 | | | session | 2208 | | | Request | 2209 | | 11|<-----via Ci-------| 2210 | | | Update | 2211 | | | subscriber | 2212 | | | session | 2213 | | | Response | 2214 | | 12|------via Ci------>| 2215 | | | | 2217 Figure 25: IPv4 L2TP-LNS Access 2219 In this case, the BNG is running as an LNS and separated into LNS-CP 2220 and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When 2221 the L2TP session and tunnel negotiations are finished, the LNS-CP 2222 will create an L2TP LNS subscriber session on the LNS-UP. The format 2223 of the messages is as follows: 2225 ::= 2226 2227 2228 2229 2230 2231 2232 [] 2234 ::= 2235 2236 [] 2238 After that, the LNS-CP will trigger an AAA authentication. If the 2239 authentication result is positive, a PPP IPCP process will follow, 2240 then the CP will update the session with the following message 2241 exchanges: 2243 ::= 2244 2245 2246 2247 2248 2249 2250 [] 2252 ::= 2253 2254 [] 2256 5.4.3. L2TP LNS IPv6 Access 2258 RG LAC UP(LNS) AAA CP(LNS) 2259 | | | | | 2260 | PPPoE | | | | 2261 | Discovery | | | | 2262 1|<---------->| | | | 2263 | | | | | 2264 | PPP LCP | | | | 2265 2|<---------->| | | 2266 | | AAA | | 2267 |PPP PAP/CHAP| Req/Rep | | 2268 3|<---------->|<--------------------->| | 2269 | | | 2270 | | | 2271 | | L2TP tunnel | L2TP tunnel | 2272 | | negotiation | negotiation | 2273 | | SCCRQ/ | SCCRQ/ | 2274 | | SCCRP/ | SCCRP/ | 2275 | | SCCCN | SCCCN | 2276 | 4|<------------>|<------via Si----->| 2277 | | | | 2278 | | L2TP session | L2TP session | 2279 | | negotiation | negotiation | 2280 | | ICRQ/ | ICRQ/ | 2281 | | ICRP/ | ICRP/ | 2282 | | ICCN | ICCN | 2283 | 5|<------------>|<------via Si----->| 2284 | | | | 2285 | | | Create | 2286 | | | subscriber | 2287 | | | session | 2288 | | | Request | 2289 | | 6|<-----via Ci-------| 2290 | | | Create | 2291 | | | subscriber | 2292 | | | session | 2293 | | | Response | 2294 | | 7|------via Ci------>| 2295 | | 2296 | PAP/CHAP (Triggered by LNS) | 2297 8|<--------------------------------------------->| 2298 | | 2299 | | | | AAA | 2300 | | | | Req/Rep | 2301 | | | 9|<-------->| 2302 | | | | | 2303 | | 2304 | PPP IP6CP | 2305 10|<--------------------------------------------->| 2306 | | 2307 | | | Update | 2308 | | | subscriber | 2309 | | | session | 2310 | | | Request | 2311 | | 11|<-----via Ci-------| 2312 | | | Update | 2313 | | | subscriber | 2314 | | | session | 2315 | | | Response | 2316 | | 12|------via Ci------>| 2317 | | | | 2318 | | | 2319 | ND negotiation | ND negotiation | 2320 13|<------------------------->|<-----via Si------>| 2321 | | | 2322 | | | Update | 2323 | | | subscriber | 2324 | | | session | 2325 | | | Request | 2326 | | 14|<-----via Ci-------| 2327 | | | Update | 2328 | | | subscriber | 2329 | | | session | 2330 | | | Response | 2331 | | 15|------via Ci------>| 2332 | | | | 2334 Figure 26: L2TP-LNS IPv6 Access 2336 Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5 2337 finish the normal L2TP dial-up process. When the L2TP session and 2338 tunnel negotiations are finished, the LNS-CP will create an L2TP LNS 2339 subscriber session on the LNS-UP. The format of the messages is as 2340 follows: 2342 ::= 2343 2344 2345 2346 2347 2348 2349 [] 2351 ::= 2352 2354 After that, the LNS-CP will trigger a AAA authentication. If the 2355 authentication result is positive, a PPP IP6CP process will follow, 2356 then the CP will update the session with the following message 2357 exchanges: 2359 ::= 2360 2361 2362 2363 2364 2365 2366 [] 2368 ::= 2369 2371 Then, an ND negotiation will be triggered by the RG. After the ND 2372 negotiation, the CP will update the session with the following 2373 message exchanges: 2375 ::= 2376 2377 2378 2379 2380 2381 2382 [] 2384 ::= 2385 2387 5.5. CGN (Carrier Grade NAT) 2389 RG UP CP AAA 2390 | | | | 2391 | | Public Address Block | | 2392 | | Allocation Request | | 2393 | 1|<--------via Ci-------->| | 2394 | | Public Address Block | | 2395 | | Allocation Reply | | 2396 | 2|---------via Ci-------->| | 2397 | | | | 2398 | Subscriber | | | 2399 | access request| Subscriber | | 2400 3|-------------->| access request | | 2401 | 4|----------via Si------->| | 2402 | | | AAA | 2403 | | Subscriber | Req/Rep | 2404 | Subscriber | access reply 5|<------------->| 2405 | access reply 6|<---------via Si--------| | 2406 7|<--------------| | | 2407 | | | | 2408 | | Create subscriber | | 2409 | | session Request | | 2410 | 8|<--------via Ci---------| | 2411 | | | | 2412 | | Create subscriber | | 2413 | | session Response | | 2414 | | (with NAT information) | | 2415 | 9|---------via Ci-------->| | 2416 | | | | 2417 | | | Accounting | 2418 | | | with source | 2419 | | | information | 2420 | | 10|<------------->| 2421 | | | Public IP + | 2422 | | | Port range | 2423 | | | to Private IP| 2424 | | | mapping | 2425 | | | | 2427 Figure 27: CGN Access 2429 The first steps allocate one or more CGN address blocks to the UP 2430 (steps 1-2). This is achieved by the following message exchanges 2431 between CP and UP. 2433 ::= 2434 2436 ::= 2437
2439 Steps 3-9 show the general dial-up process in the case of CGN mode. 2440 The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in 2441 above sections. 2443 If a subscriber is a CGN subscriber, once the subscriber session is 2444 created/updated, the UP will report the NAT information to the CP. 2445 This is achieved by carrying the "Subscriber CGN Port Range TLV" in 2446 the Update_Response message. 2448 5.6. L3 Leased Line Access 2450 5.6.1. Web Authentication 2452 RG UP CP AAA WEB Server 2453 | | | | | 2454 | User | | | | 2455 | traffic | | | | 2456 1|------------>| | | | 2457 | | User | | | 2458 | | traffic | | | 2459 | 2|-----via Si---->| AAA | | 2460 | | | Req/Rep | | 2461 | | 3|<-------->| | 2462 | | Create session | | | 2463 | | Request | | | 2464 | 4|<----via Ci-----| | | 2465 | | | | | 2466 | | Create session | | | 2467 | | Response | | | 2468 | 5|----via Ci----->| | | 2469 | HTTP | | | | 2470 | traffic | | | | 2471 6|------------>| | | | 2472 | | | | | 2473 | Redirect to | | | | 2474 | Web URL | | | | 2475 7|<------------| | | | 2476 | | | | | 2477 | | 2478 8|-----------------Redirected to Web server----------->| 2479 | | 2480 9|<----------------Push HTTP Log-in page---------------| 2481 | | 2482 10|-----------------User Authentication---------------->| 2483 | | 2484 | | | Portal Interchange | 2485 | | 11|<-------------------->| 2486 | | | | 2487 | | | AAA | | 2488 | | | Req/Rep | | 2489 | | 12|<-------->| | 2490 | | | | | 2491 | | | | | 2492 | | Update session | | | 2493 | | Request | | | 2494 | 13|<----via Ci-----| | | 2495 | | | | | 2496 | | Update session | | | 2497 | | Response | | | 2498 | 14|----via Ci----->| | | 2499 | | | | | 2501 Figure 28: Web Authentication based L3 Leased Line Access 2503 In this case, IP traffic from the RG will trigger the CP to 2504 authenticate the RG by checking the source IP and the exchanges with 2505 the AAA server. Once the RG passed the authentication, the CP will 2506 create a corresponding subscriber session on the UP through the 2507 following message exchanges: 2509 IPv4 Case: 2510 ::= 2511 2512 2513 2514 [] 2516 ::= 2517 2518 [] 2520 IPv6 Case: 2521 ::= 2522 2523 2524 2525 [] 2527 ::= 2528 2530 Then, the HTTP traffic from the RG will be redirected to a WEB server 2531 to finish the WEB authentication. Once the WEB authentication is 2532 passed, the CP will trigger another AAA authentication. After the 2533 AAA authentication, the CP will update the session with the following 2534 message exchanges: 2536 IPv4 Case: 2537 ::= 2538 2539 2540 2541 [] 2543 ::= 2544 2545 [] 2547 IPv6 Case: 2548 ::= 2549 2550 2551 2552 [] 2554 ::= 2555 2557 5.6.2. User Traffic Trigger 2559 RG UP CP AAA 2560 | | | | 2561 | | L3 access | | 2562 | | control list | | 2563 | 1|<----via Ci-----| | 2564 | User | | | 2565 | traffic | | | 2566 2|------------>| | | 2567 | | User | | 2568 | | traffic | | 2569 | 3|-----via Si---->| | 2570 | | | AAA | 2571 | | | Req/Rep | 2572 | | 4|<-------->| 2573 | | | | 2574 | | Create session | | 2575 | | Request | | 2576 | 5|<----via Ci-----| | 2577 | | Create session | | 2578 | | Response | | 2579 | 6|----via Ci----->| | 2580 | | | | 2582 Figure 29: User Traffic Triggered L3 Leased Line Access 2584 In this user traffic triggered case, the CP must install an access 2585 control list on the UP, which is used by the UP to determine whether 2586 an RG is legal or not. If the traffic is from a legal RG, it will be 2587 redirected to the CP though the Si. The CP will trigger a AAA 2588 interchange with the AAA server. After that, the CP will create a 2589 corresponding subscriber session on the UP with the following message 2590 exchanges: 2592 IPv4 Case: 2593 ::= 2594 2595 2596 2597 [] 2599 ::= 2600 2601 [] 2603 IPv6 Case: 2604 ::= 2605 2606 2607 2608 [] 2610 ::= 2611 2613 5.7. Multicast Service Access 2615 RG UP CP AAA 2616 | | | | 2617 | User access | User access | AAA | 2618 | request | request | Req/Rep | 2619 1|<----------->|<----via Si---->|<-------->| 2620 | | User | | 2621 | | | | 2622 | | | | 2623 | | Create session | | 2624 | | Request | | 2625 | 2|<----via Ci---->| | 2626 | | | | 2627 | | Create session | | 2628 | | Response | | 2629 | 3|----via Ci----->| | 2630 | | | | 2631 | Multicast | | | 2632 | negotiation | | | 2633 4|<----------->| | | 2634 | | | | 2636 Figure 30: Multicast Access 2638 Multicast access starts with a user access request from the RG. The 2639 request will be redirected to the CP by the Si. A follow-up AAA 2640 interchange between the CP and the AAA server will be triggered. 2641 After the authentication, the CP will create a multicast subscriber 2642 session on the UP through the following messages: 2644 IPv4 Case: 2645 ::= 2646 2647 2648 2649 2650 [] 2652 ::= 2653 2654 [] 2656 IPv6 Case: 2657 ::= 2658 2659 2660 2661 2662 [] 2664 ::= 2665 2667 6. S-CUSP Message Formats 2669 An S-CUSP message consists of a common header followed by a variable- 2670 length body consisting entirely of TLVs. Receiving an S-CUSP message 2671 with an unknown message type or missing mandatory TLV MUST trigger an 2672 Error message (see Section 6.7) or a response message with an Error 2673 Information TLV (see Section 7.6). 2675 Conversely, if a TLV is optional, the TLV may or may not be present. 2676 Optional TLVs are indicated in the message formats shown in this 2677 document by being enclosed in square brackets. 2679 This section specifies the format of the common S-CUSP message header 2680 and lists the defined messages. 2682 Network byte order is used for all multi-byte fields. 2684 6.1. Common Message Header 2686 S-CUSP Common Message Header: 2687 0 1 2 3 2688 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 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | Ver | Resv | Message-Type | Message-Length | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | Reserved | Transaction-ID | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 Figure 6.1: S-CUSP Message Common Header 2697 o Ver (4 bits): The major version of the protocol. This document 2698 specifies version 1. Different major versions of the protocol 2699 may have significantly different message structure and format 2700 except that the Ver field will always be in the same place at 2701 the beginning of each message. A successful S-CUSP session 2702 depends on the CP and the UP both using the same major version 2703 of the protocol. 2705 o Resv (4 bits): Reserved. MUST be sent as zero and ignored on 2706 receipt. 2708 o Message-Type (8 bits): The set of message types specified in 2709 this document is listed in Section 9.1. 2711 o Message-Length (16 bits): Total length of the S-CUSP message 2712 including the common header, expressed in number of bytes as an 2713 unsigned integer. 2715 o Transaction ID (16 bits): This field is used to identify 2716 requests. It is echoed back in any corresponding 2717 ACK/Response/Error message. It is RECOMMENDED that a 2718 monotonically increasing value be used in successive message 2719 and that value wrap back to zero after 0xFFFF. The contents of 2720 this field is an opaque value that the receiver MUST NOT use 2721 for any purpose except to echo back in a corresponding response 2722 and, optionally, for logging. 2724 6.2. Control Messages 2726 This document defines the following control messages: 2728 Type Name Notes and TLVs that can be carried 2729 ---- ---- ------------------------------------ 2730 1 Hello Hello TLV, Keepalive TLV. 2731 2 Keepalive A common header with the Keepalive message 2732 type. 2733 3 Sync_Request Synchronization request. 2734 4 Sync_Begin Synchronization starts. 2735 5 Sync_Data Synchronization data: TLVs specified in 2736 Section 5. 2737 6 Sync_End End synchronization. 2738 7 Update_Request TLVs specified in Sections 7.6-7.9. 2739 8 Update_Response TLVs specified in Sections 7.6-7.9. 2741 6.2.1. Hello Message 2743 Hello message is used for S-CUSP session establishment and version 2744 negotiation. The detail of S-CUSP session establishment and version 2745 negotiation can be found in Section 4.1.1. 2747 The format of Hello message is as follows: 2749 ::= 2750 2751 2752 [] 2754 The return code and negotiation result will be carried in the Error 2755 Information TLV. They are listed as follows: 2757 0: Success, version negotiation success. 2759 1: Failure, malformed message received. 2761 2: One or more of the TLVs was not understood. 2763 1001: The version negotiation fails. The S-CUSP session 2764 establishment phase fails. 2766 1002: The keepalive negotiation fails. The S-CUSP session 2767 establishment phase fails. 2769 1003: The establishment timer expires. session establishment 2770 phase fails. 2772 6.2.2. Keepalive Message 2774 Each end of an S-CUSP session periodically sends a Keepalive message. 2775 It is used to detect whether the peer end is still alive. The 2776 Keepalive procedures are defined in Section 4.1.2. 2778 The format of the Keepalive message is as follows: 2780 ::= 2782 6.2.3. Sync_Request Message 2784 The Sync_Request message is used to request synchronization from an 2785 S-CUSP peer. Both CP and UP can request their peer to synchronize 2786 data. 2788 The format of the Sync_Request message is as follows: 2790 ::= 2792 A Sync_Request message may result in a Sync_Begin message from its 2793 peer. The Sync_Begin message is defined in Section 6.2.4. 2795 6.2.4. Sync_Begin Message 2797 The Sync_Begin message is a reply to a Sync_Request message. It is 2798 used to notify the synchronization requester whether the 2799 synchronization can be started. 2801 The format of Sync_Begin message is as follows: 2803 ::= 2804 2806 The return codes are carried in the Error Information TLV. The codes 2807 are listed below: 2809 0: Success, be ready to synchronize. 2811 1: Failure, malformed message received. 2813 2: One or more of the TLVs was not understood. 2815 2001: Synch-NoReady. The data to be synchronized is not ready. 2817 2002: Synch-Unsupport. The data synchronization is not supported. 2819 6.2.5. Sync_Data Message 2821 The Sync_Data message is used to send data being synchronized between 2822 the CP and UP. The Sync_Data message has the same function and 2823 format as the Update_Request message. The difference is that there 2824 is no ACK for a Sync_Data message. An error caused by the Sync_Data 2825 message will result in a Sync_End message. 2827 There are two scenarios: 2829 Synchronization from UP to CP: Synchronize the resource data to 2830 CP. 2832 ::= 2833 [] 2835 Synchronization from CP to UP: Synchronize all subscriber sessions 2836 to UP. As for which TLVs should be carried, it depends on the 2837 specific session data to be synchronized. The process is 2838 equivalent to the creation of a particular session. Refer to 2839 Section 5 to see more details. 2841 ::= 2842 [] 2844 [] 2845 [] 2846 [] 2847 [] 2849 6.2.6. Sync_End Message 2851 The Sync_End message is used to indicate the end of a synchronization 2852 process. The format of a Sync_End message is as follows: 2854 ::= 2855 2857 The return/error codes are listed as follows: 2859 0: Success, synchronization finished. 2861 1: Failure, malformed message received. 2863 2: One or more of the TLVs was not understood. 2865 6.2.7. Update_Request Message 2867 The Update_Request message is a multi-purpose message, it can be used 2868 to create, update, and delete subscriber sessions on a UP. 2870 For session operations, the specific operation is controlled by the 2871 "Oper" field of the carried TLVs. As defined in Section 7.1, the 2872 "Oper" can be set to either "Update" or "Delete" when a TLV is 2873 carried in an Update_Request message. 2875 When the "Oper" set to Update, it means to create or update a 2876 subscriber session. If the "Oper" set to Delete, it is a request to 2877 delete a corresponding session. 2879 The format of Update_Request message is as follows: 2881 ::= 2882 [] 2883 [] 2884 [] 2885 [] 2886 [] 2888 Each Update_Request message will result in an Update_Response message 2889 that is defined in Section 6.2.8. 2891 6.2.8. Update_Response Message 2893 The Update_Response message is a response to an Update_Request 2894 message. It is used to confirm the update request (or reject it in 2895 the case of an error). The format of an Update_Response message is 2896 as follows: 2898 ::= 2899 [] 2900 2902 The return/error codes are carried in the Error Information TLV. 2903 They are listed as follows: 2905 0: Success. 2907 1: Failure, malformed message received. 2909 2: One or more of the TLVs was not understood. 2911 3001(Pool-Mismatch): The corresponding address pool cannot be 2912 found. 2914 3002 (Pool-Full): The address pool is fully allocated and no 2915 address segment is available. 2917 3003 (Subnet-Mismatch): The address pool subnet cannot be found. 2919 3004 (Subnet-Conflict): Subnets in the address pool have been 2920 classified into other clients. 2922 4001 (Update-Fail-No-Res): The forwarding table fails to be 2923 delivered because the forwarding resources are insufficient. 2925 4002 (QoS-Update-Success): The QoS policy takes effect. 2927 4003 (QoS-Update-Sq-Fail): Failed to process the queue in the QoS 2928 policy. 2930 4004 (QoS-Update-CAR-Fail): Processing of the CAR in the QoS 2931 policy fails. 2933 4005 (Statistic-Fail-No-Res): Statistics processing failed due to 2934 insufficient statistics resources. 2936 6.3. Event Message 2938 The Event message is used to report subscriber session traffic 2939 statistics and detection information. The format of Event message is 2940 as follows: 2942 ::= 2943 [] 2944 [] 2946 6.4. Report Message 2948 The Report message is used to report board and interface status on a 2949 UP. The format of Report message is as follows: 2951 ::= 2952 [] 2953 [] 2955 6.5. CGN Messages 2957 This document defines the following resource allocation messages: 2959 Type Message Name TLV that is carried 2960 ---- ------------------- ------------------------ 2961 200 Addr_Allocation_Req Address Allocation Request 2962 201 Addr_Allocation_Ack Address Allocation Response 2963 202 Addr_Renew_Req Address Renewal Request 2964 203 Addr_Renew_Ack Address Renewal Response 2965 204 Addr_Release_Req Address Release Request 2966 205 Addr_Release_Ack Address Release Response 2968 6.5.1. Addr_Allocation_Req Message 2970 The Addr_Allocation_Req message is used to request CGN address 2971 allocation. The format of Addr_Allocation_Req message is as follows: 2973 ::= 2974
2976 6.5.2. Addr_Allocation_Ack Message 2978 The Addr_Allocation_Ack message is a response to an 2979 Addr_Allocation_Req message. The format of Addr_Allocation_Ack 2980 message is as follows: 2982 ::= 2983
2985 6.5.3. Addr_Renew_Req Message 2987 The Addr_Renew_Req message is used to request address renewal. The 2988 format of Addr_Renew_Req message is as follows: 2990 ::= 2991
2993 6.5.4. Addr_Renew_Ack Message 2995 The Addr_Renew_Ack message is a response to an Addr_Renew_Req 2996 message. The format of Addr_Renew_Req message is as follows: 2998 ::= 2999
3001 6.5.5. Addr_Release_Req Message 3003 The Addr_Release_Req message is used to request address release. The 3004 format of Addr_Release_Req message is as follows: 3006 ::= 3007
3009 6.5.6. Addr_Release_Ack Message 3011 The Addr_Release_Ack message is a response to an Addr_Release_Req 3012 message. The format of Addr_Release_Ack message is as follows: 3014 ::= 3015
3017 6.6. Vendor Message 3019 The Vendor message, in conjunction with the vendor TLV and vendor 3020 sub-TLV, can be used by vendors to extend the S-CUSP protocol. The 3021 message type is 11. If the receiver does not recognize the message, 3022 an Error message will be returned to the sender. 3024 The format of the Vendor message is as follows: 3026 ::= 3027 3028 [] 3030 6.7 Error Message 3032 The Error message is defined to return some critical error 3033 information to the sender. If a receiver does not support the type 3034 of the received message, it MUST return an Error message to the 3035 sender. 3037 The format of the Error message is as below: 3039 ::= 3040 3042 7. S-CUSP TLVs and Sub-TLVs 3044 This section specifies the following: 3046 o the format of the TLVs that appear in S-CUSP messages, 3048 o the format of the sub-TLVs that appear within the values of some 3049 TLVs, and 3051 o the format of some basic data fields that appear within TLVs or 3052 sub-TLVs. 3054 See Section 9 for a list of all defined TLVs and sub-TLVs. 3056 7.1. Common TLV Header 3058 S-CUSP messages consist of the common header specified in Section 6.1 3059 followed by TLVs formatted as specified in this section. 3061 0 1 2 3 3062 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 3063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3064 | Oper | TLV-Type | TLV-Length | 3065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3066 ~ Value ~ 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 Figure 32: Common TLV Header 3071 o Oper (4 bits): For Message-Types that specify an operation on a 3072 data set, the Oper field is interpreted as Update, Delete, or 3073 Reserved as specified in Section 9.3. For all other Message-Types, 3074 the Oper field MUST be sent as zero and ignored on receipt. 3076 o TLV-Type (12 bits): The Type of a TLV. TLV-Type specifies the 3077 interpretation and format of the Value field of the TLV. See 3078 Section 9.2. 3080 o TLV-Length (2 bytes): The length of the Value portion of the TLV 3081 in bytes as an unsigned integer. 3083 o Value (variable length): This is the value portion of the TLV 3084 whose size is given by TLV-Length. The value portion consists of 3085 fields, frequently using one of the basic data field types (see 3086 Section 7.2) and sub-TLVs (see Section 7.3). 3088 7.2. Basic Data Fields 3090 This section specifies the binary format of several standard basic 3091 data fields that are used within other data structures in this 3092 specification. 3094 o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section 3095 7.3) to provide the length. The use of this data type in S-CUSP is 3096 to provide convenient labels for use by network operators in 3097 configuring and debugging their networks and interpreting S-CUSP 3098 messages. Subscribers will not normally see these labels. They 3099 are normally interpreted as ASCII [RFC20]. 3101 o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042]. 3103 o IPv4-Address: 8 octets. 4 octets of the IPv4 address value 3104 followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX. 3106 o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4 3107 octet integer n in the range of 0 to 128 which gives the address 3108 mask as the one's complement of 2**(128-n) - 1. 3110 o VLAN ID: 2 octets. As follows [802.1Q]: 3112 0 1 3113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 | PRI |D| VLAN-ID | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 PRI: Priority. Default value 7. 3120 D: Drop Eligibility Indicator (DEI). Default value 0. 3122 VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are 3123 not valid VLAN IDs [802.1Q].) 3125 7.3. Sub-TLV Format and Sub-TLVs 3127 In some cases, the Value portion of a TLV, as specified above, can 3128 contain one or more Sub-TLVs formatted as follows: 3130 0 1 2 3 3131 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 3132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 | Type | Length | 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3135 | Value | 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 3138 Figure 33: Sub-TLV Header 3140 o Type (2 bytes): The Type of a Sub-TLV. The Type field specified 3141 the interpretation and format of the Value field of the TLV. 3142 Sub-TLV Type values have the same meaning regardless of the TLV 3143 Type of the TLV within which the sub-TLV occurs. See Section 3144 9.4. 3146 o Length (2 bytes): The length of the Value portion of the sub- 3147 TLV in bytes as an unsigned integer. 3149 o Value (variable length): This is the value portion of the sub- 3150 TLV whose size is given by Length. 3152 The sub-TLVs currently specified are defined in the following 3153 subsections. 3155 7.3.1. Name sub-TLVs 3157 This document defines the following name sub-TLVs that are used to 3158 carry the name of the corresponding object. The length of each of 3159 these sub-TLVs is variable from 1 to 255 octets. The value is of 3160 type STRING padded with zeros octets to 4-octet alignment. 3162 Type Sub-TLV Name Meaning 3163 ----- -------------------- ------------------- 3164 1 VRF-Name The name of a VRF 3165 2 Ingress-QoS-Profile The name of an ingress QoS profile 3166 3 Egress-QoS-Profile The name of an egress QoS profile 3167 4 User-ACL-Policy The name of an ACL policy 3168 5 Multicast-ProfileV4 The name of an IPv4 multicast profile 3169 6 Multicast-ProfileV6 The name of an IPv6 multicast profile 3170 7 NAT-Instance The name of a NAT instance 3171 8 Pool-Name The name of an address pool 3173 7.3.2. Ingress-CAR sub-TLV 3175 The Ingress-CAR sub-TLV indicates the authorized upstream Committed 3176 Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR 3177 sub-TLV is 9. The sub-TLV length is 16. The format is as shown in 3178 Figure 34. 3180 0 1 2 3 3181 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 3182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3183 | CIR (Committed Information Rate) | 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 | PIR (Peak Information Rate) | 3186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 | CBS (Committed Burst Size) | 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 | PBS (Peak Burst Size) | 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3192 Figure 34: Ingress-CAR sub-TLV 3194 Where: 3196 CIR (4 bytes): Guaranteed rate in bits/second. 3198 PIR (4 bytes): Burst rate in bits/second. 3200 CBS (4 bytes): The token bucket in bytes. 3202 PBS (4 bytes): Burst token bucket in bytes. 3204 These fields are unsigned integers. More details about CIR, PIR, CBS, 3205 and PBS can be found in [RFC2698]. 3207 7.3.3. Egress-CAR sub-TLV 3209 The Egress-CAR sub-TLV indicates the authorized downstream Committed 3210 Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub- 3211 TLV is 10. Its sub-TLV length is 16 octets. The format of the value 3212 part is as defined below. 3214 0 1 2 3 3215 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 3216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3217 | CIR (Committed Information Rate) | 3218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 | PIR (Peak Information Rate) | 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 | CBS (Committed Burst Size) | 3222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 | PBS (Peak Burst Size) | 3224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3226 Figure 35: Egress-CAR sub-TLV 3228 Where: 3230 CIR (4 bytes): Guaranteed rate in bits/second. 3232 PIR (4 bytes): Burst rate in bits/second. 3234 CBS (4 bytes): The token bucket in bytes. 3236 PBS (4 bytes): Burst token bucket in bytes. 3238 These fields are unsigned integers. More details about CIR, PIR, CBS, 3239 and PBS can be found in [RFC2698]. 3241 7.3.4. If-Desc sub-TLV 3243 The If-Desc sub-TLV is defined to designate an interface. It is an 3244 optional sub-TLV that may be carried in those TLVs that have an "if- 3245 index" or "out-if-index" field. The If-Desc sub-TLV is used as a 3246 locally unique identifier within a BNG. 3248 The sub-TLV type is 11. The sub-TLV length is 12 octets. The format 3249 depends on the If-Type. The format of the value part is as follows: 3251 0 1 2 3 3252 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 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 | If-Type (1-5)| Chassis | Slot | 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 | Sub-Slot | Port Number | 3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3258 | Sub-Port Number | 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 If-Desc sub-TLV (Physical Port) 3262 0 1 2 3 3263 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 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 | If-Type (6-7) | Reserved | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 | Logic-ID | 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 | Sub-Port Number | 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3271 If-Desc sub-TLV (Virtual Port) 3273 Figure 36: If-Desc sub-TLV Formats 3275 Where: 3277 If-Type: 8 bits in length. The value of this field indicates the 3278 type of an interface. The If-Type values defined in this document 3279 are listed in Section 9.6. 3281 Chassis (8 bits): Identifies the chassis that the interface 3282 belongs to. 3284 Slot (16 bits): Identifies the slot that the interface belongs to. 3286 Sub-slot (16 bits): Identifies the sub-slot the interface belongs 3287 to. 3289 Port Number (16 bits): An identifier of a physical port/interface 3290 (e.g., If-Type: 1-5). It is locally significant within the 3291 slot/sub-slot. 3293 Sub-port Number (32 bits): An identifier of the sub-port. Locally 3294 significant within its "parent" port (physical or virtual). 3296 Logic-ID (32 bits): An identifier of a virtual interface (e.g., 3297 If-Type: 6-7) 3299 7.3.5. IPv6 Address List sub-TLV 3301 The IPv6 Address List sub-TLV is used to convey one or more IPv6 3302 addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV 3303 type is 12. The sub-TLV length is variable. 3305 The format of IPv6 Addresses sub-TLV is as follows: 3307 0 1 2 3 3308 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 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3310 ~ IPv6 Address ~ 3311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3312 ~ IPv6 Address ~ 3313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 ~ ... ~ 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 ~ IPv6 Address ~ 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3319 Figure 37: IPv6 Address List sub-TLV 3321 Where: 3323 IP Address (IPv6-Address): Each IP Address is an IP-Address type, 3324 carries an IPv6 address. 3326 7.3.6. Vendor sub-TLV 3328 The Vendor sub-TLV is intended to be used inside the value portion of 3329 the Vendor TLV (Section 7.13). It provides a Sub-Type that 3330 effectively extends the sub-TLV type in the sub-TLV header and 3331 provides for versioning of vendor sub-TLVs. 3333 The value part of the Vendor sub-TLV is formatted as follows: 3335 0 1 2 3 3336 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 3337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3338 | Vendor ID | 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 | Sub-Type | Sub-Type-Version | 3341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3342 ~ value (other as specified by vendor) ~ 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 Figure 38: Vendor sub-TLV 3347 Where: 3349 The sub-TLV type: 13. 3351 The sub-TLV length: variable. 3353 Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865]. 3355 Sub-Type (2 bytes): Used by the Vendor to distinguish multiple 3356 different sub-TLVs. 3358 Sub-Type-Version (2 bytes): Used by the Vendor to distinguish 3359 different versions of a Vendor-Defined sub-TLV sub-Type. 3361 value: as specified by the vendor. 3363 Since Vendor code will be handling the sub-TLV after the Vendor ID 3364 field is recognized, the remainder of the sub-TLV can be organized 3365 however the vendor wants. But it desirable for a vendor to be able to 3366 define multiple different vendor sub-TLVs and to keep track of 3367 different versions of its vendor-defined sub-TLVs. Thus, it is 3368 RECOMMENDED that the vendor assign a Sub-Type value for each of that 3369 vendor's sub-TLVs that is different from other Sub-Type values that 3370 vendor has used. Also, when modifying a vendor-defined sub-TLV in a 3371 way potentially incompatible with a previous definition, the vendor 3372 SHOULD increase the value it is using in the Sub-Type-Version field. 3374 7.4. The Hello TLV 3376 The Hello TLV is defined to be carried in the Hello message for 3377 version and capabilities negotiation. It indicates the S-CUSP sub- 3378 version and capabilities supported. The format of Hello TLV is as 3379 follows: 3381 0 1 2 3 3382 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 3383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 | VerSupported | 3385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3386 | Vendor ID | 3387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3388 | Capabilities | 3389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 Figure 39: Hello TLV 3393 Where: 3395 The TLV type is 100. 3397 The TLV length is 12 octets. 3399 The value field consists of three parts: 3401 VerSupported: 32 bits in length. It is a bit map of the Sub- 3402 Versions of the S-CUSP protocol that the sender supports. This 3403 document specifies Sub-Version zero of Major Version 1, that 3404 is, Version 1.0. The VerSupported field MUST be non-zero. The 3405 VerSupported bits are numbered from 0 as the most significant 3406 bit. Bit 0 indicates support of Sub-Version zero, bit 1 3407 indicates support of Sub-Version one, etc. 3409 Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS 3410 [RFC2865]. 3412 Capabilities: 32 bits in length. Flags that indicate the 3413 support of particular capabilities by the sender of the Hello. 3414 No Capabilities are defined in this document, so 3415 implementations of the version specified herein will set this 3416 field to zero. The Capabilities field of the Hello TLV MUST be 3417 checked before any other TLVs in the Hello because capabilities 3418 defined in the future might extend existing TLVs or permit new 3419 TLVs. 3421 After the exchange of Hello messages, the CP and UP each perform a 3422 logical AND of the Sub-Version supported by the CP and the UP and 3423 separately perform a logical AND of the Capabilities bits fields for 3424 the CP and the UP. 3426 If the result of the AND of the Sub-Versions supported is zero, then 3427 no session can be established and the connection is torn down. If the 3428 result of the AND of the Sub-Versions supported is non-zero, then the 3429 session uses the highest Sub-Version supported by both the CP and UP. 3431 For example, if one side supports Sub-Versions 1, 3, 4, and 5 3432 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 3433 (VerSupported = 0x38000000), then 3 and 4 are the Sub-Versions in 3434 common and 4 is the highest Sub-Version supported by both sides. So 3435 Sub-Version 4 is used for the session that has been negotiated. 3437 The result of the logical AND of the Capabilities bits will show what 3438 additional capabilities both sides support. If this result is zero, 3439 there are no such capabilities so none can be used during the 3440 session. If this result is non-zero, it shows the additional 3441 capabilities that can be used during the session. The CP and the UP 3442 MUST NOT use a capability unless both advertise support. 3444 7.5. The Keepalive TLV 3446 The Keepalive TLV is carried in the Hello message. It provides 3447 timing information for this feature. The format of Hello TLV is as 3448 follows: 3450 0 1 2 3 3451 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 3452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3453 | Keepalive | DeadTimer | Reserved | 3454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 Figure 40: Keepalive TLV 3458 Where: 3460 The TLV type: 102. 3462 The value of the Length field is 4 octets. 3464 Keepalive (8 bits): Indicates the maximum interval (in seconds) 3465 between two consecutive S-CUSP messages sent by the sender of the 3466 message containing this TLV as an unsigned integer. The minimum 3467 value for the Keepalive field is 1 second. When set to 0, once the 3468 session is established, no further Keepalive messages are sent to 3469 the remote peer. A RECOMMENDED value for the Keepalive frequency 3470 is 30 seconds. 3472 DeadTimer (8 bits in length): Specifies the amount of time as an 3473 unsigned integer number of seconds after the expiration of which 3474 the S-CUSP peer can declare the session with the sender of the 3475 Hello message to be down if no S-CUSP message has been received. 3476 The DeadTimer SHOULD be set to 0 and MUST be ignored if the 3477 Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 3478 times the value of the Keepalive. 3480 The Reserved bits MUST be sent as zero and ignored on receipt. 3482 7.6. The Error Information TLV 3484 The Error Information TLV is a common TLV that can be used in many 3485 Response (e.g., Update_Response message) and ACK messages (e.g., 3486 Addr_Allocation_Ack message, etc.). It is used to convey the 3487 information about an error in the received S-CUSP message. The 3488 format of the Error Information TLV is as follows: 3490 0 1 2 3 3491 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 3492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3493 | Message-Type | Reserved | TLV-Type | 3494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3495 | Error Code | 3496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3498 Figure 41: Error Information TLV 3500 Where: 3502 The TLV type: 101. 3504 The value of the Length field is 8 octets. 3506 Message-Type(1 byte): This parameter is the message type of the 3507 message containing an error. 3509 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3511 TLV-Type (2 bytes): Indicates which TLV caused the error. 3513 Error Code: 4 bytes in length. Indicate the specific Error Code 3514 (see Section 9.5). 3516 7.7. BAS Function TLV 3518 The BAS Function TLV is used by a CP to control the access mode, 3519 authentication methods, and other related functions of an interface 3520 on a UP. 3522 The format of the BAS Function TLV value part is as follows: 3524 0 1 2 3 3525 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 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 | If-Index | 3528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3531 | Flags | 3532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3533 | sub-TLVs (optional) | 3534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 Figure 42: BAS Function TLV 3538 Where: 3540 The TLV type: 1. 3542 The value of the Length field is variable. 3544 If-Index: 4 bytes in length, a unique identifier of an interface 3545 of a BNG. 3547 Access-Mode: 1 byte in length. It indicates the access mode of the 3548 interface. The defined values are listed in Section 9.7. 3550 Auth-Method4: 1 byte in length. It indicates the authentication on 3551 this interface for the IPv4 scenario. This field is defined as a 3552 bitmap. The bits defined in this document are listed in Section 3553 9.8. Other bits are reserved and MUST be sent as zero and ignored 3554 on receipt. 3556 Auth-Method6: 1 byte in length. It indicates the authentication on 3557 this interface for the IPv6 scenario. This field is defined as a 3558 bitmap. The bits defined in this document are listed in Section 3559 9.8. Other bits are reserved and MUST be sent as zero and ignored 3560 on receipt. 3562 sub-TLVs: 3563 The IF-Desc sub-TLV can be carried. 3564 If-Desc sub-TLV: carries the interface information. 3566 The flags field is defined as follows: 3568 0 1 2 3 3569 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 3570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3571 | MBZ |Y|X|P|I|N|A|S|F| 3572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3574 Figure 43: Interface Flags 3576 Where: 3578 F (IPv4 Trigger) bit: Indicates whether IPv4 packets can 3579 trigger a subscriber to go online. 1: enabled, 0: disabled. 3581 S (IPv6 Trigger) bit: Indicates whether IPv6 packets can 3582 trigger a subscriber to go online. 1: enabled, 0: disabled. 3584 A (ARP Trigger) bit: Indicates whether ARP packets can trigger 3585 a subscriber to go online. 1: enabled, 0: disabled. 3587 N (ND Trigger) bit: Indicates whether ND packets can trigger a 3588 subscriber to go online. 1: enabled, 0: disabled. 3590 I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable 3591 traffic detection. 0: Disable traffic detection. 3593 P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable 3594 traffic detection. 0: Disable traffic detection. 3596 X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy 3597 and can process ARP requests across different Port+VLANs. 0: 3598 The ARP proxy is not enabled on the interface and only the ARP 3599 requests of the same Port+VLAN are processed. 3601 Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and 3602 can process ND requests across different Port+VLANs. 0: The ND 3603 proxy is not enabled on the interface and only the ND requests 3604 of the same Port+VLAN are processed. 3606 MBZ: Reserved bits that MUST be sent as zero and ignored on 3607 receipt. 3609 7.8. Routing TLVs 3611 Typically, after an S-CUSP session is established between a UP and a 3612 CP, the CP will allocate one or more blocks of IP addresses to the 3613 UP. Those IP addresses will be allocated to subscribers who will 3614 dial-up (as defined in Section 2.1) to the UP. To make sure that 3615 other nodes within the network learn how to reach those IP addresses, 3616 the CP needs to install one or more routes that can reach those IP 3617 addresses on the UP and notify the UP to advertise the routes to the 3618 network. 3620 The Routing TLVs are used by a CP to notify a UP of the updates to 3621 network routing information. They can be carried in the 3622 Update_Request message and Sync_Data message. 3624 7.8.1. IPv4 Routing TLV 3626 The IPv4 Routing TLV is used to carry information related to IPv4 3627 network routing. 3629 The format of the TLV value part is as below: 3631 0 1 2 3 3632 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 3633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3634 | User ID | 3635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3636 | Dest-Address | 3637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3638 | Next-Hop | 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 | Out-If-Index | 3641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3642 | Cost | 3643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3644 | Tag | 3645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3646 | Route Type | Reserved |A| 3647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3648 ~ sub-TLVs (optional) ~ 3649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 Figure 44: IPv4 Routing TLV 3653 Where: 3655 The TLV Type: 7 3657 The TLV Length: Variable 3659 User-ID: 4 bytes in length. This field carries the user 3660 identifier. It is filled with all Fs when a non-user route is 3661 delivered to the UP. 3663 Dest-Address (IPv4-Address type): Identifies the destination 3664 address. 3666 Next-Hop: (IPv4-Address type): Identifies the next hop address. 3668 Out-If-Index (4 bytes): Indicates the interface index. 3670 Cost (4 bytes): The cost value of the route. 3672 Tag (4 bytes): The tag value of the route. 3674 Route-Type (2 bytes): The value of this field indicates the route 3675 type. The values defined in this document are listed in Section 3676 9.9. 3678 Advertise-Flag: 1 bit shown as "A" is the figure above. Indicates 3679 whether the IP should advertise the route. The following flag 3680 values are defined: 3681 0: Not advertised, 3682 1: Advertised. 3684 sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried. 3685 VRF-Name sub-TLV: indicates which VRF the route belongs to. 3686 If-Desc sub-TLV: carries the interface information. 3688 The Reserved field MUST be sent as zero and ignored on receipt. 3690 7.8.2. IPv6 Routing TLV 3692 The IPv6 Routing TLV is used to carry IPv6 network routing 3693 information. 3695 The format of this TLV is as follows: 3697 0 1 2 3 3698 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 3699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3700 | User ID | 3701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3702 ~ IPv6 Dest-Address ~ 3703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3704 ~ IPv6 Next-Hop ~ 3705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3706 | Out-If-Index | 3707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3708 | Cost | 3709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3710 | Tag | 3711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3712 | Route Type | Reserved |A| 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 ~ sub-TLVs (optional) ~ 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3717 Figure 45: IPv6 Routing TLV 3719 Where: 3721 The TLV Type: 7 3723 The TLV Length is Variable. 3725 User-ID: 4 bytes in length. This field carries the user 3726 identifier. This field is filled with all Fs when a non-user 3727 route is delivered to the UP. 3729 IPv6 Dest-Address (IPv6-Address type): Identifies the destination 3730 address. 3732 IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop 3733 address. 3735 Out-If-Index (4 bytes): Indicates the interface index. 3737 Cost (4 bytes): This is the cost value of the route. 3739 Tag (4 bytes): The tag value of the route. 3741 Route-Type: (2 bytes): The value of this field indicates the 3742 route type. The values defined in this document are listed in 3743 Section 9.9. 3745 Advertise-Flag: 1 bit shown as "A" is the figure above. Indicates 3746 whether UP should advertise the route. Following flags are 3747 defined: 3748 0: Not advertised, 3749 1: Advertised. 3751 sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried. 3752 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3753 belongs. 3754 If-Desc sub TLV: carries the interface information. 3756 The Reserved field MUST be sent as zero and ignored on receipt. 3758 7.9. Subscriber TLVs 3760 The Subscriber TLVs are defined for a CP to send the basic 3761 information about a user to a UP. 3763 7.9.1. Basic Subscriber TLV 3765 The Basic Subscriber TLV is used to carry the basic common 3766 information for all kinds of access subscribers. It is carried in an 3767 Update_Request message. 3769 The format of the Basic Subscriber TLV value part is as follows: 3771 0 1 2 3 3772 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 3773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3774 | User ID | 3775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3776 | Session ID | 3777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3778 | User MAC | 3779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3780 | User MAC | Oper ID | Reserved | 3781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3782 | Access Type |Sub-access Type| Account Type | Address Family| 3783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3784 | C-VID | P-VID | 3785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 | Detect Times | Detect Interval | 3787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3788 | If-Index | 3789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3790 ~ sub-TLVs (optional) ~ 3791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3793 Figure 46: Basic Subscriber TLV 3795 Where: 3797 The TLV Type: 2. 3799 The TLV is variable in length. 3801 User-ID (4 bytes): The identifier of a subscriber. 3803 Session-ID (4 bytes): Session ID of a PPPoE subscriber. The value 3804 zero identifies a non-PPPoE subscriber. 3806 User-Mac (MAC-Addr type): The MAC Address of a subscriber. 3808 Oper-ID (1 byte): Indicates the ID of an operation performed by a 3809 user. This field is carried in the response from the UP. 3811 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3813 Access-Type (1 byte): Indicates the type of subscriber access. 3814 Values defined in this document are listed in Section 9.10. 3816 Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP 3817 relay is used. 3818 0: Reserved 3819 1: PPP Relay (for LAC) 3820 2: PPP termination (for LNS) 3822 Account-Type (1 byte): 3823 0: Collects statistics on IPv4 and IPv6 traffic of terminals 3824 independently. 3825 1: Collects statistics on IPv4 and IPv6 traffic of terminals. 3827 Address Family (1 byte) 3828 1: IPv4 3829 2: IPv6 3830 3: dual stack 3832 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 3833 indicates that the VLAN ID is invalid. The default value of PRI 3834 is 7, the value of DEI is 0, and the value of VID is 1~4094. The 3835 PRI value can also be obtained by parsing terminal packets. 3837 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 3838 indicates that the VLAN ID is invalid. The format is the same as 3839 that for C-VID. 3841 Detect-Times (2 bytes): Number of detection timeout times. The 3842 value 0 indicates that no detection is performed. 3844 Detect-Interval (2 bytes): Detection interval in seconds. 3846 If-Index (4 bytes): Interface index. 3848 Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried. 3849 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3850 belongs. 3851 If-Desc sub-TLV: carries the interface information. 3853 The Reserved field MUST be sent as zero and ignored on receipt. 3855 7.9.2. PPP Subscriber TLV 3857 The PPP Subscriber TLV is defined to carry PPP information of a User 3858 from a CP to a UP. It will be carried in an Update_Request message 3859 when PPPoE or L2TP access is used. 3861 The format of the TLV value part is as follows: 3863 0 1 2 3 3864 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 3865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3866 | User ID | 3867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3868 | MSS | Reserved |M| 3869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3870 | MRU | Reserved | 3871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3872 | Magic Number | 3873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3874 | Peer Magic Number | 3875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 Figure 47: PPP Subscriber TLV 3879 Where: 3881 The TLV type: 3. 3883 The TLV length is 12 octets. 3885 User-ID (4 bytes): The identifier of a subscriber. 3887 MSS-Value (2 bytes): Indicates the MSS value (in bytes). 3889 MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled. 3890 0: Disabled. 3891 1: Enabled. 3893 MRU (2 bytes): PPPoE local MRU (in bytes). 3895 Magic-Number (4 bytes): Local magic number in PPP negotiation 3896 packets. 3898 Peer-Magic-Number (4 bytes): Remote peer magic number. 3900 The Reserved fields MUST be sent as zero and ignored on receipt. 3902 7.9.3. IPv4 Subscriber TLV 3904 The IPv4 Subscriber TLV is defined to carry IPv4 related information 3905 for a BNG user. It will be carried in an Update_Request message when 3906 IPv4 IPoE or PPPoE access is used. 3908 The format of the TLV value part is as follows: 3910 0 1 2 3 3911 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 3912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3913 | User ID | 3914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 | User IPv4 Address | 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 | Gateway IPv4 Address | 3918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 | MTU | Reserved |U|E|W|P| 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3921 ~ VRF-Name sub-TLV ~ 3922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3924 Figure 48: IPv4 Subscriber TLV 3926 Where: 3928 The TLV type: 4. 3930 The TLV length is variable. 3932 User-ID (4 bytes): The identifier of a subscriber. 3934 User-IPv4 (IPv4-Address): The IPv4 address of the subscriber. 3936 Gateway-IPv4 (IPv4-Address): The gateway address of the 3937 subscriber. 3939 Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on. 3941 Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on. 3943 Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off, 3944 1: on. 3946 IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) 3947 flag. 0: off, 1: on. 3949 MTU 2 bytes MTU value. The default value is 1500. 3951 VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. 3953 The Reserved field MUST be sent as zero and ignored on receipt. 3955 7.9.4. IPv6 Subscriber TLV 3957 The IPv6 Subscriber TLV is defined to carry IPv6 related information 3958 for a BNG user. It will be carried in an Update_Request message when 3959 IPv6 IPoE or PPPoE access is used. 3961 The format of the TLV value part is as follows: 3963 0 1 2 3 3964 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 3965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3966 | User-ID | 3967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3968 ~ User PD-Address (IPv6 Address List sub-TLV) ~ 3969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3970 ~ Gateway ND-Address (IPv6 Address List sub-TLV) ~ 3971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3972 | User Link-Local-Address | 3973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3974 | IPv6 Interface ID | 3975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3976 | IPv6 Interface ID (cont.) | 3977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3978 | MTU | Reserved |U|E|W|P| 3979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3980 ~ VRF Name sub-TLV (optional) ~ 3981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3983 Figure 49: IPv6 Subscriber TLV 3985 Where: 3987 The TLV type: 5. 3989 The TLV length is variable. 3991 User-ID (4 bytes): The identifier of a subscriber. 3993 User PD-Addresses (IPv6 Address List): Carries a list of Prefix 3994 Delegation (PD) addresses of the subscriber. 3996 User ND-Addresses (IPv6 Address List): Carries a list of Neighbor 3997 Discovery (ND) addresses of the subscriber. 3999 User Link-Local-Address (IPv6-Address): The link-local address of 4000 the subscriber. 4002 IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface. 4004 Portal Force 1 bit (P): Push advertisement, 0: off, 1: on. 4006 Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on. 4008 Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off; 4009 1: on. 4011 IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0: 4012 off; 1: on. 4014 MTU (2 bytes): The MTU value. The default value is 1500. 4016 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4017 belongs. 4019 The Reserved field MUST be sent as zero and ignored on receipt. 4021 7.9.5. IPv4 Static Subscriber Detect TLV 4023 The IPv4 Static Subscriber Detect TLV is defined to carry IPv4 4024 related information for a static access subscriber. It will be 4025 carried in an Update_Request message when IPv4 static access on a UP 4026 needs to be enabled. 4028 The format of the TLV value part is as follows: 4030 0 1 2 3 4031 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 4032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4033 | If-Index | 4034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4035 | C-VID | P-VID | 4036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4037 | User Address | 4038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4039 | Gateway Address | 4040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4041 | User MAC | 4042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4043 | User MAC (cont.) | Reserved | 4044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4045 ~ sub-TLVs (optional) ~ 4046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4048 Figure 50: IPv4 Static Subscriber TLV 4050 Where: 4052 The TLV type: 6. 4054 The TLV length is variable. 4056 If-Index (4 bytes): The interface index of the interface from 4057 which the subscriber will dial-up. 4059 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4060 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4062 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4063 indicates that the VLAN ID is invalid. The format is the same as 4064 that of the C-VID. A valid value is 1~4094. For a single-layer 4065 VLAN, set this parameter to PeVid. 4067 User Address (IPv4-Addr): The user's IPv4 address. 4069 Gateway Address (IPv4-Addr): The gateway's IPv4 Address. 4071 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4073 Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried. 4074 VRF-Name sub-TLV: Indicates the VEF to which the subscriber 4075 belongs. 4076 If-Desc sub-TLV: Carries the interface information. 4078 The Reserved field MUST be sent as zero and ignored on receipt. 4080 7.9.6. IPv6 Static Subscriber Detect TLV 4082 The IPv6 Static Subscriber Detect TLV is defined to carry IPv6 4083 related information for a static access subscriber. It will be 4084 carried in an Update_Request message when needed to enable IPv6 4085 static subscriber detection on a UP. 4087 The format of the TLV value part is as follows: 4089 0 1 2 3 4090 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 4091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4092 | If-Index | 4093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4094 | C-VID | P-VID | 4095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4096 ~ User Address ~ 4097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4098 ~ Gateway Address ~ 4099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4100 | User MAC | 4101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4102 | User MAC (cont.) | Reserved | 4103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4104 ~ sub-TLVs (optional) ~ 4105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4107 Figure 51: IPv6 Static Subscriber Detect TLV 4109 Where: 4111 The TLV type: 6. 4113 The TLV length is variable. 4115 If-Index (4 bytes): The interface index of the interface from 4116 which the subscriber will dial-up. 4118 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4119 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4121 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4122 indicates that the VLAN ID is invalid. The format is the same as 4123 that the of C-VID. A valid value is 1~4094. For a single-layer 4124 VLAN, set this parameter to PeVid. 4126 User Address (IPv6-Address type): The subscriber's IPv6 address. 4128 Gateway Address (IPv6-Address type): The gateway's IPv6 Address. 4130 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4132 sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried 4133 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4134 belongs. 4135 If-Desc sub-TLV: Carries the interface information. 4137 The Reserved field MUST be sent as zero and ignored on receipt. 4139 7.9.7. L2TP-LAC Subscriber TLV 4141 The L2TP-LAC Subscriber TLV is defined to carry the related 4142 information for an L2TP LAC access subscriber. It will be carried in 4143 an Update_Request message when L2TP LAC access is used. 4145 The format of the TLV value part is as follows: 4147 0 1 2 3 4148 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 4149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4150 | User ID | 4151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4152 | Local Tunnel ID | Local Session ID | 4153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4154 | Remote Tunnel ID | Remote Session ID | 4155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4157 Figure 52: L2TP-LAC Subscriber TLV 4159 Where: 4161 The TLV type: 11. 4163 The TLV is 12 octets long. 4165 User-ID (4 bytes): The identifier of a user/subscriber. 4167 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4169 Local-Session-ID (2 bytes): The local session ID with the L2TP 4170 tunnel. 4172 Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at 4173 the remote end-point. 4175 Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at 4176 the remote end-point. 4178 7.9.8. L2TP-LNS Subscriber TLV 4180 The L2TP-LNS Subscriber TLV is defined to carry the related 4181 information for a L2TP LNS access subscriber. It will be carried in 4182 an Update_Request message when L2TP LNS access is used. 4184 The format of the TLV value part is as follows: 4186 0 1 2 3 4187 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 4188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4189 | User ID | 4190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4191 | Local Tunnel ID | Local Session ID | 4192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4193 | Remote Tunnel ID | Remote Session ID | 4194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4196 Figure 53: L2TP-LNS Subscriber TLV 4198 Where: 4200 The TLV type: 12. 4202 The TLV length is 12 octets. 4204 User-ID (4 bytes): The identifier of a user/subscriber. 4206 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4208 Local-Session-ID (2 bytes): The local session ID with the L2TP 4209 tunnel. 4211 Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at 4212 the remote end-point. 4214 Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at 4215 the remote end-point. 4217 7.9.9. L2TP-LAC Tunnel TLV 4219 The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel 4220 related information. It will be carried in the Update_Request 4221 message when L2TP LAC access is used. 4223 The format of the TLV value part is as follows: 4225 0 1 2 3 4226 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 4227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4228 | Local Tunnel ID | Remote Tunnel ID | 4229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4230 | Source Port | Destination Port | 4231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4232 ~ Tunnel Source Address ~ 4233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4234 ~ Tunnel Destination Address ~ 4235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4236 ~ VRF Name sub-TLV ~ 4237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4239 Figure 54: L2TP-LAC Tunnel TLV 4241 Where: 4243 The TLV type: 13. 4245 The TLV length is variable. 4247 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4249 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4251 Source-Port (2 bytes): The source UDP port number of an L2TP 4252 subscriber. 4254 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4255 subscriber. 4257 Source-IP (IPv4/v6): The source IP address of the tunnel. 4259 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4261 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4262 belongs. 4264 7.9.10. L2TP-LNS Tunnel TLV 4266 The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel 4267 related information. It will be carried in the Update_Request 4268 message when L2TP LNS access is used. 4270 The format of the TLV value part is as follows: 4272 0 1 2 3 4273 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 4274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4275 | Local Tunnel ID | Remote Tunnel ID | 4276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4277 | Source Port | Destination Port | 4278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4279 ~ Tunnel Source Address ~ 4280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4281 ~ Tunnel Destination Address ~ 4282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4283 ~ VRF Name sub-TLV ~ 4284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4286 Figure 55: L2TP-LNS Tunnel TLV 4288 Where: 4290 The TLV type: 14. 4292 The TLV length is variable. 4294 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4296 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4298 Source-Port (2 bytes): The source UDP port number of an L2TP 4299 subscriber. 4301 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4302 subscriber. 4304 Source-IP (IPv4/v6): The source IP address of the tunnel. 4306 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4308 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4309 belongs. 4311 7.9.11. Update Response TLV 4313 The Update Response TLV is used to return the operation result of an 4314 update request. It is carried in the Update_Response message as a 4315 response to the Update_Request message. 4317 The format of Update Response TLV is as follows: 4319 0 1 2 3 4320 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 4321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4322 | User-ID | 4323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4324 | User-Trans-ID | Oper-Code | Oper-Result | Reserved | 4325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4326 | Error-Code | 4327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4329 Figure 56: Update Response TLV 4331 Where: 4333 The TLV type: 302. 4335 The TLV length is 12. 4337 User-ID (4 bytes): A unique identifier of a user/subscriber. 4339 User-Trans-ID (1 byte): In the case of dual-stack access or when 4340 modifying a session, User-Trans-ID is used to identify a user 4341 operation transaction. It is used by the CP to correlate a 4342 response to a specific request. 4344 Oper-Code (1 byte): Operation code. 1: update, 2: delete. 4346 Oper-Result (1 byte): Operation Result. 0: Success, Others: 4347 Failure. 4349 Error-Code (4 bytes): Operation failure cause code. for details, 4350 see Section 9.5. 4352 The Reserved field MUST be sent as zero and ignored on receipt. 4354 7.9.12. Subscriber Policy TLV 4356 The Subscriber Policy TLV is used to carry the policies that will be 4357 applied to a subscriber. It is carried in the Update_Request 4358 message. 4360 The format of the TLV value part is as follows: 4362 0 1 2 3 4363 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 4364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4365 | User ID | 4366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4367 | I-Priority | E-Priority | Reserved | 4368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4369 ~ sub-TLVs ~ 4370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4372 Figure 57: User QoS Policy Information TLV 4374 Where: 4376 The TLV type: 6. 4378 The TLV length is variable. 4380 User-ID (4 bytes): The identifier of a user/subscriber. 4382 Ingress-Priority (1 byte): Indicates the upstream priority. The 4383 value range is 0~7. 4385 Egress-Priority (1 byte): Indicates the downstream priority. The 4386 value range is 0~7. 4388 sub-TLVs: The sub-TLVs that are present can occur in any order. 4390 Ingress-CAR sub-TLV: Upstream CAR. 4392 Egress-CAR sub-TLV: Downstream CAR. 4394 Ingress-QoS-Profile sub-TLV: Indicates the name of the QoS- 4395 Profile that is the profile in the upstream direction. 4397 Egress-QoS-Profile Sub-TLV: Indicates the name of the QoS- 4398 Profile that is the profile in the downstream direction. 4400 User-ACL-Policy Sub-TLV: All ACL user policies, including 4401 v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, 4402 v4SpecialACL, and v6SpecialACL. 4404 Multicast-Profile4 Sub-TLV: IPv4 multicast policy name. 4406 Multicast-Profile6 Sub-TLV: IPv6 multicast policy name. 4408 NAT-Instance Sub-TLV: Indicates the instance ID of a NAT user. 4410 The Reserved field MUST be sent as zero and ignored on receipt. 4412 7.9.13. Subscriber CGN Port Range TLV 4414 The Subscriber CGN Port Range TLV is used to carry the NAT public 4415 address and port range. It will be carried in the Update_Response 4416 message when CGN is used. 4418 The format of this TLV is as follows: 4420 0 1 2 3 4421 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 4422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4423 | User ID | 4424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4425 | NAT-Port-Start | NAT-Port-End | 4426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4427 | NAT-Address | 4428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4430 Figure 58: Subscriber CGN Port Range TLV 4432 Where: 4434 The TLV type: 15. 4436 The TLV length is 12 octets. 4438 User-ID (4 bytes): The identifier of a user/subscriber. 4440 NAT-Port-Start (2 bytes): The start port number. 4442 NAT-Port-End (2 bytes): The end port number. 4444 NAT-Address (4 bytes): The NAT public network address. 4446 7.10. Device Status TLVs 4448 The TLVs in this section are for reporting Interface and Board level 4449 information from the UP to the CP. 4451 7.10.1. Interface Status TLV 4453 The Interface Status TLV is used to carry the status information of 4454 an interface on a UP. It is carried in a Report message. 4456 The format of the value part of this TLV is as follows: 4458 0 1 2 3 4459 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 4460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4461 | If-Index | 4462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4463 | MAC Address (upper part) | 4464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4465 | MAC Address (lower part) | Phy-State | Reserved | 4466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4467 | MTU | 4468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4469 | sub-TLVs (optional) | 4470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4472 Figure 59: Interface Status TLV 4474 Where: 4476 The TLV type: 200. 4478 The TLV length is variable. 4480 If-Index (4 bytes): Indicates the interface index. 4482 MAC-Address (MAC-Addr type): Interface MAC address. 4484 Phy-State (1 byte): Physical status of the interface. 0: down, 1: 4485 Up 4487 MTU (4 bytes): Interface MTU value. 4489 sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried. 4491 The Reserved field MUST be sent as zero and ignored on receipt. 4493 7.10.2. Board Status TLV 4495 The Board Status TLV is used to carry the status information of a 4496 board on an UP. It is carried in a Report message. 4498 The format of Board Status TLV is as follows: 4500 0 1 2 3 4501 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 4502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4503 | Board-Type | Board-State | Reserved | Chassis | 4504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4505 | Slot | Reserved | 4506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 Figure 60: Interface Resource TLV 4510 Where: 4512 The TLV type: 201. 4514 The TLV length is 8 octets. 4516 Chassis (1 byte): The chassis number of the Board. 4518 Slot (1 byte): The slot number of the Board. 4520 Sub-Slot (1 byte): The sub-slot number of the Board. 4522 Board-Type (1 byte): 4523 1: CGN Service Process Unit (SPU) board. 4524 2: Line Process Unit (LPU) Board. 4526 Board-State (1 byte): 4527 0: Normal. 4528 1: Abnormal. 4530 The reserved field MUST be sent as zero and ignored on receipt. 4532 7.11. CGN TLVs 4534 7.11.1. Address Allocation Request TLV 4536 The Address Allocation Request TLV is used to request address 4537 allocation from CP. An address Pool-Name sub-TLV is carried to 4538 indicate from which address pool to allocate addresses. The Address 4539 Allocation Request TLV is carried in the Addr_Allocation_Req message. 4541 The format of the value part of this TLV is as follows: 4543 0 1 2 3 4544 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 4545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4546 ~ Pool-Name sub-TLV ~ 4547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4549 Figure 61: Address Allocation Request TLV 4551 Where: 4553 The TLV type: 400. 4555 The TLV length is variable. 4557 Pool-Name sub-TLV: Indicates from which Address pool to allocate 4558 address. 4560 7.11.2. Address Allocation Response TLV 4562 The Address Allocation Response TLV is used to return the address 4563 allocation result, it is carried the Addr_Allocation_Ack message. 4565 The value part of the Address Allocation Response TLV is formatted as 4566 follows: 4568 0 1 2 3 4569 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 4570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4571 | Lease Time | 4572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4573 | IPv4 Addr and Mask | 4574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4575 | IPv4 Addr and Mask continued | 4576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4577 | Error-Code | 4578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4579 ~ Pool-Name sub-TLV ~ 4580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4582 Figure 62: Address Assignment Response TLV 4584 Where: 4586 The TLV type: 401. 4588 The TLV length is variable. 4590 Lease Time (4 bytes): Duration of address lease in seconds. 4592 IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4 4593 address. 4595 Error-Code (4 bytes): Indicates success or an error. 4597 0: Success. 4599 1: Failure. 4601 3001 (Pool-Mismatch): The corresponding address pool cannot be 4602 found. 4604 3002 (Pool-Full): The address pool is fully allocated and no 4605 address segment is available. 4607 Pool-Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4608 Address pool the address is allocated. 4610 7.11.3. Address Renewal Request TLV 4612 The Address Renewal Request TLV is used to request address renewal 4613 from the CP. It is carried the Addr_Renew_Req message. 4615 The format of this TLV value is as follows: 4617 0 1 2 3 4618 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 4619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4620 | IPv4 Address and Mask | 4621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4622 | IPv4 Address and Mask continued | 4623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4624 ~ Pool-Name sub-TLV ~ 4625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4627 Figure 63: Address Renewal Request TLV 4629 Where: 4631 The TLV type: 402. 4633 The TLV length is variable. 4635 IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed. 4637 Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4638 Address pool to renew the address. 4640 7.11.4. The Address Renewal Response TLV 4642 The Address Renewal Response TLV is used to return the address 4643 renewal result. It is carried in the Addr_Renew_Ack message. 4645 The format of this TLV value is as follows: 4647 0 1 2 3 4648 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 4649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4650 | IPv4 Address and Mask | 4651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4652 | IPv4 Address and Mask continued | 4653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4654 | Error-Code | 4655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4656 ~ Pool-Name sub-TLV ~ 4657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4659 Figure 64: Address Renewal Response TLV 4661 Where: 4663 The TLV type: 403. 4665 The TLV length is variable. 4667 Client-IP (IPv4-Address type): The renewed IPv4 address. 4669 Error Code (4 bytes): Indicates success or an error: 4671 0: Renew succeeded. 4673 1: Renew failed. 4675 3001 (Pool-Mismatch): The corresponding address pool cannot be 4676 found. 4678 3002 (Pool-Full): The address pool is fully allocated and no 4679 address segment is available. 4681 3003 (Subnet-Mismatch): The address pool subnet cannot be 4682 found. 4684 3004 (Subnet-Conflict): Subnets in the address pool have been 4685 assigned to other clients. 4687 Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4688 Address pool to renew the address. 4690 7.11.5. Address Release Request TLV 4692 The Address Release Request TLV is used to release an IPv4 address. 4693 It is carried in the Addr_Release_Req message. 4695 The value part of this TLV is formatted as follows: 4697 0 1 2 3 4698 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 4699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4700 | IPv4 Address and Mask | 4701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4702 | IPv4 Address and Mask continued | 4703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4704 ~ Pool-Name sub-TLV ~ 4705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4707 Figure 65: Address Release Request TLV 4709 Where: 4711 The TLV type: 404. 4713 The TLV length is variable. 4715 IPv4 Address and Mask (IPv4-Address type): The IPv4 address be 4716 released. 4718 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4719 Address pool to release the address. 4721 7.11.6. The Address Release Response TLV 4723 The Address Release Response TLV is used to return the address 4724 release result. It is carried in the Addr_Release_Ack message. 4726 The format of this TLV is as follows: 4728 0 1 2 3 4729 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 4730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4731 | IPv4 Address and Mask | 4732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4733 | IPv4 Address and Mask continued | 4734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4735 | Error-Code | 4736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4737 ~ Pool-Name sub-TLV ~ 4738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4740 Figure 66: Address Renewal Response TLV 4742 Where: 4744 The TLV type: 405. 4746 The TLV length is variable. 4748 Client-IP (IPv4-Address type): The released IPv4 address. 4750 Error-Code (4 bytes): Indicates success or an error. 4752 0: Address release success. 4754 1: Address release failed. 4756 3001 (Pool-Mismatch): The corresponding address pool cannot be 4757 found. 4759 3003 (Subnet-Mismatch): The address cannot be found. 4761 3004 (Subnet-Conflict): The address has been allocated to 4762 another subscriber. 4764 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4765 address pool to release the address. 4767 7.12. Event TLVs 4768 7.12.1. Subscriber Traffic Statistics TLV 4770 The Subscriber Traffic Statistics TLV is used to return the traffic 4771 statistics of a user/subscriber. The format of this TLV is as 4772 follows: 4774 0 1 2 3 4775 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 4776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4777 | User-ID | 4778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4779 | Statistics Type | 4780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4781 | Ingress Packets (upper part) | 4782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4783 | Ingress Packets (lower part) | 4784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4785 | Ingress Bytes (upper part) | 4786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4787 | Ingress Bytes (lower part) | 4788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4789 | Ingress Loss Packets (upper part) | 4790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4791 | Ingress Loss Packets (lower part) | 4792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4793 | Ingress Loss Bytes (upper part) | 4794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4795 | Ingress Loss Bytes (lower part) | 4796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4797 | Egress Packets (upper part) | 4798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4799 | Egress Packets (lower part) | 4800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4801 | Egress Bytes (upper part) | 4802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4803 | Egress Bytes (lower part) | 4804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4805 | Egress Loss Packets (upper part) | 4806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4807 | Egress Loss Packets (lower part) | 4808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4809 | Egress Loss Bytes (upper part) | 4810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4811 | Egress Loss Bytes (lower part) | 4812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4814 Figure 67: Subscriber Traffic Statistics TLV 4816 Where: 4818 The TLV type: 300. 4820 The TLV length is 72 octets. 4822 User-ID (4 bytes): The subscriber identifier. 4824 Statistics-Type (4 bytes): Traffic type. It can be one of the 4825 following options: 4827 0: IPv4 traffic. 4828 1: IPv6 traffic. 4829 2: Dual stack traffic. 4831 Ingress Packets (8 bytes): The number of the packets in upstream 4832 direction. 4834 Ingress Bytes (8 bytes): The bytes of the upstream traffic. 4836 Ingress Loss Packets (8 bytes): The number of the lost packets in 4837 upstream direction. 4839 Ingress Loss Bytes (8 bytes): The bytes of the lost upstream 4840 packets. 4842 Egress Packets (8 bytes): The number of the packets in downstream 4843 direction. 4845 Egress Bytes (8 bytes): The bytes of the downstream traffic. 4847 Egress Loss Packets (8 bytes): The number of the lost packets in 4848 downstream direction. 4850 Egress Loss Bytes (8 bytes): The bytes of the lost downstream 4851 packets. 4853 7.12.2. Subscriber Detection Result TLV 4855 The Subscriber Detection Result TLV is used to return the detection 4856 result of a subscriber. Subscriber detection is a function to detect 4857 whether a subscriber is online or not. The result can be used by the 4858 CP to determine how to deal with the subscriber session. (e.g., 4859 delete the session if detection failed). 4861 The format of this TLV value part is as follows: 4863 0 1 2 3 4864 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 4865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4866 | User-ID | 4867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4868 | Detect Type | Detect Result | Reserved | 4869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4871 Figure 68: Subscriber Detection Result TLV 4873 Where: 4875 The TLV type: 301. 4877 The TLV length is 8 octets. 4879 User-ID (4 bytes): The subscriber identifier. 4881 Detect-Type (1 byte): 4883 0: IPv4 detection. 4884 1: IPv6 detection. 4885 2: PPP detection. 4887 Detect-Result (1 byte): 4889 0: Indicates that the detection is successful. 4891 1: Detection failure. The UP needs report only when the 4892 detection fails. 4894 The Reserved field MUST be sent as zero and ignored on receipt. 4896 7.13. Vendor TLV 4898 The Vendor ID TLV occurs as the first TLV in the Vendor message 4899 (Section 6.6). It provides a Sub-Type that effectively extends the 4900 message type in the message header, provides for versioning of vendor 4901 TLVs, and can accommodate sub-TLVs. 4903 The value part of the Vendor TLV is formatted as follows: 4905 0 1 2 3 4906 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 4907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4908 | Vendor ID | 4909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4910 | Sub-Type | Sub-Type-Version | 4911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4912 ~ sub-TLVs (optional) ~ 4913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4915 Figure 69: Vendor TLV 4917 Where: 4919 The TLV type: 1024. 4921 The TLV length is variable. 4923 Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS [RFC2865]. 4925 Sub-Type (2 bytes): Used by the Vendor to distinguish multiple 4926 different vendor messages. 4928 Sub-Type-Version (2 bytes): Used by the Vendor to distinguish 4929 different versions of a Vendor-Defined message sub-type. 4931 Sub-TLVs (variable): Sub-TLVs as specified by the vendor. 4933 Since Vendor code will be handling the TLV after the Vendor ID field 4934 is recognized, the remainder of the TLV value can be organized 4935 however the vendor wants. But it is desirable for a vendor to be able 4936 to define multiple different vendor messages and to keep track of 4937 different versions of its vendor-defined messages. Thus, it is 4938 RECOMMENDED that the vendor assign a Sub-Type value for each vendor 4939 message that it defines different from other Sub-Type values that 4940 vendor has used. Also, when modifying a vendor-defined message in a 4941 way potentially incompatible with a previous definition, the vendor 4942 SHOULD increase the value it is using in the Sub-Type-Version field. 4944 8. Implementation Status 4946 RFC Editor: Please remove this section before publication. 4948 This section discusses the status of implementations that have 4949 provided information and the testing of this protocol at the time of 4950 posting of this Internet-Draft, and is based on the proposal in 4951 [RFC7942] ("Improving Awareness of Running Code: The Implementation 4952 Status Section"). The description of implementations in this section 4953 is intended to assist in processing drafts to RFCs. 4955 Please note that the listing of any individual implementation or test 4956 results here does not imply endorsement by the RFC Series Editor 4957 (RSE), the Independent Submissions Editor (ISE), or the IETF. 4958 Furthermore, no effort has been spent to verify the information 4959 presented here that was supplied by contributors. This is not 4960 intended as, and must not be construed to be, a catalog of available 4961 implementations or their testing or features. Readers are advised to 4962 note that other implementations may exist. 4964 According to [RFC7942], "this will allow reviewers ... to assign due 4965 consideration to documents that have the benefit of running code, 4966 which may serve as evidence of valuable experimentation and feedback 4967 that have made the implemented protocols more mature.". 4969 8.1. Implementations 4971 Information on three S-CUSP implementations appears below. 4973 8.1.1. Huawei Technologies 4975 Name: Cloud-based BNG. 4977 Maturity: Production. 4979 Coverage: According to S-CUSP protocol. 4981 Contact information: 4982 Zhouyi Yu: yuzhouyi@huawei.com 4984 Date: 2018-11-01 4986 8.1.2. ZTE 4988 Name: ZXR10 V6000 vBRAS 4990 Maturity: Production 4992 Coverage: According to S-CUSP protocol. 4994 Contact information: 4995 Yong Chen: 10056167@zte.com.cn 4996 Huaibin Wang: 10008729@zte.com.cn 4998 Date: 2018-12-01 5000 8.1.3. H3C 5002 Name: CUSP protocol for BRAS Control Plane and User Plane 5003 Separation 5005 Maturity: Research 5007 Coverage: According to S-CUSP protocol 5009 Contact information: mengdan@h3c.com; liuhanlei@h3c.com 5011 Date: 2019-1-30 5013 8.2. Hackathon 5015 Successful use of the protocol at the IETF-102 Hackathon, Montreal, 5016 Quebec, in 2018. 5018 Hackathon Project: Control Plane and User Plane Separation BNG 5019 control channel Protocol (CUSP) 5021 Champions: Zhenqiang Li, Michael Wang 5023 Report: See 5024 github.com/IETF-Hackathon/ietf102-project-presentations/blob/ 5025 master/IETF102-hackathon-presentation-CUSP.pptx 5027 8.3. EANTC Testing 5029 EANTC (European Advanced Networking Test Center (www.eantc.de)) 5030 tested the Huawei implementation. Their summary was as follows: 5031 "EANTC tested advanced aspects of the Cloud-based Broadband Network 5032 Gateway (vBNG) with a focus on performance, scalability and high 5033 availability with up to 20 Million emulated subscribers. The solution 5034 performed very well across all test scenarios." 5036 See report at 5037 www.eantc.de/fileadmin/eantc/downloads/News/2018/EANTC-vBRAS- 5038 phase2.pdf 5040 9. Tables of S-CUSP Codepoints 5042 This section provides tables of the S-CUSP codepoints, particularly 5043 message types, TLV types, TLV operation codes, sub-TLV types, and 5044 error codes. In most cases, references are provided to relevant 5045 sections elsewhere in this document. 5047 9.1. Message Types 5049 Type Name Section of this document 5050 ------- ---------------- ------------------------ 5051 0 reserved 5052 1 Hello 6.2.1. 5053 2 Keepalive 6.2.2. 5054 3 Sync_Request 6.2.3. 5055 4 Sync_Begin 6.2.4. 5056 5 Sync_Data 6.2.5. 5057 6 Sync_End 6.2.6. 5058 7 Update_Request 6.2.7. 5059 8 Update_Response 6.2.8. 5060 9 Report 6.4. 5061 10 Event 6.3. 5062 11 Vendor 6.6. 5063 12 Error 6.7. 5064 13-199 unassigned 5065 200 Addr_Allocation_Req 6.5.1. 5066 201 Addr_Allocation_Ack 6.5.2. 5067 202 Addr_Renew_Req 6.5.3. 5068 203 Addr_Renew_Ack 6.5.4. 5069 204 Addr_Release_Req 6.5.5. 5070 205 Addr_Release_Ack 6.5.6. 5071 206-254 unassigned 5072 255 reserved 5074 9.2. TLV Types 5076 Type Name Usage Description 5077 ------ ------------ -------------------------- 5078 0 reserved - 5079 1 BAS Function Carries the BNG access 5080 functions to be enabled or 5081 disabled on specified 5082 interfaces. 5083 2 Basic Subscriber Carries the basic information 5084 about a BNG subscriber. 5085 3 PPP Subscriber Carries the PPP information 5086 about a BNG subscriber. 5087 4 IPv4 Subscriber Carries the IPv4 address of a 5088 BNG subscriber. 5089 5 IPv6 Subscriber Carries the IPv6 address of a 5090 BNG subscriber. 5091 6 Subscriber Policy Carries the policy information 5092 applied to a BNG subscriber. 5093 7 IPv4 Routing Carries the IPv4 network 5094 routing information. 5095 8 IPv6 Routing Carries the IPv6 network 5096 routing information. 5097 9 IPv4 Static Subscriber Detect Carries the IPv4 static 5098 subscriber detect information. 5099 10 IPv6 Static Subscriber Detect Carries the IPv6 static 5100 subscriber detect information. 5101 11 L2TP-LAC Subscriber Carries the L2TP LAC 5102 subscriber information. 5103 12 L2TP-LNS Subscriber Carries the L2TP LNS 5104 subscriber information. 5105 13 L2TP-LAC-Tunnel Carries the L2TP LAC tunnel 5106 subscriber information. 5107 14 L2TP-LNS-Tunnel Carries the L2TP LNS tunnel 5108 subscriber information. 5109 15 Subscriber CGN Port Range Carries the public IPv4 5110 address and related port range 5111 of a BNG subscriber. 5112 16-99 unassigned - 5113 100 Hello Used for version and Keepalive 5114 timers negotiation. 5115 101 Error Information Carried in the Ack of the 5116 control message. Carries the 5117 processing result, success, or 5118 error. 5119 102 Keepalive Carried in the Hello message 5120 for Keepalive timers 5121 negotiation. 5122 103-199 unassigned - 5123 200 Interface Status Interfaces status reported by 5124 the UP including physical 5125 interfaces, sub-interfaces, 5126 trunk interfaces, and tunnel 5127 interfaces. 5128 201 Board Status Board information reported by 5129 the UP including the board 5130 type and in-position status. 5131 202-299 unassigned - 5132 300 Subscriber Traffic Statistics User traffic statistics. 5133 301 Subscriber Detection Results User detection information. 5134 302 Update Response The processing result of a 5135 subscriber session update. 5137 303-299 unassigned - 5138 400 Address Allocation Request Request address allocation. 5139 401 Address Allocation Response Address allocation response. 5140 402 Address Renewal Request Request for address lease 5141 renewal. 5142 403 Address Renewal Response Response to a request for 5143 extending an IP address lease. 5144 404 Address Release Request Request to release the 5145 address. 5146 405 Address Release Response Ack of a message releasing an 5147 IP address. 5148 406-1023 unassigned - 5149 1024 Vendor As implemented by vendor. 5150 1039-4095 unassigned - 5152 9.3. TLV Operation Codes 5154 TLV operation codes appear in the Oper field in the header of some 5155 TLVs. See Section 7.1. 5157 Code Operation 5158 ---- ---------- 5159 0 reserved 5160 1 Update 5161 2 Delete 5162 3-15 unassigned 5164 9.4. Sub-TLV Types 5166 See Section 7.3. 5168 Type Name Section of this document 5169 ---- ------------------ ------------------------ 5170 0 reserved 5171 1 VRF Name 7.3.1. 5172 2 Ingress-QoS-Profile 7.3.1. 5173 3 Egress-QoS-Profile 7.3.1. 5174 4 User-ACL-Policy 7.3.1. 5175 5 Multicast-ProfileV4 7.3.1. 5176 6 Multicast-ProfileV6 7.3.1. 5177 7 Ingress-CAR 7.3.2. 5178 8 Egress-CAR 7.3.3. 5179 9 NAT-Instance 7.3.1. 5180 10 Pool-Name 7.3.1. 5181 11 If-Desc 7.3.4. 5182 12 IPv6-Address List 7.3.5. 5183 13 Vendor 7.3.6. 5184 12-64534 unassigned 5185 65535 reserved 5187 9.5. Error Codes 5189 Value Name Remarks 5190 ------- ------- -------- 5191 0 Success Success 5193 1 Fail Malformed message received. 5194 2 TLV-Unknown One or more of the TLVs was not 5195 understood. 5196 3 TLV-Length The TLV length is abnormal. 5197 4-999 unassigned Unassigned basic error codes. 5198 1000 reserved 5199 1001 Version-Mismatch The version negotiation fails. Terminate. 5200 The subsequent service processes 5201 corresponding to the UP are suspended. 5202 1002 Keepalive Error The keepalive negotiation fails. 5203 1003 Timer Expires The establishment timer expired. 5204 1004-1999 unassigned Unassigned error codes for version 5205 negotiation. 5206 2000 reserved 5207 2001 Synch-NoReady The data to be smoothed is not ready. 5208 2002 Synch-Unsupport The request for smooth data is not 5209 supported. 5210 2003-2999 unassigned Unassigned data synchronization error 5211 codes. 5213 3000 reserved 5214 3001 Pool-Mismatch The corresponding address pool cannot be 5215 found. 5216 3002 Pool-Full The address pool is fully allocated and no 5217 address segment is available. 5218 3003 Subnet-Mismatch The address pool subnet cannot be found. 5219 3004 Subnet-Conflict Subnets in the address pool have been 5220 classified into other clients. 5221 3005-3999 unassigned Unassigned error codes for address 5222 allocation. 5223 4000 reserved 5224 4001 Update-Fail-No-Res The forwarding table fails to be 5225 delivered because the forwarding resources 5226 are insufficient. 5227 4002 QoS-Update-Success The QoS policy takes effect. 5228 4003 QoS-Update-Sq-Fail Failed to process the queue in the QoS 5229 policy. 5230 4004 QoS-Update-CAR-Fail Processing of the CAR in the QoS 5231 policy fails. 5232 4005 Statistic-Fail-No-Res Statistics processing failed due to 5233 insufficient statistics resources. 5234 4006-4999 unassigned forwarding table delivery error codes. 5236 5000-4294967295 reserved 5238 9.6. If-Type Values 5240 Defined values of the If-Type field in the If-Desc sub-TLV (see 5241 Section 7.3.4) are as follows: 5243 Value Meaning 5244 ----- ------------ 5245 0 reserved 5246 1 Fast Ethernet (FE) 5247 2 GE 5248 3 10GE 5249 4 100GE 5250 5 Eth-Trunk 5251 6 Tunnel 5252 7 VE 5253 8-254 unassigned 5254 255 reserved 5256 9.7. Access-Mode Values 5258 Defined values of the Access-Mode field in the BAS Function TLV (see 5259 Section 7.7) are as follows: 5261 Value Meaning 5262 ----- ---------- 5263 0 Layer 2 subscriber 5264 1 Layer 3 subscriber 5265 2 Layer 2 leased line 5266 3 Layer 3 leased line 5267 4-254 unassigned 5268 255 reserved. 5270 9.8. Access Method Bits 5272 Defined values of the Auth-Method4 and Auth-Method6 fields in the BAS 5273 Function TLV (see Section 7.7) are defined as bit fields as follows: 5275 Auth-Method4 5276 Bit Meaning 5277 ---- --------- 5278 0x01 PPPoE authentication 5279 0x02 DOT1X authentication 5280 0x04 Web authentication 5281 0x08 Web fast authentication 5282 0x10 Binding authentication 5283 0x20 reserved 5284 0x40 reserved 5285 0x80 reserved 5287 Auth-Method6 5288 Bit Meaning 5289 ---- --------- 5290 0x01 PPPoE authentication 5291 0x02 DOT1X authentication 5292 0x04 Web authentication 5293 0x08 Web fast authentication 5294 0x10 Binding authentication 5295 0x20 reserved 5296 0x40 reserved 5297 0x80 reserved 5299 9.9. Route-Type Values 5301 Values of the Route-Type field in the IPv4 and IPv6 Routing TLVs (see 5302 Section 7.8.1 and 7.8.2) defined in this document are as follows: 5304 Value Meaning 5305 ------- --------- 5306 0 User host route 5307 1 Radius authorization FrameRoute 5308 2 Network segment route 5309 3 Gateway route 5310 4 Radius authorized IP route 5311 5 L2TP LNS side user route 5312 6-65534 unassigned 5313 65535 reserved 5315 9.10. Access-Type Values 5317 Values of the Access-Type field in the Basic Subscriber TLV (see 5318 Section 7.9.1) defined in this document are as follows: 5320 Access-Type 5321 Value Meaning 5322 ------ ---------- 5323 0 reserved 5324 1 PPP access (PPP [RFC1661]) 5325 2 PPP over Ethernet over ATM access (PPPoEoA) 5326 3 PPP over ATM access (PPPoA [RFC3336]) 5327 4 PPP over Ethernet access (PPPoE [RFC2516]) 5328 5 PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) 5329 6 PPP over LNS access (PPPoLNS) 5330 7 IP over Ethernet DHCP access (IPoE_DHCP) 5331 8 IP over Ethernet EAP authentication access (IPoE_EAP) 5332 9 IP over Ethernet Layer 3 access (IPoE_L3) 5333 10 IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) 5334 11 Layer 2 Leased Line access (L2_Leased_Line) 5335 12 Layer 2 VPN Leased Line access (L2VPN_Leased_Line) 5336 13 Layer 3 Leased Line access (L3_Leased_Line) 5337 14 Layer 2 Leased line Sub-User access 5338 (L2_Leased_Line_SUB_USER) 5339 15 L2TP LAC tunnel access (L2TP_LAC) 5340 16 L2TP LNS tunnel access (L2TP_LNS) 5341 17-254 unassigned 5342 255 reserved 5344 10. IANA Considerations 5346 This document requires no IANA actions. 5348 11. Security Considerations 5350 The Service, Control, and Management Interfaces between the CP and UP 5351 might be across the general Internet or other hostile environment. 5352 The ability of an adversary to block or corrupt messages or introduce 5353 spurious messages on any one or more of these interfaces would give 5354 the adversary the ability to stop subscribers from accessing network 5355 services, disrupt existing subscriber sessions, divert traffic, mess 5356 up accounting statistics, and generally cause havoc. Damage would not 5357 necessarily be limited to one or a few subscribers but could disrupt 5358 routing or deny service to one or more instances of the CP or 5359 otherwise cause extensive interference. If the adversary knows the 5360 details of the UP equipment and its forwarding rule capabilities, the 5361 adversary may be able to cause a copy of most or all user data to be 5362 sent to an address of the adversary's choosing, thus enabling 5363 eavesdropping. 5365 Thus, appropriate protections MUST be implemented to provide 5366 integrity, authenticity, and secrecy of traffic over those 5367 interfaces. Whether such protection is used is a network operator 5368 decision. See [RFC6241] for Management Interface / NETCONF security. 5369 Security on the Service Interface is dependent on the tunneling 5370 protocol used which is out of scope for this document. Security for 5371 the Control Interface, over which the S-CUSP protocol flows, is 5372 further discussed below. 5374 S-CUSP messages do not provide security. Thus, if these messages are 5375 exchanged in an environment where security is a concern, that 5376 security MUST be provided by another protocol such as TLS 1.3 5377 [RFC8446] or IPSEC. TLS 1.3 is the mandatory to implement protocol 5378 for interoperability. The use of a particular security protocol on 5379 the Control Interface is determined by configuration. Such security 5380 protocols need not always be used and lesser security precautions 5381 might be appropriate because, in some cases, the communication 5382 between the CP and UP is in a benign environment. 5384 Contributors 5386 Zhenqiang Li 5387 China Mobile 5388 32 Xuanwumen West Ave, Xicheng District 5389 Beijing, Beijing 100053 5390 China 5392 Email: lizhenqiang@chinamobile.com 5394 Mach (Guoyi) Chen 5395 Huawei Technologies 5396 Huawei Bldg., No. 156 Beiqing Road 5397 Beijing 100095 China 5399 Email: mach.chen@huawei.com 5401 Zhouyi Yu 5402 Huawei Technologies 5404 Email: yuzhouyi@huawei.com 5406 Chengguang Niu 5407 Huawei Technologies 5409 Email: chengguang.niu@huawei.com 5411 Zitao Wang 5412 Huawei Technologies 5414 Email: wangzitao@huawei.com 5416 Jun Song 5417 Huawei Technologies 5419 Email: song.jun@huawei.com 5421 Dan Meng 5422 H3C Technologies 5423 No.1 Lixing Center 5424 No.8 guangxun south street, Chaoyang District, 5425 Beijing, 100102 5426 China 5427 Email: mengdan@h3c.com 5429 Hanlei Liu 5430 H3C Technologies 5431 No.1 Lixing Center 5432 No.8 guangxun south street, Chaoyang District, 5433 Beijing, 100102 5434 China 5436 Email: hanlei_liu@h3c.com 5438 Victor Lopez 5439 Telefonica 5440 Spain 5442 Email: victor.lopezalvarez@telefonica.com 5444 Acknowledgements 5446 The helpful comments and suggestions of the following are hereby 5447 acknowledged: 5449 Loa Andersson 5451 Greg Mirsky 5453 Normative References 5455 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 5456 20, DOI 10.17487/RFC0020, October 1969, . 5459 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 5460 DOI 10.17487/RFC0793, September 1981, . 5463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5464 Requirement Levels", BCP 14, RFC 2119, DOI 5465 10.17487/RFC2119, March 1997, . 5468 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 5469 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 5470 2661, DOI 10.17487/RFC2661, August 1999, . 5473 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 5474 "Remote Authentication Dial In User Service (RADIUS)", RFC 5475 2865, DOI 10.17487/RFC2865, June 2000, . 5478 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5479 and A. Bierman, Ed., "Network Configuration Protocol 5480 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5481 . 5483 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 5484 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 5485 2017, . 5487 Informative References 5489 [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area 5490 networks / Bridges and Bridged Networks", IEEE Std 5491 802.1Q-2014, 3 November 2013. 5493 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 5494 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 5495 . 5497 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 5498 DOI 10.17487/RFC2131, March 1997, . 5501 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 5502 and R. Wheeler, "A Method for Transmitting PPP Over 5503 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 5504 1999, . 5506 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 5507 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 5508 . 5510 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 5511 Address Translator (Traditional NAT)", RFC 3022, DOI 5512 10.17487/RFC3022, January 2001, 5515 [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over 5516 Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 5517 3336, DOI 10.17487/RFC3336, December 2002, 5518 . 5520 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used 5521 to Form Encoding Rules in Various Routing Protocol 5522 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 5523 2009, . 5525 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 5526 IETF Protocol and Documentation Usage for IEEE 802 5527 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 5528 October 2013, . 5530 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 5531 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 5532 eXtensible Local Area Network (VXLAN): A Framework for 5533 Overlaying Virtualized Layer 2 Networks over Layer 3 5534 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 5535 . 5537 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5538 Code: The Implementation Status Section", BCP 205, RFC 5539 7942, DOI 10.17487/RFC7942, July 2016, . 5542 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5543 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5544 . 5546 [TR-384] Broadband Forum, "Cloud Central Office Reference 5547 Architectural Framework", BBF TR-384, 2018. 5549 [WT-459] Broadband Forum, "Control and User Plane Separation for a 5550 Disaggregated BNG", BBF WT-459, work in progress, 2019. 5552 Authors' Addresses 5554 Shujun Hu 5555 China Mobile 5556 32 Xuanwumen West Ave, Xicheng District 5557 Beijing, Beijing 100053 5558 China 5560 Email: hushujun@chinamobile.com 5562 Donald Eastlake, 3rd 5563 Futurewei Technologies 5564 2386 Panoramic Circle 5565 Apopka, FL 32703 5566 USA 5568 Phone: +1-508-333-2270 5569 Email: d3e3e3@gmail.com 5571 Fengwei Qin 5572 China Mobile 5573 32 Xuanwumen West Ave, Xicheng District 5574 Beijing, Beijing 100053 5575 China 5577 Email: qinfengwei@chinamobile.com 5579 Tee Mong Chua 5580 Singapore Telecommunications Limited 5581 31 Exeter Road, #05-04 Comcentre Podium Block 5582 Singapore City 239732 5583 Singapore 5585 Email: teemong@singtel.com 5587 Daniel Huang 5588 ZTE 5590 Email: huang.guangping@zte.com.cn 5592 Copyright, Disclaimer, and Additional IPR Provisions 5594 Copyright (c) 2019 IETF Trust and the persons identified as the 5595 document authors. All rights reserved. 5597 This document is subject to BCP 78 and the IETF Trust's Legal 5598 Provisions Relating to IETF Documents 5599 (http://trustee.ietf.org/license-info) in effect on the date of 5600 publication of this document. Please review these documents 5601 carefully, as they describe your rights and restrictions with respect 5602 to this document. Code Components extracted from this document must 5603 include Simplified BSD License text as described in Section 4.e of 5604 the Trust Legal Provisions and are provided without warranty as 5605 described in the Simplified BSD License.