idnits 2.17.1 draft-chz-simple-cu-separation-bng-protocol-05.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 10, 2019) is 1631 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 9, 2020 October 10, 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-05 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 2. Terminology 242 This section specifies implementation requirement keywords and terms 243 used in this document. S-CUSP messages are described in this document 244 using Routing Backus-Naur Form (RBNF) as defined in [RFC5511]. 246 2.1. Implementation Requirement Keywords 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 250 "OPTIONAL" in this document are to be interpreted as described in BCP 251 14 [RFC2119] [RFC8174] when, and only when, they appear in all 252 capitals, as shown here. 254 2.2. Terms 256 This section specifies terms used in this document. 258 AAA: Authentication Authorization Accounting. 260 ACK: Acknowledgement message. 262 BAS: Broadband Access Server (BRAS, BNG). 264 BNG: Broadband Network Gateway. A broadband remote access server 265 (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic 266 to and from broadband remote access devices such as digital 267 subscriber line access multiplexers (DSLAM) on an Internet 268 Service Provider's (ISP) network. BRAS can also be referred to 269 as a Broadband Network Gateway (BNG). 271 BRAS: BRoadband Access Server (BNG). 273 CAR: Committed Access Rate. 275 CBS: Committed Burst Size. 277 CGN: Carrier Grade NAT. 279 Ci: Control Interface. 281 CIR: Committed Information Rate. 283 CoA: Change of Authorization. 285 CP: Control Plane. 287 CP is a user control management component which supports the 288 management of the UP's resources such as the user entry and 289 forwarding policy. 291 CPE: Customer Premises Equipment. 293 CU: Control-plane / User-plane. 295 CUSP: Control and User plane Separation Protocol. 297 DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the 298 priority and before the VLAN ID. (This bit was formerly the CFI 299 (Canonical Format Indicator).) [802.1Q] 301 DHCP: Dynamic Host Configuration Protocol [RFC2131]. 303 dial-up: This refers to the initial connection messages when a new 304 subscriber appears. The name is left over from when subscribers 305 literally dialed up on a modem equipped phone line but herein is 306 applied to other initial connection techniques. Initial 307 connection is frequently indicated by the receipt of packets over 308 PPPoE [RFC2516] or IPoE. 310 EMS: Element Management System. 312 IPoE: IP over Ethernet. 314 L2TP: Layer 2 Tunneling Protocol [RFC2661]. 316 LAC: L2TP Access Concentrator. 318 LNS: L2TP Network Server. 320 MAC: 48-bit Media Access Control address [RFC7042]. 322 MANO: Management and Orchestration. 324 Mi: Management Interface. 326 MSS: Maximum Segment Size. 328 MRU: Maximum Receive Unit. 330 NAT: Network Address Translation [RFC3022]. 332 ND: Neighbor Discovery. 334 NFV: Network Function Virtualization. 336 NFVI: NFV Infrastructure 338 PBS: Peak Burst Size. 340 PD: Prefix Delegation. 342 PIR: Peak Information Rate. 344 PPP: Point to Point Protocol [RFC1661]. 346 PPPoE: PPP over Ethernet [RFC2516]. 348 RBNF: Routing Backus-Naur Form [RFC5511]. 350 RG: Residential Gateway. 352 S-CUSP: Simple Control and User Plane Separation Protocol. 354 Subscriber: The remote user gaining network accesses via a BNG. 356 Si: Service Interface. 358 TLV: Type, Length, Value. See Sections 7.1 and 7.3. 360 UP: User Plane. UP is a network edge and user policy implementation 361 component. The traditional router's Control Plane and Forwarding 362 Plane are both preserved on BNG devices in the form of a user 363 plane. 365 URPF: Unicast Reverse Path Forwarding. 367 User: Equivalent to "customer" or "subscriber". 369 VRF: Virtual Routing and Forwarding. 371 3. BNG CUPS Overview 373 3.1. BNG CUPS Motivation 375 The rapid development of new services, such as 4K TV, IoT, etc., and 376 increasing numbers of home broadband service users present some new 377 challenges for BNGs such as: 379 Low resource utilization: The traditional BNG acts as both a gateway 380 for user access authentication and accounting and an IP network's 381 Layer 3 edge. The mutually affecting nature of the tightly 382 coupled control plane and forwarding plane makes it difficult to 383 achieve the maximum performance of either plane. 385 Complex management and maintenance: Due to the large numbers of 386 traditional BNGs, configuring each device in a network is very 387 tedious when deploying global service policies. As the network 388 expands and new services are introduced, this deployment mode 389 will cease to be feasible as it is unable to manage services 390 effectively and rectify faults rapidly. 392 Slow service provisioning: The coupling of control plane and 393 forwarding plane, in addition to a distributed network control 394 mechanism, means that any new technology has to rely heavily on 395 the existing network devices. 397 The framework for a cloud-based BNG with Control Plane and User Plane 398 (CU) separation to address these challenges for fixed networks is 399 described in [TR-384]. The main idea of CU separation is to extract 400 and centralize the user management functions of multiple BNG devices, 401 forming a unified and centralized Control Plane (CP). And the 402 traditional router's Control Plane and Forwarding Plane are both 403 preserved on BNG devices in the form of a User Plane (UP). 405 3.2. BNG CUPS Architecture Overview 407 The functions in a traditional BNG can be divided into two parts: one 408 is the user access management function, the other is the router 409 function. The user management function can be deployed as a 410 centralized module or device, called the BNG Control Plane (BNG-CP). 411 The other functions, such as the router function and forwarding 412 engine, can be deployed in the form of the BNG User Plane (BNG-UP). 414 The following figure shows the architecture of CU separated BNG: 416 +------------------------------------------------------------------+ 417 | Neighboring policy and resource management systems | 418 | | 419 | +-------------+ +-----------+ +---------+ +----------+ | 420 | |AAA Server| |DHCP Server| | EMS | | MANO | | 421 | +-------------+ +-----------+ +---------+ +----------+ | 422 +------------------------------------------------------------------+ 424 +------------------------------------------------------------------+ 425 | CU-separated BNG system | 426 | +--------------------------------------------------------------+ | 427 | | +----------+ +----------+ +------++------++-----------+ | | 428 | | | Address | |Subscriber| | AAA ||Access|| UP | | | 429 | | |management| |management| | || Mgt ||management | | | 430 | | +----------+ +----------+ +------++------++-----------+ | | 431 | | CP | | 432 | +--------------------------------------------------------------+ | 433 | | 434 | | 435 | | 436 | +---------------------------+ +--------------------------+ | 437 | | +------------------+ | | +------------------+ | | 438 | | | Routing control | | | | Routing control | | | 439 | | +------------------+ | ... | +------------------+ | | 440 | | +------------------+ | | +------------------+ | | 441 | | |Forwarding engine | | | |Forwarding engine | | | 442 | | +------------------+ UP | | +------------------+ UP| | 443 | +---------------------------+ +--------------------------+ | 444 +------------------------------------------------------------------+ 446 Figure 1: Architecture of CU Separated BNG 448 As shown in Figure 1, the BNG Control Plane could be virtualized and 449 centralized, which provides benefits such as centralized session 450 management, flexible address allocation, high scalability for 451 subscriber management capacity, and cost-efficient redundancy, etc. 452 The functional components inside the BNG Service Control Plane can be 453 implemented as Virtual Network Functions (VNFs) and hosted in a 454 Network Function Virtualization Infrastructure (NFVI). 456 The User Plane Management module in the BNG Control Plane centrally 457 manages the distributed BNG User Planes (e.g., load balancing), as 458 well as the setup, deletion, and maintenance of channels between 459 Control Planes and User Planes. Other modules in the BNG control 460 plane, such as address management, AAA, etc., are responsible for the 461 connection with external subsystems in order to fulfill those 462 services. Note that the User Plane SHOULD support both physical and 463 virtual network functions. For example, BNG user plane L3 forwarding 464 related network functions can be disaggregated and distributed across 465 the physical infrastructure. And the other control plane and 466 management plane functions in the CU Separation BNG can be moved into 467 the NFVI for virtualization [TR-384]. 469 The details of CU separated BNG's function components are as 470 following: 472 The Control Plane is responsible for the following: 474 1. Address management: unified address pool management and CGN 475 subscriber address traceability management. 477 2. AAA: This component performs Authentication, Authorization and 478 Accounting, together with RADIUS/DIAMETER. The BNG communicates 479 with the AAA server to check whether the subscriber who sent an 480 Access-Request has network access authority. Once the subscriber 481 goes online, this component together with the Service Control 482 component implement accounting, data capacity limitation, and QoS 483 enforcement policies. 485 3. Subscriber management: user entry management and forwarding 486 policy management. 488 4. Access management: process user dial-up packets, such as PPPoE, 489 DHCP, L2TP, etc. 491 5. UP management: management of UP interface status, and the setup, 492 deletion, and maintenance of channels between CP and UP. 494 The User Plane is responsible for the following: 496 1. Routing control functions: responsible for constructing routing 497 forwarding plane (e.g., routing, multicast, MPLS, etc.). 499 2. Routing and Service Forwarding plane functions: responsible 500 including traffic forwarding, QoS and traffic statistics 501 collection. 503 Subscriber detection: responsible for detecting whether a subscriber 504 is still online. 506 3.3. BNG CUPS Interfaces 508 Three interfaces defined below support the communication between the 509 Control Plane and User Plane. These are referred to as the Service 510 Interface (Si), Control Interface (Ci), and Management Interface (Mi) 511 as shown in Figure 2. 513 +-----------------------------------+ 514 | | 515 | BNG-CP | 516 | | 517 +--+--------------+--------------+--+ 518 | | | 519 1. Service | 2. Control | 3. Management| 520 Interface | Interface | Interface | 521 (Si) | (Ci) | (Mi) | 522 | | | 523 | ___|___ | 524 | ___( )___ | 525 _|______( )______|_ 526 ( ) 527 ( Network/Internet ) 528 (________ ________) 529 | (___ ___) | 530 | (_______) | 531 | | | 532 | | | 533 +--+--------------+--------------+--+ 534 | | 535 | BNG-UP | 536 | | 537 +-----------------------------------+ 539 Figure 2: Interfaces Between the CP and UP of the BNG 541 3.3.1. Service Interface 543 For a traditional BNG (without CU separation), the user dial-up 544 signals are terminated and processed by the control plane of a BNG. 545 When the CP and UP of a BNG are separated, there needs to be a way to 546 relay these signals between the CP and the UP. 548 The Service Interface (Si) is used to establish tunnels between the 549 CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, 550 and L2TP related control packets that are received from a Residential 551 Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN 552 [RFC7348]. 554 The detailed definition of Si is out of scope for this document. 556 3.3.2. Control Interface 558 The CP uses the Control Interface to deliver subscriber session 559 states, network routing entries, etc. to the UP (see Section 6.2.7)). 560 The UP uses this interface to report subscriber service statistics, 561 subscriber detection results, etc. to the CP (see Sections 6.3 and 562 6.4). A carrying protocol for this interface is specified in this 563 document. 565 3.3.3. Management Interface 567 NETCONF [RFC6241] is the protocol used on the Management Interface 568 between a CP and UP. It is used to configure the parameters of the 569 Control Interface, Service Interface, the Access interfaces and 570 QoS/ACL Templates. It is expected that implementations will make use 571 of existing YANG models where possible, but that new YANG models 572 specific to S-CUSP will need to be defined. The definitions of the 573 parameters that can be configured are out of scope for this document. 575 3.4. BNG CUPS Procedure Overview 577 The following numbered sequences (Figure 3) gives a high-level view 578 of the main BNG CUPS procedures. 580 RG UP CP AAA 581 | | | | 582 | |Establish S-CUSP Channel| | 583 | 1|<---------------------->| | 584 | | | | 585 | | Report Board | | 586 | | interface | | 587 | | information | | 588 | 2|------to CP via Ci----->| | 589 | | | | 590 | | Update BAS function | | 591 | 3| request / response | | 592 | |<-----on UP via Ci----->| | 593 | | | | 594 | | Update network routing | | 595 | | request / response | | 596 | 4|<------- via Ci-------->| | 597 | | | | 598 | Online Req | | | 599 5.1|-------------->| | | 600 | | Relay the Online Req | | 601 | 5.2|-----to CP via Si------>| Authentication| 602 | | | Req/Rep | 603 | | 5.3|<------------->| 604 | | Send the Online Rep | | 605 | 5.4|<----to UP via Si-------| | 606 | Online Rep | | | 607 5.5|<--------------| | | 608 | | Create subscriber | | 609 | | session on UP | | 610 | 5.6|<--------via Ci-------->| | 611 | | | CoA Request | 612 | | 6.1|<--------------| 613 | | Update session on UP | | 614 | 6.2|<--------via Ci-------->| | 615 | | | CoA Response | 616 | | 6.3|-------------->| 617 | | | | 618 | Offline Req | | | 619 7.1|-------------->| | | 620 | | Relay the Offline Req | | 621 | 7.2|------to CP via Si----->| | 622 | | | | 623 | | Send the Offline Rep | | 624 | 7.3|<-----to UP via Si------| | 625 | Offline Rep | | | 626 7.4|<--------------| | | 627 | | Delete session on UP | | 628 | 7.5|<--------via Ci-------->| | 629 | | | | 630 | | Event report | | 631 | 8|---------via Ci-------->| | 632 | | | | 633 | | Data Synchronization | | 634 | 9|<--------via Ci-------->| | 635 | | | | 636 | | CGN Address Allocation | | 637 | 10|<--------via Ci-------->| | 638 | | | | 640 Figure 3: BNG CUPS Procedures Overview 642 1. S-CUSP session establishment: This is the first step of BNG CUPS 643 procedures. Once the Control Interface parameters are configured 644 on a UP, it will start to setup S-CUSP sessions with the 645 specified CPs. The detailed definition of S-CUSP session 646 establishment can be found in Section 4.1.1. 648 2. Board and interface report: Once the S-CUSP session is 649 established between the UP and a CP, the UP will report status 650 information on the boards and subscriber-facing interfaces of 651 this UP to the CP. A board can also be called a Line/Service 652 Process Unit (LPU/SPU) card. The subscriber-facing interfaces 653 refer to the interfaces that connect the Access Network nodes 654 (e.g., OLT: Optical Line Terminal, DSLAM: Digital Subscriber Line 655 Access Multiplexer, etc.). The CP can use this information to 656 enable the Broadband Access Service (BAS) function (e.g., IPoE, 657 PPPoE, etc.) on the specified interfaces. See Sections 4.2.1 and 658 7.10 for more details on Resource reporting. 660 3. BAS (Broadband Access Service) function enable: To enable the BAS 661 function on the specified interfaces of a UP. 663 4. Subscriber network route advertisement: The CP will allocate one 664 or more IP address blocks to a UP. Each address block contains a 665 series of IP addresses. Those IP addresses will be allocated to 666 subscribers who are dialing up from the UP. To enable other nodes 667 in the network to learn how to reach the subscribers, the CP 668 needs to notify the UP to advertise to the network the routes 669 that can reach those IP addresses. 671 5. 5.1-5.6 is a complete call flow of a subscriber dial-up (as 672 defined in Section 2.1) process. When a UP receives a dial-up 673 request, it will relay the request packet to a CP through the 674 Service Interface. The CP will parse the request. If everything 675 is OK, it will send an authentication request to the AAA server 676 to authenticate the subscriber. Once the subscriber passes the 677 authentication, the AAA server will return a positive response to 678 the CP. Then the CP will send the dial-up response packet to the 679 UP, and the UP will forward the response packet to the subscriber 680 (RG). At the same time, the CP will create a subscriber session 681 on the UP, which enables the subscriber to access the network. 682 For different access types, the process may be a bit different. 683 But the high-level process is similar. For each access type, the 684 detail process can be found in Section 5. 686 6. 6.1-6.3 is the sequence when updating an existing subscriber 687 session. The AAA server initiates a Change of Authorization (CoA) 688 and sends the CoA to the CP. The CP will then update the session 689 according to the CoA. See Section 4.3.2 for more detail on CP 690 messages updating UP tables. 692 7. 7.1-7.5 is the sequence for deleting an existing subscriber 693 session. When a UP receives an offline request, it will relay the 694 request to a CP through the Service Interface. The CP will send 695 back a response to the UP through the Service Interface. The UP 696 will then forward the offline response to the subscriber. Then 697 the CP will delete the session on the UP through the Control 698 Interface. 700 8. Event reports include the following two parts (more detail can be 701 found in Section 4.3.4) Both are reported using the Event 702 message. 704 8.1. Subscriber Traffic Statistics Report 705 8.2. Subscriber Detection Result Report 707 9. Data synchronization: See Sections 4.2.5 for more detail on CP 708 and UP Synchronization. 710 10. CGN address allocation: See Sections 4.2.4 for more detail on CGN 711 Address Allocation. 713 4. S-CUSP Protocol Overview 715 4.1. Control Channel Related Procedures 717 4.1.1. S-CUSP Session Establishment 719 A UP is associated with a CP and is controlled by that CP. In the 720 case of a hot-standby or cold-standby, a UP is associated with two 721 CPs, one called the Master CP and the other called the Standby CP. 722 The association between a UP and its CPs is implemented by dynamic 723 configuration. 725 Once a UP knows its CPs, the UP starts to establish S-CUSP sessions 726 with those CPs, as shown in Figure 4. 728 UP CP 729 | | 730 | TCP Session Establishment | 731 |<------------------------------->| 732 | | 733 | HELLO (version, capability) | 734 |-------------------------------->| 735 | | 736 | HELLO (version, capability) | 737 |<--------------------------------| 738 | | 740 Figure 4: S-CUSP Session Establishment 742 The S-CUSP session establishment consists of two successive steps: 744 1. Establishment of a TCP [RFC793] connection (3-way handshake) 745 between the CP and the UP using a configured port from the 746 dynamic port range (49152-65535). 748 2. Establishment of an S-CUSP session over the TCP connection. 750 Once the TCP connection is established, the CP and the UP initialize 751 the S-CUSP session during which the version and Keepalive timers are 752 negotiated. 754 The version information (Hello TLV, see Section 7.4) is carried 755 within Hello messages (see Section 6.2.1). A CP can support multiple 756 versions, but a UP can only support one version. So, the version 757 negotiation is based on whether a version can be supported by both 758 the CP and the UP. For a CP or UP, if a Hello message is received 759 that does not indicate a version supported by both, a subsequent 760 Hello message with an Error Information TLV will be sent to the peer 761 to notify the peer of the "Version-Mismatch" error and the session 762 establishment phase fails. 764 Keepalive negotiation is performed by carrying a Keepalive TLV in the 765 Hello message. The Keepalive TLV includes a Keepalive timer and Dead 766 Timer field. The CP and UP have to agree on the Keepalive Timer and 767 Dead Timer. Otherwise, a subsequent Hello message with an Error 768 Information TLV will be sent to its peer and the session 769 establishment phase fails. 771 The S-CUSP session establishment phase fails if the CP or UP disagree 772 on the version and keepalive parameters or if one of the CP or UP 773 does not answer after the expiration of the Establishment timer. 774 When the S-CUSP session establishment fails, the TCP connection is 775 promptly closed. Successive retries are permitted, but an 776 implementation SHOULD make use of an exponential back-off session 777 establishment retry procedure. 779 The S-CUSP session timer values that need to be configured are 780 summarized in the table below. 782 Timer Range in Default 783 Name seconds Value 784 ------------- ------- ------- 785 Establishment Timer 1-32767 45 786 Keepalive Timer 0-255 30 787 DeadTimer 1-32767 4 * Keepalive 789 4.1.2. Keepalive Timer and DeadTimer 791 Once an S-CUSP session has been established, a UP or CP may want to 792 know that its S-CUSP peer is still connected. 794 Each end of an S-CUSP session runs a Keepalive timer. It restarts 795 the timer every time it sends a message on the session. When the 796 timer expires, it sends a Keepalive message. Thus, a message is 797 transmitted at least as often as the value the Keepalive timer is 798 reset to, unless, as explained below, that value is the special value 799 zero. 801 Each end of a S-CUSP session also run a DeadTimer, and restarts that 802 DeadTimer whenever a message is received on the session. If the 803 DeadTimer at an end of the session expires, that end declares the 804 session dead and the session will be closed, unless their DeadTimer 805 is set to the special value zero in which case the session will not 806 time out. 808 The minimum value of the Keepalive timer is 1 second, and it is 809 specified in units of 1 second. The RECOMMENDED default value is 30 810 seconds. The recommended default for the DeadTimer is four times the 811 value of the Keepalive timer used by the remote peer. As above, the 812 timers may be disabled by setting them to zero. 814 The Keepalive timer and DeadTimer are negotiated through the 815 Keepalive TLV carried in the Hello Message. 817 4.2. Node Related Procedures 819 4.2.1. UP Resource Report 821 Once an S-CUSP session has been established between a CP and an UP, 822 the UP reports the state information of the Boards and access-facing 823 interfaces on the UP to the CP, as shown in Figure 5. Report messages 824 are unacknowledged and are assumed to be delivered because the 825 session runs over TCP. 827 The CP can use that information to activate/enable the Broadband 828 Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the 829 specified interfaces. 831 In addition, the UP resource report may trigger a UP warm-standby 832 process. In the case of warm-standby, a failure on a UP may trigger 833 the CP to start a warm-standby process, by moving the on-line 834 subscriber sessions to a standby UP and then direct the affected 835 subscribers to access the Internet through the standby UP. 837 UP CP 838 | | 839 | Report Board Status | 840 |------to CP via Ci----->| 841 | | 842 | Report Interface Status| 843 |------to CP via Ci----->| 844 | | 846 Figure 5: UP Board and Interface Report 848 Board status information is carried in the Board Status TLV (Section 849 7.10.2) and Interface status information is carried in Interface 850 Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are 851 carried in the Report Message (Section 6.4). 853 4.2.2. Update BAS Function on Access Interface 855 Once the CP collects the interface status of a UP, it will 856 activate/de-activate/modify the BAS functions on specified interfaces 857 through the Update_Request and Update_Response message (Section 6.2) 858 exchanges, carrying the BAS Function TLV (Section 7.7). 860 UP CP 861 | | 862 | Update BAS function | 863 | Request | 864 |<-----on UP via Ci-------| 865 | | 866 | Update BAS function | 867 | Response | 868 |------on UP via Ci------>| 869 | | 871 Figure 6: Update BAS Function 873 4.2.3. Update Network Routing 875 The CP will allocate one or more address blocks to a UP. Each address 876 block contains a series of IP addresses. Those IP addresses will be 877 assigned to subscribers who are dialing up to the UP. To enable the 878 other nodes in the network to learn how to reach the subscribers, the 879 CP needs to install the routes on the UP and notify the UP to 880 advertise the routes to the network. 882 UP CP 883 | | 884 | Subscriber network route| 885 | update request | 886 |<------- via Ci----------| 887 | | 888 | Subscriber network route| 889 | update response | 890 |-------- via Ci--------->| 891 | | 893 Figure 7: Update Network Routing 895 The Update Request and Response Message exchanges, carrying the 896 IPv4/IPv6 Routing Information TLVs (Section 7.8), update the 897 subscriber's network routing information. 899 4.2.4. CGN Public IP Address Allocation 901 The following sequences describe the CGN address management related 902 procedures. Three independent procedures are defined, one each for 903 CGN address allocation request/response, CGN address renewal 904 request/response, and CGN address release request/response. 906 CGN address allocation/renew/release procedures are designed for the 907 case where the CGN function is running on the UP. The UP has to map 908 the subscriber private IP addresses to a public IP addresses, and 909 such mapping is performed by the UP locally when a subscriber dials- 910 up. That means the UP has to ask for public IPv4 address blocks for 911 CGN subscribers from the CP. 913 In addition, when a public IP address is allocated to a UP, there 914 will be a lease time (e.g., one day). Before the lease time expires, 915 the UP can ask for renewal of the IP address lease from the CP. It is 916 achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack 917 messages. 919 If the public IP address will not be used anymore, the UP SHOULD 920 release the address by sending an Addr_Release_Req message to the CP. 922 If the CP wishes to withdraw addresses that it has previously leased 923 to a UP, it uses the same procedures as above. The "Oper" code in 924 the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the 925 request is an update or withdraw. 927 The relevant messages are defined in Section 6.5. 929 UP CP 930 | | 931 | CGN Address Allocation | 932 | Request | 933 1.1|-------- via Ci--------->| 934 | CGN Address Allocation | 935 | Response | 936 1.2|<------- via Ci----------| 937 | | 938 | CGN Address Renew | 939 | Request | 940 2.1|-------- via Ci--------->| 941 | CGN Address Renew | 942 | Response | 943 2.2|<------- via Ci----------| 944 | | 945 | CGN Address Release | 946 | Request | 947 3.1|-------- via Ci--------->| 948 | CGN Address Release | 949 | Response | 950 3.3|<------- via Ci----------| 951 | | 953 Figure 8: CGN Public IP Address Allocation 955 4.2.5. Data Synchronization between the CP and UP 957 For a CU separated BNG, the UP will continue to function using the 958 state that has been installed in it even if the CP fails or the 959 session between the UP and CP fails. 961 Under some circumstances, it is necessary to synchronize state 962 between the CP and UP, for example if a CP fails and the UP is 963 switched to a different CP. 965 Synchronization includes two directions. One direction is from UP to 966 CP; in that case, the synchronization information is mainly about the 967 board/interface status of the UP. The other direction is from CP to 968 UP; in that case, the subscriber sessions, subscriber network routes, 969 L2TP tunnels, etc. will be synchronized to the UP. 971 The synchronization is triggered by a Sync_Request message, to which 972 the receiver will (1) reply with a Sync_Begin message to notify the 973 requester that synchronization will begin, and (2) then start the 974 synchronization using the Sync_Data message. When synchronization 975 finished, a Sync_End message will be sent. 977 The following figure shows the process of data synchronization 978 between a UP and a CP. 980 UP CP 981 | | 982 | Synchronization Request | 983 |<------- via Ci----------| 984 | | 985 | Synchronization Begin | 986 |-------- via Ci--------->| 987 | | 988 | Board/Interface Report | 989 |-------- via Ci--------->| 990 | | 991 | Synchronization End | 992 |-------- via Ci--------->| 993 | | 994 1) Synchronization from UP to CP 996 UP CP 997 | | 998 | Synchronization Request | 999 |-------- via Ci--------->| 1000 | | 1001 | Synchronization Begin | 1002 |<-------- via Ci---------| 1003 | | 1004 | Synchronizes | 1005 |Subscriber Session States| 1006 | Network Route Entries | 1007 |<------- via Ci----------| 1008 | | 1009 | Synchronization End | 1010 |<-------- via Ci---------| 1011 | | 1012 2) Synchronization from CP to UP 1014 Figure 9: Data Synchronization 1016 4.3. Subscriber Session Related Procedures 1018 A subscriber session consists of a set of forwarding states, 1019 policies, and security rules that are applied to the subscriber. It 1020 is used for forwarding subscriber traffic in a UP. To initialize a 1021 session on a UP, A collection of hardware resources (e.g., NP, TCAM 1022 etc.) have to be allocated to a session on a UP as part of its 1023 initiation. 1025 Subscriber session related procedures include subscriber session 1026 create, update, delete, and statistics report. The following sub- 1027 sections give a high-level view of the procedures. 1029 4.3.1. Create Subscriber Session 1031 The below sequence describes the DHCP IPv4 dial-up process. It is an 1032 example that shows how a subscriber session is created. (An example 1033 for IPv6 appears in Section 5.1.2.) 1035 RG UP CP AAA 1036 | | | | 1037 | Online Request| | | 1038 1|-------------->| | | 1039 | |Relay the Online Request| | 1040 | 2|-----to CP via Si------>| Authentication| 1041 | | | Req/Rep | 1042 | | 3|<------------->| 1043 | | Create subscriber | | 1044 | | session Request | | 1045 | 4|<--------via Ci---------| | 1046 | | | | 1047 | | Create subscriber | | 1048 | | session Response | | 1049 | 5|---------via Ci-------->| | 1050 | | | | 1051 | | | Accounting | 1052 | | 6|<------------->| 1053 | | | | 1054 | | Send Online Response | | 1055 | 7|<----to UP via Si-------| | 1056 | | | | 1057 |Online Response| | | 1058 12|<--------------| | | 1059 | | | | 1061 Figure 10: Subscriber Session Create 1063 The request starts from an Online Request message (step 1) from the 1064 RG (for example, a DHCP Discovery packet). When the UP receives the 1065 Online Request from the RG, it will tunnel the Online Request to the 1066 CP through the Service Interface (Step 2). A tunneling technology 1067 implements the Service Interface. 1069 When the CP receives the Online Request from the UP, it will send an 1070 authentication request to the AAA server to authenticate and 1071 authorize the subscriber (step 3). When a positive reply is received 1072 from the AAA server, the CP starts to create a subscriber session for 1073 the request. Relevant resources (e.g., IP address, bandwidth, etc.) 1074 will be allocated to the subscriber. Policies and security rules will 1075 be generated for the subscriber. Then the CP sends a request to 1076 create a session to the UP through the Control Interface (Ci) (step 1077 4), and a response is expected from the UP to confirm the creation 1078 (step 5). 1080 Finally, the CP will notify the AAA server to start accounting (step 1081 6). At the same time, an Online Response message (for example, a 1082 DHCP Ack packet) will be sent to the UP through the Si (step 7). And 1083 the UP will forward the Online Response to the RG (step 8). 1085 That completes the subscriber activation process. 1087 4.3.2. Update Subscriber Session 1089 The following numbered sequence shows the process of updating the 1090 subscriber session. 1092 UP CP AAA 1093 | | COA Request | 1094 | 1|<--------------| 1095 | Session update Request | | 1096 2|<--------via Ci---------| | 1097 | | | 1098 | Session update Response| | 1099 3|---------via Ci-------->| | 1100 | | COA Response | 1101 | 4|-------------->| 1102 | | | 1104 Figure 11: Subscriber Session Update 1106 When a subscriber session has been created on a UP, there may be 1107 requirements to update the session with new parameters (e.g., 1108 Bandwidth, QoS, policies, etc.). 1110 This procedure is triggered by a Change of Authorization (COA) 1111 request message sent by the AAA server. The CP will update the 1112 session on the UP according to the new parameters through the Control 1113 Interface. 1115 4.3.3. Delete Subscriber Session 1117 The below call flow shows how S-CUPS deals with a subscriber offline 1118 request. 1120 RG UP CP 1121 | | | 1122 |Offline Request | | 1123 1|--------------->| | 1124 | | Relay the Offline | 1125 | | Request | 1126 | 2|------to CP via Si----->| 1127 | | | 1128 | | Send the Offline | 1129 | | Response | 1130 | 3|<-----to UP via Si------| 1131 |Offline Response| | 1132 4|<---------------| | 1133 | | Session delete | 1134 | | Request | 1135 | |<--------via Ci---------| 1136 | | Session delete | 1137 | | Response | 1138 | |---------via Ci-------->| 1139 | | | 1141 Figure 12: Subscriber Session Delete 1143 Similar to the session creation process, when a UP receives an 1144 offline request from an RG, it will tunnel the request to a CP 1145 through the Si. 1147 When the CP receives the offline request, it will withdraw/release 1148 the resources (e.g., IP address, bandwidth) that have been allocated 1149 to the subscriber. Then, it sends a reply to the UP through the 1150 Service Interface and the UP will forward the reply to the RG. At 1151 the same time, it will delete all the status of the session on the UP 1152 through the Ci. 1154 4.3.4. Subscriber Session Events Report 1156 UP CP 1157 | | 1158 | Statistic/Detect report| 1159 |---------via Ci-------->| 1160 | | 1162 Figure 13: Events Report 1164 When a session is created on a UP, the UP will periodically report 1165 statistics information and detect results of the session to the CP. 1167 5. S-CUSP Call Flows 1169 The subsections below give an overview of various "dial-up" 1170 interactions over the Service Interface followed by an overview of 1171 the setting of information in the UP by the CP using S-CUSP over the 1172 Control Interface. 1174 S-CUSP messages are described in this document using Routing Backus 1175 Naur Form (RBNF) as defined in [RFC5511]. 1177 5.1. IPoE 1179 5.1.1. DHCPv4 Access 1181 The following sequence shows detailed procedures for DHCPv4 access. 1183 RG UP CP AAA 1184 | | | | 1185 | DHCP Discovery| | | 1186 1|-------------->| | | 1187 | |Relay the DHCP Discovery| | 1188 | 2|-----to CP via Si------>| AAA | 1189 | | | Req/Rep | 1190 | | 3|<------------->| 1191 | | | | 1192 | | Send the DHCP Offer | | 1193 | 4|<----to UP vis Si-------| | 1194 | DHCP Offer | | | 1195 5|<--------------| | | 1196 | DHCP Request | | | 1197 6|-------------->| | | 1198 | | Relay the DHCP Request| | 1199 | 7|-----to CP via Si------>| | 1200 | | | | 1201 | | Create subscriber | | 1202 | | session Request | | 1203 | 8|<--------via Ci---------| | 1204 | | Create subscriber | | 1205 | | session Response | | 1206 | 9|---------via Ci-------->| | 1207 | | | Accounting | 1208 | | 10|<------------->| 1209 | | | | 1210 | | Send DHCP ACK | | 1211 | 11|<----to UP via Si-------| | 1212 | | | | 1213 | DHCP ACK | | | 1214 12|<--------------| | | 1215 | | | | 1217 Figure 14: DHCPv4 Access 1219 The S-CUSP protocol implements steps 8 and 9. 1221 After a subscriber is authenticated and authorized by the AAA server, 1222 the CP creates a new subscriber session on the UP. This is achieved 1223 by sending an Update_Request message to the UP. 1225 The format of the Update_Request message is shown as follows using 1226 RBNF: 1228 ::= 1229 1230 1231 1232 [] 1234 The UP will reply with an Update_Response message, the format of the 1235 Update_Response message is as follows: 1237 ::= 1238 1239 [] 1241 5.1.2. DHCPv6 Access 1243 The following sequence shows detailed procedures for DHCPv6 access. 1245 RG UP CP AAA 1246 | | | | 1247 | Solicit | | | 1248 1|-------------->| | | 1249 | | Relay the Solicit | | 1250 | 2|-----to CP via Si------>| AAA | 1251 | | | Req/Rep | 1252 | | 3|<------------->| 1253 | | | | 1254 | | Send the Advertise | | 1255 | 4|<----to UP vis Si-------| | 1256 | Advertise | | | 1257 5|<--------------| | | 1258 | | | | 1259 | Request | | | 1260 6|-------------->| | | 1261 | | Relay the Request | | 1262 | 7|-----to CP via Si------>| | 1263 | | | | 1264 | | | | 1265 | | Create subscriber | | 1266 | | session Request | | 1267 | 8|<--------via Ci-------->| | 1268 | | | | 1269 | | Create subscriber | | 1270 | | session Response | | 1271 | 9|---------via Ci-------->| | 1272 | | | | 1273 | | | Accounting | 1274 | | 10|<------------->| 1275 | | | | 1276 | | Send Reply | | 1277 | 11|<----to UP via Si-------| | 1278 | | | | 1279 | Reply | | | 1280 12|<--------------| | | 1281 | | | | 1283 Figure 15: DHCPv6 Access 1285 Steps 1-7 are a standard DHCP IPv6 access process. The subscriber 1286 creation is triggered by a DHCP IPv6 request message. When this 1287 message is received, it means that the subscriber has passed the AAA 1288 authentication and authorization. Then the CP will create a 1289 subscriber session on the UP. This is achieved by sending an 1290 Update_Request message to the UP (Step 8). 1292 The format of the Update_Request message is as follows: 1294 ::= 1295 1296 1297 1298 [] 1300 The UP will reply with an Update_Response message (Step 9). The 1301 format of the Update_Response message is as follows: 1303 ::= 1304 1306 5.1.3. IPv6 SLAAC Access 1308 The following flow shows the IPv6 SLAAC access process. 1310 RG UP CP AAA 1311 | | | | 1312 | RS | | | 1313 1|-------------->| | | 1314 | | Relay the Router | | 1315 | | Solicit (RS) | | 1316 | 2|-----to CP via Si------>| AAA | 1317 | | | Req/Rep | 1318 | | 3|<------------->| 1319 | | | | 1320 | | Create subscriber | | 1321 | | session Request | | 1322 | 4|<--------via Ci---------| | 1323 | | | | 1324 | | Create subscriber | | 1325 | | session Response | | 1326 | 5|---------via Ci-------->| | 1327 | | | | 1328 | | Send Router Advertise | | 1329 | | (RA) | | 1330 | 6|<----to UP vis Si-------| | 1331 | RA | | | 1332 7|<--------------| | | 1333 | | | | 1334 | NS | | | 1335 8|-------------->| | | 1336 | | Relay the Neighbor | | 1337 | | Solicit (NS) | | 1338 | 9|-----to CP via Si------>| | 1339 | | | | 1340 | | | Accounting | 1341 | | 10|<------------->| 1342 | | | | 1343 | | Send a Neighbor | | 1344 | | Advertise (NA) | | 1345 | 11|<----to UP via Si-------| | 1346 | | | | 1347 | NA | | | 1348 12|<--------------| | | 1349 | | | | 1351 Figure 16: IPv6 SLAAC Access 1353 It starts with a Router Solicit (RS) request from an RG that is 1354 tunneled to the CP by the UP. After the AAA authentication and 1355 authorization, the CP will create a subscriber session on the UP. 1357 This is achieved by sending an Update_Request message to the UP (step 1358 4). 1360 The format of the Update_Request message is as follows: 1362 ::= 1363 1364 1365 1366 [] 1368 The UP will reply with an Update_Response message (step 5), the 1369 format of the Update_Response message is as follows: 1371 ::= 1372 1374 5.1.4. DHCPv6 + SLAAC Access 1376 The following call flow shows the DHCP IPv6 and SLAAC access process. 1378 RG UP CP AAA 1379 | | | | 1380 | RS | | | 1381 1|-------------->| | | 1382 | | Relay the Router | | 1383 | | Solicit (RA) | | 1384 | 2|-----to CP via Si------>| AAA | 1385 | | | Req/Rep | 1386 | | 3|<------------->| 1387 | | | | 1388 | | Create subscriber | | 1389 | | session Request | | 1390 | 4|<--------via Ci---------| | 1391 | | | | 1392 | | Create subscriber | | 1393 | | session Response | | 1394 | 5|---------via Ci-------->| | 1395 | | | | 1396 | | Send Router Advertise | | 1397 | | (RA) | | 1398 | 6|<----to UP vis Si-------| | 1399 | RA | | | 1400 7|<--------------| | | 1401 | | | | 1402 |DHCPv6 Solicit | | | 1403 8|-------------->| | | 1404 | | Relay DHCPv6 Solicit | | 1405 | 9|-----to CP via Si------>| | 1406 | | | | 1407 | | Update subscriber | | 1408 | | session Request | | 1409 | 10|<--------via Ci---------| | 1410 | | | | 1411 | | Update subscriber | | 1412 | | session Response | | 1413 | 11|---------via Ci-------->| | 1414 | | | | 1415 | | | Accounting | 1416 | | 12|<------------->| 1417 | | | | 1418 | | Send DHCPv6 Reply | | 1419 | 13|<----to UP via Si-------| | 1420 | | | | 1421 | DHCPv6 Reply | | | 1422 14|<--------------| | | 1423 | | | | 1425 Figure 17: DHCPv6 + SLAAC Access 1427 When a subscriber passes AAA authentication, the CP will create a 1428 subscriber session on the UP. This is achieved by sending an 1429 Update_Request message to the UP (step 4). 1431 ::= 1432 1433 1434 1435 [] 1437 The UP will reply with an Update_Response message (step 5). The 1438 format of the Update_Response is as follows: 1440 ::= 1441 1443 After receiving a DHCPv6 Solicit, the CP will update the subscriber 1444 session by sending an Update_Request message with new parameters to 1445 the UP (Step 10). 1447 The format of the Update_Request message is as follows: 1449 ::= 1450 1451 1452 1453 [] 1455 The UP will reply with an Update_Response message (step 11). The 1456 format of the Update_Response is as follows: 1458 ::= 1459 1461 5.1.5. DHCP Dual Stack Access 1463 The following sequence is a combination of DHCP IPv4 and DHCP IPv6 1464 access processes. 1466 RG UP CP AAA 1467 | | | | 1468 | DHCP Discovery| | | 1469 1|-------------->| | | 1470 | |Relay the DHCP Discovery| | 1471 | 2|-----to CP via Si------>| AAA | 1472 | | | Req/Resp | 1473 | | 3|<------------->| 1474 | | | | 1475 | | Send the DHCP Offer | | 1476 | 4|<----to UP vis Si-------| | 1477 | DHCP Offer | | | 1478 5|<--------------| | | 1479 | DHCP Request | | | 1480 6|-------------->| | | 1481 | | Relay the DHCP Request| | 1482 | 7|-----to CP via Si------>| | 1483 | | | | 1484 | | Create subscriber | | 1485 | | session Request | | 1486 | 8|<--------via Ci-------->| | 1487 | | Create subscriber | | 1488 | | session Response | | 1489 | 9|---------via Ci-------->| | 1490 | | | Accounting | 1491 | | 10|<------------->| 1492 | | Send DHCP ACK | | 1493 | 11|<----to UP via Si-------| | 1494 | | | | 1495 | DHCP ACK | | | 1496 12|<--------------| | | 1497 | RS | | | 1498 13|-------------->| | | 1499 | | Relay the Router | | 1500 | | Solicit (RA) | | 1501 | 14|-----to CP via Si------>| AAA | 1502 | | | Req/Rep | 1503 | | 15|<------------->| 1504 | | | | 1505 | | Create subscriber | | 1506 | | session Request | | 1507 | 16|<--------via Ci---------| | 1508 | | Create subscriber | | 1509 | | session Response | | 1510 | 17|---------via Ci-------->| | 1511 | | | | 1512 | | Send Router Advertise | | 1513 | | (RA) | | 1514 | 18|<----to UP vis Si-------| | 1515 | RA | | | 1516 19|<--------------| | | 1517 | | | | 1518 |DHCPv6 Solicit | | | 1519 20|-------------->| | | 1520 | | Relay DHCPv6 Solicit | | 1521 | 21|-----to CP via Si------>| | 1522 | | | | 1523 | | Update subscriber | | 1524 | | session Request | | 1525 | 22|<--------via Ci---------| | 1526 | | Update subscriber | | 1527 | | session Response | | 1528 | 23|---------via Ci-------->| | 1529 | | | Accounting | 1530 | | 24|<------------->| 1531 | | Send DHCPv6 Reply | | 1532 | 25|<----to UP via Si-------| | 1533 | DHCPv6 Reply | | | 1534 26|<--------------| | | 1535 | | | | 1537 Figure 18: DHCP Dual Stack Access 1539 The DHCP dual stack access includes three sets of Update_Request / 1540 Update_Response exchanges to create/update DHCPv4/v6 subscriber 1541 session. 1543 1. Create a DHCPv4 session (step 8 and 9) 1545 ::= 1546 1547 1548 1549 [] 1551 ::= 1552 1553 [] 1555 2. Create a DHCPv6 session (step 16 and 17) 1557 ::= 1558 1559 1560 1561 [] 1563 ::= 1564 1566 3. Update DHCPv6 session (step 22 and 23) 1568 ::= 1569 1570 1571 1572 [] 1574 ::= 1575 1577 5.1.6. L2 Static Subscriber Access 1579 L2 static subscriber access processes are as follows: 1581 RG UP CP AAA 1582 | | | | 1583 | | Static Subscriber | | 1584 | | Detection Req. | | 1585 | 1|<-----to UP via Ci------| | 1586 | | Static Subscriber | | 1587 | | Detection Rep. | | 1588 | 2|------to UP via Ci----->| | 1589 | ARP/ND(REQ) | | | 1590 3.1|<--------------| | | 1591 | ARP/ND(ACK) | | | 1592 3.2|-------------->| | | 1593 | | Relay the ARP/ND | | 1594 | 3.3|-----to CP via Si------>| AAA | 1595 | | | Req/Rep | 1596 | | 3.4|<------------->| 1597 | | Create subscriber | | 1598 | | session Request | | 1599 | 3.5|<--------via Ci---------| | 1600 | | Create subscriber | | 1601 | | session Response | | 1602 | 3.6|---------via Ci-------->| | 1603 | | | | 1604 | ARP/ND(REQ) | | | 1605 4.1|-------------->| | | 1606 | | Relay the ARP/ND | | 1607 | 4.2|-----to CP via Si------>| AAA | 1608 | | | Req/Rep | 1609 | | 4.3|<------------->| 1610 | | Create subscriber | | 1611 | | session Request | | 1612 | 4.4|<--------via Ci---------| | 1613 | | Create subscriber | | 1614 | | session Response | | 1615 | 4.5|---------via Ci-------->| | 1616 | ARP/ND(ACK) | | | 1617 4.6|<--------------| | | 1618 | | | | 1619 | IP Traffic | | | 1620 5.1|-------------->| | | 1621 | | Relay the IP Traffic | | 1622 | 5.2|-----to CP via Si------>| AAA | 1623 | | | Req/Rep | 1624 | | 5.3|<------------->| 1625 | | Create subscriber | | 1626 | | session Request | | 1627 | 5.4|<--------via Ci-------->| | 1628 | | Create subscriber | | 1629 | | session Response | | 1630 | 5.5|---------via Ci-------->| | 1631 | | | | 1632 | ARP/ND(REQ) | | | 1633 5.6|<--------------| | | 1634 | ARP/ND(ACK) | | | 1635 5.7|-------------->| | | 1636 | | | | 1638 Figure 19: L2 Static Subscriber Access 1640 For L2 static subscriber access, the process starts with a CP 1641 installing a static subscriber detection list on a UP. The list 1642 determines which subscribers will be detected. That is implemented 1643 by exchanging Update_Request and Update_Response messages between CP 1644 and UP. The format of the messages are as follows: 1646 ::= 1647 1648 1650 ::= 1651 1653 For L2 Static subscriber access, there are three ways to trigger the 1654 access process: 1656 1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP 1657 address, the access interface, and VLAN of the RG. The UP will 1658 actively trigger the access flow by sending an ARP/ND packet to 1659 the RG. If the RG is online, it will reply with an ARP/ND to the 1660 UP. The UP will tunnel the ARP/ND to the CP through the Si. The 1661 CP then triggers the authentication process. If the 1662 authentication result is positive. The CP will create a 1663 corresponding subscriber session on the UP. 1665 2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as 1666 option 1 (triggered by UP). The difference is that the RG will 1667 actively send the ARP/ND to trigger the process. 1669 3. Triggered by RG IP traffic (5.1-5.7): This is for the case where 1670 the RG has the ARP/ND information, but the subscriber session on 1671 the UP is lost (e.g., due to failure on the UP, or the UP 1672 restarted). That means the RG may keep sending IP packets to the 1673 UP. The packets will trigger the UP to start a new access 1674 process. 1676 From a subscriber session point of view, the procedures and the 1677 message formats for the above three cases are the same, as follows: 1679 IPv4 Case: 1680 ::= 1681 1682 1683 1684 [] 1686 ::= 1687 1688 [] 1690 IPv6 Case: 1691 ::= 1692 1693 1694 1695 [] 1697 ::= 1698 1700 5.2. PPPoE 1702 5.2.1. IPv4 PPPoE Access 1704 The following figure shows the IPv4 PPPoE access call flow. 1706 RG UP CP AAA 1707 | | | | 1708 | PPPoE Disc | PPPoE Disc | | 1709 1|<------------->|<---------via Si------->| | 1710 | | | | 1711 | PPP LCP | PPP LCP | | 1712 2|<------------->|<---------via Si------->| | 1713 | | | AAA | 1714 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1715 3|<------------->|<---------via Si------->|<------------->| 1716 | | | | 1717 | PPP IPCP | PPP IPCP | | 1718 4|<------------->|<---------via Si------->| | 1719 | | | | 1720 | | Create subscriber | | 1721 | | session Request | | 1722 | 5|<--------via Ci---------| | 1723 | | | | 1724 | | Create subscriber | | 1725 | | session Response | | 1726 | 6|---------via Ci-------->| | 1727 | | | | 1728 | | | Accounting | 1729 | | 7|<------------->| 1730 | | | | 1732 Figure 20: IPv4 PPPoE Access 1734 From the above sequence, step 1-4 are the standard PPPoE call flow. 1735 The UP is responsible for redirecting the PPPoE control packets to 1736 the CP or RG. The PPPoE control packets are transmitted between the 1737 CP and UP through the Si. 1739 After the PPPoE call flow, if the subscriber passed the AAA 1740 authentication and authorization, the CP will create a corresponding 1741 session on the UP through the Ci. The formats of the messages are as 1742 follows: 1744 ::= 1745 1746 1747 1748 1749 [] 1751 ::= 1752 1753 [] 1755 5.2.2. IPv6 PPPoE Access 1757 The following figure describes the IPv6 PPPoE access call flow. 1759 RG UP CP AAA 1760 | | | | 1761 | PPPoE Disc | PPPoE Disc | | 1762 1|<------------->|<--------via Si-------->| | 1763 | | | | 1764 | PPP LCP | PPP LCP | | 1765 2|<------------->|<---------via Si------->| | 1766 | | | AAA | 1767 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1768 3|<------------->|<---------via Si------->|<------------->| 1769 | | | | 1770 | PPP IP6CP | PPP IP6CP | | 1771 4|<------------->|<---------via Si------->| | 1772 | | | | 1773 | | Create subscriber | | 1774 | | session Request | | 1775 | 5|<--------via Ci---------| | 1776 | | | | 1777 | | Create subscriber | | 1778 | | session Response | | 1779 | 6|---------via Ci-------->| | 1780 | | | | 1781 | ND Negotiation| ND Negotiation | | 1782 7|<------------->|<---------via Si------->| | 1783 | | | | 1784 | | Update subscriber | | 1785 | | session Request | | 1786 | 8|<--------via Ci---------| | 1787 | | | | 1788 | | Update subscriber | | 1789 | | session Response | | 1790 | 9|---------via Ci-------->| | 1791 | | | | 1792 | | | Accounting | 1793 | | 10|<------------->| 1794 | | | | 1795 | DHCPv6 | DHCPv6 | | 1796 | Negotiation | Negotiation | | 1797 7'|<------------->|<---------via Si------->| | 1798 | | | | 1799 | | Update subscriber | | 1800 | | session Request | | 1801 | 8'|<---------via Ci--------| | 1802 | | | | 1803 | | Update subscriber | | 1804 | | session Response | | 1805 | 9'|---------via Ci-------->| | 1806 | | | | 1807 | | | Accounting | 1808 | | 10'|<------------->| 1809 | | | | 1811 Figure 21: IPv6 PPPoE Access 1813 From the above sequence, steps 1-4 are the standard PPPoE call flow. 1814 The UP is responsible for redirecting the PPPoE control packets to 1815 the CP or RG. The PPPoE control packets are transmitted between the 1816 CP and UP through the Si. 1818 After the PPPoE call flow, if the subscriber passed the AAA 1819 authentication and authorization, the CP will create a corresponding 1820 session on the UP through the Ci. The formats of the messages are as 1821 follows: 1823 ::= 1824 1825 1826 1827 1828 [] 1830 ::= 1831 1833 Then, the RG will initialize an ND/DHCPv6 negotiation process with 1834 the CP (see step 7 and 7'), after that, it will trigger an update 1835 (8-9, 8'-9') to the subscriber session. The formats of the update 1836 messages are as follows: 1838 ::= 1839 1840 1841 1842 1843 [] 1845 ::= 1846 1848 5.2.3. PPPoE Dual Stack Access 1850 The following figure shows a combination of IPv4 and IPv6 PPPoE 1851 access call flow. 1853 RG UP CP AAA 1854 | | | | 1855 |PPPoE Discovery| PPPoE Discovery | | 1856 1|<------------->|<---------via Si------->| | 1857 | | | | 1858 | PPP LCP | PPP LCP | | 1859 2|<------------->|<---------via Si------->| | 1860 | | | AAA | 1861 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1862 3|<------------->|<---------via Si------->|<------------->| 1863 | | | | 1864 | PPP IPCP | PPP IPCP | | 1865 4|<------------->|<---------via Si------->| | 1866 | | | | 1867 | | Create v4 subscriber | | 1868 | | session Request | | 1869 | 5|<--------via Ci---------| | 1870 | | Create v4 subscriber | | 1871 | | session Response | | 1872 | 6|---------via Ci-------->| | 1873 | | | Accounting | 1874 | | 7|<------------->| 1875 | PPP IP6CP | PPP IP6CP | | 1876 4'|<------------->|<---------via Si------->| | 1877 | | | | 1878 | | Create V6 subscriber | | 1879 | | session Request | | 1880 | 5'|<--------via Ci---------| | 1881 | | Create v6 subscriber | | 1882 | | session Response | | 1883 | 6'|---------via Ci-------->| | 1884 | | | | 1885 | ND Negotiation| ND Negotiation | | 1887 8|<------------->|<---------via Si------->| | 1888 | | | | 1889 | | Update v6 subscriber | | 1890 | | session Request | | 1891 | 9|<---------via Ci--------| | 1892 | | Update v6 subscriber | | 1893 | | session Response | | 1894 | 10|---------via Ci-------->| | 1895 | | | Accounting | 1896 | | 7'|<------------->| 1897 | DHCPv6 | DHCPv6 | | 1898 | Negotiation | Negotiation | | 1899 8'|<------------->|<---------via Si------->| | 1900 | | | | 1901 | | Update v6 subscriber | | 1902 | | session Request | | 1903 | 9'|<--------via Ci---------| | 1904 | | | | 1905 | | Update v6 subscriber | | 1906 | | session Response | | 1907 | 10'|---------via Ci-------->| | 1908 | | | | 1909 | | | Accounting | 1910 | | 7"|<------------->| 1911 | | | | 1913 Figure 22: PPPoE Dual Stack Access 1915 PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE 1916 access. The process is as above. The formats of the messages are as 1917 follows: 1919 1. Create an IPv4 PPPoE subscriber session (5-6) 1921 ::= 1922 1923 1924 1925 1926 [] 1928 ::= 1929 1930 [] 1932 2. Create an IPv6 PPPoE subscriber session (5'-6') 1934 ::= 1935 1936 1937 1938 1939 [] 1941 ::= 1942 1944 3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10') 1946 ::= 1947 1948 1949 1950 1951 [] 1953 ::= 1954 1956 5.3. WLAN Access 1958 The following figure shows the WLAN access call flow. 1960 RG UP CP AAA WEB Server 1961 | | | | | 1962 | DHCP | | | | 1963 | Discovery | | | | 1964 1|------------>| | | | 1965 | | DHCP | | | 1966 | | Discovery | | | 1967 | 2|-----via Si---->| AAA | | 1968 | | DHCP Offer |<-------->| | 1969 | 3|<----via Si-----| | | 1970 | DHCP Offer | | | | 1971 4|<------------| | | | 1972 | DHCP | | | | 1973 | Request | | | | 1974 5|------------>| | | | 1975 | | DHCP Request | | | 1976 | 6|-----via Si---->| | | 1977 | | | | | 1978 | | Create session | | | 1979 | | Request | | | 1980 | 7|<----via Ci-----| | | 1981 | | Create session | | | 1982 | | Response | | | 1983 | 8|----via Ci----->| | | 1984 | | | | | 1985 | | DHCP ACK | | | 1986 | 9|<----via Si-----| | | 1987 | | | | | 1988 | DHCP ACK | | | | 1989 10|<------------| | | | 1990 | | | | | 1991 | Subscriber | | | | 1992 | HTTP Traffic| | | | 1993 11|------------>|--> | | | 1994 | | | WEB URL | | | 1995 | Traffic | | Redirect | | | 1996 | Redirection | | | | | 1997 12|<------------|<-+ | | | 1998 | | | | 1999 | | 2000 13|-----------------Redirect to Web server------------->| 2001 | | 2002 14|<----------------Push HTTP log-in page---------------| 2003 | | 2004 15|-----------------User Authentication---------------->| 2005 | | 2006 | | | Portal Interchange | 2007 | | 16|<-------------------->| 2008 | | | | 2009 | | | AAA | | 2010 | | | Req/Rep | | 2011 | | 17|<-------->| | 2012 | | | | | 2013 | | Update session | | | 2014 | | Request | | | 2015 | 18|<----via Ci-----| | | 2016 | | | | | 2017 | | Update session | | | 2018 | | Response | | | 2019 | 19|-----via Ci---->| | | 2020 | | | | | 2022 Figure 23: WLAN Access 2024 WLAN access starts with the DHCP dial-up process (steps 1-6), after 2025 that the CP will create a subscriber session on the UP (steps 7-8). 2026 The formats of the session creation messages are as follows: 2028 IPv4 Case: 2029 ::= 2030 2031 2032 2033 [] 2035 ::= 2036 2037 [] 2039 IPv6 Case: 2040 ::= 2041 2042 2043 2044 [] 2046 ::= 2047 2049 After step 10, the RG will be allocated an IP address and its first 2050 HTTP packet will be redirected to a WEB server for subscriber 2051 authentication (steps 11-17). After the WEB authentication, if the 2052 result is positive, the CP will update the subscriber session by 2053 using the following message exchanges: 2055 IPv4 Case: ::= 2056 2057 2058 2059 [] 2061 ::= 2062 2063 [] 2065 IPv6 Case: ::= 2066 2067 2068 2069 [] 2071 ::= 2072 2074 5.4. L2TP 2076 5.4.1. L2TP LAC Access 2078 RG UP(LAC) CP(LAC) AAA LNS 2079 | | | | | 2080 | PPPoE | PPPoE | | | 2081 | Discovery | Discovery | | | 2082 1|<---------->|<---via Si--->| | | 2083 | | | | | 2084 | PPP LCP | PPP LCP | | | 2085 2|<---------->|<---via Si--->| | | 2086 | | | AAA | | 2087 |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| | 2088 3|<---------->|<---via Si--->|<------>| | 2089 | | | | | 2090 | PPP IPCP | PPP IPCP | | | 2091 4|<---------->|<---via Si--->| | | 2092 | | | | | 2093 | | L2TP tunnel | | | 2094 | | negotiation | | | 2095 | | SCCRQ/ | | | 2096 | | SCCRP/ | | | 2097 | | SCCCN | | | 2098 | 5|<---via Si--->| | | 2099 | | /\ | 2100 | | || forward | 2101 | | \/ | 2102 | |<-----------via routing---------->| 2103 | | | 2104 | | L2TP session | | | 2105 | | negotiation | | | 2106 | | ICRQ/ | | | 2107 | | ICRP/ | | | 2108 | | ICCN | | | 2109 | 6|<---via Si--->| | | 2110 | | /\ | 2111 | | || forward | 2112 | | \/ | 2113 | |<-----------via routing---------->| 2114 | | | 2115 | | Create | | | 2116 | | subscriber | | | 2117 | | session | | | 2118 | | Request | | | 2119 | 7|<---via Ci----| | | 2120 | | | | | 2121 | | Create | | | 2122 | | subscriber | | | 2123 | | session | | | 2124 | | Response | | | 2125 | 8|----via Ci--->| | | 2126 | | | | | 2127 | | 2128 | PAP/CHAP (Triggered by LNS) | 2129 9|<-----------------via routing?---------------->| 2130 | | 2132 Figure 24: L2TP-LAC Access 2134 Steps 1-4 are a standard PPPoE access process. After that, the LAC- 2135 CP starts to negotiate an L2TP session and tunnel with the LNS. 2136 After the negotiation, the CP will create an L2TP LAC subscriber 2137 session on the UP through the following messages: 2139 ::= 2140 2141 2142 2144 ::= 2145 2147 5.4.2. L2TP LNS IPv4 Access 2149 RG LAC UP(LNS) AAA CP(LNS) 2150 | | | | | 2151 | PPPoE | | | | 2152 | Discovery | | | | 2153 1|<---------->| | | | 2154 | | | | | 2155 | PPP LCP | | | | 2156 2|<---------->| | | 2157 | | AAA | | 2158 |PPP PAP/CHAP| Req/Rep | | 2159 3|<---------->|<--------------------->| | 2160 | | | 2161 | | | 2162 | | L2TP tunnel | L2TP tunnel | 2163 | | negotiation | negotiation | 2164 | | SCCRQ/ | SCCRQ/ | 2165 | | SCCRP/ | SCCRP/ | 2166 | | SCCCN | SCCCN | 2167 | 4|<------------>|<------via Si----->| 2168 | | | | 2169 | | L2TP session | L2TP session | 2170 | | negotiation | negotiation | 2171 | | ICRQ/ | ICRQ/ | 2172 | | ICRP/ | ICRP/ | 2173 | | ICCN | ICCN | 2174 | 5|<------------>|<------via Si----->| 2175 | | | | 2176 | | | Create | 2177 | | | subscriber | 2178 | | | session | 2179 | | | Request | 2180 | | 6|<-----via Ci-------| 2181 | | | Create | 2182 | | | subscriber | 2183 | | | session | 2184 | | | Response | 2185 | | 7|------via Ci------>| 2186 | | 2187 | PAP/CHAP (Triggered by LNS) | 2188 8|<--------------------------------------------->| 2189 | | 2190 | | | | AAA | 2191 | | | | Req/Rep | 2192 | | | 9|<-------->| 2193 | | | | 2194 | | 2195 | PPP IPCP | 2196 10|<--------------------------------------------->| 2197 | | 2198 | | | Update | 2199 | | | subscriber | 2200 | | | session | 2201 | | | Request | 2202 | | 11|<-----via Ci-------| 2203 | | | Update | 2204 | | | subscriber | 2205 | | | session | 2206 | | | Response | 2207 | | 12|------via Ci------>| 2208 | | | | 2210 Figure 25: IPv4 L2TP-LNS Access 2212 In this case, the BNG is running as an LNS and separated into LNS-CP 2213 and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When 2214 the L2TP session and tunnel negotiations are finished, the LNS-CP 2215 will create an L2TP LNS subscriber session on the LNS-UP. The format 2216 of the messages is as follows: 2218 ::= 2219 2220 2221 2222 2223 2224 2225 [] 2227 ::= 2228 2229 [] 2231 After that, the LNS-CP will trigger an AAA authentication. If the 2232 authentication result is positive, a PPP IPCP process will follow, 2233 then the CP will update the session with the following message 2234 exchanges: 2236 ::= 2237 2238 2239 2240 2241 2242 2243 [] 2245 ::= 2246 2247 [] 2249 5.4.3. L2TP LNS IPv6 Access 2251 RG LAC UP(LNS) AAA CP(LNS) 2252 | | | | | 2253 | PPPoE | | | | 2254 | Discovery | | | | 2255 1|<---------->| | | | 2256 | | | | | 2257 | PPP LCP | | | | 2258 2|<---------->| | | 2259 | | AAA | | 2260 |PPP PAP/CHAP| Req/Rep | | 2261 3|<---------->|<--------------------->| | 2262 | | | 2263 | | | 2264 | | L2TP tunnel | L2TP tunnel | 2265 | | negotiation | negotiation | 2266 | | SCCRQ/ | SCCRQ/ | 2267 | | SCCRP/ | SCCRP/ | 2268 | | SCCCN | SCCCN | 2269 | 4|<------------>|<------via Si----->| 2270 | | | | 2271 | | L2TP session | L2TP session | 2272 | | negotiation | negotiation | 2273 | | ICRQ/ | ICRQ/ | 2274 | | ICRP/ | ICRP/ | 2275 | | ICCN | ICCN | 2276 | 5|<------------>|<------via Si----->| 2277 | | | | 2278 | | | Create | 2279 | | | subscriber | 2280 | | | session | 2281 | | | Request | 2282 | | 6|<-----via Ci-------| 2283 | | | Create | 2284 | | | subscriber | 2285 | | | session | 2286 | | | Response | 2287 | | 7|------via Ci------>| 2288 | | 2289 | PAP/CHAP (Triggered by LNS) | 2290 8|<--------------------------------------------->| 2291 | | 2292 | | | | AAA | 2293 | | | | Req/Rep | 2294 | | | 9|<-------->| 2295 | | | | | 2296 | | 2297 | PPP IP6CP | 2298 10|<--------------------------------------------->| 2299 | | 2300 | | | Update | 2301 | | | subscriber | 2302 | | | session | 2303 | | | Request | 2304 | | 11|<-----via Ci-------| 2305 | | | Update | 2306 | | | subscriber | 2307 | | | session | 2308 | | | Response | 2309 | | 12|------via Ci------>| 2310 | | | | 2311 | | | 2312 | ND negotiation | ND negotiation | 2313 13|<------------------------->|<-----via Si------>| 2314 | | | 2315 | | | Update | 2316 | | | subscriber | 2317 | | | session | 2318 | | | Request | 2319 | | 14|<-----via Ci-------| 2320 | | | Update | 2321 | | | subscriber | 2322 | | | session | 2323 | | | Response | 2324 | | 15|------via Ci------>| 2325 | | | | 2327 Figure 26: L2TP-LNS IPv6 Access 2329 Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5 2330 finish the normal L2TP dial-up process. When the L2TP session and 2331 tunnel negotiations are finished, the LNS-CP will create an L2TP LNS 2332 subscriber session on the LNS-UP. The format of the messages is as 2333 follows: 2335 ::= 2336 2337 2338 2339 2340 2341 2342 [] 2344 ::= 2345 2347 After that, the LNS-CP will trigger a AAA authentication. If the 2348 authentication result is positive, a PPP IP6CP process will follow, 2349 then the CP will update the session with the following message 2350 exchanges: 2352 ::= 2353 2354 2355 2356 2357 2358 2359 [] 2361 ::= 2362 2364 Then, an ND negotiation will be triggered by the RG. After the ND 2365 negotiation, the CP will update the session with the following 2366 message exchanges: 2368 ::= 2369 2370 2371 2372 2373 2374 2375 [] 2377 ::= 2378 2380 5.5. CGN (Carrier Grade NAT) 2382 RG UP CP AAA 2383 | | | | 2384 | | Public Address Block | | 2385 | | Allocation Request | | 2386 | 1|<--------via Ci-------->| | 2387 | | Public Address Block | | 2388 | | Allocation Reply | | 2389 | 2|---------via Ci-------->| | 2390 | | | | 2391 | Subscriber | | | 2392 | access request| Subscriber | | 2393 3|-------------->| access request | | 2394 | 4|----------via Si------->| | 2395 | | | AAA | 2396 | | Subscriber | Req/Rep | 2397 | Subscriber | access reply 5|<------------->| 2398 | access reply 6|<---------via Si--------| | 2399 7|<--------------| | | 2400 | | | | 2401 | | Create subscriber | | 2402 | | session Request | | 2403 | 8|<--------via Ci---------| | 2404 | | | | 2405 | | Create subscriber | | 2406 | | session Response | | 2407 | | (with NAT information) | | 2408 | 9|---------via Ci-------->| | 2409 | | | | 2410 | | | Accounting | 2411 | | | with source | 2412 | | | information | 2413 | | 10|<------------->| 2414 | | | Public IP + | 2415 | | | Port range | 2416 | | | to Private IP| 2417 | | | mapping | 2418 | | | | 2420 Figure 27: CGN Access 2422 The first steps allocate one or more CGN address blocks to the UP 2423 (steps 1-2). This is achieved by the following message exchanges 2424 between CP and UP. 2426 ::= 2427 2429 ::= 2430
2432 Steps 3-9 show the general dial-up process in the case of CGN mode. 2433 The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in 2434 above sections. 2436 If a subscriber is a CGN subscriber, once the subscriber session is 2437 created/updated, the UP will report the NAT information to the CP. 2438 This is achieved by carrying the "Subscriber CGN Port Range TLV" in 2439 the Update_Response message. 2441 5.6. L3 Leased Line Access 2443 5.6.1. Web Authentication 2445 RG UP CP AAA WEB Server 2446 | | | | | 2447 | User | | | | 2448 | traffic | | | | 2449 1|------------>| | | | 2450 | | User | | | 2451 | | traffic | | | 2452 | 2|-----via Si---->| AAA | | 2453 | | | Req/Rep | | 2454 | | 3|<-------->| | 2455 | | Create session | | | 2456 | | Request | | | 2457 | 4|<----via Ci-----| | | 2458 | | | | | 2459 | | Create session | | | 2460 | | Response | | | 2461 | 5|----via Ci----->| | | 2462 | HTTP | | | | 2463 | traffic | | | | 2464 6|------------>| | | | 2465 | | | | | 2466 | Redirect to | | | | 2467 | Web URL | | | | 2468 7|<------------| | | | 2469 | | | | | 2470 | | 2471 8|-----------------Redirected to Web server----------->| 2472 | | 2473 9|<----------------Push HTTP Log-in page---------------| 2474 | | 2475 10|-----------------User Authentication---------------->| 2476 | | 2477 | | | Portal Interchange | 2478 | | 11|<-------------------->| 2479 | | | | 2480 | | | AAA | | 2481 | | | Req/Rep | | 2482 | | 12|<-------->| | 2483 | | | | | 2484 | | | | | 2485 | | Update session | | | 2486 | | Request | | | 2487 | 13|<----via Ci-----| | | 2488 | | | | | 2489 | | Update session | | | 2490 | | Response | | | 2491 | 14|----via Ci----->| | | 2492 | | | | | 2494 Figure 28: Web Authentication based L3 Leased Line Access 2496 In this case, IP traffic from the RG will trigger the CP to 2497 authenticate the RG by checking the source IP and the exchanges with 2498 the AAA server. Once the RG passed the authentication, the CP will 2499 create a corresponding subscriber session on the UP through the 2500 following message exchanges: 2502 IPv4 Case: 2503 ::= 2504 2505 2506 2507 [] 2509 ::= 2510 2511 [] 2513 IPv6 Case: 2514 ::= 2515 2516 2517 2518 [] 2520 ::= 2521 2523 Then, the HTTP traffic from the RG will be redirected to a WEB server 2524 to finish the WEB authentication. Once the WEB authentication is 2525 passed, the CP will trigger another AAA authentication. After the 2526 AAA authentication, the CP will update the session with the following 2527 message exchanges: 2529 IPv4 Case: 2530 ::= 2531 2532 2533 2534 [] 2536 ::= 2537 2538 [] 2540 IPv6 Case: 2541 ::= 2542 2543 2544 2545 [] 2547 ::= 2548 2550 5.6.2. User Traffic Trigger 2552 RG UP CP AAA 2553 | | | | 2554 | | L3 access | | 2555 | | control list | | 2556 | 1|<----via Ci-----| | 2557 | User | | | 2558 | traffic | | | 2559 2|------------>| | | 2560 | | User | | 2561 | | traffic | | 2562 | 3|-----via Si---->| | 2563 | | | AAA | 2564 | | | Req/Rep | 2565 | | 4|<-------->| 2566 | | | | 2567 | | Create session | | 2568 | | Request | | 2569 | 5|<----via Ci-----| | 2570 | | Create session | | 2571 | | Response | | 2572 | 6|----via Ci----->| | 2573 | | | | 2575 Figure 29: User Traffic Triggered L3 Leased Line Access 2577 In this user traffic triggered case, the CP must install an access 2578 control list on the UP, which is used by the UP to determine whether 2579 an RG is legal or not. If the traffic is from a legal RG, it will be 2580 redirected to the CP though the Si. The CP will trigger a AAA 2581 interchange with the AAA server. After that, the CP will create a 2582 corresponding subscriber session on the UP with the following message 2583 exchanges: 2585 IPv4 Case: 2586 ::= 2587 2588 2589 2590 [] 2592 ::= 2593 2594 [] 2596 IPv6 Case: 2597 ::= 2598 2599 2600 2601 [] 2603 ::= 2604 2606 5.7. Multicast Service Access 2608 RG UP CP AAA 2609 | | | | 2610 | User access | User access | AAA | 2611 | request | request | Req/Rep | 2612 1|<----------->|<----via Si---->|<-------->| 2613 | | User | | 2614 | | | | 2615 | | | | 2616 | | Create session | | 2617 | | Request | | 2618 | 2|<----via Ci---->| | 2619 | | | | 2620 | | Create session | | 2621 | | Response | | 2622 | 3|----via Ci----->| | 2623 | | | | 2624 | Multicast | | | 2625 | negotiation | | | 2626 4|<----------->| | | 2627 | | | | 2629 Figure 30: Multicast Access 2631 Multicast access starts with a user access request from the RG. The 2632 request will be redirected to the CP by the Si. A follow-up AAA 2633 interchange between the CP and the AAA server will be triggered. 2634 After the authentication, the CP will create a multicast subscriber 2635 session on the UP through the following messages: 2637 IPv4 Case: 2638 ::= 2639 2640 2641 2642 2643 [] 2645 ::= 2646 2647 [] 2649 IPv6 Case: 2650 ::= 2651 2652 2653 2654 2655 [] 2657 ::= 2658 2660 6. S-CUSP Message Formats 2662 An S-CUSP message consists of a common header followed by a variable- 2663 length body consisting entirely of TLVs. Receiving an S-CUSP message 2664 with an unknown message type or missing mandatory TLV MUST trigger an 2665 Error message (see Section 6.7) or a response message with an Error 2666 Information TLV (see Section 7.6). 2668 Conversely, if a TLV is optional, the TLV may or may not be present. 2669 Optional TLVs are indicated in the message formats shown in this 2670 document by being enclosed in square brackets. 2672 This section specifies the format of the common S-CUSP message header 2673 and lists the defined messages. 2675 Network byte order is used for all multi-byte fields. 2677 6.1. Common Message Header 2679 S-CUSP Common Message Header: 2680 0 1 2 3 2681 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 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | Ver | Resv | Message-Type | Message-Length | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | Reserved | Transaction-ID | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 Figure 6.1: S-CUSP Message Common Header 2690 o Ver (4 bits): The major version of the protocol. This document 2691 specifies version 1. Different major versions of the protocol 2692 may have significantly different message structure and format 2693 except that the Ver field will always be in the same place at 2694 the beginning of each message. A successful S-CUSP session 2695 depends on the CP and the UP both using the same major version 2696 of the protocol. 2698 o Resv (4 bits): Reserved. MUST be sent as zero and ignored on 2699 receipt. 2701 o Message-Type (8 bits): The set of message types specified in 2702 this document is listed in Section 9.1. 2704 o Message-Length (16 bits): Total length of the S-CUSP message 2705 including the common header, expressed in number of bytes as an 2706 unsigned integer. 2708 o Transaction ID (16 bits): This field is used to identify 2709 requests. It is echoed back in any corresponding 2710 ACK/Response/Error message. It is RECOMMENDED that a 2711 monotonically increasing value be used in successive message 2712 and that value wrap back to zero after 0xFFFF. The contents of 2713 this field is an opaque value that the receiver MUST NOT use 2714 for any purpose except to echo back in a corresponding response 2715 and, optionally, for logging. 2717 6.2. Control Messages 2719 This document defines the following control messages: 2721 Type Name Notes and TLVs that can be carried 2722 ---- ---- ------------------------------------ 2723 1 Hello Hello TLV, Keepalive TLV. 2724 2 Keepalive A common header with the Keepalive message 2725 type. 2726 3 Sync_Request Synchronization request. 2727 4 Sync_Begin Synchronization starts. 2728 5 Sync_Data Synchronization data: TLVs specified in 2729 Section 5. 2730 6 Sync_End End synchronization. 2731 7 Update_Request TLVs specified in Sections 7.6-7.9. 2732 8 Update_Response TLVs specified in Sections 7.6-7.9. 2734 6.2.1. Hello Message 2736 Hello message is used for S-CUSP session establishment and version 2737 negotiation. The detail of S-CUSP session establishment and version 2738 negotiation can be found in Section 4.1.1. 2740 The format of Hello message is as follows: 2742 ::= 2743 2744 2745 [] 2747 The return code and negotiation result will be carried in the Error 2748 Information TLV. They are listed as follows: 2750 0: Success, version negotiation success. 2752 1: Failure, malformed message received. 2754 2: One or more of the TLVs was not understood. 2756 1001: The version negotiation fails. The S-CUSP session 2757 establishment phase fails. 2759 1002: The keepalive negotiation fails. The S-CUSP session 2760 establishment phase fails. 2762 1003: The establishment timer expires. session establishment 2763 phase fails. 2765 6.2.2. Keepalive Message 2767 Each end of an S-CUSP session periodically sends a Keepalive message. 2768 It is used to detect whether the peer end is still alive. The 2769 Keepalive procedures are defined in Section 4.1.2. 2771 The format of the Keepalive message is as follows: 2773 ::= 2775 6.2.3. Sync_Request Message 2777 The Sync_Request message is used to request synchronization from an 2778 S-CUSP peer. Both CP and UP can request their peer to synchronize 2779 data. 2781 The format of the Sync_Request message is as follows: 2783 ::= 2785 A Sync_Request message may result in a Sync_Begin message from its 2786 peer. The Sync_Begin message is defined in Section 6.2.4. 2788 6.2.4. Sync_Begin Message 2790 The Sync_Begin message is a reply to a Sync_Request message. It is 2791 used to notify the synchronization requester whether the 2792 synchronization can be started. 2794 The format of Sync_Begin message is as follows: 2796 ::= 2797 2799 The return codes are carried in the Error Information TLV. The codes 2800 are listed below: 2802 0: Success, be ready to synchronize. 2804 1: Failure, malformed message received. 2806 2: One or more of the TLVs was not understood. 2808 2001: Synch-NoReady. The data to be synchronized is not ready. 2810 2002: Synch-Unsupport. The data synchronization is not supported. 2812 6.2.5. Sync_Data Message 2814 The Sync_Data message is used to send data being synchronized between 2815 the CP and UP. The Sync_Data message has the same function and 2816 format as the Update_Request message. The difference is that there 2817 is no ACK for a Sync_Data message. An error caused by the Sync_Data 2818 message will result in a Sync_End message. 2820 There are two scenarios: 2822 Synchronization from UP to CP: Synchronize the resource data to 2823 CP. 2825 ::= 2826 [] 2828 Synchronization from CP to UP: Synchronize all subscriber sessions 2829 to UP. As for which TLVs should be carried, it depends on the 2830 specific session data to be synchronized. The process is 2831 equivalent to the creation of a particular session. Refer to 2832 Section 5 to see more details. 2834 ::= 2835 [] 2837 [] 2838 [] 2839 [] 2840 [] 2842 6.2.6. Sync_End Message 2844 The Sync_End message is used to indicate the end of a synchronization 2845 process. The format of a Sync_End message is as follows: 2847 ::= 2848 2850 The return/error codes are listed as follows: 2852 0: Success, synchronization finished. 2854 1: Failure, malformed message received. 2856 2: One or more of the TLVs was not understood. 2858 6.2.7. Update_Request Message 2860 The Update_Request message is a multi-purpose message, it can be used 2861 to create, update, and delete subscriber sessions on a UP. 2863 For session operations, the specific operation is controlled by the 2864 "Oper" field of the carried TLVs. As defined in Section 7.1, the 2865 "Oper" can be set to either "Update" or "Delete" when a TLV is 2866 carried in an Update_Request message. 2868 When the "Oper" set to Update, it means to create or update a 2869 subscriber session. If the "Oper" set to Delete, it is a request to 2870 delete a corresponding session. 2872 The format of Update_Request message is as follows: 2874 ::= 2875 [] 2876 [] 2877 [] 2878 [] 2879 [] 2881 Each Update_Request message will result in an Update_Response message 2882 that is defined in Section 6.2.8. 2884 6.2.8. Update_Response Message 2886 The Update_Response message is a response to an Update_Request 2887 message. It is used to confirm the update request (or reject it in 2888 the case of an error). The format of an Update_Response message is 2889 as follows: 2891 ::= 2892 [] 2893 2895 The return/error codes are carried in the Error Information TLV. 2896 They are listed as follows: 2898 0: Success. 2900 1: Failure, malformed message received. 2902 2: One or more of the TLVs was not understood. 2904 3001(Pool-Mismatch): The corresponding address pool cannot be 2905 found. 2907 3002 (Pool-Full): The address pool is fully allocated and no 2908 address segment is available. 2910 3003 (Subnet-Mismatch): The address pool subnet cannot be found. 2912 3004 (Subnet-Conflict): Subnets in the address pool have been 2913 classified into other clients. 2915 4001 (Update-Fail-No-Res): The forwarding table fails to be 2916 delivered because the forwarding resources are insufficient. 2918 4002 (QoS-Update-Success): The QoS policy takes effect. 2920 4003 (QoS-Update-Sq-Fail): Failed to process the queue in the QoS 2921 policy. 2923 4004 (QoS-Update-CAR-Fail): Processing of the CAR in the QoS 2924 policy fails. 2926 4005 (Statistic-Fail-No-Res): Statistics processing failed due to 2927 insufficient statistics resources. 2929 6.3. Event Message 2931 The Event message is used to report subscriber session traffic 2932 statistics and detection information. The format of Event message is 2933 as follows: 2935 ::= 2936 [] 2937 [] 2939 6.4. Report Message 2941 The Report message is used to report board and interface status on a 2942 UP. The format of Report message is as follows: 2944 ::= 2945 [] 2946 [] 2948 6.5. CGN Messages 2950 This document defines the following resource allocation messages: 2952 Type Message Name TLV that is carried 2953 ---- ------------------- ------------------------ 2954 200 Addr_Allocation_Req Address Allocation Request 2955 201 Addr_Allocation_Ack Address Allocation Response 2956 202 Addr_Renew_Req Address Renewal Request 2957 203 Addr_Renew_Ack Address Renewal Response 2958 204 Addr_Release_Req Address Release Request 2959 205 Addr_Release_Ack Address Release Response 2961 6.5.1. Addr_Allocation_Req Message 2963 The Addr_Allocation_Req message is used to request CGN address 2964 allocation. The format of Addr_Allocation_Req message is as follows: 2966 ::= 2967
2969 6.5.2. Addr_Allocation_Ack Message 2971 The Addr_Allocation_Ack message is a response to an 2972 Addr_Allocation_Req message. The format of Addr_Allocation_Ack 2973 message is as follows: 2975 ::= 2976
2978 6.5.3. Addr_Renew_Req Message 2980 The Addr_Renew_Req message is used to request address renewal. The 2981 format of Addr_Renew_Req message is as follows: 2983 ::= 2984
2986 6.5.4. Addr_Renew_Ack Message 2988 The Addr_Renew_Ack message is a response to an Addr_Renew_Req 2989 message. The format of Addr_Renew_Req message is as follows: 2991 ::= 2992
2994 6.5.5. Addr_Release_Req Message 2996 The Addr_Release_Req message is used to request address release. The 2997 format of Addr_Release_Req message is as follows: 2999 ::= 3000
3002 6.5.6. Addr_Release_Ack Message 3004 The Addr_Release_Ack message is a response to an Addr_Release_Req 3005 message. The format of Addr_Release_Ack message is as follows: 3007 ::= 3008
3010 6.6. Vendor Message 3012 The Vendor message, in conjunction with the vendor TLV and vendor 3013 sub-TLV, can be used by vendors to extend the S-CUSP protocol. The 3014 message type is 11. If the receiver does not recognize the message, 3015 an Error message will be returned to the sender. 3017 The format of the Vendor message is as follows: 3019 ::= 3020 3021 [] 3023 6.7 Error Message 3025 The Error message is defined to return some critical error 3026 information to the sender. If a receiver does not support the type 3027 of the received message, it MUST return an Error message to the 3028 sender. 3030 The format of the Error message is as below: 3032 ::= 3033 3035 7. S-CUSP TLVs and Sub-TLVs 3037 This section specifies the following: 3039 o the format of the TLVs that appear in S-CUSP messages, 3041 o the format of the sub-TLVs that appear within the values of some 3042 TLVs, and 3044 o the format of some basic data fields that appear within TLVs or 3045 sub-TLVs. 3047 See Section 9 for a list of all defined TLVs and sub-TLVs. 3049 7.1. Common TLV Header 3051 S-CUSP messages consist of the common header specified in Section 6.1 3052 followed by TLVs formatted as specified in this section. 3054 0 1 2 3 3055 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 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 | Oper | TLV-Type | TLV-Length | 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 ~ Value ~ 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 Figure 32: Common TLV Header 3064 o Oper (4 bits): For Message-Types that specify an operation on a 3065 data set, the Oper field is interpreted as Update, Delete, or 3066 Reserved as specified in Section 9.3. For all other Message-Types, 3067 the Oper field MUST be sent as zero and ignored on receipt. 3069 o TLV-Type (12 bits): The Type of a TLV. TLV-Type specifies the 3070 interpretation and format of the Value field of the TLV. See 3071 Section 9.2. 3073 o TLV-Length (2 bytes): The length of the Value portion of the TLV 3074 in bytes as an unsigned integer. 3076 o Value (variable length): This is the value portion of the TLV 3077 whose size is given by TLV-Length. The value portion consists of 3078 fields, frequently using one of the basic data field types (see 3079 Section 7.2) and sub-TLVs (see Section 7.3). 3081 7.2. Basic Data Fields 3083 This section specifies the binary format of several standard basic 3084 data fields that are used within other data structures in this 3085 specification. 3087 o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section 3088 7.3) to provide the length. The use of this data type in S-CUSP is 3089 to provide convenient labels for use by network operators in 3090 configuring and debugging their networks and interpreting S-CUSP 3091 messages. Subscribers will not normally see these labels. They 3092 are normally interpreted as ASCII [RFC20]. 3094 o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042]. 3096 o IPv4-Address: 8 octets. 4 octets of the IPv4 address value 3097 followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX. 3099 o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4 3100 octet integer n in the range of 0 to 128 which gives the address 3101 mask as the one's complement of 2**(128-n) - 1. 3103 o VLAN ID: 2 octets. As follows [802.1Q]: 3105 0 1 3106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 | PRI |D| VLAN-ID | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3111 PRI: Priority. Default value 7. 3113 D: Drop Eligibility Indicator (DEI). Default value 0. 3115 VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are 3116 not valid VLAN IDs [802.1Q].) 3118 7.3. Sub-TLV Format and Sub-TLVs 3120 In some cases, the Value portion of a TLV, as specified above, can 3121 contain one or more Sub-TLVs formatted as follows: 3123 0 1 2 3 3124 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 3125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3126 | Type | Length | 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 | Value | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 3131 Figure 33: Sub-TLV Header 3133 o Type (2 bytes): The Type of a Sub-TLV. The Type field specified 3134 the interpretation and format of the Value field of the TLV. 3135 Sub-TLV Type values have the same meaning regardless of the TLV 3136 Type of the TLV within which the sub-TLV occurs. See Section 3137 9.4. 3139 o Length (2 bytes): The length of the Value portion of the sub- 3140 TLV in bytes as an unsigned integer. 3142 o Value (variable length): This is the value portion of the sub- 3143 TLV whose size is given by Length. 3145 The sub-TLVs currently specified are defined in the following 3146 subsections. 3148 7.3.1. Name sub-TLVs 3150 This document defines the following name sub-TLVs that are used to 3151 carry the name of the corresponding object. The length of each of 3152 these sub-TLVs is variable from 1 to 255 octets. The value is of 3153 type STRING padded with zeros octets to 4-octet alignment. 3155 Type Sub-TLV Name Meaning 3156 ----- -------------------- ------------------- 3157 1 VRF-Name The name of a VRF 3158 2 Ingress-QoS-Profile The name of an ingress QoS profile 3159 3 Egress-QoS-Profile The name of an egress QoS profile 3160 4 User-ACL-Policy The name of an ACL policy 3161 5 Multicast-ProfileV4 The name of an IPv4 multicast profile 3162 6 Multicast-ProfileV6 The name of an IPv6 multicast profile 3163 7 NAT-Instance The name of a NAT instance 3164 8 Pool-Name The name of an address pool 3166 7.3.2. Ingress-CAR sub-TLV 3168 The Ingress-CAR sub-TLV indicates the authorized upstream Committed 3169 Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR 3170 sub-TLV is 9. The sub-TLV length is 16. The format is as shown in 3171 Figure 34. 3173 0 1 2 3 3174 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 3175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3176 | CIR (Committed Information Rate) | 3177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3178 | PIR (Peak Information Rate) | 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 | CBS (Committed Burst Size) | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 | PBS (Peak Burst Size) | 3183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 Figure 34: Ingress-CAR sub-TLV 3187 Where: 3189 CIR (4 bytes): Guaranteed rate in bits/second. 3191 PIR (4 bytes): Burst rate in bits/second. 3193 CBS (4 bytes): The token bucket in bytes. 3195 PBS (4 bytes): Burst token bucket in bytes. 3197 These fields are unsigned integers. More details about CIR, PIR, CBS, 3198 and PBS can be found in [RFC2698]. 3200 7.3.3. Egress-CAR sub-TLV 3202 The Egress-CAR sub-TLV indicates the authorized downstream Committed 3203 Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub- 3204 TLV is 10. Its sub-TLV length is 16 octets. The format of the value 3205 part is as defined below. 3207 0 1 2 3 3208 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 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | CIR (Committed Information Rate) | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | PIR (Peak Information Rate) | 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 | CBS (Committed Burst Size) | 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 | PBS (Peak Burst Size) | 3217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 Figure 35: Egress-CAR sub-TLV 3221 Where: 3223 CIR (4 bytes): Guaranteed rate in bits/second. 3225 PIR (4 bytes): Burst rate in bits/second. 3227 CBS (4 bytes): The token bucket in bytes. 3229 PBS (4 bytes): Burst token bucket in bytes. 3231 These fields are unsigned integers. More details about CIR, PIR, CBS, 3232 and PBS can be found in [RFC2698]. 3234 7.3.4. If-Desc sub-TLV 3236 The If-Desc sub-TLV is defined to designate an interface. It is an 3237 optional sub-TLV that may be carried in those TLVs that have an "if- 3238 index" or "out-if-index" field. The If-Desc sub-TLV is used as a 3239 locally unique identifier within a BNG. 3241 The sub-TLV type is 11. The sub-TLV length is 12 octets. The format 3242 depends on the If-Type. The format of the value part is as follows: 3244 0 1 2 3 3245 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 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | If-Type (1-5)| Chassis | Slot | 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 | Sub-Slot | Port Number | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | Sub-Port Number | 3252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3253 If-Desc sub-TLV (Physical Port) 3255 0 1 2 3 3256 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 3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3258 | If-Type (6-7) | Reserved | 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 | Logic-ID | 3261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3262 | Sub-Port Number | 3263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 If-Desc sub-TLV (Virtual Port) 3266 Figure 36: If-Desc sub-TLV Formats 3268 Where: 3270 If-Type: 8 bits in length. The value of this field indicates the 3271 type of an interface. The If-Type values defined in this document 3272 are listed in Section 9.6. 3274 Chassis (8 bits): Identifies the chassis that the interface 3275 belongs to. 3277 Slot (16 bits): Identifies the slot that the interface belongs to. 3279 Sub-slot (16 bits): Identifies the sub-slot the interface belongs 3280 to. 3282 Port Number (16 bits): An identifier of a physical port/interface 3283 (e.g., If-Type: 1-5). It is locally significant within the 3284 slot/sub-slot. 3286 Sub-port Number (32 bits): An identifier of the sub-port. Locally 3287 significant within its "parent" port (physical or virtual). 3289 Logic-ID (32 bits): An identifier of a virtual interface (e.g., 3290 If-Type: 6-7) 3292 7.3.5. IPv6 Address List sub-TLV 3294 The IPv6 Address List sub-TLV is used to convey one or more IPv6 3295 addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV 3296 type is 12. The sub-TLV length is variable. 3298 The format of IPv6 Addresses sub-TLV is as follows: 3300 0 1 2 3 3301 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 3302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3303 ~ IPv6 Address ~ 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 ~ IPv6 Address ~ 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 ~ ... ~ 3308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3309 ~ IPv6 Address ~ 3310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3312 Figure 37: IPv6 Address List sub-TLV 3314 Where: 3316 IP Address (IPv6-Address): Each IP Address is an IP-Address type, 3317 carries an IPv6 address. 3319 7.3.6. Vendor sub-TLV 3321 The Vendor sub-TLV is intended to be used inside the value portion of 3322 the Vendor TLV (Section 7.13). It provides a Sub-Type that 3323 effectively extends the sub-TLV type in the sub-TLV header and 3324 provides for versioning of vendor sub-TLVs. 3326 The value part of the Vendor sub-TLV is formatted as follows: 3328 0 1 2 3 3329 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 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | Vendor ID | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | Sub-Type | Sub-Type-Version | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 ~ value (other as specified by vendor) ~ 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3338 Figure 38: Vendor sub-TLV 3340 Where: 3342 The sub-TLV type: 13. 3344 The sub-TLV length: variable. 3346 Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865]. 3348 Sub-Type (2 bytes): Used by the Vendor to distinguish multiple 3349 different sub-TLVs. 3351 Sub-Type-Version (2 bytes): Used by the Vendor to distinguish 3352 different versions of a Vendor-Defined sub-TLV sub-Type. 3354 value: as specified by the vendor. 3356 Since Vendor code will be handling the sub-TLV after the Vendor ID 3357 field is recognized, the remainder of the sub-TLV can be organized 3358 however the vendor wants. But it desirable for a vendor to be able to 3359 define multiple different vendor sub-TLVs and to keep track of 3360 different versions of its vendor-defined sub-TLVs. Thus, it is 3361 RECOMMENDED that the vendor assign a Sub-Type value for each of that 3362 vendor's sub-TLVs that is different from other Sub-Type values that 3363 vendor has used. Also, when modifying a vendor-defined sub-TLV in a 3364 way potentially incompatible with a previous definition, the vendor 3365 SHOULD increase the value it is using in the Sub-Type-Version field. 3367 7.4. The Hello TLV 3369 The Hello TLV is defined to be carried in the Hello message for 3370 version and capabilities negotiation. It indicates the S-CUSP sub- 3371 version and capabilities supported. The format of Hello TLV is as 3372 follows: 3374 0 1 2 3 3375 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 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 | VerSupported | 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3379 | Vendor ID | 3380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3381 | Capabilities | 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 Figure 39: Hello TLV 3386 Where: 3388 The TLV type is 100. 3390 The TLV length is 12 octets. 3392 The value field consists of three parts: 3394 VerSupported: 32 bits in length. It is a bit map of the Sub- 3395 Versions of the S-CUSP protocol that the sender supports. This 3396 document specifies Sub-Version zero of Major Version 1, that 3397 is, Version 1.0. The VerSupported field MUST be non-zero. The 3398 VerSupported bits are numbered from 0 as the most significant 3399 bit. Bit 0 indicates support of Sub-Version zero, bit 1 3400 indicates support of Sub-Version one, etc. 3402 Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS 3403 [RFC2865]. 3405 Capabilities: 32 bits in length. Flags that indicate the 3406 support of particular capabilities by the sender of the Hello. 3407 No Capabilities are defined in this document, so 3408 implementations of the version specified herein will set this 3409 field to zero. The Capabilities field of the Hello TLV MUST be 3410 checked before any other TLVs in the Hello because capabilities 3411 defined in the future might extend existing TLVs or permit new 3412 TLVs. 3414 After the exchange of Hello messages, the CP and UP each perform a 3415 logical AND of the Sub-Version supported by the CP and the UP and 3416 separately perform a logical AND of the Capabilities bits fields for 3417 the CP and the UP. 3419 If the result of the AND of the Sub-Versions supported is zero, then 3420 no session can be established and the connection is torn down. If the 3421 result of the AND of the Sub-Versions supported is non-zero, then the 3422 session uses the highest Sub-Version supported by both the CP and UP. 3424 For example, if one side supports Sub-Versions 1, 3, 4, and 5 3425 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 3426 (VerSupported = 0x38000000), then 3 and 4 are the Sub-Versions in 3427 common and 4 is the highest Sub-Version supported by both sides. So 3428 Sub-Version 4 is used for the session that has been negotiated. 3430 The result of the logical AND of the Capabilities bits will show what 3431 additional capabilities both sides support. If this result is zero, 3432 there are no such capabilities so none can be used during the 3433 session. If this result is non-zero, it shows the additional 3434 capabilities that can be used during the session. The CP and the UP 3435 MUST NOT use a capability unless both advertise support. 3437 7.5. The Keepalive TLV 3439 The Keepalive TLV is carried in the Hello message. It provides 3440 timing information for this feature. The format of Hello TLV is as 3441 follows: 3443 0 1 2 3 3444 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 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | Keepalive | DeadTimer | Reserved | 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3449 Figure 40: Keepalive TLV 3451 Where: 3453 The TLV type: 102. 3455 The value of the Length field is 4 octets. 3457 Keepalive (8 bits): Indicates the maximum interval (in seconds) 3458 between two consecutive S-CUSP messages sent by the sender of the 3459 message containing this TLV as an unsigned integer. The minimum 3460 value for the Keepalive field is 1 second. When set to 0, once the 3461 session is established, no further Keepalive messages are sent to 3462 the remote peer. A RECOMMENDED value for the Keepalive frequency 3463 is 30 seconds. 3465 DeadTimer (8 bits in length): Specifies the amount of time as an 3466 unsigned integer number of seconds after the expiration of which 3467 the S-CUSP peer can declare the session with the sender of the 3468 Hello message to be down if no S-CUSP message has been received. 3469 The DeadTimer SHOULD be set to 0 and MUST be ignored if the 3470 Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 3471 times the value of the Keepalive. 3473 The Reserved bits MUST be sent as zero and ignored on receipt. 3475 7.6. The Error Information TLV 3477 The Error Information TLV is a common TLV that can be used in many 3478 Response (e.g., Update_Response message) and ACK messages (e.g., 3479 Addr_Allocation_Ack message, etc.). It is used to convey the 3480 information about an error in the received S-CUSP message. The 3481 format of the Error Information TLV is as follows: 3483 0 1 2 3 3484 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 3485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3486 | Message-Type | Reserved | TLV-Type | 3487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3488 | Error Code | 3489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3491 Figure 41: Error Information TLV 3493 Where: 3495 The TLV type: 101. 3497 The value of the Length field is 8 octets. 3499 Message-Type(1 byte): This parameter is the message type of the 3500 message containing an error. 3502 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3504 TLV-Type (2 bytes): Indicates which TLV caused the error. 3506 Error Code: 4 bytes in length. Indicate the specific Error Code 3507 (see Section 9.5). 3509 7.7. BAS Function TLV 3511 The BAS Function TLV is used by a CP to control the access mode, 3512 authentication methods, and other related functions of an interface 3513 on a UP. 3515 The format of the BAS Function TLV value part is as follows: 3517 0 1 2 3 3518 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 3519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3520 | If-Index | 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 | Flags | 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3526 | sub-TLVs (optional) | 3527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3529 Figure 42: BAS Function TLV 3531 Where: 3533 The TLV type: 1. 3535 The value of the Length field is variable. 3537 If-Index: 4 bytes in length, a unique identifier of an interface 3538 of a BNG. 3540 Access-Mode: 1 byte in length. It indicates the access mode of the 3541 interface. The defined values are listed in Section 9.7. 3543 Auth-Method4: 1 byte in length. It indicates the authentication on 3544 this interface for the IPv4 scenario. This field is defined as a 3545 bitmap. The bits defined in this document are listed in Section 3546 9.8. Other bits are reserved and MUST be sent as zero and ignored 3547 on receipt. 3549 Auth-Method6: 1 byte in length. It indicates the authentication on 3550 this interface for the IPv6 scenario. This field is defined as a 3551 bitmap. The bits defined in this document are listed in Section 3552 9.8. Other bits are reserved and MUST be sent as zero and ignored 3553 on receipt. 3555 sub-TLVs: 3556 The IF-Desc sub-TLV can be carried. 3557 If-Desc sub-TLV: carries the interface information. 3559 The flags field is defined as follows: 3561 0 1 2 3 3562 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 3563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3564 | MBZ |Y|X|P|I|N|A|S|F| 3565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3567 Figure 43: Interface Flags 3569 Where: 3571 F (IPv4 Trigger) bit: Indicates whether IPv4 packets can 3572 trigger a subscriber to go online. 1: enabled, 0: disabled. 3574 S (IPv6 Trigger) bit: Indicates whether IPv6 packets can 3575 trigger a subscriber to go online. 1: enabled, 0: disabled. 3577 A (ARP Trigger) bit: Indicates whether ARP packets can trigger 3578 a subscriber to go online. 1: enabled, 0: disabled. 3580 N (ND Trigger) bit: Indicates whether ND packets can trigger a 3581 subscriber to go online. 1: enabled, 0: disabled. 3583 I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable 3584 traffic detection. 0: Disable traffic detection. 3586 P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable 3587 traffic detection. 0: Disable traffic detection. 3589 X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy 3590 and can process ARP requests across different Port+VLANs. 0: 3591 The ARP proxy is not enabled on the interface and only the ARP 3592 requests of the same Port+VLAN are processed. 3594 Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and 3595 can process ND requests across different Port+VLANs. 0: The ND 3596 proxy is not enabled on the interface and only the ND requests 3597 of the same Port+VLAN are processed. 3599 MBZ: Reserved bits that MUST be sent as zero and ignored on 3600 receipt. 3602 7.8. Routing TLVs 3604 Typically, after an S-CUSP session is established between a UP and a 3605 CP, the CP will allocate one or more blocks of IP addresses to the 3606 UP. Those IP addresses will be allocated to subscribers who will 3607 dial-up (as defined in Section 2.1) to the UP. To make sure that 3608 other nodes within the network learn how to reach those IP addresses, 3609 the CP needs to install one or more routes that can reach those IP 3610 addresses on the UP and notify the UP to advertise the routes to the 3611 network. 3613 The Routing TLVs are used by a CP to notify a UP of the updates to 3614 network routing information. They can be carried in the 3615 Update_Request message and Sync_Data message. 3617 7.8.1. IPv4 Routing TLV 3619 The IPv4 Routing TLV is used to carry information related to IPv4 3620 network routing. 3622 The format of the TLV value part is as below: 3624 0 1 2 3 3625 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 3626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3627 | User ID | 3628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3629 | Dest-Address | 3630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3631 | Next-Hop | 3632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 | Out-If-Index | 3634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3635 | Cost | 3636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3637 | Tag | 3638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3639 | Route Type | Reserved |A| 3640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3641 ~ sub-TLVs (optional) ~ 3642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3644 Figure 44: IPv4 Routing TLV 3646 Where: 3648 The TLV Type: 7 3650 The TLV Length: Variable 3652 User-ID: 4 bytes in length. This field carries the user 3653 identifier. It is filled with all Fs when a non-user route is 3654 delivered to the UP. 3656 Dest-Address (IPv4-Address type): Identifies the destination 3657 address. 3659 Next-Hop: (IPv4-Address type): Identifies the next hop address. 3661 Out-If-Index (4 bytes): Indicates the interface index. 3663 Cost (4 bytes): The cost value of the route. 3665 Tag (4 bytes): The tag value of the route. 3667 Route-Type (2 bytes): The value of this field indicates the route 3668 type. The values defined in this document are listed in Section 3669 9.9. 3671 Advertise-Flag: 1 bit shown as "A" is the figure above. Indicates 3672 whether the IP should advertise the route. The following flag 3673 values are defined: 3674 0: Not advertised, 3675 1: Advertised. 3677 sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried. 3678 VRF-Name sub-TLV: indicates which VRF the route belongs to. 3679 If-Desc sub-TLV: carries the interface information. 3681 The Reserved field MUST be sent as zero and ignored on receipt. 3683 7.8.2. IPv6 Routing TLV 3685 The IPv6 Routing TLV is used to carry IPv6 network routing 3686 information. 3688 The format of this TLV is as follows: 3690 0 1 2 3 3691 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 3692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3693 | User ID | 3694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3695 ~ IPv6 Dest-Address ~ 3696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3697 ~ IPv6 Next-Hop ~ 3698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3699 | Out-If-Index | 3700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3701 | Cost | 3702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3703 | Tag | 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3705 | Route Type | Reserved |A| 3706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3707 ~ sub-TLVs (optional) ~ 3708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3710 Figure 45: IPv6 Routing TLV 3712 Where: 3714 The TLV Type: 7 3716 The TLV Length is Variable. 3718 User-ID: 4 bytes in length. This field carries the user 3719 identifier. This field is filled with all Fs when a non-user 3720 route is delivered to the UP. 3722 IPv6 Dest-Address (IPv6-Address type): Identifies the destination 3723 address. 3725 IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop 3726 address. 3728 Out-If-Index (4 bytes): Indicates the interface index. 3730 Cost (4 bytes): This is the cost value of the route. 3732 Tag (4 bytes): The tag value of the route. 3734 Route-Type: (2 bytes): The value of this field indicates the 3735 route type. The values defined in this document are listed in 3736 Section 9.9. 3738 Advertise-Flag: 1 bit shown as "A" is the figure above. Indicates 3739 whether UP should advertise the route. Following flags are 3740 defined: 3741 0: Not advertised, 3742 1: Advertised. 3744 sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried. 3745 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3746 belongs. 3747 If-Desc sub TLV: carries the interface information. 3749 The Reserved field MUST be sent as zero and ignored on receipt. 3751 7.9. Subscriber TLVs 3753 The Subscriber TLVs are defined for a CP to send the basic 3754 information about a user to a UP. 3756 7.9.1. Basic Subscriber TLV 3758 The Basic Subscriber TLV is used to carry the basic common 3759 information for all kinds of access subscribers. It is carried in an 3760 Update_Request message. 3762 The format of the Basic Subscriber TLV value part is as follows: 3764 0 1 2 3 3765 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 3766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3767 | User ID | 3768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3769 | Session ID | 3770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 | User MAC | 3772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3773 | User MAC | Oper ID | Reserved | 3774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3775 | Access Type |Sub-access Type| Account Type | Address Family| 3776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3777 | C-VID | P-VID | 3778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3779 | Detect Times | Detect Interval | 3780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 | If-Index | 3782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3783 ~ sub-TLVs (optional) ~ 3784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 Figure 46: Basic Subscriber TLV 3788 Where: 3790 The TLV Type: 2. 3792 The TLV is variable in length. 3794 User-ID (4 bytes): The identifier of a subscriber. 3796 Session-ID (4 bytes): Session ID of a PPPoE subscriber. The value 3797 zero identifies a non-PPPoE subscriber. 3799 User-Mac (MAC-Addr type): The MAC Address of a subscriber. 3801 Oper-ID (1 byte): Indicates the ID of an operation performed by a 3802 user. This field is carried in the response from the UP. 3804 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3806 Access-Type (1 byte): Indicates the type of subscriber access. 3807 Values defined in this document are listed in Section 9.10. 3809 Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP 3810 relay is used. 3811 0: Reserved 3812 1: PPP Relay (for LAC) 3813 2: PPP termination (for LNS) 3815 Account-Type (1 byte): 3816 0: Collects statistics on IPv4 and IPv6 traffic of terminals 3817 independently. 3818 1: Collects statistics on IPv4 and IPv6 traffic of terminals. 3820 Address Family (1 byte) 3821 1: IPv4 3822 2: IPv6 3823 3: dual stack 3825 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 3826 indicates that the VLAN ID is invalid. The default value of PRI 3827 is 7, the value of DEI is 0, and the value of VID is 1~4094. The 3828 PRI value can also be obtained by parsing terminal packets. 3830 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 3831 indicates that the VLAN ID is invalid. The format is the same as 3832 that for C-VID. 3834 Detect-Times (2 bytes): Number of detection timeout times. The 3835 value 0 indicates that no detection is performed. 3837 Detect-Interval (2 bytes): Detection interval in seconds. 3839 If-Index (4 bytes): Interface index. 3841 Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried. 3842 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3843 belongs. 3844 If-Desc sub-TLV: carries the interface information. 3846 The Reserved field MUST be sent as zero and ignored on receipt. 3848 7.9.2. PPP Subscriber TLV 3850 The PPP Subscriber TLV is defined to carry PPP information of a User 3851 from a CP to a UP. It will be carried in an Update_Request message 3852 when PPPoE or L2TP access is used. 3854 The format of the TLV value part is as follows: 3856 0 1 2 3 3857 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 3858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 | User ID | 3860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3861 | MSS | Reserved |M| 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 | MRU | Reserved | 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3865 | Magic Number | 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3867 | Peer Magic Number | 3868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3870 Figure 47: PPP Subscriber TLV 3872 Where: 3874 The TLV type: 3. 3876 The TLV length is 12 octets. 3878 User-ID (4 bytes): The identifier of a subscriber. 3880 MSS-Value (2 bytes): Indicates the MSS value (in bytes). 3882 MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled. 3883 0: Disabled. 3884 1: Enabled. 3886 MRU (2 bytes): PPPoE local MRU (in bytes). 3888 Magic-Number (4 bytes): Local magic number in PPP negotiation 3889 packets. 3891 Peer-Magic-Number (4 bytes): Remote peer magic number. 3893 The Reserved fields MUST be sent as zero and ignored on receipt. 3895 7.9.3. IPv4 Subscriber TLV 3897 The IPv4 Subscriber TLV is defined to carry IPv4 related information 3898 for a BNG user. It will be carried in an Update_Request message when 3899 IPv4 IPoE or PPPoE access is used. 3901 The format of the TLV value part is as follows: 3903 0 1 2 3 3904 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 3905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3906 | User ID | 3907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3908 | User IPv4 Address | 3909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3910 | Gateway IPv4 Address | 3911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3912 | MTU | Reserved |U|E|W|P| 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3914 ~ VRF-Name sub-TLV ~ 3915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3917 Figure 48: IPv4 Subscriber TLV 3919 Where: 3921 The TLV type: 4. 3923 The TLV length is variable. 3925 User-ID (4 bytes): The identifier of a subscriber. 3927 User-IPv4 (IPv4-Address): The IPv4 address of the subscriber. 3929 Gateway-IPv4 (IPv4-Address): The gateway address of the 3930 subscriber. 3932 Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on. 3934 Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on. 3936 Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off, 3937 1: on. 3939 IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) 3940 flag. 0: off, 1: on. 3942 MTU 2 bytes MTU value. The default value is 1500. 3944 VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. 3946 The Reserved field MUST be sent as zero and ignored on receipt. 3948 7.9.4. IPv6 Subscriber TLV 3950 The IPv6 Subscriber TLV is defined to carry IPv6 related information 3951 for a BNG user. It will be carried in an Update_Request message when 3952 IPv6 IPoE or PPPoE access is used. 3954 The format of the TLV value part is as follows: 3956 0 1 2 3 3957 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 3958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3959 | User-ID | 3960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3961 ~ User PD-Address (IPv6 Address List sub-TLV) ~ 3962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3963 ~ Gateway ND-Address (IPv6 Address List sub-TLV) ~ 3964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3965 | User Link-Local-Address | 3966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3967 | IPv6 Interface ID | 3968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3969 | IPv6 Interface ID (cont.) | 3970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3971 | MTU | Reserved |U|E|W|P| 3972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3973 ~ VRF Name sub-TLV (optional) ~ 3974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3976 Figure 49: IPv6 Subscriber TLV 3978 Where: 3980 The TLV type: 5. 3982 The TLV length is variable. 3984 User-ID (4 bytes): The identifier of a subscriber. 3986 User PD-Addresses (IPv6 Address List): Carries a list of Prefix 3987 Delegation (PD) addresses of the subscriber. 3989 User ND-Addresses (IPv6 Address List): Carries a list of Neighbor 3990 Discovery (ND) addresses of the subscriber. 3992 User Link-Local-Address (IPv6-Address): The link-local address of 3993 the subscriber. 3995 IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface. 3997 Portal Force 1 bit (P): Push advertisement, 0: off, 1: on. 3999 Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on. 4001 Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off; 4002 1: on. 4004 IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0: 4005 off; 1: on. 4007 MTU (2 bytes): The MTU value. The default value is 1500. 4009 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4010 belongs. 4012 The Reserved field MUST be sent as zero and ignored on receipt. 4014 7.9.5. IPv4 Static Subscriber Detect TLV 4016 The IPv4 Static Subscriber Detect TLV is defined to carry IPv4 4017 related information for a static access subscriber. It will be 4018 carried in an Update_Request message when IPv4 static access on a UP 4019 needs to be enabled. 4021 The format of the TLV value part is as follows: 4023 0 1 2 3 4024 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 4025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4026 | If-Index | 4027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4028 | C-VID | P-VID | 4029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4030 | User Address | 4031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4032 | Gateway Address | 4033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4034 | User MAC | 4035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4036 | User MAC (cont.) | Reserved | 4037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4038 ~ sub-TLVs (optional) ~ 4039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4041 Figure 50: IPv4 Static Subscriber TLV 4043 Where: 4045 The TLV type: 6. 4047 The TLV length is variable. 4049 If-Index (4 bytes): The interface index of the interface from 4050 which the subscriber will dial-up. 4052 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4053 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4055 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4056 indicates that the VLAN ID is invalid. The format is the same as 4057 that of the C-VID. A valid value is 1~4094. For a single-layer 4058 VLAN, set this parameter to PeVid. 4060 User Address (IPv4-Addr): The user's IPv4 address. 4062 Gateway Address (IPv4-Addr): The gateway's IPv4 Address. 4064 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4066 Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried. 4067 VRF-Name sub-TLV: Indicates the VEF to which the subscriber 4068 belongs. 4069 If-Desc sub-TLV: Carries the interface information. 4071 The Reserved field MUST be sent as zero and ignored on receipt. 4073 7.9.6. IPv6 Static Subscriber Detect TLV 4075 The IPv6 Static Subscriber Detect TLV is defined to carry IPv6 4076 related information for a static access subscriber. It will be 4077 carried in an Update_Request message when needed to enable IPv6 4078 static subscriber detection on a UP. 4080 The format of the TLV value part is as follows: 4082 0 1 2 3 4083 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 4084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4085 | If-Index | 4086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4087 | C-VID | P-VID | 4088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4089 ~ User Address ~ 4090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4091 ~ Gateway Address ~ 4092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4093 | User MAC | 4094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4095 | User MAC (cont.) | Reserved | 4096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4097 ~ sub-TLVs (optional) ~ 4098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4100 Figure 51: IPv6 Static Subscriber Detect TLV 4102 Where: 4104 The TLV type: 6. 4106 The TLV length is variable. 4108 If-Index (4 bytes): The interface index of the interface from 4109 which the subscriber will dial-up. 4111 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4112 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4114 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4115 indicates that the VLAN ID is invalid. The format is the same as 4116 that the of C-VID. A valid value is 1~4094. For a single-layer 4117 VLAN, set this parameter to PeVid. 4119 User Address (IPv6-Address type): The subscriber's IPv6 address. 4121 Gateway Address (IPv6-Address type): The gateway's IPv6 Address. 4123 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4125 sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried 4126 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4127 belongs. 4128 If-Desc sub-TLV: Carries the interface information. 4130 The Reserved field MUST be sent as zero and ignored on receipt. 4132 7.9.7. L2TP-LAC Subscriber TLV 4134 The L2TP-LAC Subscriber TLV is defined to carry the related 4135 information for an L2TP LAC access subscriber. It will be carried in 4136 an Update_Request message when L2TP LAC access is used. 4138 The format of the TLV value part is as follows: 4140 0 1 2 3 4141 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 4142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4143 | User ID | 4144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4145 | Local Tunnel ID | Local Session ID | 4146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4147 | Remote Tunnel ID | Remote Session ID | 4148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4150 Figure 52: L2TP-LAC Subscriber TLV 4152 Where: 4154 The TLV type: 11. 4156 The TLV is 12 octets long. 4158 User-ID (4 bytes): The identifier of a user/subscriber. 4160 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4162 Local-Session-ID (2 bytes): The local session ID with the L2TP 4163 tunnel. 4165 Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at 4166 the remote end-point. 4168 Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at 4169 the remote end-point. 4171 7.9.8. L2TP-LNS Subscriber TLV 4173 The L2TP-LNS Subscriber TLV is defined to carry the related 4174 information for a L2TP LNS access subscriber. It will be carried in 4175 an Update_Request message when L2TP LNS access is used. 4177 The format of the TLV value part is as follows: 4179 0 1 2 3 4180 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 4181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4182 | User ID | 4183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4184 | Local Tunnel ID | Local Session ID | 4185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4186 | Remote Tunnel ID | Remote Session ID | 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4189 Figure 53: L2TP-LNS Subscriber TLV 4191 Where: 4193 The TLV type: 12. 4195 The TLV length is 12 octets. 4197 User-ID (4 bytes): The identifier of a user/subscriber. 4199 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4201 Local-Session-ID (2 bytes): The local session ID with the L2TP 4202 tunnel. 4204 Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at 4205 the remote end-point. 4207 Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at 4208 the remote end-point. 4210 7.9.9. L2TP-LAC Tunnel TLV 4212 The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel 4213 related information. It will be carried in the Update_Request 4214 message when L2TP LAC access is used. 4216 The format of the TLV value part is as follows: 4218 0 1 2 3 4219 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 4220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4221 | Local Tunnel ID | Remote Tunnel ID | 4222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4223 | Source Port | Destination Port | 4224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4225 ~ Tunnel Source Address ~ 4226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4227 ~ Tunnel Destination Address ~ 4228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4229 ~ VRF Name sub-TLV ~ 4230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4232 Figure 54: L2TP-LAC Tunnel TLV 4234 Where: 4236 The TLV type: 13. 4238 The TLV length is variable. 4240 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4242 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4244 Source-Port (2 bytes): The source UDP port number of an L2TP 4245 subscriber. 4247 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4248 subscriber. 4250 Source-IP (IPv4/v6): The source IP address of the tunnel. 4252 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4254 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4255 belongs. 4257 7.9.10. L2TP-LNS Tunnel TLV 4259 The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel 4260 related information. It will be carried in the Update_Request 4261 message when L2TP LNS access is used. 4263 The format of the TLV value part is as follows: 4265 0 1 2 3 4266 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 4267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4268 | Local Tunnel ID | Remote Tunnel ID | 4269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4270 | Source Port | Destination Port | 4271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4272 ~ Tunnel Source Address ~ 4273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4274 ~ Tunnel Destination Address ~ 4275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4276 ~ VRF Name sub-TLV ~ 4277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4279 Figure 55: L2TP-LNS Tunnel TLV 4281 Where: 4283 The TLV type: 14. 4285 The TLV length is variable. 4287 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4289 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4291 Source-Port (2 bytes): The source UDP port number of an L2TP 4292 subscriber. 4294 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4295 subscriber. 4297 Source-IP (IPv4/v6): The source IP address of the tunnel. 4299 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4301 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4302 belongs. 4304 7.9.11. Update Response TLV 4306 The Update Response TLV is used to return the operation result of an 4307 update request. It is carried in the Update_Response message as a 4308 response to the Update_Request message. 4310 The format of Update Response TLV is as follows: 4312 0 1 2 3 4313 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 4314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4315 | User-ID | 4316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4317 | User-Trans-ID | Oper-Code | Oper-Result | Reserved | 4318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4319 | Error-Code | 4320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4322 Figure 56: Update Response TLV 4324 Where: 4326 The TLV type: 302. 4328 The TLV length is 12. 4330 User-ID (4 bytes): A unique identifier of a user/subscriber. 4332 User-Trans-ID (1 byte): In the case of dual-stack access or when 4333 modifying a session, User-Trans-ID is used to identify a user 4334 operation transaction. It is used by the CP to correlate a 4335 response to a specific request. 4337 Oper-Code (1 byte): Operation code. 1: update, 2: delete. 4339 Oper-Result (1 byte): Operation Result. 0: Success, Others: 4340 Failure. 4342 Error-Code (4 bytes): Operation failure cause code. for details, 4343 see Section 9.5. 4345 The Reserved field MUST be sent as zero and ignored on receipt. 4347 7.9.12. Subscriber Policy TLV 4349 The Subscriber Policy TLV is used to carry the policies that will be 4350 applied to a subscriber. It is carried in the Update_Request 4351 message. 4353 The format of the TLV value part is as follows: 4355 0 1 2 3 4356 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 4357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4358 | User ID | 4359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4360 | I-Priority | E-Priority | Reserved | 4361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4362 ~ sub-TLVs ~ 4363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4365 Figure 57: User QoS Policy Information TLV 4367 Where: 4369 The TLV type: 6. 4371 The TLV length is variable. 4373 User-ID (4 bytes): The identifier of a user/subscriber. 4375 Ingress-Priority (1 byte): Indicates the upstream priority. The 4376 value range is 0~7. 4378 Egress-Priority (1 byte): Indicates the downstream priority. The 4379 value range is 0~7. 4381 sub-TLVs: The sub-TLVs that are present can occur in any order. 4383 Ingress-CAR sub-TLV: Upstream CAR. 4385 Egress-CAR sub-TLV: Downstream CAR. 4387 Ingress-QoS-Profile sub-TLV: Indicates the name of the QoS- 4388 Profile that is the profile in the upstream direction. 4390 Egress-QoS-Profile Sub-TLV: Indicates the name of the QoS- 4391 Profile that is the profile in the downstream direction. 4393 User-ACL-Policy Sub-TLV: All ACL user policies, including 4394 v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, 4395 v4SpecialACL, and v6SpecialACL. 4397 Multicast-Profile4 Sub-TLV: IPv4 multicast policy name. 4399 Multicast-Profile6 Sub-TLV: IPv6 multicast policy name. 4401 NAT-Instance Sub-TLV: Indicates the instance ID of a NAT user. 4403 The Reserved field MUST be sent as zero and ignored on receipt. 4405 7.9.13. Subscriber CGN Port Range TLV 4407 The Subscriber CGN Port Range TLV is used to carry the NAT public 4408 address and port range. It will be carried in the Update_Response 4409 message when CGN is used. 4411 The format of this TLV is as follows: 4413 0 1 2 3 4414 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 4415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4416 | User ID | 4417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4418 | NAT-Port-Start | NAT-Port-End | 4419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4420 | NAT-Address | 4421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4423 Figure 58: Subscriber CGN Port Range TLV 4425 Where: 4427 The TLV type: 15. 4429 The TLV length is 12 octets. 4431 User-ID (4 bytes): The identifier of a user/subscriber. 4433 NAT-Port-Start (2 bytes): The start port number. 4435 NAT-Port-End (2 bytes): The end port number. 4437 NAT-Address (4 bytes): The NAT public network address. 4439 7.10. Device Status TLVs 4441 The TLVs in this section are for reporting Interface and Board level 4442 information from the UP to the CP. 4444 7.10.1. Interface Status TLV 4446 The Interface Status TLV is used to carry the status information of 4447 an interface on a UP. It is carried in a Report message. 4449 The format of the value part of this TLV is as follows: 4451 0 1 2 3 4452 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 4453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4454 | If-Index | 4455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4456 | MAC Address (upper part) | 4457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4458 | MAC Address (lower part) | Phy-State | Reserved | 4459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4460 | MTU | 4461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4462 | sub-TLVs (optional) | 4463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4465 Figure 59: Interface Status TLV 4467 Where: 4469 The TLV type: 200. 4471 The TLV length is variable. 4473 If-Index (4 bytes): Indicates the interface index. 4475 MAC-Address (MAC-Addr type): Interface MAC address. 4477 Phy-State (1 byte): Physical status of the interface. 0: down, 1: 4478 Up 4480 MTU (4 bytes): Interface MTU value. 4482 sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried. 4484 The Reserved field MUST be sent as zero and ignored on receipt. 4486 7.10.2. Board Status TLV 4488 The Board Status TLV is used to carry the status information of a 4489 board on an UP. It is carried in a Report message. 4491 The format of Board Status TLV is as follows: 4493 0 1 2 3 4494 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 4495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4496 | Board-Type | Board-State | Reserved | Chassis | 4497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4498 | Slot | Reserved | 4499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4501 Figure 60: Interface Resource TLV 4503 Where: 4505 The TLV type: 201. 4507 The TLV length is 8 octets. 4509 Chassis (1 byte): The chassis number of the Board. 4511 Slot (1 byte): The slot number of the Board. 4513 Sub-Slot (1 byte): The sub-slot number of the Board. 4515 Board-Type (1 byte): 4516 1: CGN Service Process Unit (SPU) board. 4517 2: Line Process Unit (LPU) Board. 4519 Board-State (1 byte): 4520 0: Normal. 4521 1: Abnormal. 4523 The reserved field MUST be sent as zero and ignored on receipt. 4525 7.11. CGN TLVs 4527 7.11.1. Address Allocation Request TLV 4529 The Address Allocation Request TLV is used to request address 4530 allocation from CP. An address Pool-Name sub-TLV is carried to 4531 indicate from which address pool to allocate addresses. The Address 4532 Allocation Request TLV is carried in the Addr_Allocation_Req message. 4534 The format of the value part of this TLV is as follows: 4536 0 1 2 3 4537 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 4538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4539 ~ Pool-Name sub-TLV ~ 4540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4542 Figure 61: Address Allocation Request TLV 4544 Where: 4546 The TLV type: 400. 4548 The TLV length is variable. 4550 Pool-Name sub-TLV: Indicates from which Address pool to allocate 4551 address. 4553 7.11.2. Address Allocation Response TLV 4555 The Address Allocation Response TLV is used to return the address 4556 allocation result, it is carried the Addr_Allocation_Ack message. 4558 The value part of the Address Allocation Response TLV is formatted as 4559 follows: 4561 0 1 2 3 4562 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 4563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4564 | Lease Time | 4565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4566 | IPv4 Addr and Mask | 4567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4568 | IPv4 Addr and Mask continued | 4569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4570 | Error-Code | 4571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4572 ~ Pool-Name sub-TLV ~ 4573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4575 Figure 62: Address Assignment Response TLV 4577 Where: 4579 The TLV type: 401. 4581 The TLV length is variable. 4583 Lease Time (4 bytes): Duration of address lease in seconds. 4585 IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4 4586 address. 4588 Error-Code (4 bytes): Indicates success or an error. 4590 0: Success. 4592 1: Failure. 4594 3001 (Pool-Mismatch): The corresponding address pool cannot be 4595 found. 4597 3002 (Pool-Full): The address pool is fully allocated and no 4598 address segment is available. 4600 Pool-Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4601 Address pool the address is allocated. 4603 7.11.3. Address Renewal Request TLV 4605 The Address Renewal Request TLV is used to request address renewal 4606 from the CP. It is carried the Addr_Renew_Req message. 4608 The format of this TLV value is as follows: 4610 0 1 2 3 4611 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 4612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4613 | IPv4 Address and Mask | 4614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4615 | IPv4 Address and Mask continued | 4616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4617 ~ Pool-Name sub-TLV ~ 4618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4620 Figure 63: Address Renewal Request TLV 4622 Where: 4624 The TLV type: 402. 4626 The TLV length is variable. 4628 IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed. 4630 Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4631 Address pool to renew the address. 4633 7.11.4. The Address Renewal Response TLV 4635 The Address Renewal Response TLV is used to return the address 4636 renewal result. It is carried in the Addr_Renew_Ack message. 4638 The format of this TLV value is as follows: 4640 0 1 2 3 4641 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 4642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4643 | IPv4 Address and Mask | 4644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4645 | IPv4 Address and Mask continued | 4646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4647 | Error-Code | 4648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4649 ~ Pool-Name sub-TLV ~ 4650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4652 Figure 64: Address Renewal Response TLV 4654 Where: 4656 The TLV type: 403. 4658 The TLV length is variable. 4660 Client-IP (IPv4-Address type): The renewed IPv4 address. 4662 Error Code (4 bytes): Indicates success or an error: 4664 0: Renew succeeded. 4666 1: Renew failed. 4668 3001 (Pool-Mismatch): The corresponding address pool cannot be 4669 found. 4671 3002 (Pool-Full): The address pool is fully allocated and no 4672 address segment is available. 4674 3003 (Subnet-Mismatch): The address pool subnet cannot be 4675 found. 4677 3004 (Subnet-Conflict): Subnets in the address pool have been 4678 assigned to other clients. 4680 Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4681 Address pool to renew the address. 4683 7.11.5. Address Release Request TLV 4685 The Address Release Request TLV is used to release an IPv4 address. 4686 It is carried in the Addr_Release_Req message. 4688 The value part of this TLV is formatted as follows: 4690 0 1 2 3 4691 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 4692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4693 | IPv4 Address and Mask | 4694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4695 | IPv4 Address and Mask continued | 4696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4697 ~ Pool-Name sub-TLV ~ 4698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4700 Figure 65: Address Release Request TLV 4702 Where: 4704 The TLV type: 404. 4706 The TLV length is variable. 4708 IPv4 Address and Mask (IPv4-Address type): The IPv4 address be 4709 released. 4711 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4712 Address pool to release the address. 4714 7.11.6. The Address Release Response TLV 4716 The Address Release Response TLV is used to return the address 4717 release result. It is carried in the Addr_Release_Ack message. 4719 The format of this TLV is as follows: 4721 0 1 2 3 4722 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 4723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4724 | IPv4 Address and Mask | 4725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4726 | IPv4 Address and Mask continued | 4727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4728 | Error-Code | 4729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4730 ~ Pool-Name sub-TLV ~ 4731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4733 Figure 66: Address Renewal Response TLV 4735 Where: 4737 The TLV type: 405. 4739 The TLV length is variable. 4741 Client-IP (IPv4-Address type): The released IPv4 address. 4743 Error-Code (4 bytes): Indicates success or an error. 4745 0: Address release success. 4747 1: Address release failed. 4749 3001 (Pool-Mismatch): The corresponding address pool cannot be 4750 found. 4752 3003 (Subnet-Mismatch): The address cannot be found. 4754 3004 (Subnet-Conflict): The address has been allocated to 4755 another subscriber. 4757 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4758 address pool to release the address. 4760 7.12. Event TLVs 4761 7.12.1. Subscriber Traffic Statistics TLV 4763 The Subscriber Traffic Statistics TLV is used to return the traffic 4764 statistics of a user/subscriber. The format of this TLV is as 4765 follows: 4767 0 1 2 3 4768 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 4769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4770 | User-ID | 4771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4772 | Statistics Type | 4773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4774 | Ingress Packets (upper part) | 4775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4776 | Ingress Packets (lower part) | 4777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4778 | Ingress Bytes (upper part) | 4779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4780 | Ingress Bytes (lower part) | 4781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4782 | Ingress Loss Packets (upper part) | 4783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4784 | Ingress Loss Packets (lower part) | 4785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4786 | Ingress Loss Bytes (upper part) | 4787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4788 | Ingress Loss Bytes (lower part) | 4789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4790 | Egress Packets (upper part) | 4791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4792 | Egress Packets (lower part) | 4793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4794 | Egress Bytes (upper part) | 4795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4796 | Egress Bytes (lower part) | 4797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4798 | Egress Loss Packets (upper part) | 4799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4800 | Egress Loss Packets (lower part) | 4801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4802 | Egress Loss Bytes (upper part) | 4803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4804 | Egress Loss Bytes (lower part) | 4805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4807 Figure 67: Subscriber Traffic Statistics TLV 4809 Where: 4811 The TLV type: 300. 4813 The TLV length is 72 octets. 4815 User-ID (4 bytes): The subscriber identifier. 4817 Statistics-Type (4 bytes): Traffic type. It can be one of the 4818 following options: 4820 0: IPv4 traffic. 4821 1: IPv6 traffic. 4822 2: Dual stack traffic. 4824 Ingress Packets (8 bytes): The number of the packets in upstream 4825 direction. 4827 Ingress Bytes (8 bytes): The bytes of the upstream traffic. 4829 Ingress Loss Packets (8 bytes): The number of the lost packets in 4830 upstream direction. 4832 Ingress Loss Bytes (8 bytes): The bytes of the lost upstream 4833 packets. 4835 Egress Packets (8 bytes): The number of the packets in downstream 4836 direction. 4838 Egress Bytes (8 bytes): The bytes of the downstream traffic. 4840 Egress Loss Packets (8 bytes): The number of the lost packets in 4841 downstream direction. 4843 Egress Loss Bytes (8 bytes): The bytes of the lost downstream 4844 packets. 4846 7.12.2. Subscriber Detection Result TLV 4848 The Subscriber Detection Result TLV is used to return the detection 4849 result of a subscriber. Subscriber detection is a function to detect 4850 whether a subscriber is online or not. The result can be used by the 4851 CP to determine how to deal with the subscriber session. (e.g., 4852 delete the session if detection failed). 4854 The format of this TLV value part is as follows: 4856 0 1 2 3 4857 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 4858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4859 | User-ID | 4860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4861 | Detect Type | Detect Result | Reserved | 4862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4864 Figure 68: Subscriber Detection Result TLV 4866 Where: 4868 The TLV type: 301. 4870 The TLV length is 8 octets. 4872 User-ID (4 bytes): The subscriber identifier. 4874 Detect-Type (1 byte): 4876 0: IPv4 detection. 4877 1: IPv6 detection. 4878 2: PPP detection. 4880 Detect-Result (1 byte): 4882 0: Indicates that the detection is successful. 4884 1: Detection failure. The UP needs report only when the 4885 detection fails. 4887 The Reserved field MUST be sent as zero and ignored on receipt. 4889 7.13. Vendor TLV 4891 The Vendor ID TLV occurs as the first TLV in the Vendor message 4892 (Section 6.6). It provides a Sub-Type that effectively extends the 4893 message type in the message header, provides for versioning of vendor 4894 TLVs, and can accommodate sub-TLVs. 4896 The value part of the Vendor TLV is formatted as follows: 4898 0 1 2 3 4899 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 4900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4901 | Vendor ID | 4902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4903 | Sub-Type | Sub-Type-Version | 4904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4905 ~ sub-TLVs (optional) ~ 4906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4908 Figure 69: Vendor TLV 4910 Where: 4912 The TLV type: 1024. 4914 The TLV length is variable. 4916 Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS [RFC2865]. 4918 Sub-Type (2 bytes): Used by the Vendor to distinguish multiple 4919 different vendor messages. 4921 Sub-Type-Version (2 bytes): Used by the Vendor to distinguish 4922 different versions of a Vendor-Defined message sub-type. 4924 Sub-TLVs (variable): Sub-TLVs as specified by the vendor. 4926 Since Vendor code will be handling the TLV after the Vendor ID field 4927 is recognized, the remainder of the TLV value can be organized 4928 however the vendor wants. But it is desirable for a vendor to be able 4929 to define multiple different vendor messages and to keep track of 4930 different versions of its vendor-defined messages. Thus, it is 4931 RECOMMENDED that the vendor assign a Sub-Type value for each vendor 4932 message that it defines different from other Sub-Type values that 4933 vendor has used. Also, when modifying a vendor-defined message in a 4934 way potentially incompatible with a previous definition, the vendor 4935 SHOULD increase the value it is using in the Sub-Type-Version field. 4937 8. Implementation Status 4939 RFC Editor: Please remove this section before publication. 4941 This section discusses the status of implementations that have 4942 provided information and the testing of this protocol at the time of 4943 posting of this Internet-Draft, and is based on the proposal in 4944 [RFC7942] ("Improving Awareness of Running Code: The Implementation 4945 Status Section"). The description of implementations in this section 4946 is intended to assist in processing drafts to RFCs. 4948 Please note that the listing of any individual implementation or test 4949 results here does not imply endorsement by the RFC Series Editor 4950 (RSE), the Independent Submissions Editor (ISE), or the IETF. 4951 Furthermore, no effort has been spent to verify the information 4952 presented here that was supplied by contributors. This is not 4953 intended as, and must not be construed to be, a catalog of available 4954 implementations or their testing or features. Readers are advised to 4955 note that other implementations may exist. 4957 According to [RFC7942], "this will allow reviewers ... to assign due 4958 consideration to documents that have the benefit of running code, 4959 which may serve as evidence of valuable experimentation and feedback 4960 that have made the implemented protocols more mature.". 4962 8.1. Implementations 4964 Information on three S-CUSP implementations appears below. 4966 8.1.1. Huawei Technologies 4968 Name: Cloud-based BNG. 4970 Maturity: Production. 4972 Coverage: According to S-CUSP protocol. 4974 Contact information: 4975 Zhouyi Yu: yuzhouyi@huawei.com 4977 Date: 2018-11-01 4979 8.1.2. ZTE 4981 Name: ZXR10 V6000 vBRAS 4983 Maturity: Production 4985 Coverage: According to S-CUSP protocol. 4987 Contact information: 4988 Yong Chen: 10056167@zte.com.cn 4989 Huaibin Wang: 10008729@zte.com.cn 4991 Date: 2018-12-01 4993 8.1.3. H3C 4995 Name: CUSP protocol for BRAS Control Plane and User Plane 4996 Separation 4998 Maturity: Research 5000 Coverage: According to S-CUSP protocol 5002 Contact information: mengdan@h3c.com; liuhanlei@h3c.com 5004 Date: 2019-1-30 5006 8.2. Hackathon 5008 Successful use of the protocol at the IETF-102 Hackathon, Montreal, 5009 Quebec, in 2018. 5011 Hackathon Project: Control Plane and User Plane Separation BNG 5012 control channel Protocol (CUSP) 5014 Champions: Zhenqiang Li, Michael Wang 5016 Report: See 5017 github.com/IETF-Hackathon/ietf102-project-presentations/blob/ 5018 master/IETF102-hackathon-presentation-CUSP.pptx 5020 8.3. EANTC Testing 5022 EANTC (European Advanced Networking Test Center (www.eantc.de)) 5023 tested the Huawei implementation. Their summary was as follows: 5024 "EANTC tested advanced aspects of the Cloud-based Broadband Network 5025 Gateway (vBNG) with a focus on performance, scalability and high 5026 availability with up to 20 Million emulated subscribers. The solution 5027 performed very well across all test scenarios." 5029 See report at 5030 www.eantc.de/fileadmin/eantc/downloads/News/2018/EANTC-vBRAS- 5031 phase2.pdf 5033 9. Tables of S-CUSP Codepoints 5035 This section provides tables of the S-CUSP codepoints, particularly 5036 message types, TLV types, TLV operation codes, sub-TLV types, and 5037 error codes. In most cases, references are provided to relevant 5038 sections elsewhere in this document. 5040 9.1. Message Types 5042 Type Name Section of this document 5043 ------- ---------------- ------------------------ 5044 0 reserved 5045 1 Hello 6.2.1. 5046 2 Keepalive 6.2.2. 5047 3 Sync_Request 6.2.3. 5048 4 Sync_Begin 6.2.4. 5049 5 Sync_Data 6.2.5. 5050 6 Sync_End 6.2.6. 5051 7 Update_Request 6.2.7. 5052 8 Update_Response 6.2.8. 5053 9 Report 6.4. 5054 10 Event 6.3. 5055 11 Vendor 6.6. 5056 12 Error 6.7. 5057 13-199 unassigned 5058 200 Addr_Allocation_Req 6.5.1. 5059 201 Addr_Allocation_Ack 6.5.2. 5060 202 Addr_Renew_Req 6.5.3. 5061 203 Addr_Renew_Ack 6.5.4. 5062 204 Addr_Release_Req 6.5.5. 5063 205 Addr_Release_Ack 6.5.6. 5064 206-254 unassigned 5065 255 reserved 5067 9.2. TLV Types 5069 Type Name Usage Description 5070 ------ ------------ -------------------------- 5071 0 reserved - 5072 1 BAS Function Carries the BNG access 5073 functions to be enabled or 5074 disabled on specified 5075 interfaces. 5076 2 Basic Subscriber Carries the basic information 5077 about a BNG subscriber. 5078 3 PPP Subscriber Carries the PPP information 5079 about a BNG subscriber. 5080 4 IPv4 Subscriber Carries the IPv4 address of a 5081 BNG subscriber. 5082 5 IPv6 Subscriber Carries the IPv6 address of a 5083 BNG subscriber. 5084 6 Subscriber Policy Carries the policy information 5085 applied to a BNG subscriber. 5086 7 IPv4 Routing Carries the IPv4 network 5087 routing information. 5088 8 IPv6 Routing Carries the IPv6 network 5089 routing information. 5090 9 IPv4 Static Subscriber Detect Carries the IPv4 static 5091 subscriber detect information. 5092 10 IPv6 Static Subscriber Detect Carries the IPv6 static 5093 subscriber detect information. 5094 11 L2TP-LAC Subscriber Carries the L2TP LAC 5095 subscriber information. 5096 12 L2TP-LNS Subscriber Carries the L2TP LNS 5097 subscriber information. 5098 13 L2TP-LAC-Tunnel Carries the L2TP LAC tunnel 5099 subscriber information. 5100 14 L2TP-LNS-Tunnel Carries the L2TP LNS tunnel 5101 subscriber information. 5102 15 Subscriber CGN Port Range Carries the public IPv4 5103 address and related port range 5104 of a BNG subscriber. 5105 16-99 unassigned - 5106 100 Hello Used for version and Keepalive 5107 timers negotiation. 5108 101 Error Information Carried in the Ack of the 5109 control message. Carries the 5110 processing result, success, or 5111 error. 5112 102 Keepalive Carried in the Hello message 5113 for Keepalive timers 5114 negotiation. 5115 103-199 unassigned - 5116 200 Interface Status Interfaces status reported by 5117 the UP including physical 5118 interfaces, sub-interfaces, 5119 trunk interfaces, and tunnel 5120 interfaces. 5121 201 Board Status Board information reported by 5122 the UP including the board 5123 type and in-position status. 5124 202-299 unassigned - 5125 300 Subscriber Traffic Statistics User traffic statistics. 5126 301 Subscriber Detection Results User detection information. 5127 302 Update Response The processing result of a 5128 subscriber session update. 5130 303-299 unassigned - 5131 400 Address Allocation Request Request address allocation. 5132 401 Address Allocation Response Address allocation response. 5133 402 Address Renewal Request Request for address lease 5134 renewal. 5135 403 Address Renewal Response Response to a request for 5136 extending an IP address lease. 5137 404 Address Release Request Request to release the 5138 address. 5139 405 Address Release Response Ack of a message releasing an 5140 IP address. 5141 406-1023 unassigned - 5142 1024 Vendor As implemented by vendor. 5143 1039-4095 unassigned - 5145 9.3. TLV Operation Codes 5147 TLV operation codes appear in the Oper field in the header of some 5148 TLVs. See Section 7.1. 5150 Code Operation 5151 ---- ---------- 5152 0 reserved 5153 1 Update 5154 2 Delete 5155 3-15 unassigned 5157 9.4. Sub-TLV Types 5159 See Section 7.3. 5161 Type Name Section of this document 5162 ---- ------------------ ------------------------ 5163 0 reserved 5164 1 VRF Name 7.3.1. 5165 2 Ingress-QoS-Profile 7.3.1. 5166 3 Egress-QoS-Profile 7.3.1. 5167 4 User-ACL-Policy 7.3.1. 5168 5 Multicast-ProfileV4 7.3.1. 5169 6 Multicast-ProfileV6 7.3.1. 5170 7 Ingress-CAR 7.3.2. 5171 8 Egress-CAR 7.3.3. 5172 9 NAT-Instance 7.3.1. 5173 10 Pool-Name 7.3.1. 5174 11 If-Desc 7.3.4. 5175 12 IPv6-Address List 7.3.5. 5176 13 Vendor 7.3.6. 5177 12-64534 unassigned 5178 65535 reserved 5180 9.5. Error Codes 5182 Value Name Remarks 5183 ------- ------- -------- 5184 0 Success Success 5186 1 Fail Malformed message received. 5187 2 TLV-Unknown One or more of the TLVs was not 5188 understood. 5189 3 TLV-Length The TLV length is abnormal. 5190 4-999 unassigned Unassigned basic error codes. 5191 1000 reserved 5192 1001 Version-Mismatch The version negotiation fails. Terminate. 5193 The subsequent service processes 5194 corresponding to the UP are suspended. 5195 1002 Keepalive Error The keepalive negotiation fails. 5196 1003 Timer Expires The establishment timer expired. 5197 1004-1999 unassigned Unassigned error codes for version 5198 negotiation. 5199 2000 reserved 5200 2001 Synch-NoReady The data to be smoothed is not ready. 5201 2002 Synch-Unsupport The request for smooth data is not 5202 supported. 5203 2003-2999 unassigned Unassigned data synchronization error 5204 codes. 5206 3000 reserved 5207 3001 Pool-Mismatch The corresponding address pool cannot be 5208 found. 5209 3002 Pool-Full The address pool is fully allocated and no 5210 address segment is available. 5211 3003 Subnet-Mismatch The address pool subnet cannot be found. 5212 3004 Subnet-Conflict Subnets in the address pool have been 5213 classified into other clients. 5214 3005-3999 unassigned Unassigned error codes for address 5215 allocation. 5216 4000 reserved 5217 4001 Update-Fail-No-Res The forwarding table fails to be 5218 delivered because the forwarding resources 5219 are insufficient. 5220 4002 QoS-Update-Success The QoS policy takes effect. 5221 4003 QoS-Update-Sq-Fail Failed to process the queue in the QoS 5222 policy. 5223 4004 QoS-Update-CAR-Fail Processing of the CAR in the QoS 5224 policy fails. 5225 4005 Statistic-Fail-No-Res Statistics processing failed due to 5226 insufficient statistics resources. 5227 4006-4999 unassigned forwarding table delivery error codes. 5229 5000-4294967295 reserved 5231 9.6. If-Type Values 5233 Defined values of the If-Type field in the If-Desc sub-TLV (see 5234 Section 7.3.4) are as follows: 5236 Value Meaning 5237 ----- ------------ 5238 0 reserved 5239 1 Fast Ethernet (FE) 5240 2 GE 5241 3 10GE 5242 4 100GE 5243 5 Eth-Trunk 5244 6 Tunnel 5245 7 VE 5246 8-254 unassigned 5247 255 reserved 5249 9.7. Access-Mode Values 5251 Defined values of the Access-Mode field in the BAS Function TLV (see 5252 Section 7.7) are as follows: 5254 Value Meaning 5255 ----- ---------- 5256 0 Layer 2 subscriber 5257 1 Layer 3 subscriber 5258 2 Layer 2 leased line 5259 3 Layer 3 leased line 5260 4-254 unassigned 5261 255 reserved. 5263 9.8. Access Method Bits 5265 Defined values of the Auth-Method4 and Auth-Method6 fields in the BAS 5266 Function TLV (see Section 7.7) are defined as bit fields as follows: 5268 Auth-Method4 5269 Bit Meaning 5270 ---- --------- 5271 0x01 PPPoE authentication 5272 0x02 DOT1X authentication 5273 0x04 Web authentication 5274 0x08 Web fast authentication 5275 0x10 Binding authentication 5276 0x20 reserved 5277 0x40 reserved 5278 0x80 reserved 5280 Auth-Method6 5281 Bit Meaning 5282 ---- --------- 5283 0x01 PPPoE authentication 5284 0x02 DOT1X authentication 5285 0x04 Web authentication 5286 0x08 Web fast authentication 5287 0x10 Binding authentication 5288 0x20 reserved 5289 0x40 reserved 5290 0x80 reserved 5292 9.9. Route-Type Values 5294 Values of the Route-Type field in the IPv4 and IPv6 Routing TLVs (see 5295 Section 7.8.1 and 7.8.2) defined in this document are as follows: 5297 Value Meaning 5298 ------- --------- 5299 0 User host route 5300 1 Radius authorization FrameRoute 5301 2 Network segment route 5302 3 Gateway route 5303 4 Radius authorized IP route 5304 5 L2TP LNS side user route 5305 6-65534 unassigned 5306 65535 reserved 5308 9.10. Access-Type Values 5310 Values of the Access-Type field in the Basic Subscriber TLV (see 5311 Section 7.9.1) defined in this document are as follows: 5313 Access-Type 5314 Value Meaning 5315 ------ ---------- 5316 0 reserved 5317 1 PPP access (PPP [RFC1661]) 5318 2 PPP over Ethernet over ATM access (PPPoEoA) 5319 3 PPP over ATM access (PPPoA [RFC3336]) 5320 4 PPP over Ethernet access (PPPoE [RFC2516]) 5321 5 PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) 5322 6 PPP over LNS access (PPPoLNS) 5323 7 IP over Ethernet DHCP access (IPoE_DHCP) 5324 8 IP over Ethernet EAP authentication access (IPoE_EAP) 5325 9 IP over Ethernet Layer 3 access (IPoE_L3) 5326 10 IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) 5327 11 Layer 2 Leased Line access (L2_Leased_Line) 5328 12 Layer 2 VPN Leased Line access (L2VPN_Leased_Line) 5329 13 Layer 3 Leased Line access (L3_Leased_Line) 5330 14 Layer 2 Leased line Sub-User access 5331 (L2_Leased_Line_SUB_USER) 5332 15 L2TP LAC tunnel access (L2TP_LAC) 5333 16 L2TP LNS tunnel access (L2TP_LNS) 5334 17-254 unassigned 5335 255 reserved 5337 10. IANA Considerations 5339 This document requires no IANA actions. 5341 11. Security Considerations 5343 The Service, Control, and Management Interfaces between the CP and UP 5344 might be across the general Internet or other hostile environment. 5345 The ability of an adversary to block or corrupt messages or introduce 5346 spurious messages on any one or more of these interfaces would give 5347 the adversary the ability to stop subscribers from accessing network 5348 services, disrupt existing subscriber sessions, divert traffic, mess 5349 up accounting statistics, and generally cause havoc. Damage would not 5350 necessarily be limited to one or a few subscribers but could disrupt 5351 routing or deny service to one or more instances of the CP or 5352 otherwise cause extensive interference. If the adversary knows the 5353 details of the UP equipment and its forwarding rule capabilities, the 5354 adversary may be able to cause a copy of most or all user data to be 5355 sent to an address of the adversary's choosing, thus enabling 5356 eavesdropping. 5358 Thus, appropriate protections MUST be implemented to provide 5359 integrity, authenticity, and secrecy of traffic over those 5360 interfaces. Whether such protection is used is a network operator 5361 decision. See [RFC6241] for Management Interface / NETCONF security. 5362 Security on the Service Interface is dependent on the tunneling 5363 protocol used which is out of scope for this document. Security for 5364 the Control Interface, over which the S-CUSP protocol flows, is 5365 further discussed below. 5367 S-CUSP messages do not provide security. Thus, if these messages are 5368 exchanged in an environment where security is a concern, that 5369 security MUST be provided by another protocol such as TLS 1.3 5370 [RFC8446] or IPSEC. TLS 1.3 is the mandatory to implement protocol 5371 for interoperability. The use of a particular security protocol on 5372 the Control Interface is determined by configuration. Such security 5373 protocols need not always be used and lesser security precautions 5374 might be appropriate because, in some cases, the communication 5375 between the CP and UP is in a benign environment. 5377 Contributors 5379 Zhenqiang Li 5380 China Mobile 5381 32 Xuanwumen West Ave, Xicheng District 5382 Beijing, Beijing 100053 5383 China 5385 Email: lizhenqiang@chinamobile.com 5387 Mach (Guoyi) Chen 5388 Huawei Technologies 5389 Huawei Bldg., No. 156 Beiqing Road 5390 Beijing 100095 China 5392 Email: mach.chen@huawei.com 5394 Zhouyi Yu 5395 Huawei Technologies 5397 Email: yuzhouyi@huawei.com 5399 Chengguang Niu 5400 Huawei Technologies 5402 Email: chengguang.niu@huawei.com 5404 Zitao Wang 5405 Huawei Technologies 5407 Email: wangzitao@huawei.com 5409 Jun Song 5410 Huawei Technologies 5412 Email: song.jun@huawei.com 5414 Dan Meng 5415 H3C Technologies 5416 No.1 Lixing Center 5417 No.8 guangxun south street, Chaoyang District, 5418 Beijing, 100102 5419 China 5420 Email: mengdan@h3c.com 5422 Hanlei Liu 5423 H3C Technologies 5424 No.1 Lixing Center 5425 No.8 guangxun south street, Chaoyang District, 5426 Beijing, 100102 5427 China 5429 Email: hanlei_liu@h3c.com 5431 Victor Lopez 5432 Telefonica 5433 Spain 5435 Email: victor.lopezalvarez@telefonica.com 5437 Acknowledgements 5439 The helpful comments and suggestions of the following are hereby 5440 acknowledged: 5442 Loa Andersson 5444 Greg Mirsky 5446 Normative References 5448 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 5449 20, DOI 10.17487/RFC0020, October 1969, . 5452 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 5453 DOI 10.17487/RFC0793, September 1981, . 5456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5457 Requirement Levels", BCP 14, RFC 2119, DOI 5458 10.17487/RFC2119, March 1997, . 5461 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 5462 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 5463 2661, DOI 10.17487/RFC2661, August 1999, . 5466 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 5467 "Remote Authentication Dial In User Service (RADIUS)", RFC 5468 2865, DOI 10.17487/RFC2865, June 2000, . 5471 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5472 and A. Bierman, Ed., "Network Configuration Protocol 5473 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5474 . 5476 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 5477 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 5478 2017, . 5480 Informative References 5482 [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area 5483 networks / Bridges and Bridged Networks", IEEE Std 5484 802.1Q-2014, 3 November 2013. 5486 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 5487 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 5488 . 5490 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 5491 DOI 10.17487/RFC2131, March 1997, . 5494 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 5495 and R. Wheeler, "A Method for Transmitting PPP Over 5496 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 5497 1999, . 5499 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 5500 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 5501 . 5503 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 5504 Address Translator (Traditional NAT)", RFC 3022, DOI 5505 10.17487/RFC3022, January 2001, 5508 [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over 5509 Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 5510 3336, DOI 10.17487/RFC3336, December 2002, 5511 . 5513 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used 5514 to Form Encoding Rules in Various Routing Protocol 5515 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 5516 2009, . 5518 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 5519 IETF Protocol and Documentation Usage for IEEE 802 5520 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 5521 October 2013, . 5523 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 5524 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 5525 eXtensible Local Area Network (VXLAN): A Framework for 5526 Overlaying Virtualized Layer 2 Networks over Layer 3 5527 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 5528 . 5530 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5531 Code: The Implementation Status Section", BCP 205, RFC 5532 7942, DOI 10.17487/RFC7942, July 2016, . 5535 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5536 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5537 . 5539 [TR-384] Broadband Forum, "Cloud Central Office Reference 5540 Architectural Framework", BBF TR-384, 2018. 5542 Authors' Addresses 5544 Shujun Hu 5545 China Mobile 5546 32 Xuanwumen West Ave, Xicheng District 5547 Beijing, Beijing 100053 5548 China 5550 Email: hushujun@chinamobile.com 5552 Donald Eastlake, 3rd 5553 Futurewei Technologies 5554 1424 Pro Shop Court 5555 Davenport, FL 33896 5556 USA 5558 Phone: +1-508-333-2270 5559 Email: d3e3e3@gmail.com 5561 Fengwei Qin 5562 China Mobile 5563 32 Xuanwumen West Ave, Xicheng District 5564 Beijing, Beijing 100053 5565 China 5567 Email: qinfengwei@chinamobile.com 5569 Tee Mong Chua 5570 Singapore Telecommunications Limited 5571 31 Exeter Road, #05-04 Comcentre Podium Block 5572 Singapore City 239732 5573 Singapore 5575 Email: teemong@singtel.com 5577 Daniel Huang 5578 ZTE 5580 Email: huang.guangping@zte.com.cn 5582 Copyright, Disclaimer, and Additional IPR Provisions 5584 Copyright (c) 2019 IETF Trust and the persons identified as the 5585 document authors. All rights reserved. 5587 This document is subject to BCP 78 and the IETF Trust's Legal 5588 Provisions Relating to IETF Documents 5589 (http://trustee.ietf.org/license-info) in effect on the date of 5590 publication of this document. Please review these documents 5591 carefully, as they describe your rights and restrictions with respect 5592 to this document. Code Components extracted from this document must 5593 include Simplified BSD License text as described in Section 4.e of 5594 the Trust Legal Provisions and are provided without warranty as 5595 described in the Simplified BSD License.