idnits 2.17.1 draft-chz-simple-cu-separation-bng-protocol-03.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 == Line 3696 has weird spacing: '...RF-Name and/o...' -- The document date (June 27, 2019) is 1764 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Hu 2 Intended status: Informational China Mobile 3 D. Eastlake 4 Futurewei Technologies 5 M. Chen 6 Huawei Technologies 7 F. Qin 8 Z. Li 9 China Mobile 10 T. Chua 11 Singapore Telecommunications 12 D. Huang 13 ZTE 14 Expires: December 26, 2019 June 27, 2019 16 The China Mobile, Huawei, and ZTE BNG 17 Simple Control and User Plane Separation Protocol (S-CUSP) 18 draft-chz-simple-cu-separation-bng-protocol-03 20 Abstract 22 To support Control Plane (CP) and User Plane (UP) Separation (CUPS) 23 for fixed network Broadband Network Gateway (BNG) service providers, 24 China Mobile, Huawei Technologies, and ZTE have developed a simple 25 CUPS control channel Protocol (S-CUSP). 27 This document is not an IETF standard and does not have IETF 28 consensus. It is presented here to make the S-CUSP 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 58 2. Terminology............................................7 59 2.1. Implementation Requirement Keywords................7 60 2.2. Terms..............................................7 62 3. BNG CUPS Overview.....................................10 63 3.1. BNG CUPS Motivation...............................10 64 3.2. BNG CUPS Architecture Overview....................10 65 3.3. BNG CUPS Interfaces...............................12 66 3.3.1. Service Interface...............................13 67 3.3.2. Control Interface...............................14 68 3.3.3. Management Interface............................14 69 3.4. BNG CUPS Procedure Overview.......................14 71 4. S-CUSP Protocol Overview..............................18 72 4.1. Control Channel Related Procedures................18 73 4.1.1. S-CUSP Session Establishment....................18 74 4.1.2. Keep Alive......................................19 75 4.2. Node Related Procedures...........................20 76 4.2.1. UP Resource Report..............................20 77 4.2.2. Update BAS Function on Access Interface.........21 78 4.2.3. Update Network Routing..........................21 79 4.2.4. CGN Public IP Address Allocation................22 80 4.2.5. Data Synchronization between the CP and UP......23 81 4.3. Subscriber Session Related Procedures.............24 82 4.3.1. Create Subscriber Session.......................25 83 4.3.2. Update Subscriber Session.......................26 84 4.3.3. Delete Subscriber Session.......................27 85 4.3.4. Subscriber Session Events Report................27 87 5. S-CUSP Call Flows.....................................29 88 5.1. IPoE..............................................29 89 5.1.1. DHCPv4 Access...................................29 90 5.1.2. DHCPv6 Access...................................30 91 5.1.3. IPv6 SLAAC Access...............................32 92 5.1.4. DHCPv6 + SLAAC Access...........................33 93 5.1.5. DHCP Dual Stack Access..........................35 94 5.1.6. L2 Static Subscriber Access.....................37 95 5.2. PPPoE.............................................40 96 5.2.1. IPv4 PPPoE Access...............................40 97 5.2.2. IPv6 PPPoE Access...............................41 98 5.2.3. PPPoE Dual Stack Access.........................43 99 5.3. WLAN Access.......................................45 100 5.4. L2TP..............................................47 101 5.4.1. L2TP LAC Access.................................47 102 5.4.2. L2TP LNS IPv4 Access............................49 103 5.4.3. L2TP LNS IPv6 Access............................51 104 5.5. CGN (Carrier Grade NAT)...........................54 106 Table of Contents (continued) 108 5.6. L3 Leased Line Access.............................55 109 5.6.1. Web Authentication..............................55 110 5.6.2. User Traffic Trigger............................57 111 5.7. Multicast Access..................................58 113 6. S-CUSP Message Formats................................60 114 6.1. Common Message Header.............................60 115 6.2. Control Messages..................................61 116 6.2.1. Hello Message...................................61 117 6.2.2. Keepalive Message...............................62 118 6.2.3. Sync_Request Message............................62 119 6.2.4. Sync_Begin Message..............................62 120 6.2.5. Sync_Data Message...............................63 121 6.2.6. Sync_End Message................................63 122 6.2.7. Update_Request Message..........................64 123 6.2.8. Update_Response Message.........................64 124 6.3. Event Message.....................................65 125 6.4. Report Message....................................66 126 6.5. CGN Messages......................................66 127 6.5.1. Addr_Allocation_Req Message.....................66 128 6.5.2. Addr_Allocation_Ack Message.....................66 129 6.5.3. Addr_Renew_Req Message..........................67 130 6.5.4. Addr_Renew_Ack Message..........................67 131 6.5.5. Addr_Release_Req Message........................67 132 6.5.6. Addr_Release_Ack Message........................67 133 6.6. Vendor Message....................................67 134 6.7 Error Message.......................................68 136 7. S-CUSP TLVs and Sub-TLVs..............................69 137 7.1. Common TLV Header.................................69 138 7.2. Basic Data Fields.................................70 139 7.3. Sub-TLV Format and Sub-TLVs.......................71 140 7.3.1. Name sub-TLVs...................................71 141 7.3.2. Ingress-CAR sub-TLV.............................72 142 7.3.3. Egress-CAR sub-TLV..............................72 143 7.3.4. If-Desc sub-TLV.................................73 144 7.3.5. IPv6 Address List sub-TLV.......................75 145 7.3.6. Vendor sub-TLV..................................75 146 7.4. The Hello TLV.....................................77 147 7.5. The Keep Alive TLV................................78 148 7.6. The Error Information TLV.........................79 149 7.7. BAS Function TLV..................................79 150 7.8. Routing TLVs......................................82 151 7.8.1. IPv4 Routing TLV................................82 152 7.8.2. IPv6 Routing TLV................................84 153 7.9. Subscriber TLVs...................................85 154 7.9.1. Basic Subscriber TLV............................86 155 7.9.2. PPP Subscriber TLV..............................88 156 7.9.3. IPv4 Subscriber TLV.............................89 158 Table of Contents (continued) 160 7.9.4. IPv6 Subscriber TLV.............................90 161 7.9.5. IPv4 Static Subscriber Detect TLV...............91 162 7.9.6. IPv6 Static Subscriber Detect TLV...............93 163 7.9.7. L2TP-LAC Subscriber TLV.........................94 164 7.9.8. L2TP-LNS Subscriber TLV.........................95 165 7.9.9. L2TP-LAC Tunnel TLV.............................95 166 7.9.10. L2TP-LNS Tunnel TLV............................96 167 7.9.11. Update Response TLV............................97 168 7.9.12. Subscriber Policy TLV..........................98 169 7.9.13. Subscriber CGN Port Range TLV.................100 170 7.10. Device Status TLVs..............................100 171 7.10.1. Interface Status TLV..........................101 172 7.10.2. Board Status TLV..............................101 173 7.11. CGN TLVs........................................102 174 7.11.1. Address Allocation Request TLV................102 175 7.11.2. Address Allocation Response TLV...............103 176 7.11.3. Address Renewal Request TLV...................104 177 7.11.4. The Address Renewal Response TLV..............105 178 7.11.5. Address Release Request TLV...................106 179 7.11.6. The Address Release Response TLV..............106 180 7.12. Event TLVs......................................107 181 7.12.1. Subscriber Traffic Statistics TLV..............108 182 7.12.2. Subscriber Detection Result TLV...............109 183 7.13. Vendor TLV......................................110 185 8. Implementation Status................................112 186 8.1. Implementations..................................112 187 8.1.1. Huawei Technologies............................112 188 8.1.2. ZTE............................................113 189 8.1.3. H3C............................................113 190 8.2. Hackathon........................................113 191 8.3. EANTC Testing....................................114 193 9. Summary of Major S-CUSP Codepoints...................115 194 9.1. Message Types....................................115 195 9.2. TLV Types........................................115 196 9.3. TLV Operation Codes..............................117 197 9.4. Sub-TLV Types....................................118 198 9.5. Error Codes......................................118 200 10. IANA Considerations.................................120 201 11. Security Considerations.............................121 203 Contributors.............................................122 205 Normative References.....................................123 206 Informative References...................................124 208 Authors' Addresses.......................................126 210 1. Introduction 212 A fixed network Broadband Network Gateway (BNG) is an Ethernet- 213 centric IP edge router, and the aggregation point for user traffic. 214 To provide centralized session management, flexible address 215 allocation, high scalability for subscriber management capacity, and 216 cost-efficient redundancy, the Control/User (CU) separated BNG 217 framework is described in [TR-384]. The CU separated service Control 218 Plane (CP), which is responsible for user access authentication and 219 setting forwarding entries in User Planes (UPs), can be virtualized 220 and centralized. The routing control and forwarding plane, i.e. the 221 BNG user plane (local), can be distributed across the infrastructure. 222 Other structures can also be supported such as both CP and UP being 223 virtual or both being physical. 225 This document specifies the Simple CU Separation BNG control channel 226 Protocol (S-CUSP) for communications between a BNG Control Plane (CP) 227 and a set of User Planes (UPs). S-CUSP is designed to be flexible 228 and extensible so as to easily allow for additional messages and data 229 items, should further requirements be expressed in the future. 231 This document is not an IETF standard and does not have IETF 232 consensus. S-CUSP was designed by China Mobile, Huawei Technologies, 233 and ZTE, it is presented here to make the S-CUSP specification 234 conveniently available to the Internet community to enable diagnosis 235 and interoperability. 237 2. Terminology 239 This section specifies implementation requirement keywords and terms 240 used in this document. S-CUSP messages are described in this document 241 using Routing Backus-Naur Form (RBNF) as defined in [RFC5511]. 243 2.1. Implementation Requirement Keywords 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 247 "OPTIONAL" in this document are to be interpreted as described in BCP 248 14 [RFC2119] [RFC8174] when, and only when, they appear in all 249 capitals, as shown here. 251 2.2. Terms 253 This section specifies terms used in this document. 255 AAA: Authentication Authorization Accounting. 257 ACK: Acknowledgement message. 259 BAS: Broadband Access Server (BRAS, BNG). 261 BNG: Broadband Network Gateway. A broadband remote access server 262 (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic 263 to and from broadband remote access devices such as digital 264 subscriber line access multiplexers (DSLAM) on an Internet 265 Service Provider's (ISP) network. BRAS can also be referred to 266 as a Broadband Network Gateway (BNG). 268 BRAS: BRoadband Access Server (BNG). 270 CAR: Committed Access Rate. 272 CBS: Committed Burst Size. 274 CGN: Carrier Grade NAT. 276 Ci: Control Interface. 278 CIR: Committed Information Rate. 280 CoA: Change of Authorization. 282 CP: Control Plane. 284 CP is a user control management component which supports the 285 management of the UP's resources such as the user entry and 286 forwarding policy. 288 CPE: Customer Premises Equipment. 290 CU: Control-plane / User-plane. 292 CUSP: Control and User plane Separation Protocol. 294 DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the 295 priority and before the VLAN ID. (This bit was formerly the CFI 296 (Canonical Format Indicator).) [802.1Q] 298 DHCP: Dynamic Host Configuration Protocol [RFC2131]. 300 dial-up: This refers to the initial connection messages when a new 301 user appears. The name is left over from when users literally 302 dialed up on a modem equipped phone line but herein is applied to 303 other initial connection techniques. Initial connection is 304 frequently indicated by the receipt of packets over PPPoE 305 [RFC2516] or IPoE. 307 EMS: Element Management System. 309 IPoE: IP over Ethernet. 311 L2TP: Layer 2 Tunneling Protocol [RFC2661]. 313 LAC: L2TP Access Concentrator. 315 LNS: L2TP Network Server. 317 MAC: 48-bit Media Access Control address [RFC7042]. 319 MANO: Management and Orchestration. 321 Mi: Management Interface. 323 MSS: Maximum Segment Size. 325 MRU: Maximum Receive Unit. 327 NAT: Network Address Translation [RFC3022]. 329 ND: Neighbor Discovery. 331 NFV: Network Function Virtualization. 333 NFVI: NFV Infrastructure 335 PBS: Peak Burst Size. 337 PD: Prefix Delegation. 339 PIR: Peak Information Rate. 341 PPP: Point to Point Protocol [RFC1661]. 343 PPPoE: PPP over Ethernet [RFC2516]. 345 RBNF: Routing Backus-Naur Form [RFC5511]. 347 RG: Residential Gateway. 349 S-CUSP: Simple Control and User Plane Separation Protocol. 351 Si: Service Interface. 353 TLV: Type, Length, Value. See Sections 7.1 and 7.3. 355 UP: User Plane. UP is a network edge and user policy implementation 356 component. The traditional router's Control Plane and Forwarding 357 Plane are both preserved on BNG devices in the form of a user 358 plane. 360 URPF: Unicast Reverse Path Forwarding. 362 User: Equivalent to "customer" or "subscriber". 364 VRF: Virtual Routing and Forwarding. 366 3. BNG CUPS Overview 368 3.1. BNG CUPS Motivation 370 The rapid development of new services, such as 4K TV, IoT, etc., and 371 increasing numbers of home broadband service users present some new 372 challenges for BNGs such as: 374 Low resource utilization: The traditional BNG acts as both a gateway 375 for user access authentication and accounting and an IP network's 376 Layer 3 edge. The mutually affecting nature of the tightly 377 coupled control plane and forwarding plane makes it difficult to 378 achieve the maximum performance of either plane. 380 Complex management and maintenance: Due to the large numbers of 381 traditional BNGs, configuring each device in a network is very 382 tedious when deploying global service policies. As the network 383 expands and new services are introduced, this deployment mode 384 will cease to be feasible as it is unable to manage services 385 effectively and rectify faults rapidly. 387 Slow service provisioning: The coupling of control plane and 388 forwarding plane, in addition to a distributed network control 389 mechanism, means that any new technology has to rely heavily on 390 the existing network devices. 392 To address these challenges for fixed networks, the framework for a 393 cloud-based BNG with Control Plane and User Plane (CU) separation is 394 described in [TR-384]. The main idea of CU separation is to extract 395 and centralize the user management functions of multiple BNG devices, 396 forming a unified and centralized Control Plane (CP). And the 397 traditional router's Control Plane and Forwarding Plane are both 398 preserved on BNG devices in the form of a User Plane (UP). 400 3.2. BNG CUPS Architecture Overview 402 The functions in a traditional BNG can be divided into two parts: one 403 is the user access management function, the other is the router 404 function. The user management function can be centralized and 405 deployed as a concentrated module or device, called the BNG Control 406 Plane (BNG-CP). The other functions, such as the router function and 407 forwarding engine, can be deployed in the form of the BNG User Plane 408 (BNG-UP). 410 The following figure shows the architecture of CU separated BNG: 412 +------------------------------------------------------------------+ 413 | Neighboring policy and resource management systems | 414 | | 415 | +-------------+ +-----------+ +---------+ +----------+ | 416 | |AAA Server| |DHCP Server| | EMS | | MANO | | 417 | +-------------+ +-----------+ +---------+ +----------+ | 418 +------------------------------------------------------------------+ 420 +------------------------------------------------------------------+ 421 | CU-separated BNG system | 422 | +--------------------------------------------------------------+ | 423 | | +----------+ +----------+ +------++------++-----------+ | | 424 | | | Address | |Subscriber| | AAA ||Access|| UP | | | 425 | | |management| |management| | || Mgt ||management | | | 426 | | +----------+ +----------+ +------++------++-----------+ | | 427 | | CP | | 428 | +--------------------------------------------------------------+ | 429 | | 430 | | 431 | | 432 | +---------------------------+ +--------------------------+ | 433 | | +------------------+ | | +------------------+ | | 434 | | | Routing control | | | | Routing control | | | 435 | | +------------------+ | ... | +------------------+ | | 436 | | +------------------+ | | +------------------+ | | 437 | | |Forwarding engine | | | |Forwarding engine | | | 438 | | +------------------+ UP | | +------------------+ UP| | 439 | +---------------------------+ +--------------------------+ | 440 +------------------------------------------------------------------+ 442 Figure 1: Architecture of CU Separated BNG 444 As shown in Figure 1, the BNG Control Plane could be virtualized and 445 centralized, which provides benefits such as centralized session 446 management, flexible address allocation, high scalability for 447 subscriber management capacity, and cost-efficient redundancy, etc. 448 The functional components inside the BNG Service Control Plane can be 449 implemented as Virtual Network Functions (VNFs) and hosted in a 450 Network Function Virtualization Infrastructure (NFVI). 452 The User Plane Management module in the BNG Control Plane centrally 453 manages the distributed BNG User Planes (e.g. load balancing), as 454 well as the setup, deletion, and maintenance of channels between 455 Control Planes and User Planes. Other modules in the BNG control 456 plane, such as address management, AAA, etc., are responsible for the 457 connection with outside subsystems in order to fulfill those 458 services. Note that the User Plane SHOULD support both physical and 459 virtual network functions. For example, BNG user plane L3 forwarding 460 related network functions can be disaggregated and distributed across 461 the physical infrastructure. And the other control plane and 462 management plane functions in the CU Separation BNG can be moved into 463 the NFVI for virtualization [TR-384]. 465 The details of CU separated BNG's function components are as 466 following: 468 The Control Plane is responsible for the following: 470 1. Address management: unified address pool management and CGN 471 subscriber address traceability management. 473 2. AAA: This component performs Authentication, Authorization and 474 Accounting, together with RADIUS/DIAMETER. The BNG communicates 475 with the AAA server to check whether the subscriber who sent an 476 Access-Request has network access authority. Once the subscriber 477 goes online, this component together with the Service Control 478 component implement accounting, data capacity limitation, and QoS 479 enforcement policies. 481 3. Subscriber management: user entry management and forwarding 482 policy management. 484 4. Access management: process user dial-up packets, such as PPPoE, 485 DHCP, L2TP, etc. 487 5. UP management: management of UP interface status, and the setup, 488 deletion, and maintenance of channels between CP and UP. 490 The User Plane is responsible for the following: 492 1. Routing control functions: responsible for constructing routing 493 forwarding plane (e.g., routing, multicast, MPLS, etc.). 495 2. Routing and Service Forwarding plane functions: responsible 496 including traffic forwarding, QoS and traffic statistics 497 collection. 499 Subscriber detection: responsible for detecting whether a subscriber 500 is still online. 502 3.3. BNG CUPS Interfaces 504 To support the communication between the Control Plane and User 505 Plane, three interfaces are assumed. These are referred to as the 506 Service Interface (Si), Control Interface (Ci), and Management 507 Interface (Mi) as shown in Figure 2. 509 +-----------------------------------+ 510 | | 511 | BNG-CP | 512 | | 513 +--+--------------+--------------+--+ 514 | | | 515 1. Service | 2. Control | 3. Management| 516 Interface | Interface | Interface | 517 (Si) | (Ci) | (Mi) | 518 | | | 519 | ___|___ | 520 | ___( )___ | 521 _|______( )______|_ 522 ( ) 523 ( Network/Internet ) 524 (________ ________) 525 | (___ ___) | 526 | (_______) | 527 | | | 528 | | | 529 +--+--------------+--------------+--+ 530 | | 531 | BNG-UP | 532 | | 533 +-----------------------------------+ 535 Figure 2: Interfaces Between the CP and UP of the BNG 537 3.3.1. Service Interface 539 For a traditional BNG (without CU separation), the user dial-up 540 signals are terminated and processed by the control plane of a BNG. 541 When the CP and UP of a BNG are separated, there needs to be a way to 542 relay these signals between the CP and the UP. 544 The Service Interface (Si) is used to establish tunnels between the 545 CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, 546 and L2TP related control packets that are received from a Residential 547 Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN 548 [RFC7348]. 550 The detailed definition of Si is out of scope for this document. 552 3.3.2. Control Interface 554 The CP uses the Control Interface to deliver subscriber session 555 states, network routing entries, etc. to the UP (see Section 6.2.7)). 556 The UP uses this interface to report subscriber service statistics, 557 subscriber detection results, etc. to the CP (see Sections 6.3 and 558 6.4). A carrying protocol for this interface is specified in this 559 document. 561 3.3.3. Management Interface 563 NETCONF [RFC6241] is the protocol used on the Management Interface 564 between a CP and UP. It is used to configure the parameters of the 565 Control Interface, Service Interface, the Access interfaces and 566 QoS/ACL Templates. It is expected that implementations will make use 567 of existing YANG models where possible, but that new YANG models 568 specific to S-CUSP will need to be defined. The definitions of the 569 parameters are out of scope for this document. 571 3.4. BNG CUPS Procedure Overview 573 The following numbered sequences (Figure 3) gives a high level view 574 of the main BNG CUPS procedures. 576 RG UP CP AAA 577 | | | | 578 | |Establish S-CUSP Channel| | 579 | 1|<---------------------->| | 580 | | | | 581 | | Report Board | | 582 | | interface | | 583 | | information | | 584 | 2|------to CP via Ci----->| | 585 | | | | 586 | | Update BAS function | | 587 | 3| request / response | | 588 | |<-----on UP via Ci----->| | 589 | | | | 590 | | Update network routing | | 591 | | request / response | | 592 | 4|<------- via Ci-------->| | 593 | | | | 594 | Online Req | | | 595 5.1|-------------->| | | 596 | | Relay the Online Req | | 597 | 5.2|-----to CP via Si------>| Authentication| 598 | | | Req/Rep | 599 | | 5.3|<------------->| 600 | | Send the Online Rep | | 601 | 5.4|<----to UP via Si-------| | 602 | Online Rep | | | 603 5.5|<--------------| | | 604 | | Create subscriber | | 605 | | session on UP | | 606 | 5.6|<--------via Ci-------->| | 607 | | | CoA Request | 608 | | 6.1|<--------------| 609 | | Update session on UP | | 610 | 6.2|<--------via Ci-------->| | 611 | | | CoA Response | 612 | | 6.3|-------------->| 613 | | | | 614 | Offline Req | | | 615 7.1|-------------->| | | 616 | | Relay the Offline Req | | 617 | 7.2|------to CP via Si----->| | 618 | | | | 619 | | Send the Offline Rep | | 620 | 7.3|<-----to UP via Si------| | 621 | Offline Rep | | | 622 7.4|<--------------| | | 623 | | Delete session on UP | | 624 | 7.5|<--------via Ci-------->| | 625 | | | | 626 | | Event report | | 627 | 8|---------via Ci-------->| | 628 | | | | 629 | | Data Synchronization | | 630 | 9|<--------via Ci-------->| | 631 | | | | 632 | | CGN Address Allocation | | 633 | 10|<--------via Ci-------->| | 634 | | | | 636 Figure 3: BNG CUPS Procedures Overview 638 1. S-CUSP session establishment: This is the first step of BNG CUPS 639 procedures. Once the Control Interface parameters are configured 640 on a UP. It will start to setup S-CUSP sessions with the 641 specified CPs. The detailed definition of S-CUSP session 642 establishment can be found in Section 4.1.1. 644 2. Board and interface report: Once the S-CUSP session is 645 established between the UP and a CP, the UP will report status 646 information on the boards and subscriber side interfaces of this 647 UP to the CP. A board can also be called a Line/Service Process 648 Unit (LPU/SPU) card. The subscriber side interfaces refer to the 649 interfaces that connect the Acess Network nodes (e.g., OLT: 650 Optical Line Terminal, DSLAM: Digital Subscriber Line Access 651 Multiplexer, etc.). The CP can use this information to enable the 652 Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, etc.) 653 on the specified interfaces. See Sections 4.2.1 and 7.10 for more 654 details on Resource reporting. 656 3. BAS (Broadband Access Service) function enable: To enable the BAS 657 function on the specified interfaces of a UP. 659 4. Subscriber network route advertisement: The CP will allocate one 660 or more IP address blocks to a UP. Each address block contains a 661 series of IP addresses. Those IP addresses will be allocated to 662 subscribers who are dialing up from the UP. To enable other nodes 663 in the network to learn how to reach the subscribers, the CP 664 needs to notify the UP to advertise to the network the routes 665 that can reach those IP addresses. 667 5. 5.1-5.6 is a complete call flow of a subscriber dial-up process. 668 When a UP receives a dial-up request, it will relay the request 669 packet to a CP through the Service Interface. The CP will parse 670 the request. If everything is OK, it will send an authentication 671 request to the AAA server to authenticate the subscriber. Once 672 the subscriber passes the authentication, the AAA server will 673 return a positive response to the CP. Then the CP will send the 674 dial-up response packet to the UP and the UP will forward the 675 response packet to the subscriber (RG). At the same time, the CP 676 will create a subscriber session on the UP, which enables the 677 subscriber to access the network. For different access types, 678 the process may be a bit different. But the high-level process is 679 similar. For each access type, the detail process can be found in 680 Section 5. 682 6. 6.1-6.3 is the sequence when updating an existing subscriber 683 session. The AAA server initiates a Change of Authorization (CoA) 684 and sends the CoA to the CP. The CP will then update the session 685 according to the CoA. See Section 4.3.2 for more detail on CP 686 messages updating UP tables. 688 7. 7.1-7.5 is the sequence for deleting an existing subscriber 689 session. When a UP receives an offline request, it will relay the 690 request to a CP through the Service Interface. The CP will send 691 back a response to the UP through the Service Interface. The UP 692 will then forward the offline response to the subscriber. Then 693 the CP will delete the session on the UP through the Control 694 Interface. 696 8. Event reports include the following two parts (more detail can be 697 found in Section 4.3.4) Both are reported using the Event 698 message. 700 8.1. Subscriber Traffic Statistics Report 701 8.2. Subscriber Detection Result Report 703 9. Data synchronization: See Sections 4.2.5 for more detail on CP 704 and UP Synchronization. 706 10. CGN address allocation: See Sections 4.2.4 for more detail on CGN 707 Address Allocation. 709 4. S-CUSP Protocol Overview 711 4.1. Control Channel Related Procedures 713 4.1.1. S-CUSP Session Establishment 715 A UP is associated with a CP and is controlled by that CP. In the 716 case of a hot-standby or cold-standby, a UP is associated with two 717 CPs, one called the Master CP and the other called the Standby CP. 718 The association between a UP and its CPs is implemented by dynamic 719 configuration. 721 Once a UP knows its CPs, the UP starts to establish S-CUSP sessions 722 with those CPs as shown in Figure 4. 724 UP CP 725 | | 726 | TCP Session Establishment | 727 |<------------------------------->| 728 | | 729 | HELLO (version, capability) | 730 |-------------------------------->| 731 | | 732 | HELLO (version, capability) | 733 |<--------------------------------| 734 | | 736 Figure 4: S-CUSP Session Establishment 738 The S-CUSP session establishment consists of two successive steps: 740 1. Establishment of a TCP [RFC793] connection (3-way handshake) 741 between the CP and the UP using a configured port from the 742 dynamic port range (49152-65535). 744 2. Establishment of a S-CUSP session over the TCP connection. 746 Once the TCP connection is established, the CP and the UP initialize 747 the S-CUSP session during which the version and Keepalive timers are 748 negotiated. 750 The version information (Hello TLV, see Section 7.4) is carried 751 within Hello messages (see Section 6.2.1). A CP can support multiple 752 versions, but a UP can only support one version. So, the version 753 negotiation is based on whether a version can be support by both the 754 CP and the UP. For a CP or UP, if a Hello message is received that 755 does not indicate a version supported by both, a subsequent Hello 756 message with an Error Information TLV will be sent to the peer to 757 notify the peer of the "Version-Mismatch" error and the session 758 establishment phase fails. 760 Keepalive negotiation is performed by carrying a Keepalive TLV in the 761 Hello message. The Keepalive TLV includes a Keepalive timer and Dead 762 Timer field. The CP and UP have to agree on the Keepalive Timer and 763 Dead Timer. Otherwise, a subsequent Hello message with an Error 764 Information TLV will be sent to its peer and the session 765 establishment phase fails. 767 The S-CUSP session establishment phase fails if the CP or UP disagree 768 on the version and keepalive parameters or if one of the CP or UP 769 does not answer after the expiration of the Establishment timer. 770 When the S-CUSP session establishment fails, the TCP connection is 771 promptly closed. Successive retries are permitted but an 772 implementation SHOULD make use of an exponential back-off session 773 establishment retry procedure. 775 The S-CUSP session timer values that need to be configured are 776 summarized in the table below. 778 Timer Range in Default 779 Name seconds Value 780 ------------- ------- ------- 781 Establishment 1-32767 45 782 Keepalive 0-255 30 783 DeadTimer 1-32767 4 * Keepalive 785 4.1.2. Keep Alive 787 Once an S-CUSP session has been established, a UP or CP may want to 788 know that its S-CUSP peer is still available for use. 790 Each end of a S-CUSP session runs a Keepalive timer. It restarts the 791 timer every time it sends a message on the session. When the timer 792 expires, it sends a Keepalive message. 794 The ends of the S-CUSP session also run DeadTimers, and they restart 795 the timers whenever a message is received on the session. If one end 796 of the session receives no message after the DeadTimer expires, it 797 declares the session dead. The session will be closed. 799 The minimum value of the Keepalive timer is 1 second, and it is 800 specified in units of 1 second. The RECOMMENDED default value is 30 801 seconds. The timer may be disabled by setting it to zero. 803 The recommended default for the DeadTimer is 4 times the value of the 804 Keepalive timer used by the remote peer. This implies there is 805 essentially no risk of TCP congestion due to excessive Keepalive 806 messages. 808 The Keepalive timer and DeadTimer are initially negotiated through 809 the Keepalive TLV carried in the Hello Message. 811 4.2. Node Related Procedures 813 4.2.1. UP Resource Report 815 Once an S-CUSP session has been established between a CP and an UP. 816 The UP reports the information of the Boards and access side 817 interfaces on this UP to the CP as shown in Figure 5. Report messages 818 are unacknowledged and are assumed to be delivered because the 819 session runs over TCP. 821 The CP can use that information to activate/enable the Broadband 822 Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the 823 specified interfaces. 825 In addition, the UP resource report may trigger a UP warm-standby 826 process. In the case of warm-standby, a failure on an UP may trigger 827 the CP to start a warm-standby process, by moving the on-line 828 subscriber sessions to a standby UP and then direct the affected 829 subscribers to access the Internet through the standby UP. 831 UP CP 832 | | 833 | Report Board Status | 834 |------to CP via Ci----->| 835 | | 836 | Report Interface Status| 837 |------to CP via Ci----->| 838 | | 840 Figure 5: UP Board and Interface Report 842 Board status information is carried in the Board Status TLV (Section 843 7.10.2) and Interface status information is carried in Interface 844 Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are 845 carried in the Report Message (Section 6.4). 847 4.2.2. Update BAS Function on Access Interface 849 Once the CP collects the interface status of a UP, it will 850 activate/de-activate/modify the BAS functions on specified interfaces 851 through the Update_Request and Update_Response message (Section 6.2) 852 exchanges carrying the BAS Function TLV (Section 7.7). 854 UP CP 855 | | 856 | Update BAS function | 857 | Request | 858 |<-----on UP via Ci-------| 859 | | 860 | Update BAS function | 861 | Response | 862 |------on UP via Ci------>| 863 | | 865 Figure 6: Update BAS Function 867 4.2.3. Update Network Routing 869 The CP will allocate one or more address blocks to a UP. Each address 870 block contains a series of IP addresses. Those IP addresses will be 871 allocated to subscribers who are dialing up to the UP. To enable the 872 other nodes in the network to learn how to reach the subscribers, the 873 CP needs to install the routes on the UP and notify the UP to 874 advertise the routes to the network. 876 UP CP 877 | | 878 | Subscriber network route| 879 | update request | 880 |<------- via Ci----------| 881 | | 882 | Subscriber network route| 883 | update response | 884 |-------- via Ci--------->| 885 | | 887 Figure 7: Update Network Routing 889 The subscriber network routing update request and response are 890 achieved through the Update Request and Response Message exchanges by 891 carrying the IPv4/IPv6 Routing Information TLVs (Section 7.8). 893 4.2.4. CGN Public IP Address Allocation 895 The following sequences describe the CGN address management related 896 procedures. Three independent procedures are defined, one each for 897 CGN address allocation request/response, CGN address renewal 898 request/response, and CGN address release request/response. 900 CGN address allocation/renew/release procedures are designed for the 901 case where the CGN function is running on the UP. The UP has to map 902 the subscriber private IP addresses to a public IP addresses, and 903 such mapping is performed by the UP locally when a subscriber dials- 904 up. That means the UP has to ask for public IPv4 address blocks for 905 CGN subscribers from the CP. 907 In addition, when a public IP address is allocated to a UP, there 908 will be a lease time (e.g., one day). Before the lease time expires, 909 the UP can ask for renewal of the IP address lease from the CP. It is 910 achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack 911 messages. 913 If the public IP address will not be used anymore, the UP SHOULD 914 release the address by sending an Addr_Release_Req message to the CP. 916 If the CP wishes to withdraw addresses that it has previously leased 917 to a UP, it uses the same procedures as above. The "Oper" code in 918 the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the 919 request is an update or withdraw. 921 The relevant messages are defined in Section 6.5. 923 UP CP 924 | | 925 | CGN Address Allocation | 926 | Request | 927 1.1|-------- via Ci--------->| 928 | CGN Address Allocation | 929 | Response | 930 1.2|<------- via Ci----------| 931 | | 932 | CGN Address Renew | 933 | Request | 934 2.1|-------- via Ci--------->| 935 | CGN Address Renew | 936 | Response | 937 2.2|<------- via Ci----------| 938 | | 939 | CGN Address Release | 940 | Request | 941 3.1|-------- via Ci--------->| 942 | CGN Address Release | 943 | Response | 944 3.3|<------- via Ci----------| 945 | | 947 Figure 8: CGN Public IP Address Allocation 949 4.2.5. Data Synchronization between the CP and UP 951 For a CU separated BNG, the UP will continue to function using the 952 state that has been installed in it even if the CP fails or the 953 session between the UP and CP fails. 955 Under some circumstances it is necessary to synchronize state between 956 the CP and UP, for example if a CP fails and the UP is switched to a 957 different CP. 959 Synchronization includes two directions. One direction is from UP to 960 CP; in that case, the synchronization information is mainly about the 961 board/interface status of the UP. The other direction is from CP to 962 UP; in that case, the subscriber sessions, subscriber network routes, 963 L2TP tunnels, etc. will be synchronized to the UP. 965 The synchronization is triggered by a Sync_Request message, to which 966 the receiver will (1) reply with a Sync_Begin message to notify the 967 requester that synchronization will begin, and (2) then start the 968 synchronization using the Sync_Data message. When synchronization 969 finished, a Sync_End message will be sent. 971 The following figure shows the process of data synchronization 972 between a UP and a CP. 974 UP CP 975 | | 976 | Synchronization Request | 977 |<------- via Ci----------| 978 | | 979 | Synchronization Begin | 980 |-------- via Ci--------->| 981 | | 982 | Board/Interface Report | 983 |-------- via Ci--------->| 984 | | 985 | Synchronization End | 986 |-------- via Ci--------->| 987 | | 988 1) Synchronization from UP to CP 990 UP CP 991 | | 992 | Synchronization Request | 993 |-------- via Ci--------->| 994 | | 995 | Synchronization Begin | 996 |<-------- via Ci---------| 997 | | 998 | Synchronizes | 999 |Subscriber Session States| 1000 | Network Route Entries | 1001 |<------- via Ci----------| 1002 | | 1003 | Synchronization End | 1004 |<-------- via Ci---------| 1005 | | 1006 2) Synchronization from CP to UP 1008 Figure 9: Data Synchronization 1010 4.3. Subscriber Session Related Procedures 1012 A subscriber session consists of a set of forwarding states, 1013 policies, and security rules that are applied to the subscriber. It 1014 is used for forwarding subscriber traffic in a UP. To initialize a 1015 session on a UP, a set of hardware resource have to be allocated 1016 (e.g., NP, TCAM etc.) to a session. 1018 Subscriber session related procedures include subscriber session 1019 create, update, delete, and statistics report. The following sub- 1020 sections give a high level view of the procedures. 1022 4.3.1. Create Subscriber Session 1024 The below sequence describes the DHCP IPv4 dial-up process, it is an 1025 example that shows how a subscriber session is created. (An example 1026 for IPv6 appears in Section 5.1.2.) 1028 RG UP CP AAA 1029 | | | | 1030 | Online Request| | | 1031 1|-------------->| | | 1032 | |Relay the Online Request| | 1033 | 2|-----to CP via Si------>| Authentication| 1034 | | | Req/Rep | 1035 | | 3|<------------->| 1036 | | Create subscriber | | 1037 | | session Request | | 1038 | 4|<--------via Ci---------| | 1039 | | | | 1040 | | Create subscriber | | 1041 | | session Response | | 1042 | 5|---------via Ci-------->| | 1043 | | | | 1044 | | | Accounting | 1045 | | 6|<------------->| 1046 | | | | 1047 | | Send Online Response | | 1048 | 7|<----to UP via Si-------| | 1049 | | | | 1050 |Online Response| | | 1051 12|<--------------| | | 1052 | | | | 1054 Figure 10: Subscriber Session Create 1056 The request starts from an Online Request message (step 1) from the 1057 RG (for example, a DHCP Discovery packet). When the UP receives the 1058 Online Request from the RG, it will tunnel the Online Request to the 1059 CP through the Service Interface (Step 2). The Service Interface is 1060 implemented by a tunneling technology. 1062 When the CP receives the Online Request from the UP, it will send an 1063 authentication request to the AAA server to authenticate and 1064 authorize the subscriber (step 3). When a positive reply is received 1065 from the AAA sever, the CP starts to create a subscriber session for 1066 the request. Relevant resources (e.g., IP address, bandwidth, etc.) 1067 will be allocated to the subscriber, policies and security rules will 1068 be generated for the subscriber Then the CP sends a session create 1069 request to the UP through the Control Interface (Ci) (step 4), and a 1070 response is expected from the UP to confirm the creation (step 5). 1072 Finally, the CP will notify the AAA server to start accounting (step 1073 6). At the same time, an Online Response message (for example, a 1074 DHCP Ack packet) will be sent to the UP through the Si (step 7). And 1075 the UP will forward the Online Response to the RG (step 8). 1077 This completes the subscriber online process. 1079 4.3.2. Update Subscriber Session 1081 The following numbered sequence shows the process of subscriber 1082 session update. 1084 UP CP AAA 1085 | | COA Request | 1086 | 1|<--------------| 1087 | Session update Request | | 1088 2|<--------via Ci---------| | 1089 | | | 1090 | Session update Response| | 1091 3|---------via Ci-------->| | 1092 | | COA Response | 1093 | 4|-------------->| 1094 | | | 1096 Figure 11: Subscriber Session Update 1098 When a subscriber session has been created on a UP, there may be 1099 requirements to update the session with new parameters (e.g., 1100 Bandwidth, QoS, policies, etc.). 1102 This procedure is triggered by a Change of Authorization (COA) 1103 request message sent by the AAA server. The CP will update the 1104 session on the UP according to the new parameters through the Control 1105 Interface. 1107 4.3.3. Delete Subscriber Session 1109 The below call flow shows generally how S-CUPS deals with a 1110 subscriber offline request. 1112 RG UP CP 1113 | | | 1114 |Offline Request | | 1115 1|--------------->| | 1116 | | Relay the Offline | 1117 | | Request | 1118 | 2|------to CP via Si----->| 1119 | | | 1120 | | Send the Offline | 1121 | | Response | 1122 | 3|<-----to UP via Si------| 1123 |Offline Response| | 1124 4|<---------------| | 1125 | | Session delete | 1126 | | Request | 1127 | |<--------via Ci---------| 1128 | | Session delete | 1129 | | Response | 1130 | |---------via Ci-------->| 1131 | | | 1133 Figure 12: Subscriber Session Delete 1135 Similar to the session creation process, when a UP receives an 1136 offline request from a RG, it will tunnel the request to a CP through 1137 the Si. 1139 When the CP receives the offline request, it will withdraw/release 1140 the resources (e.g., IP address, bandwidth) that have been allocated 1141 to the subscriber. Then, it sends a reply to the UP through the 1142 Service Interface and the UP will forward the reply to the RG. At 1143 the same time, it will delete all the status of the session on the UP 1144 through the Ci. 1146 4.3.4. Subscriber Session Events Report 1148 UP CP 1149 | | 1150 | Statistic/Detect report| 1151 |---------via Ci-------->| 1152 | | 1154 Figure 13: Events Report 1156 When a session is created on an UP, the UP will periodically report 1157 statistics information and detect results of the session to the CP. 1159 5. S-CUSP Call Flows 1161 The subsections below give an overview of various "dial-up" 1162 interactions over the Service Interface followed by an overview of 1163 the setting of various information in the UP by the CP using S-CUSP 1164 over the Control Interface. 1166 S-CUSP messages are described in this document using Routing Backus 1167 Naur Form (RBNF) as defined in [RFC5511]. 1169 5.1. IPoE 1171 5.1.1. DHCPv4 Access 1173 The following sequence shows detailed procedures for DHCPv4 access. 1175 RG UP CP AAA 1176 | | | | 1177 | DHCP Discovery| | | 1178 1|-------------->| | | 1179 | |Relay the DHCP Discovery| | 1180 | 2|-----to CP via Si------>| AAA | 1181 | | | Req/Rep | 1182 | | 3|<------------->| 1183 | | | | 1184 | | Send the DHCP Offer | | 1185 | 4|<----to UP vis Si-------| | 1186 | DHCP Offer | | | 1187 5|<--------------| | | 1188 | DHCP Request | | | 1189 6|-------------->| | | 1190 | | Relay the DHCP Request| | 1191 | 7|-----to CP via Si------>| | 1192 | | | | 1193 | | Create subscriber | | 1194 | | session Request | | 1195 | 8|<--------via Ci---------| | 1196 | | Create subscriber | | 1197 | | session Response | | 1198 | 9|---------via Ci-------->| | 1199 | | | Accounting | 1200 | | 10|<------------->| 1201 | | | | 1202 | | Send DHCP ACK | | 1203 | 11|<----to UP via Si-------| | 1204 | | | | 1205 | DHCP ACK | | | 1206 12|<--------------| | | 1207 | | | | 1209 Figure 14: DHCPv4 Access 1211 Step 8 and 9 are implemented by the S-CUSP protocol. 1213 When a subscriber is authenticated and authorized by the AAA server, 1214 the CP will create a subscriber session on the UP. This is achieved 1215 by sending an Update_Request message to the UP. 1217 The format of the Update_Request message is shown as follows using 1218 RBNF: 1220 ::= 1221 1222 1223 1224 [] 1226 The UP will reply with an Update_Response message, the format of the 1227 Update_Response message is as follows: 1229 ::= 1230 1231 [] 1233 5.1.2. DHCPv6 Access 1235 The following sequence shows detailed procedures for DHCPv6 access. 1237 RG UP CP AAA 1238 | | | | 1239 | Solicit | | | 1240 1|-------------->| | | 1241 | | Relay the Solicit | | 1242 | 2|-----to CP via Si------>| AAA | 1243 | | | Req/Rep | 1244 | | 3|<------------->| 1245 | | | | 1246 | | Send the Advertise | | 1247 | 4|<----to UP vis Si-------| | 1248 | Advertise | | | 1249 5|<--------------| | | 1250 | | | | 1251 | Request | | | 1252 6|-------------->| | | 1253 | | Relay the Request | | 1254 | 7|-----to CP via Si------>| | 1255 | | | | 1256 | | | | 1257 | | Create subscriber | | 1258 | | session Request | | 1259 | 8|<--------via Ci-------->| | 1260 | | | | 1261 | | Create subscriber | | 1262 | | session Response | | 1263 | 9|---------via Ci-------->| | 1264 | | | | 1265 | | | Accounting | 1266 | | 10|<------------->| 1267 | | | | 1268 | | Send Reply | | 1269 | 11|<----to UP via Si-------| | 1270 | | | | 1271 | Reply | | | 1272 12|<--------------| | | 1273 | | | | 1275 Figure 15: DHCPv6 Access 1277 Steps 1-7 are a standard DHCP IPv6 access process. The subscriber 1278 creation is triggered by a DHCP IPv6 request message. When this 1279 message is received, it means that the subscriber has passed the AAA 1280 authentication and authorization. Then the CP will create a 1281 subscriber session on the UP. This is achieved by sending an 1282 Update_Request message to the UP (Step 8). 1284 The format of the Update_Request message is as follows: 1286 ::= 1287 1288 1289 1290 [] 1292 The UP will reply with an Update_Response message (Step 9). The 1293 format of the Update_Response message is as follows: 1295 ::= 1296 1298 5.1.3. IPv6 SLAAC Access 1300 The following flow shows the IPv6 SLAAC access process. 1302 RG UP CP AAA 1303 | | | | 1304 | RS | | | 1305 1|-------------->| | | 1306 | | Relay the Router | | 1307 | | Solicit (RS) | | 1308 | 2|-----to CP via Si------>| AAA | 1309 | | | Req/Rep | 1310 | | 3|<------------->| 1311 | | | | 1312 | | Create subscriber | | 1313 | | session Request | | 1314 | 4|<--------via Ci---------| | 1315 | | | | 1316 | | Create subscriber | | 1317 | | session Response | | 1318 | 5|---------via Ci-------->| | 1319 | | | | 1320 | | Send Router Advertise | | 1321 | | (RA) | | 1322 | 6|<----to UP vis Si-------| | 1323 | RA | | | 1324 7|<--------------| | | 1325 | | | | 1326 | NS | | | 1327 8|-------------->| | | 1328 | | Relay the Neighbor | | 1329 | | Solicit (NS) | | 1330 | 9|-----to CP via Si------>| | 1331 | | | | 1332 | | | Accounting | 1333 | | 10|<------------->| 1334 | | | | 1335 | | Send a Neighbor | | 1336 | | Advertise (NA) | | 1337 | 11|<----to UP via Si-------| | 1338 | | | | 1339 | NA | | | 1340 12|<--------------| | | 1341 | | | | 1343 Figure 16: IPv6 SLAAC Access 1345 It starts with a Router Solicit (RS) request from an RG that is 1346 tunneled to the CP by the UP. After the AAA authentication and 1347 authorization, the CP will create a subscriber session on the UP. 1349 This is achieved by sending an Update_Request message to the UP (step 1350 4). 1352 The format of the Update_Request message is as follows: 1354 ::= 1355 1356 1357 1358 [] 1360 The UP will reply with an Update_Response message (step 5), the 1361 format of the Update_Response message is as follows: 1363 ::= 1364 1366 5.1.4. DHCPv6 + SLAAC Access 1368 The following call flow shows the DHCP IPv6 and SLAAC access process. 1370 RG UP CP AAA 1371 | | | | 1372 | RS | | | 1373 1|-------------->| | | 1374 | | Relay the Router | | 1375 | | Solicit (RA) | | 1376 | 2|-----to CP via Si------>| AAA | 1377 | | | Req/Rep | 1378 | | 3|<------------->| 1379 | | | | 1380 | | Create subscriber | | 1381 | | session Request | | 1382 | 4|<--------via Ci---------| | 1383 | | | | 1384 | | Create subscriber | | 1385 | | session Response | | 1386 | 5|---------via Ci-------->| | 1387 | | | | 1388 | | Send Router Advertise | | 1389 | | (RA) | | 1390 | 6|<----to UP vis Si-------| | 1391 | RA | | | 1392 7|<--------------| | | 1393 | | | | 1394 |DHCPv6 Solicit | | | 1395 8|-------------->| | | 1396 | | Relay DHCPv6 Solicit | | 1397 | 9|-----to CP via Si------>| | 1398 | | | | 1399 | | Update subscriber | | 1400 | | session Request | | 1401 | 10|<--------via Ci---------| | 1402 | | | | 1403 | | Update subscriber | | 1404 | | session Response | | 1405 | 11|---------via Ci-------->| | 1406 | | | | 1407 | | | Accounting | 1408 | | 12|<------------->| 1409 | | | | 1410 | | Send DHCPv6 Reply | | 1411 | 13|<----to UP via Si-------| | 1412 | | | | 1413 | DHCPv6 Reply | | | 1414 14|<--------------| | | 1415 | | | | 1417 Figure 17: DHCPv6 + SLAAC Access 1419 When a subscriber passes AAA authentication, the CP will create a 1420 subscriber session on the UP. This is achieved by sending an 1421 Update_Request message to the UP (step 4). 1423 ::= 1424 1425 1426 1427 [] 1429 The UP will reply with an Update_Response message (step 5). The 1430 format of the Update_Response is as follows: 1432 ::= 1433 1435 After receiving a DHCPv6 Solicit, the CP will update the subscriber 1436 session by sending an Update_Request message with new parameters to 1437 the UP (Step 10). 1439 The format of the Update_Request message is as follows: 1441 ::= 1442 1443 1444 1445 [] 1447 The UP will reply with an Update_Response message (step 11). The 1448 format of the Update_Response is as follows: 1450 ::= 1451 1453 5.1.5. DHCP Dual Stack Access 1455 The following sequence is a combination of DHCP IPv4 and DHCP IPv6 1456 access processes. 1458 RG UP CP AAA 1459 | | | | 1460 | DHCP Discovery| | | 1461 1|-------------->| | | 1462 | |Relay the DHCP Discovery| | 1463 | 2|-----to CP via Si------>| AAA | 1464 | | | Req/Resp | 1465 | | 3|<------------->| 1466 | | | | 1467 | | Send the DHCP Offer | | 1468 | 4|<----to UP vis Si-------| | 1469 | DHCP Offer | | | 1470 5|<--------------| | | 1471 | DHCP Request | | | 1472 6|-------------->| | | 1473 | | Relay the DHCP Request| | 1474 | 7|-----to CP via Si------>| | 1475 | | | | 1476 | | Create subscriber | | 1477 | | session Request | | 1478 | 8|<--------via Ci-------->| | 1479 | | Create subscriber | | 1480 | | session Response | | 1481 | 9|---------via Ci-------->| | 1482 | | | Accounting | 1483 | | 10|<------------->| 1484 | | Send DHCP ACK | | 1485 | 11|<----to UP via Si-------| | 1486 | | | | 1487 | DHCP ACK | | | 1488 12|<--------------| | | 1489 | RS | | | 1490 13|-------------->| | | 1491 | | Relay the Router | | 1492 | | Solicit (RA) | | 1493 | 14|-----to CP via Si------>| AAA | 1494 | | | Req/Rep | 1495 | | 15|<------------->| 1496 | | | | 1497 | | Create subscriber | | 1498 | | session Request | | 1499 | 16|<--------via Ci---------| | 1500 | | Create subscriber | | 1501 | | session Response | | 1502 | 17|---------via Ci-------->| | 1503 | | | | 1504 | | Send Router Advertise | | 1505 | | (RA) | | 1506 | 18|<----to UP vis Si-------| | 1507 | RA | | | 1508 19|<--------------| | | 1509 | | | | 1510 |DHCPv6 Solicit | | | 1511 20|-------------->| | | 1512 | | Relay DHCPv6 Solicit | | 1513 | 21|-----to CP via Si------>| | 1514 | | | | 1515 | | Update subscriber | | 1516 | | session Request | | 1517 | 22|<--------via Ci---------| | 1518 | | Update subscriber | | 1519 | | session Response | | 1520 | 23|---------via Ci-------->| | 1521 | | | Accounting | 1522 | | 24|<------------->| 1523 | | Send DHCPv6 Reply | | 1524 | 25|<----to UP via Si-------| | 1525 | DHCPv6 Reply | | | 1526 26|<--------------| | | 1527 | | | | 1529 Figure 18: DHCP Dual Stack Access 1531 The DHCP dual stack access includes three sets of Update_Request / 1532 Update_Response exchanges to create/update DHCPv4/v6 subscriber 1533 session. 1535 1. Create DHCPv4 session (step 8 and 9) 1537 ::= 1538 1539 1540 1541 [] 1543 ::= 1544 1545 [] 1547 2. Create DHCPv6 session (step 16 and 17) 1549 ::= 1550 1551 1552 1553 [] 1555 ::= 1556 1558 3. Update DHCPv6 session (step 22 and 23) 1560 ::= 1561 1562 1563 1564 [] 1566 ::= 1567 1569 5.1.6. L2 Static Subscriber Access 1571 L2 static subscriber access processes are as follows: 1573 RG UP CP AAA 1574 | | | | 1575 | | Static Subscriber | | 1576 | | Detection Req. | | 1577 | 1|<-----to UP via Ci------| | 1578 | | Static Subscriber | | 1579 | | Detection Rep. | | 1580 | 2|------to UP via Ci----->| | 1581 | ARP/ND(REQ) | | | 1582 3.1|<--------------| | | 1583 | ARP/ND(ACK) | | | 1584 3.2|-------------->| | | 1585 | | Relay the ARP/ND | | 1586 | 3.3|-----to CP via Si------>| AAA | 1587 | | | Req/Rep | 1588 | | 3.4|<------------->| 1589 | | Create subscriber | | 1590 | | session Request | | 1591 | 3.5|<--------via Ci---------| | 1592 | | Create subscriber | | 1593 | | session Response | | 1594 | 3.6|---------via Ci-------->| | 1595 | | | | 1596 | ARP/ND(REQ) | | | 1597 4.1|-------------->| | | 1598 | | Relay the ARP/ND | | 1599 | 4.2|-----to CP via Si------>| AAA | 1600 | | | Req/Rep | 1601 | | 4.3|<------------->| 1602 | | Create subscriber | | 1603 | | session Request | | 1604 | 4.4|<--------via Ci---------| | 1605 | | Create subscriber | | 1606 | | session Response | | 1607 | 4.5|---------via Ci-------->| | 1608 | ARP/ND(ACK) | | | 1609 4.6|<--------------| | | 1610 | | | | 1611 | IP Traffic | | | 1612 5.1|-------------->| | | 1613 | | Relay the IP Traffic | | 1614 | 5.2|-----to CP via Si------>| AAA | 1615 | | | Req/Rep | 1616 | | 5.3|<------------->| 1617 | | Create subscriber | | 1618 | | session Request | | 1619 | 5.4|<--------via Ci-------->| | 1620 | | Create subscriber | | 1621 | | session Response | | 1622 | 5.5|---------via Ci-------->| | 1623 | | | | 1624 | ARP/ND(REQ) | | | 1625 5.6|<--------------| | | 1626 | ARP/ND(ACK) | | | 1627 5.7|-------------->| | | 1628 | | | | 1630 Figure 19: L2 Static Subscriber Access 1632 For L2 static subscriber access, the process starts with a CP 1633 installing a static subscriber detection list on an UP. The list 1634 determines which subscribers will be detected. This is implemented 1635 by exchanging Update_Request and Update_Response messages between CP 1636 and UP. The format of the messages are as follows: 1638 ::= 1639 1640 1642 ::= 1643 1645 For L2 Static subscriber access, there are three ways to trigger the 1646 access process: 1648 1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP 1649 address, the access interface, and VLAN of the RG. The UP will 1650 actively trigger the access flow by sending an ARP/ND packet to 1651 the RG. If the RG is online, it will reply with an ARP/ND to the 1652 UP. The UP will tunnel the ARP/ND to the CP through the Si. The 1653 CP then triggers the authentication process. If the 1654 authentication result is positive. The CP will create a 1655 corresponding subscriber session on the UP. 1657 2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as 1658 option 1 (triggered by UP). The difference is that the RG will 1659 actively send the ARP/ND to trigger the process. 1661 3. Triggered by RG IP traffic (5.1-5.7): This is for the case where 1662 the RG has the ARP/ND information, but the subscriber session on 1663 the UP is lost (e.g., due to failure on the UP, or the UP 1664 restarted). That means the RG may keep sending IP packets to the 1665 UP. The packets will trigger the UP to start a new access 1666 process. 1668 From a subscriber session point of view, the procedures and the 1669 message formats for the above three cases are the same, as follows: 1671 IPv4 Case: 1672 ::= 1673 1674 1675 1676 [] 1678 ::= 1679 1680 [] 1682 IPv6 Case: 1683 ::= 1684 1685 1686 1687 [] 1689 ::= 1690 1692 5.2. PPPoE 1694 5.2.1. IPv4 PPPoE Access 1696 The following figure shows the IPv4 PPPoE access call flow. 1698 RG UP CP AAA 1699 | | | | 1700 | PPPoE Disc | PPPoE Disc | | 1701 1|<------------->|<---------via Si------->| | 1702 | | | | 1703 | PPP LCP | PPP LCP | | 1704 2|<------------->|<---------via Si------->| | 1705 | | | AAA | 1706 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1707 3|<------------->|<---------via Si------->|<------------->| 1708 | | | | 1709 | PPP IPCP | PPP IPCP | | 1710 4|<------------->|<---------via Si------->| | 1711 | | | | 1712 | | Create subscriber | | 1713 | | session Request | | 1714 | 5|<--------via Ci---------| | 1715 | | | | 1716 | | Create subscriber | | 1717 | | session Response | | 1718 | 6|---------via Ci-------->| | 1719 | | | | 1720 | | | Accounting | 1721 | | 7|<------------->| 1722 | | | | 1724 Figure 20: IPv4 PPPoE Access 1726 From the above sequence, step 1-4 are the standard PPPoE call flow. 1727 The UP is responsible for redirecting the PPPoE control packets to 1728 the CP or RG. The PPPoE control packets are transmitted between the 1729 CP and UP through the Si. 1731 After the PPPoE call flow, if the subscriber passed the AAA 1732 authentication and authorization, the CP will create a corresponding 1733 session on the UP through the Ci. The formats of the messages are as 1734 follows: 1736 ::= 1737 1738 1739 1740 1741 [] 1743 ::= 1744 1745 [] 1747 5.2.2. IPv6 PPPoE Access 1749 The following figure describes the IPv6 PPPoE access call flow. 1751 RG UP CP AAA 1752 | | | | 1753 | PPPoE Disc | PPPoE Disc | | 1754 1|<------------->|<--------via Si-------->| | 1755 | | | | 1756 | PPP LCP | PPP LCP | | 1757 2|<------------->|<---------via Si------->| | 1758 | | | AAA | 1759 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1760 3|<------------->|<---------via Si------->|<------------->| 1761 | | | | 1762 | PPP IP6CP | PPP IP6CP | | 1763 4|<------------->|<---------via Si------->| | 1764 | | | | 1765 | | Create subscriber | | 1766 | | session Request | | 1767 | 5|<--------via Ci---------| | 1768 | | | | 1769 | | Create subscriber | | 1770 | | session Response | | 1771 | 6|---------via Ci-------->| | 1772 | | | | 1773 | ND Negotiation| ND Negotiation | | 1774 7|<------------->|<---------via Si------->| | 1775 | | | | 1776 | | Update subscriber | | 1777 | | session Request | | 1778 | 8|<--------via Ci---------| | 1779 | | | | 1780 | | Update subscriber | | 1781 | | session Response | | 1782 | 9|---------via Ci-------->| | 1783 | | | | 1784 | | | Accounting | 1785 | | 10|<------------->| 1786 | | | | 1787 | DHCPv6 | DHCPv6 | | 1788 | Negotiation | Negotiation | | 1789 7'|<------------->|<---------via Si------->| | 1790 | | | | 1791 | | Update subscriber | | 1792 | | session Request | | 1793 | 8'|<---------via Ci--------| | 1794 | | | | 1795 | | Update subscriber | | 1796 | | session Response | | 1797 | 9'|---------via Ci-------->| | 1798 | | | | 1799 | | | Accounting | 1800 | | 10'|<------------->| 1801 | | | | 1803 Figure 21: IPv6 PPPoE Access 1805 From the above sequence, steps 1-4 are the standard PPPoE call flow. 1806 The UP is responsible for redirecting the PPPoE control packets to 1807 the CP or RG. The PPPoE control packets are transmitted between the 1808 CP and UP through the Si. 1810 After the PPPoE call flow, if the subscriber passed the AAA 1811 authentication and authorization, the CP will create a corresponding 1812 session on the UP through the Ci. The formats of the messages are as 1813 follows: 1815 ::= 1816 1817 1818 1819 1820 [] 1822 ::= 1823 1825 Then, the RG will initialize a ND/DHCPv6 negotiation process with the 1826 CP (see step 7 and 7'), after that, it will trigger an update (8-9, 1827 8'-9') to the subscriber session. The formats of the update messages 1828 are as follows: 1830 ::= 1831 1832 1833 1834 1835 [] 1837 ::= 1838 1840 5.2.3. PPPoE Dual Stack Access 1842 The following figure shows a combination of IPv4 and IPv6 PPPoE 1843 access call flow. 1845 RG UP CP AAA 1846 | | | | 1847 |PPPoE Discovery| PPPoE Discovery | | 1848 1|<------------->|<---------via Si------->| | 1849 | | | | 1850 | PPP LCP | PPP LCP | | 1851 2|<------------->|<---------via Si------->| | 1852 | | | AAA | 1853 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1854 3|<------------->|<---------via Si------->|<------------->| 1855 | | | | 1856 | PPP IPCP | PPP IPCP | | 1857 4|<------------->|<---------via Si------->| | 1858 | | | | 1859 | | Create v4 subscriber | | 1860 | | session Request | | 1861 | 5|<--------via Ci---------| | 1862 | | Create v4 subscriber | | 1863 | | session Response | | 1864 | 6|---------via Ci-------->| | 1865 | | | Accounting | 1866 | | 7|<------------->| 1867 | PPP IP6CP | PPP IP6CP | | 1868 4'|<------------->|<---------via Si------->| | 1869 | | | | 1870 | | Create V6 subscriber | | 1871 | | session Request | | 1872 | 5'|<--------via Ci---------| | 1873 | | Create v6 subscriber | | 1874 | | session Response | | 1875 | 6'|---------via Ci-------->| | 1876 | | | | 1877 | ND Negotiation| ND Negotiation | | 1879 8|<------------->|<---------via Si------->| | 1880 | | | | 1881 | | Update v6 subscriber | | 1882 | | session Request | | 1883 | 9|<---------via Ci--------| | 1884 | | Update v6 subscriber | | 1885 | | session Response | | 1886 | 10|---------via Ci-------->| | 1887 | | | Accounting | 1888 | | 7'|<------------->| 1889 | DHCPv6 | DHCPv6 | | 1890 | Negotiation | Negotiation | | 1891 8'|<------------->|<---------via Si------->| | 1892 | | | | 1893 | | Update v6 subscriber | | 1894 | | session Request | | 1895 | 9'|<--------via Ci---------| | 1896 | | | | 1897 | | Update v6 subscriber | | 1898 | | session Response | | 1899 | 10'|---------via Ci-------->| | 1900 | | | | 1901 | | | Accounting | 1902 | | 7"|<------------->| 1903 | | | | 1905 Figure 22: PPPoE Dual Stack Access 1907 PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE 1908 access. The process is as above. The formats of the messages are as 1909 follows: 1911 1. Create an IPv4 PPPoE subscriber session (5-6) 1913 ::= 1914 1915 1916 1917 1918 [] 1920 ::= 1921 1922 [] 1924 2. Create an IPv6 PPPoE subscriber session (5'-6') 1926 ::= 1927 1928 1929 1930 1931 [] 1933 ::= 1934 1936 3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10') 1938 ::= 1939 1940 1941 1942 1943 [] 1945 ::= 1946 1948 5.3. WLAN Access 1950 The following figure shows the WLAN access call flow. 1952 RG UP CP AAA WEB Server 1953 | | | | | 1954 | DHCP | | | | 1955 | Discovery | | | | 1956 1|------------>| | | | 1957 | | DHCP | | | 1958 | | Discovery | | | 1959 | 2|-----via Si---->| AAA | | 1960 | | DHCP Offer |<-------->| | 1961 | 3|<----via Si-----| | | 1962 | DHCP Offer | | | | 1963 4|<------------| | | | 1964 | DHCP | | | | 1965 | Request | | | | 1966 5|------------>| | | | 1967 | | DHCP Request | | | 1968 | 6|-----via Si---->| | | 1969 | | | | | 1970 | | Create session | | | 1971 | | Request | | | 1972 | 7|<----via Ci-----| | | 1973 | | Create session | | | 1974 | | Response | | | 1975 | 8|----via Ci----->| | | 1976 | | | | | 1977 | | DHCP ACK | | | 1978 | 9|<----via Si-----| | | 1979 | | | | | 1980 | DHCP ACK | | | | 1981 10|<------------| | | | 1982 | | | | | 1983 | Subscriber | | | | 1984 | HTTP Traffic| | | | 1985 11|------------>|--> | | | 1986 | | | WEB URL | | | 1987 | Traffic | | Redirect | | | 1988 | Redirection | | | | | 1989 12|<------------|<-+ | | | 1990 | | | | 1991 | | 1992 13|-----------------Redirect to Web server------------->| 1993 | | 1994 14|<----------------Push HTTP log-in page---------------| 1995 | | 1996 15|-----------------User Authentication---------------->| 1997 | | 1998 | | | Portal Interchange | 1999 | | 16|<-------------------->| 2000 | | | | 2001 | | | AAA | | 2002 | | | Req/Rep | | 2003 | | 17|<-------->| | 2004 | | | | | 2005 | | Update session | | | 2006 | | Request | | | 2007 | 18|<----via Ci-----| | | 2008 | | | | | 2009 | | Update session | | | 2010 | | Response | | | 2011 | 19|-----via Ci---->| | | 2012 | | | | | 2014 Figure 23: WLAN Access 2016 WLAN access starts with the DHCP dial-up process (steps 1-6), after 2017 that the CP will create a subscriber session on the UP (steps 7-8). 2018 The formats of the session creation messages are as follows: 2020 IPv4 Case: 2021 ::= 2022 2023 2024 2025 [] 2027 ::= 2028 2029 [] 2031 IPv6 Case: 2032 ::= 2033 2034 2035 2036 [] 2038 ::= 2039 2041 After step 10, the RG will be allocated an IP address and its first 2042 HTTP packet will be redirected to a WEB server for subscriber 2043 authentication (steps 11-17). After the WEB authentication, if the 2044 result is positive, the CP will update the subscriber session by 2045 using the following message exchanges: 2047 IPv4 Case: ::= 2048 2049 2050 2051 [] 2053 ::= 2054 2055 [] 2057 IPv6 Case: ::= 2058 2059 2060 2061 [] 2063 ::= 2064 2066 5.4. L2TP 2068 5.4.1. L2TP LAC Access 2070 RG UP(LAC) CP(LAC) AAA LNS 2071 | | | | | 2072 | PPPoE | PPPoE | | | 2073 | Discovery | Discovery | | | 2074 1|<---------->|<---via Si--->| | | 2075 | | | | | 2076 | PPP LCP | PPP LCP | | | 2077 2|<---------->|<---via Si--->| | | 2078 | | | AAA | | 2079 |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| | 2080 3|<---------->|<---via Si--->|<------>| | 2081 | | | | | 2082 | PPP IPCP | PPP IPCP | | | 2083 4|<---------->|<---via Si--->| | | 2084 | | | | | 2085 | | L2TP tunnel | | | 2086 | | negotiation | | | 2087 | | SCCRQ/ | | | 2088 | | SCCRP/ | | | 2089 | | SCCCN | | | 2090 | 5|<---via Si--->| | | 2091 | | /\ | 2092 | | || forward | 2093 | | \/ | 2094 | |<-----------via routing---------->| 2095 | | | 2096 | | L2TP session | | | 2097 | | negotiation | | | 2098 | | ICRQ/ | | | 2099 | | ICRP/ | | | 2100 | | ICCN | | | 2101 | 6|<---via Si--->| | | 2102 | | /\ | 2103 | | || forward | 2104 | | \/ | 2105 | |<-----------via routing---------->| 2106 | | | 2107 | | Create | | | 2108 | | subscriber | | | 2109 | | session | | | 2110 | | Request | | | 2111 | 7|<---via Ci----| | | 2112 | | | | | 2113 | | Create | | | 2114 | | subscriber | | | 2115 | | session | | | 2116 | | Response | | | 2117 | 8|----via Ci--->| | | 2118 | | | | | 2119 | | 2120 | PAP/CHAP (Triggered by LNS) | 2121 9|<-----------------via routing?---------------->| 2122 | | 2123 Figure 24: L2TP-LAC Access 2125 Steps 1-4 are a standard PPPoE access process. After that the LAC-CP 2126 starts to negotiate an L2TP session and tunnel with the LNS. After 2127 the negotiation, the CP will create an L2TP LAC subscriber session on 2128 the UP through the following messages: 2130 ::= 2131 2132 2133 2135 ::= 2136 2138 5.4.2. L2TP LNS IPv4 Access 2140 RG LAC UP(LNS) AAA CP(LNS) 2141 | | | | | 2142 | PPPoE | | | | 2143 | Discovery | | | | 2144 1|<---------->| | | | 2145 | | | | | 2146 | PPP LCP | | | | 2147 2|<---------->| | | 2148 | | AAA | | 2149 |PPP PAP/CHAP| Req/Rep | | 2150 3|<---------->|<--------------------->| | 2151 | | | 2152 | | | 2153 | | L2TP tunnel | L2TP tunnel | 2154 | | negotiation | negotiation | 2155 | | SCCRQ/ | SCCRQ/ | 2156 | | SCCRP/ | SCCRP/ | 2157 | | SCCCN | SCCCN | 2158 | 4|<------------>|<------via Si----->| 2159 | | | | 2160 | | L2TP session | L2TP session | 2161 | | negotiation | negotiation | 2162 | | ICRQ/ | ICRQ/ | 2163 | | ICRP/ | ICRP/ | 2164 | | ICCN | ICCN | 2165 | 5|<------------>|<------via Si----->| 2166 | | | | 2167 | | | Create | 2168 | | | subscriber | 2169 | | | session | 2170 | | | Request | 2171 | | 6|<-----via Ci-------| 2172 | | | Create | 2173 | | | subscriber | 2174 | | | session | 2175 | | | Response | 2176 | | 7|------via Ci------>| 2177 | | 2178 | PAP/CHAP (Triggered by LNS) | 2179 8|<--------------------------------------------->| 2180 | | 2181 | | | | AAA | 2182 | | | | Req/Rep | 2183 | | | 9|<-------->| 2184 | | | | 2185 | | 2186 | PPP IPCP | 2187 10|<--------------------------------------------->| 2188 | | 2189 | | | Update | 2190 | | | subscriber | 2191 | | | session | 2192 | | | Request | 2193 | | 11|<-----via Ci-------| 2194 | | | Update | 2195 | | | subscriber | 2196 | | | session | 2197 | | | Response | 2198 | | 12|------via Ci------>| 2199 | | | | 2201 Figure 25: IPv4 L2TP-LNS Access 2203 In this case, the BNG is running as an LNS and separated into LNS-CP 2204 and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When 2205 the L2TP session and tunnel negotiations are finished, the LNS-CP 2206 will create an L2TP LNS subscriber session on the LNS-UP. The format 2207 of messages are as follows: 2209 ::= 2210 2211 2212 2213 2214 2215 2216 [] 2218 ::= 2219 2220 [] 2222 After that, the LNS-CP will trigger an AAA authentication. If the 2223 authentication result is positive, a PPP IPCP process will follow, 2224 then the CP will update the session with the following message 2225 exchanges: 2227 ::= 2228 2229 2230 2231 2232 2233 2234 [] 2236 ::= 2237 2238 [] 2240 5.4.3. L2TP LNS IPv6 Access 2242 RG LAC UP(LNS) AAA CP(LNS) 2243 | | | | | 2244 | PPPoE | | | | 2245 | Discovery | | | | 2246 1|<---------->| | | | 2247 | | | | | 2248 | PPP LCP | | | | 2249 2|<---------->| | | 2250 | | AAA | | 2251 |PPP PAP/CHAP| Req/Rep | | 2252 3|<---------->|<--------------------->| | 2253 | | | 2254 | | | 2255 | | L2TP tunnel | L2TP tunnel | 2256 | | negotiation | negotiation | 2257 | | SCCRQ/ | SCCRQ/ | 2258 | | SCCRP/ | SCCRP/ | 2259 | | SCCCN | SCCCN | 2260 | 4|<------------>|<------via Si----->| 2261 | | | | 2262 | | L2TP session | L2TP session | 2263 | | negotiation | negotiation | 2264 | | ICRQ/ | ICRQ/ | 2265 | | ICRP/ | ICRP/ | 2266 | | ICCN | ICCN | 2267 | 5|<------------>|<------via Si----->| 2268 | | | | 2269 | | | Create | 2270 | | | subscriber | 2271 | | | session | 2272 | | | Request | 2273 | | 6|<-----via Ci-------| 2274 | | | Create | 2275 | | | subscriber | 2276 | | | session | 2277 | | | Response | 2278 | | 7|------via Ci------>| 2279 | | 2280 | PAP/CHAP (Triggered by LNS) | 2281 8|<--------------------------------------------->| 2282 | | 2283 | | | | AAA | 2284 | | | | Req/Rep | 2285 | | | 9|<-------->| 2286 | | | | | 2287 | | 2288 | PPP IP6CP | 2289 10|<--------------------------------------------->| 2290 | | 2291 | | | Update | 2292 | | | subscriber | 2293 | | | session | 2294 | | | Request | 2295 | | 11|<-----via Ci-------| 2296 | | | Update | 2297 | | | subscriber | 2298 | | | session | 2299 | | | Response | 2300 | | 12|------via Ci------>| 2301 | | | | 2302 | | | 2303 | ND negotiation | ND negotiation | 2304 13|<------------------------->|<-----via Si------>| 2305 | | | 2306 | | | Update | 2307 | | | subscriber | 2308 | | | session | 2309 | | | Request | 2310 | | 14|<-----via Ci-------| 2311 | | | Update | 2312 | | | subscriber | 2313 | | | session | 2314 | | | Response | 2315 | | 15|------via Ci------>| 2316 | | | | 2318 Figure 26: L2TP-LNS IPv6 Access 2320 Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5 2321 finish the normal L2TP dial-up process. When the L2TP session and 2322 tunnel negotiations are finished, the LNS-CP will create an L2TP LNS 2323 subscriber session on the LNS-UP. The format of the messages is as 2324 follows: 2326 ::= 2327 2328 2329 2330 2331 2332 2333 [] 2335 ::= 2336 2338 After that, the LNS-CP will trigger a AAA authentication. If the 2339 authentication result is positive, a PPP IP6CP process will follow, 2340 then the CP will update the session with the following message 2341 exchanges: 2343 ::= 2344 2345 2346 2347 2348 2349 2350 [] 2352 ::= 2353 2355 Then, an ND negotiation will be triggered by the RG. After the ND 2356 negotiation, the CP will update the session with the following 2357 message exchanges: 2359 ::= 2360 2361 2362 2363 2364 2365 2366 [] 2368 ::= 2369 2371 5.5. CGN (Carrier Grade NAT) 2373 RG UP CP AAA 2374 | | | | 2375 | | Public Address Block | | 2376 | | Allocation Request | | 2377 | 1|<--------via Ci-------->| | 2378 | | Public Address Block | | 2379 | | Allocation Reply | | 2380 | 2|---------via Ci-------->| | 2381 | | | | 2382 | Subscriber | | | 2383 | access request| Subscriber | | 2384 3|-------------->| access request | | 2385 | 4|----------via Si------->| | 2386 | | | AAA | 2387 | | Subscriber | Req/Rep | 2388 | Subscriber | access reply 5|<------------->| 2389 | access reply 6|<---------via Si--------| | 2390 7|<--------------| | | 2391 | | | | 2392 | | Create subscriber | | 2393 | | session Request | | 2394 | 8|<--------via Ci---------| | 2395 | | | | 2396 | | Create subscriber | | 2397 | | session Response | | 2398 | | (with NAT information) | | 2399 | 9|---------via Ci-------->| | 2400 | | | | 2401 | | | Accounting | 2402 | | | with source | 2403 | | | information | 2404 | | 10|<------------->| 2405 | | | Public IP + | 2406 | | | Port range | 2407 | | | to Private IP| 2408 | | | mapping | 2409 | | | | 2411 Figure 27: CGN Access 2413 The first steps allocate one or more CGN address blocks to the UP 2414 (steps 1-2). This is achieved by the following message exchanges 2415 between CP and UP. 2417 ::= 2418 2420 ::= 2421
2423 Steps 3-9 show the general dial-up process in the case of CGN mode. 2424 The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in 2425 above sections. 2427 If a subscriber is a CGN subscriber, once the subscriber session is 2428 created/updated, the UP will report the NAT information to the CP. 2429 This is achieved by carrying the "Subscriber CGN Port Range TLV" in 2430 the Update_Response message. 2432 5.6. L3 Leased Line Access 2434 5.6.1. Web Authentication 2436 RG UP CP AAA WEB Server 2437 | | | | | 2438 | User | | | | 2439 | traffic | | | | 2440 1|------------>| | | | 2441 | | User | | | 2442 | | traffic | | | 2443 | 2|-----via Si---->| AAA | | 2444 | | | Req/Rep | | 2445 | | 3|<-------->| | 2446 | | Create session | | | 2447 | | Request | | | 2448 | 4|<----via Ci-----| | | 2449 | | | | | 2450 | | Create session | | | 2451 | | Response | | | 2452 | 5|----via Ci----->| | | 2453 | HTTP | | | | 2454 | traffic | | | | 2455 6|------------>| | | | 2456 | | | | | 2457 | Redirect to | | | | 2458 | Web URL | | | | 2459 7|<------------| | | | 2460 | | | | | 2461 | | 2462 8|-----------------Redirected to Web server----------->| 2463 | | 2464 9|<----------------Push HTTP Log-in page---------------| 2465 | | 2466 10|-----------------User Authentication---------------->| 2467 | | 2468 | | | Portal Interchange | 2469 | | 11|<-------------------->| 2470 | | | | 2471 | | | AAA | | 2472 | | | Req/Rep | | 2473 | | 12|<-------->| | 2474 | | | | | 2475 | | | | | 2476 | | Update session | | | 2477 | | Request | | | 2478 | 13|<----via Ci-----| | | 2479 | | | | | 2480 | | Update session | | | 2481 | | Response | | | 2482 | 14|----via Ci----->| | | 2483 | | | | | 2485 Figure 28: Web Authentication based L3 Leased Line Access 2487 In this case, IP traffic from the RG will trigger the CP to 2488 authenticate the RG by checking the source IP and the exchanges with 2489 the AAA server. Once the RG passed the authentication, the CP will 2490 create a corresponding subscriber session on the UP through the 2491 following message exchanges: 2493 IPv4 Case: 2494 ::= 2495 2496 2497 2498 [] 2500 ::= 2501 2502 [] 2504 IPv6 Case: 2505 ::= 2506 2507 2508 2509 [] 2511 ::= 2512 2514 Then, the HTTP traffic from the RG will be redirected to a WEB server 2515 to finish the WEB authentication. Once the WEB authentication is 2516 passed, the CP will trigger another AAA authentication. After the 2517 AAA authentication, the CP will update the session with the following 2518 message exchanges: 2520 IPv4 Case: 2521 ::= 2522 2523 2524 2525 [] 2527 ::= 2528 2529 [] 2531 IPv6 Case: 2532 ::= 2533 2534 2535 2536 [] 2538 ::= 2539 2541 5.6.2. User Traffic Trigger 2543 RG UP CP AAA 2544 | | | | 2545 | | L3 access | | 2546 | | control list | | 2547 | 1|<----via Ci-----| | 2548 | User | | | 2549 | traffic | | | 2550 2|------------>| | | 2551 | | User | | 2552 | | traffic | | 2553 | 3|-----via Si---->| | 2554 | | | AAA | 2555 | | | Req/Rep | 2556 | | 4|<-------->| 2557 | | | | 2558 | | Create session | | 2559 | | Request | | 2560 | 5|<----via Ci-----| | 2561 | | Create session | | 2562 | | Response | | 2563 | 6|----via Ci----->| | 2564 | | | | 2566 Figure 29: User Traffic Triggered L3 Leased Line Access 2568 In this user traffic triggered case, the CP must install an access 2569 control list on the UP, which is used by the UP to determine whether 2570 an RG is legal or not. If the traffic is from a legal RG, it will be 2571 redirected to the CP though the Si. The CP will trigger a AAA 2572 interchange with the AAA server. After that, the CP will create a 2573 corresponding subscriber session on the UP with the following message 2574 exchanges: 2576 IPv4 Case: 2577 ::= 2578 2579 2580 2581 [] 2583 ::= 2584 2585 [] 2587 IPv6 Case: 2588 ::= 2589 2590 2591 2592 [] 2594 ::= 2595 2597 5.7. Multicast Access 2599 RG UP CP AAA 2600 | | | | 2601 | User access | User access | AAA | 2602 | request | request | Req/Rep | 2603 1|<----------->|<----via Si---->|<-------->| 2604 | | User | | 2605 | | | | 2606 | | | | 2607 | | Create session | | 2608 | | Request | | 2609 | 2|<----via Ci---->| | 2610 | | | | 2611 | | Create session | | 2612 | | Response | | 2613 | 3|----via Ci----->| | 2614 | | | | 2615 | Multicast | | | 2616 | negotiation | | | 2617 4|<----------->| | | 2618 | | | | 2620 Figure 30: Multicast Access 2622 Multicast access starts with an user access request from the RG. The 2623 request will be redirected to the CP by the Si. A follow-up AAA 2624 interchange between the CP and the AAA server will be triggered. 2625 After the authentication, the CP will create a multicast subscriber 2626 session on the UP through the following messages: 2628 IPv4 Case: 2629 ::= 2630 2631 2632 2633 2634 [] 2636 ::= 2637 2638 [] 2640 IPv6 Case: 2641 ::= 2642 2643 2644 2645 2646 [] 2648 ::= 2649 2651 6. S-CUSP Message Formats 2653 An S-CUSP message consists of a common header followed by a variable- 2654 length body consisting entirely of TLVs. Receiving an S-CUSP message 2655 with an unknown message type or missing mandatory TLV MUST trigger an 2656 Error message (see Section 6.7) or a response message with an Error 2657 Information TLV (see Section 7.6). 2659 Conversely, if a TLV is optional, the TLV may or may not be present. 2660 Optional TLVs are indicated in the message formats shown in this 2661 document by being enclosed in square brackets. 2663 This section specifies the format of the common S-CUSP message header 2664 and lists the defined messages. 2666 Network byte order is used for all multi-byte fields. 2668 6.1. Common Message Header 2670 S-CUSP Common Message Header: 2671 0 1 2 3 2672 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 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | Ver | Resv | Message-Type | Message-Length | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | Reserved | Transaction-ID | 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 Figure 6.1: S-CUSP Message Common Header 2681 o Ver (4 bits): The major version of the protocol. This document 2682 specifies version 1. Different major versions of the protocol 2683 may have significantly different message structure and format 2684 except that the Ver field will always be in the same place at 2685 the beginning of each message. A successful S-CUSP session 2686 depends on the CP and the UP both using the same major version 2687 of the protocol. 2689 o Resv (4 bits): Reserved. MUST be sent as zero and ignored on 2690 receipt. 2692 o Message-Type (8 bits): The set of message types specified in 2693 this document is listed in Section 9.1. 2695 o Message-Length (16 bits): Total length of the S-CUSP message 2696 including the common header, expressed in number of bytes as an 2697 unsigned integer. 2699 o Transaction ID (16 bits): This field is used to identify 2700 requests. It is echoed back in any corresponding ACK / response 2701 / Error message. It is RECOMMENDED that a monotonically 2702 increasing value be used in successive message and that value 2703 wrap back to zero after 0xFFFF. The contents of this field is 2704 an opaque value that the receiver MUST NOT use for any purpose 2705 except to echo back in a corresponding response and, 2706 optionally, for logging. 2708 6.2. Control Messages 2710 This document defines the following control messages: 2712 Type Name Notes and TLVs that can be carried 2713 ---- ---- ------------------------------------ 2714 1 Hello Hello TLV, Keep-Alive TLV. 2715 2 Keepalive A common header with the Keepalive message 2716 type. 2717 3 Sync_Request Synchronization request. 2718 4 Sync_Begin Synchronization starts. 2719 5 Sync_Data Synchronization data: TLVs specified in 2720 Section 5. 2721 6 Sync_End End synchronization. 2722 7 Update_Request TLVs specified in Sections 7.6-7.9. 2723 8 Update_Response TLVs specified in Sections 7.6-7.9. 2725 6.2.1. Hello Message 2727 Hello message is used for S-CUSP session establishment and version 2728 negotiation. The detail of S-CUSP session establishment and version 2729 negotiation can be found in Section 4.1.1. 2731 The format of Hello message is as follows: 2733 ::= 2734 2735 2736 [] 2738 The return code and negotiation result will be carried in the Error 2739 Information TLV. They are listed as follows: 2741 0: Success, version negotiation success. 2743 1: Failure, malformed message received. 2745 2: One or more of the TLVs was not understood. 2747 1001: The version negotiation fails. The S-CUSP session 2748 establishment phase fails. 2750 1002: The keepalive negotiation fails. The S-CUSP session 2751 establishment phase fails. 2753 1003: The establishment timer expires. session establishment 2754 phase fails. 2756 6.2.2. Keepalive Message 2758 The Keepalive message is periodically sent by each end of an S-CUSP 2759 session. It is used to detect whether the peer end is still alive. 2760 The Keepalive procedures are defined Section 4.1.2. 2762 The format of the Keepalive message is as follows: 2764 ::= 2766 6.2.3. Sync_Request Message 2768 The Sync_Request message is used to request synchronization from an 2769 S-CUSP peer. Both CP and UP can request their peer to synchronize 2770 data. 2772 The format of the Sync_Request message is as follows: 2774 ::= 2776 A Sync_Request message may result in a Sync_Begin message from its 2777 peer. The Sync_Begin message is defined in Section 6.2.4. 2779 6.2.4. Sync_Begin Message 2781 The Sync_Begin message is a reply to a Sync_Request message. It is 2782 used to notify the synchronization requester whether the 2783 synchronization can be started. 2785 The format of Sync_Begin message is as follows: 2787 ::= 2788 2790 The return codes are carried in the Error Information TLV. The codes 2791 are listed below: 2793 0: Success, be ready to synchronize. 2795 1: Failure, malformed message received. 2797 2: One or more of the TLVs was not understood. 2799 2001: Synch-NoReady. The data to be synchronized is not ready. 2801 2002: Synch-Unsupport. The data synchronization is not supported. 2803 6.2.5. Sync_Data Message 2805 The Sync_Data message is used to send data being synchronized between 2806 the CP and UP. The Sync_Data message has the same function and 2807 format as the Update_Request message. The difference is that there 2808 is no ACK for a Sync_Data message. An error caused by the Sync_Data 2809 message will result in a Sync_End message. 2811 There are two scenarios: 2813 Synchronization from UP to CP: Synchronize the resource data to 2814 CP. 2816 ::= 2817 [] 2819 Synchronization from CP to UP: Synchronize all subscriber sessions 2820 to UP. As for which TLVs should be carried, it depends on the 2821 specific session data to be synchronized. This is equivalent to 2822 create the specific session. Refer to Section 5 to see more 2823 details. 2825 ::= 2826 [] 2827 [] 2828 [] 2829 [] 2830 [] 2832 6.2.6. Sync_End Message 2834 The Sync_End message is used to indicate the end of a synchronization 2835 process. The format of a Sync_End message is as follows: 2837 ::= 2838 2840 The return/error codes are listed as follows: 2842 0: Success, synchronization finished. 2844 1: Failure, malformed message received. 2846 2: One or more of the TLVs was not understood. 2848 6.2.7. Update_Request Message 2850 The Update_Request message is a multi-task message, it can be used to 2851 create, update, and delete subscriber sessions on a UP. 2853 For session operations, the specific operation is controlled by the 2854 "Oper" field of the carried TLVs. As defined in Section 7.1, the 2855 "Oper" can be set to either "update" or "delete" when a TLV is 2856 carried in an Update_Request message. 2858 When the "Oper" set to update, it means to create or update a 2859 subscriber session, if the "Oper" set to delete, it indicates to 2860 delete a corresponding session on an UP. 2862 The format of Update_Request message is as follows: 2864 ::= 2865 [] 2866 [] 2867 [] 2868 [] 2869 [] 2871 Each Update_Request message will result in an Update_Response message 2872 that is defined in Section 6.2.8. 2874 6.2.8. Update_Response Message 2876 The Update_Response message is a response to an Update_Request 2877 message. It is used to confirm the update request (or reject it in 2878 the case of an error). The format of an Update_Response message is 2879 as follows: 2881 ::= 2882 [] 2883 2885 The return/error codes are carried in the Error Information TLV. 2886 They are listed as follows: 2888 0: Success. 2890 1: Failure, malformed message received. 2892 2: One or more of the TLVs was not understood. 2894 3001(Pool-Mismatch): The corresponding address pool cannot be 2895 found. 2897 3002 (Pool-Full): The address pool is fully allocated and no 2898 address segment is available. 2900 3003 (Subnet-Mismatch): The address pool subnet cannot be found. 2902 3004 (Subnet-Conflict): Subnets in the address pool have been 2903 classified into other clients. 2905 4001 (Update-Fail-No-Res): The forwarding table fails to be 2906 delivered because the forwarding resources are insufficient. 2908 4002 (QoS-Update-Success): The QoS policy takes effect. 2910 4003 (QoS-Update-Sq-Fail): Failed to process the queue in the QoS 2911 policy. 2913 4004 (QoS-Update-CAR-Fail): Processing of the CAR in the QoS 2914 policy fails. 2916 4005 (Statistic-Fail-No-Res): Statistics processing failed due to 2917 insufficient statistics resources. 2919 6.3. Event Message 2921 The Event message is used to report subscriber session traffic 2922 statistics and detection information. The format of Event message is 2923 as follows: 2925 ::= 2926 [] 2927 [] 2929 6.4. Report Message 2931 The Report message is used to report board and interface status on a 2932 UP. The format of Report message is as follows: 2934 ::= 2935 [] 2936 [] 2938 6.5. CGN Messages 2940 This document defines the following resource allocation messages: 2942 Type Message Name TLV that is carried 2943 ---- ------------------- ------------------------ 2944 200 Addr_Allocation_Req Address Allocation Request 2945 201 Addr_Allocation_Ack Address Allocation Response 2946 202 Addr_Renew_Req Address Renewal Request 2947 203 Addr_Renew_Ack Address Renewal Response 2948 204 Addr_Release_Req Address Release Request 2949 205 Addr_Release_Ack Address Release Response 2951 6.5.1. Addr_Allocation_Req Message 2953 The Addr_Allocation_Req message is used to request CGN address 2954 allocation. The format of Addr_Allocation_Req message is as follows: 2956 ::= 2957
2959 6.5.2. Addr_Allocation_Ack Message 2961 The Addr_Allocation_Ack message is a response to an 2962 Addr_Allocation_Req message. The format of Addr_Allocation_Ack 2963 message is as follows: 2965 ::= 2966
2968 6.5.3. Addr_Renew_Req Message 2970 The Addr_Renew_Req message is used to request address renewal. The 2971 format of Addr_Renew_Req message is as follows: 2973 ::= 2974
2976 6.5.4. Addr_Renew_Ack Message 2978 The Addr_Renew_Ack message is a response to an Addr_Renew_Req 2979 message. The format of Addr_Renew_Req message is as follows: 2981 ::= 2982
2984 6.5.5. Addr_Release_Req Message 2986 The Addr_Release_Req message is used to request address release. The 2987 format of Addr_Release_Req message is as follows: 2989 ::= 2990
2992 6.5.6. Addr_Release_Ack Message 2994 The Addr_Release_Ack message is a response to an Addr_Release_Req 2995 message. The format of Addr_Release_Ack message is as follows: 2997 ::= 2998
3000 6.6. Vendor Message 3002 The Vendor message is, in conjunction with the vendor TLV and vendor 3003 sub-TLV, can be used by vendors to extend the S-CUSP protocol. It's 3004 message type is 11. If the receiver does not recognize the message, 3005 an Error message will be returned to the sender. 3007 The format of the Vendor message is as follows: 3009 ::= 3010 3011 [] 3013 6.7 Error Message 3015 The Error message is defined to return some critical error 3016 information to the sender. If a receiver does not know the message 3017 type of a received message, it MUST return an Error message to the 3018 sender. 3020 The format of the Error message is as below: 3022 ::= 3023 3025 7. S-CUSP TLVs and Sub-TLVs 3027 This section specifies the following: 3029 o the format of the TLVs that appear in S-CUSP messages, 3031 o the format of the sub-TLVs that appear within the values of some 3032 TLVs, and 3034 o the format of some basic data fields that appear within TLVs or 3035 sub-TLVs. 3037 See Section 9 for a list of all defined TLVs and sub-TLVs. 3039 7.1. Common TLV Header 3041 S-CUSP messages consist of the common header specified in Section 6.1 3042 followed by TLVs formatted as specified in this section. 3044 0 1 2 3 3045 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 3046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3047 | Oper | TLV-Type | TLV-Length | 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 ~ Value ~ 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3052 Figure 32: Common TLV Header 3054 o Oper (4 bits): For Message-Types that indicate an operation on a 3055 data set, the Oper field is interpreted as Update, Delete, or 3056 Reserved as specified in Section 9.3. For all other Message-Types, 3057 the Oper field MUST be sent as zero and ignored on receipt. 3059 o TLV-Type (12 bits): The Type of a TLV, that is the meaning and 3060 format of the Value part, are determined by the TLV-Type of the 3061 TLV. See Section 9.2. 3063 o TLV-Length (2 bytes): The length of the Value portion of the TLV 3064 in bytes as an unsigned integer. 3066 o Value (variable length): This is the value portion of the TLV 3067 whose size is given by TLV-Length. The value portion consists of 3068 fields, frequently using one of the basic data field types (see 3069 Section 7.2) and sub-TLVs (see Section 7.3). 3071 7.2. Basic Data Fields 3073 This section specifies the binary format of several standard basic 3074 data fields that are used within other data structures in this 3075 specification. 3077 o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section 3078 7.3) to provide the length. The use of this data type in S-CUSP is 3079 to provide convenient labels for use by network operators in 3080 configuring and debugging their networks and interpreting S-CUSP 3081 messages. These labels will not normally be seen by subscribers. 3082 They are normally interpreted as ASCII [RFC20]. 3084 o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042]. 3086 o IPv4-Address: 8 octets. 4 octets of the IPv4 address value 3087 followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX. 3089 o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4 3090 octet integer n in the range of 0 to 128 which gives the address 3091 mask as the one's complement of 2**(128-n) - 1. 3093 o VLAN ID: 2 octets. As follows [802.1Q]: 3095 0 1 3096 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3098 | PRI |D| VLAN-ID | 3099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 PRI: Priority. Default value 7. 3103 D: Drop Eligibility Indicator (DEI). Default value 0. 3105 VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are 3106 not valid VLAN IDs [802.1Q].) 3108 7.3. Sub-TLV Format and Sub-TLVs 3110 In some cases, the Value portion of a TLV, as specified above, can 3111 contain one or more Sub-TLVs formatted as follows: 3113 0 1 2 3 3114 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 3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3116 | Type | Length | 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 | Value | 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 3121 Figure 33: Sub-TLV Header 3123 o Type (2 bytes): The Type of a Sub-TLV, that is the meaning and 3124 format of the Value part, are determined by the Type of the 3125 TLV. Sub-TLV Types numbers have the same meaning regardless of 3126 the TLV Type of the TLV within which the sub-TLV occurs. See 3127 Section 9.4. 3129 o Length (2 bytes): The length of the Value portion of the sub- 3130 TLV in bytes as an unsigned integer. 3132 o Value (variable length): This is the value portion of the sub- 3133 TLV whose size is given by Length. 3135 The sub-TLVs currently specified are defined in the following 3136 subsections. 3138 7.3.1. Name sub-TLVs 3140 This document defines the following name sub-TLVs that are used to 3141 carry the name of the corresponding object. The length of each of 3142 these sub-TLV is variable from 1 to 255 octets. The value is of type 3143 STRING padded with zeros octets to 4-octet alignment. 3145 Type Sub-TLV Name Meaning 3146 ----- -------------------- ------------------- 3147 1 VRF-Name The name of a VRF 3148 2 Ingress-QoS-Profile The name of an ingress QoS profile 3149 3 Egress-QoS-Profile The name of an egress QoS profile 3150 4 User-ACL-Policy The name of an ACL policy 3151 5 Multicast-ProfileV4 The name of an IPv4 multicast profile 3152 6 Multicast-ProfileV6 The name of an IPv6 multicast profile 3153 7 NAT-Instance The name of a NAT instance 3154 8 Pool-Name The name of an address pool 3156 7.3.2. Ingress-CAR sub-TLV 3158 The Ingress-CAR sub-TLV indicates the authorized upstream Committed 3159 Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR 3160 sub-TLV is 9 and the sub-TLV length is 16. The format is as shown in 3161 Figure 34. 3163 0 1 2 3 3164 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 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 | CIR (Committed Information Rate) | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | PIR (Peak Information Rate) | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | CBS (Committed Burst Size) | 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3172 | PBS (Peak Burst Size) | 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 Figure 34: Ingress-CAR sub-TLV 3177 Where: 3179 CIR (4 bytes): Guaranteed rate in bits/second. 3181 PIR (4 bytes): Burst rate in bits/second. 3183 CBS (4 bytes): The token bucket in bytes. 3185 PBS (4 bytes): Burst token bucket in bytes. 3187 These fields are unsigned integers. More details about CIR, PIR, CBS, 3188 and PBS can be found in [RFC2698]. 3190 7.3.3. Egress-CAR sub-TLV 3192 The Egress-CAR sub-TLV indicates the authorized downstream Committed 3193 Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub- 3194 TLV is 10 and its sub-TLV length is 16 octets. The format of the 3195 value part is as defined below. 3197 0 1 2 3 3198 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 3199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 | CIR (Committed Information Rate) | 3201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3202 | PIR (Peak Information Rate) | 3203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 | CBS (Committed Burst Size) | 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3206 | PBS (Peak Burst Size) | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 Figure 35: Egress-CAR sub-TLV 3211 Where: 3213 CIR (4 bytes): Guaranteed rate in bits/second. 3215 PIR (4 bytes): Burst rate in bits/second. 3217 CBS (4 bytes): The token bucket in bytes. 3219 PBS (4 bytes): Burst token bucket in bytes. 3221 These fields are unsigned integers. More details about CIR, PIR, CBS, 3222 and PBS can be found in [RFC2698]. 3224 7.3.4. If-Desc sub-TLV 3226 The If-Desc sub-TLV is defined to designate an interface. It is an 3227 optional sub-TLV that may be carried in those TLVs that have an "if- 3228 index" or "out-if-index" field. The If-Desc sub-TLV is used as a 3229 local unique identifier within a BNG. 3231 The sub-TLV type is 11 and the sub-TLV length is 12 octets. The 3232 format depends on the If-Type. The format of the value part is as 3233 follows: 3235 0 1 2 3 3236 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 3237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3238 | If-Type (1-5)| Chassis | Slot | 3239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3240 | Sub-Slot | Port Number | 3241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3242 | Sub-Port Number | 3243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 If-Desc sub-TLV (Physical Port) 3246 0 1 2 3 3247 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 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 | If-Type (6-7) | Reserved | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | Logic-ID | 3252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3253 | Sub-Port Number | 3254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3255 If-Desc sub-TLV (Virtual Port) 3257 Figure 36: If-Desc sub-TLV Formats 3259 Where: 3261 If-Type: 8 bits in length, indicates the type of an interface. 3262 Following types are defined in this document: 3264 0: Reserved 3265 1: Fast Ethernet (FE) 3266 2: GE 3267 3: 10GE 3268 4: 100GE 3269 5: Eth-Trunk 3270 6: Tunnel 3271 7: VE 3272 8-255: Reserved. 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. This 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 and so 3408 implementations will set this field to zero. The Capabilities 3409 field of the Hello TLV MUST be checked before any other TLVs in 3410 the Hello because capabilities defined in the future might 3411 extend existing TLVs or permit new TLVs. 3413 After the exchange of Hello messages, the CP and UP each perform a 3414 logical AND of the Sub-Version supported by the CP and the UP and 3415 separately perform a logical AND of the Capabilities bits fields for 3416 the CP and the UP. 3418 If the result of the AND of the Sub-Versions supported is zero, then 3419 no session can be established and the connection is torn down. If the 3420 result of the AND of the Sub-Versions supported is non-zero, then the 3421 session uses the highest Sub-Version supported by both the CP and UP. 3423 For example, if one side supports Sub-Versions 1, 3, 4, and 5 3424 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 3425 (VerSupported = 0x38000000) then 3 and 4 are the Sub-Versions in 3426 common and 4 is the highest Sub-Version supported by both sides. So 3427 Sub-Version 4 is used for the session that has been negotiated. 3429 The result of the logical AND of the Capabilities bits will show what 3430 additional capabilities both sides support. If this result is zero, 3431 there are no such capabilities so none can be used during the 3432 session. If this result is non-zero, it shows the additional 3433 capabilities that can be used during the session. The CP and the UP 3434 MUST NOT use a capability unless both advertise support. 3436 7.5. The Keep Alive TLV 3438 The Keep Alive TLV is defined to be carried in the Hello message. It 3439 provides timing information for the keep alive feature. The format 3440 of Hello TLV is as follows: 3442 0 1 2 3 3443 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 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3445 | Keepalive | DeadTimer | Reserved | 3446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 Figure 40: Keep Alive TLV 3450 Where: 3452 The TLV type: 102. 3454 The value of length: 4 octets. 3456 Keepalive (8 bits): Indicates the maximum period of time (in 3457 seconds) between two consecutive S-CUSP messages sent by the 3458 sender of the message containing this TLV as an unsigned integer. 3459 The minimum value for the Keepalive is 1 second. When set to 0, 3460 once the session is established, no further Keepalive messages are 3461 sent to the remote peer. A RECOMMENDED value for the Keepalive 3462 frequency is 30 seconds. 3464 DeadTimer (8 bits in length): Specifies the amount of time as an 3465 unsigned integer number of seconds after the expiration of which 3466 the S-CUSP peer can declare the session with the sender of the 3467 Hello message to be down if no S-CUSP message has been received. 3468 The DeadTimer SHOULD be set to 0 and MUST be ignored if the 3469 Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 3470 times the value of the Keepalive. 3472 The Reserved bits MUST be sent as zero and ignored on receipt. 3474 7.6. The Error Information TLV 3476 The Error Information TLV is a common TLV that can be used in many 3477 Response (e.g., Update_Response message) and ACK messages (e.g., 3478 Addr_Allocation_Ack message, etc.). It is used to convey the 3479 information about an error in the received S-CUSP message. The 3480 format of the Error Information TLV is as follows: 3482 0 1 2 3 3483 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 3484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3485 | Message-Type | Reserved | TLV-Type | 3486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3487 | Error Code | 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 Figure 41: Error Information TLV 3492 Where: 3494 The TLV type: 101. 3496 The value of length: 8 octets. 3498 Message-Type(1 byte): This parameter is the message type of the 3499 message containing an error. 3501 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3503 TLV-Type (2 bytes): Indicates which TLV caused the error. 3505 Error Code: 4 bytes in length. Indicate the specific Error Code 3506 (see Section 9.5). 3508 7.7. BAS Function TLV 3510 The BAS Function TLV is used by a CP to control the access mode, 3511 authentication methods, and other related functions of an interface 3512 on a UP. 3514 The format of the BAS Function TLV value part is as follows: 3516 0 1 2 3 3517 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 3518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3519 | If-Index | 3520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3521 | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | 3522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3523 | Flags | 3524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3525 | sub-TLVs (optional) | 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3528 Figure 42: BAS Function TLV 3530 Where: 3532 The TLV type: 1. 3534 The value of length: variable. 3536 If-Index: 4 bytes in length, a unique identifier of an interface 3537 of a BNG. 3539 Access-Mode: 1 byte in length, indicates the access mode of the 3540 interface. This document defines following values: 3542 0: Layer 2 subscriber; 3543 1: Layer 3 subscriber; 3544 2: Layer 2 leased line; 3545 3: Layer 3 leased line; 3546 4-255: Reserved. 3548 Auth-Method4: 1 byte in length, for IPv4 scenario, it indicates 3549 the authentication on this interface; this field is defined as a 3550 bitmap, this document defines following values (other bits are 3551 reserved and MUST be sent as zero and ignored on receipt): 3553 0x1: PPPoE authentication; 3554 0x2: DOT1X authentication; 3555 0x4: Web authentication; 3556 0x8: Web fast authentication; 3557 0x10: Binding authentication. 3559 Auth-Method6: 1 byte in length, for IPv6 scenario, it indicates 3560 the authentication on this interface; this field is defined as a 3561 bitmap, this document defines following values (other bits are 3562 reserved and MUST be sent as zero and ignored on receipt): 3564 0x1: PPPoE authentication; 3565 0x2: DOT1X authentication; 3566 0x4: Web authentication; 3567 0x8: Web fast authentication; 3568 0x10: Binding authentication; 3570 sub-TLVs: 3571 The IF-Desc sub-TLV can be carried. 3572 If-Desc sub-TLV: carries the interface information. 3574 The flags field is defined as follows: 3576 0 1 2 3 3577 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 3578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3579 | MBZ |Y|X|P|I|N|A|S|F| 3580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3582 Figure 43: Interface Flags 3584 Where: 3586 F (IPv4 Trigger) bit: Indicates whether IPv4 packets can 3587 trigger a subscriber to go online. 1: enabled, 0: disabled. 3589 S (IPv6 Trigger) bit: Indicates whether IPv6 packets can 3590 trigger a subscriber to go online. 1: enabled, 0: disabled. 3592 A (ARP Trigger) bit: Indicates whether ARP packets can trigger 3593 a subscriber to go online. 1: enabled, 0: disabled. 3595 N (ND Trigger) bit: Indicates whether ND packets can trigger a 3596 subscriber to go online. 1: enabled, 0: disabled. 3598 I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable 3599 traffic detection. 0: Disable traffic detection. 3601 P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable 3602 traffic detection. 0: Disable traffic detection. 3604 X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy 3605 and can process ARP requests across different Port+VLANs. 0: 3606 The ARP proxy is not enabled on the interface, and only the ARP 3607 requests of the same Port+VLAN are processed. 3609 Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and 3610 can process ND requests across different Port+VLANs. 0: The ND 3611 proxy is not enabled on the interface, and only the ND requests 3612 of the same Port+VLAN are processed. 3614 MBZ: Reserved bits that MUST be sent as zero and ignored on 3615 receipt. 3617 7.8. Routing TLVs 3619 Normally, after an S-CUSP session is established between a UP and a 3620 CP, the CP will allocate one or more blocks of IP addresses to the 3621 UP. Those IP addresses will be allocated to subscribers who will 3622 dial-up to the UP. In order to make sure that other nodes within the 3623 network learn how to reach those IP addresses, the CP needs to 3624 install one or more routes that can reach those IP addresses on the 3625 UP and notify the UP to advertise the routes to the network. 3627 The Routing TLVs are used by a CP to notify a UP of the network 3628 routing. They can be carried in the Update_Request message and 3629 Sync_Data message. 3631 7.8.1. IPv4 Routing TLV 3633 The IPv4 Routing TLV is used to carry IPv4 network routing related 3634 information. 3636 The format of the TLV value part is as below: 3638 0 1 2 3 3639 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 3640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3641 | User ID | 3642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3643 | Dest-Address | 3644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 | Next-Hop | 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 | Out-If-Index | 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | Cost | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 | Tag | 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 | Route Type | Reserved |A| 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3655 ~ sub-TLVs (optional) ~ 3656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3658 Figure 44: IPv4 Routing TLV 3660 Where: 3662 The TLV Type: 7 3664 The TLV Length: Variable 3666 User-ID: 4 bytes in length. Carries the user identifier. This 3667 field is filled with all Fs when a non-user route is delivered to 3668 the UP. 3670 Dest-Address (IPv4-Address type): Identifies the destination 3671 address. 3673 Next-Hop: (IPv4-Address type): Identifies the next hop address. 3675 Out-If-Index (4 bytes): Indicates the interface index. 3677 Cost (4 bytes): The cost value of the route. 3679 Tag (4 bytes): The tag value of the route. 3681 Route-Type (2 bytes): Indicates the route type. The options are 3682 as follows: 3684 0: User host route 3685 1: Radius authorization FrameRoute 3686 2: Network segment route 3687 3: Gateway route 3688 4: Radius authorized IP route 3689 5: L2TP LNS side user route 3691 Advertise-Flag: 1 bit. Indicates whether the route should be 3692 advertised by the UP. Following flags are defined: 3693 0: Not advertised, 3694 1: advertised. 3696 sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried. 3697 VRF-Name sub-TLV: indicates which VRF the route belongs to. 3698 If-Desc sub-TLV: carries the interface information. 3700 The Reserved field MUST be sent as zero and ignored on receipt. 3702 7.8.2. IPv6 Routing TLV 3704 The IPv6 Routing TLV is used to carry IPv6 network routing 3705 information. 3707 The format of this TLV is as follows: 3709 0 1 2 3 3710 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 3711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3712 | User ID | 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 ~ IPv6 Dest-Address ~ 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3716 ~ IPv6 Next-Hop ~ 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 | Out-If-Index | 3719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3720 | Cost | 3721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3722 | Tag | 3723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3724 | Route Type | Reserved |A| 3725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3726 ~ sub-TLVs (optional) ~ 3727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3729 Figure 45: IPv6 Routing TLV 3731 Where: 3733 The TLV Type: 7 3735 The TLV Length: Variable 3737 User-ID: 4 bytes in length. Carries the user identifier. This 3738 field is filled with all Fs when a non-user route is delivered to 3739 the UP. 3741 IPv6 Dest-Address (IPv6-Address type): Identifies the destination 3742 address. 3744 IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop 3745 address. 3747 Out-If-Index (4 bytes): Indicates the interface index. 3749 Cost (4 bytes): The cost value of the route. 3751 Tag (4 bytes): The tag value of the route. 3753 Route-Type: (2 bytes): Indicates the route type. The options are 3754 as follows: 3756 0: User host route 3757 1: Radius authorization FrameRoute 3758 2: Network segment route 3759 3: Gateway route 3760 4: Radius authorized IP route 3761 5: L2TP LNS side user route 3763 Advertise-Flag: 1 bit. Indicates whether the route should be 3764 advertised by the UP. Following flags are defined: 3765 0: Not advertised, 3766 1: advertised. 3768 sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried. 3769 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3770 belongs. 3771 If-Desc sub TLV: carries the interface information. 3773 The Reserved field MUST be sent as zero and ignored on receipt. 3775 7.9. Subscriber TLVs 3777 The Subscriber TLVs are defined for a CP to send the basic 3778 information about a user to a UP. 3780 7.9.1. Basic Subscriber TLV 3782 The Basic Subscriber TLV is used to carry the basic common 3783 information for all kinds of access subscribers. It is carried in an 3784 Update_Request message. 3786 The format of the Basic Subscriber TLV value part is as follows: 3788 0 1 2 3 3789 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 3790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3791 | User ID | 3792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3793 | Session ID | 3794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3795 | User MAC | 3796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3797 | User MAC | Oper ID | Reserved | 3798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3799 | Access Type |Sub-access Type| Account Type | Address Family| 3800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3801 | C-VID | P-VID | 3802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3803 | Detect Times | Detect Interval | 3804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3805 | If-Index | 3806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3807 ~ sub-TLVs (optional) ~ 3808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3810 Figure 46: Basic Subscriber TLV 3812 Where: 3814 The TLV Type: 2. 3816 The TLV Length: variable in length. 3818 User-ID (4 bytes): The identifier of a subscriber. 3820 Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero 3821 means non-PPPoE subscriber. 3823 User-Mac (MAC-Addr type): The MAC Address of a subscriber. 3825 Oper-ID (1 byte): Indicates the ID of an operation performed by a 3826 user. This field is carried in the response from the UP. 3828 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3830 Access-Type (1 byte): 3832 1: PPP access (PPP [RFC1661]) 3833 2: PPP over Ethernet over ATM access (PPPoEoA) 3834 3: PPP over ATM access (PPPoA [RFC3336]) 3835 4: PPP over Ethernet access (PPPoE [RFC2516]) 3836 5: PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) 3837 6: PPP over LNS access (PPPoLNS) 3838 7: IP over Ethernet DHCP access (IPoE_DHCP) 3839 8: IP over Ethernet EAP authentication access (IPoE_EAP) 3840 9: IP over Ethernet Layer 3 access (IPoE_L3) 3841 10: IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) 3842 11: Layer 2 Leased Line access (L2_Leased_Line) 3843 12: Layer 2 VPN Leased Line access (L2VPN_Leased_Line) 3844 13: Layer 3 Leased Line access (L3_Leased_Line) 3845 14: Layer 2 Leased line Sub-User access 3846 (L2_Leased_Line_SUB_USER) 3847 15: L2TP LAC tunnel access (L2TP_LAC) 3848 16: L2TP LNS tunnel access (L2TP_LNS) 3850 Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP 3851 relay is used. 3852 0: Reserved 3853 1: PPP Relay (for LAC) 3854 2: PPP termination (for LNS) 3856 Account-Type(1 byte): 3857 0: Collects statistics on IPv4 and IPv6 traffic of terminals 3858 independently. 3859 1: Collects statistics on IPv4 and IPv6 traffic of terminals. 3861 Address Family (1 byte) 3862 1: IPv4 3863 2: IPv6 3864 3: dual stack 3866 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 3867 indicates that the VLAN ID is invalid. The default value of PRI 3868 is 7, the value of DEI is 0, and the value of VID is 1~4094. The 3869 PRI value can also be obtained by parsing terminal packets. 3871 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 3872 indicates that the VLAN ID is invalid. The format is the same as 3873 that for C-VID. 3875 Detect-Times (2 bytes): Number of detection timeout times. The 3876 value 0 indicates that no detection is performed. 3878 Detect-Interval (2 bytes): Detection interval in seconds. 3880 If-Index (4 bytes): Interface index. 3882 Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried. 3883 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3884 belongs. 3885 If-Desc sub-TLV: carries the interface information. 3887 The Reserved field MUST be sent as zero and ignored on receipt. 3889 7.9.2. PPP Subscriber TLV 3891 The PPP Subscriber TLV is defined to carry PPP information of a User 3892 from a CP to a UP. It will be carried in an Update_Request message 3893 when PPPoE or L2TP access is used. 3895 The format of the TLV value part is as follows: 3897 0 1 2 3 3898 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 3899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3900 | User ID | 3901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3902 | MSS | Reserved |M| 3903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3904 | MRU | Reserved | 3905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3906 | Magic Number | 3907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3908 | Peer Magic Number | 3909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3911 Figure 47: PPP Subscriber TLV 3913 Where: 3915 The TLV type: 3. 3917 The TLV length: 12 octets. 3919 User-ID (4 bytes): The identifier of a subscriber. 3921 MSS-Value (2 bytes): Indicates the MSS value (in bytes). 3923 MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled. 3924 0: Disabled. 3925 1: Enabled. 3927 MRU (2 bytes): PPPoE local MRU (in bytes). 3929 Magic-Number (4 bytes): Local magic number in PPP negotiation 3930 packets. 3932 Peer-Magic-Number (4 bytes): Remote peer magic number. 3934 The Reserved fields MUST be sent as zero and ignored on receipt. 3936 7.9.3. IPv4 Subscriber TLV 3938 The IPv4 Subscriber TLV is defined to carry IPv4 related information 3939 for a BNG user. It will be carried in an Update_Request message when 3940 IPv4 IPoE, or PPPoE access is used. 3942 The format of the TLV value part is as follows: 3944 0 1 2 3 3945 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 3946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3947 | User ID | 3948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3949 | User IPv4 Address | 3950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3951 | Gateway IPv4 Address | 3952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3953 | MTU | Reserved |U|E|W|P| 3954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3955 ~ VRF-Name sub-TLV ~ 3956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3958 Figure 48: IPv4 Subscriber TLV 3960 Where: 3962 The TLV type: 4. 3964 The TLV length: variable. 3966 User-ID (4 bytes): The identifier of a subscriber. 3968 User-IPv4 (IPv4-Address): The IPv4 address of the subscriber. 3970 Gateway-IPv4 (IPv4-Address): The gateway address of the 3971 subscriber. 3973 Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on. 3975 Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on. 3977 Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off, 3978 1: on. 3980 IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) 3981 flag. 0: off, 1: on. 3983 MTU 2 bytes MTU value. The default value is 1500. 3985 VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. 3987 The Reserved field MUST be sent as zero and ignored on receipt. 3989 7.9.4. IPv6 Subscriber TLV 3991 The IPv6 Subscriber TLV is defined to carry IPv6 related information 3992 for a BNG user. It will be carried in an Update_Request message when 3993 IPv6 IPoE, or PPPoE access is used. 3995 The format of the TLV value part is as follows: 3997 0 1 2 3 3998 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 3999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4000 | User ID | 4001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4002 ~ User PD-Address (IPv6 Address List sub-TLV) ~ 4003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4004 ~ Gateway ND-Address (IPv6 Address List sub-TLV) ~ 4005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4006 | User IANA Address | 4007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4008 | IPv6 Interface ID | 4009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4010 | IPv6 Interface ID (cont.) | 4011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4012 | MTU | Reserved |U|E|W|P| 4013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4014 ~ VRF Name sub-TLV (optional) ~ 4015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4017 Figure 49: IPv6 Subscriber TLV 4019 Where: 4021 The TLV type: 5. 4023 The TLV length: variable. 4025 User-ID (4 bytes): The identifier of a subscriber. 4027 User PD-Addresses (IPv6 Address List): Carries a list of Prefix 4028 Delegation (PD) addresses of the subscriber. 4030 User ND-Addresses (IPv6 Address List): Carries a list of Neighbor 4031 Discovery (ND) addresses of the subscriber. 4033 User IANA-Address (IPv6-Address): The IANA address of the 4034 subscriber. 4036 IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface. 4038 Portal Force 1 bit (P): Push advertisement, 0: off, 1: on. 4040 Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on. 4042 Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off; 4043 1: on. 4045 IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0: 4046 off; 1: on. 4048 MTU (2 bytes): The MTU value. The default value is 1500. 4050 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4051 belongs. 4053 The Reserved field MUST be sent as zero and ignored on receipt. 4055 7.9.5. IPv4 Static Subscriber Detect TLV 4057 The IPv4 Static Subscriber Detect TLV is defined to carry IPv4 4058 related information for a static access subscriber. It will be 4059 carried in an Update_Request message when IPv4 static access on a UP 4060 needs to be enabled. 4062 The format of the TLV value part is as follows: 4064 0 1 2 3 4065 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 4066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4067 | If-Index | 4068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4069 | C-VID | P-VID | 4070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4071 | User Address | 4072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4073 | Gateway Address | 4074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4075 | User MAC | 4076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4077 | User MAC (cont.) | Reserved | 4078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4079 ~ sub-TLVs (optional) ~ 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4082 Figure 50: IPv4 Static Subscriber TLV 4084 Where: 4086 The TLV type: 6. 4088 The TLV length: variable. 4090 If-Index (4 bytes): The interface index of the interface from 4091 which the subscriber will dial-up. 4093 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4094 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4096 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4097 indicates that the VLAN ID is invalid. The format is the same as 4098 that of the C-VID. A valid value is 1~4094. For a single-layer 4099 VLAN, set this parameter to PeVid. 4101 User Address (IPv4-Addr): The user's IPv4 address. 4103 Gateway Address (IPv4-Addr): The gateway's IPv4 Address. 4105 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4107 Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried. 4108 VRF-Name sub-TLV: Indicates the VEF to which the subscriber 4109 belongs. 4110 If-Desc sub-TLV: Carries the interface information. 4112 The Reserved field MUST be sent as zero and ignored on receipt. 4114 7.9.6. IPv6 Static Subscriber Detect TLV 4116 The IPv6 Static Subscriber Detect TLV is defined to carry IPv6 4117 related information for a static access subscriber. It will be 4118 carried in an Update_Request message when needed to enable IPv6 4119 static subscriber detection on a UP. 4121 The format of the TLV value part is as follows: 4123 0 1 2 3 4124 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 4125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4126 | If-Index | 4127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4128 | C-VID | P-VID | 4129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4130 ~ User Address ~ 4131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4132 ~ Gateway Address ~ 4133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4134 | User MAC | 4135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4136 | User MAC (cont.) | Reserved | 4137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4138 ~ sub-TLVs (optional) ~ 4139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4141 Figure 51: IPv6 Static Subscriber Detect TLV 4143 Where: 4145 The TLV type: 6. 4147 The TLV length: variable. 4149 If-Index (4 bytes): The interface index of the interface from 4150 which the subscriber will dial-up. 4152 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4153 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4155 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4156 indicates that the VLAN ID is invalid. The format is the same as 4157 that the of C-VID. A valid value is 1~4094. For a single-layer 4158 VLAN, set this parameter to PeVid. 4160 User Address (IPv6-Address type): The subscriber's IPv6 address. 4162 Gateway Address (IPv6-Address type): The gateway's IPv6 Address. 4164 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4166 sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried 4167 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4168 belongs. 4169 If-Desc sub-TLV: Carries the interface information. 4171 The Reserved field MUST be sent as zero and ignored on receipt. 4173 7.9.7. L2TP-LAC Subscriber TLV 4175 The L2TP-LAC Subscriber TLV is defined to carry the related 4176 information for a L2TP LAC access subscriber. It will be carried in 4177 an Update_Request message when L2TP LAC access is used. 4179 The format of the TLV value part is as follows: 4181 0 1 2 3 4182 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 4183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4184 | User ID | 4185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4186 | Local Tunnel ID | Local Session ID | 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4188 | Remote Tunnel ID | Remote Session ID | 4189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4191 Figure 52: L2TP-LAC Subscriber TLV 4193 Where: 4195 The TLV type: 11. 4197 The TLV length: 12 octets. 4199 User-ID (4 bytes): The identifier of a user/subscriber. 4201 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4203 Local-Session-ID (2 bytes): The local session ID with the L2TP 4204 tunnel. 4206 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4208 Remote-Session-ID (2 bytes): The remote session ID of the L2TP 4209 tunnel. 4211 7.9.8. L2TP-LNS Subscriber TLV 4213 The L2TP-LNS Subscriber TLV is defined to carry the related 4214 information for a L2TP LNS access subscriber. It will be carried in 4215 an Update_Request message when L2TP LNS access is used. 4217 The format of the TLV value part is as follows: 4219 0 1 2 3 4220 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 4221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4222 | User ID | 4223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4224 | Local Tunnel ID | Local Session ID | 4225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4226 | Remote Tunnel ID | Remote Session ID | 4227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4229 Figure 53: L2TP-LNS Subscriber TLV 4231 Where: 4233 The TLV type: 12. 4235 The TLV length: 12 octets. 4237 User-ID (4 bytes): The identifier of a user/subscriber. 4239 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4241 Local-Session-ID (2 bytes): The local session ID with the L2TP 4242 tunnel. 4244 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4246 Remote-Session-ID (2 bytes): The remote session ID of the L2TP 4247 tunnel. 4249 7.9.9. L2TP-LAC Tunnel TLV 4251 The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel 4252 related information. It will be carried in the Update_Request 4253 message when L2TP LAC access is used. 4255 The format of the TLV value part is as follows: 4257 0 1 2 3 4258 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 4259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4260 | Local Tunnel ID | Remote Tunnel ID | 4261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4262 | Source Port | Destination Port | 4263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4264 ~ Tunnel Source Address ~ 4265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4266 ~ Tunnel Destination Address ~ 4267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4268 ~ VRF Name sub-TLV ~ 4269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4271 Figure 54: L2TP-LAC Tunnel TLV 4273 Where: 4275 The TLV type: 13. 4277 The TLV length: variable. 4279 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4281 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4283 Source-Port (2 bytes): The source UDP port number of an L2TP 4284 subscriber. 4286 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4287 subscriber. 4289 Source-IP (IPv4/v6): The source IP address of the tunnel. 4291 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4293 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4294 belongs. 4296 7.9.10. L2TP-LNS Tunnel TLV 4298 The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel 4299 related information. It will be carried in the Update_Request 4300 message when L2TP LNS access is used. 4302 The format of the TLV value part is as follows: 4304 0 1 2 3 4305 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 4306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4307 | Local Tunnel ID | Remote Tunnel ID | 4308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4309 | Source Port | Destination Port | 4310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4311 ~ Tunnel Source Address ~ 4312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4313 ~ Tunnel Destination Address ~ 4314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4315 ~ VRF Name sub-TLV ~ 4316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4318 Figure 55: L2TP-LNS Tunnel TLV 4320 Where: 4322 The TLV type: 14. 4324 The TLV length: variable. 4326 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4328 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4330 Source-Port (2 bytes): The source UDP port number of an L2TP 4331 subscriber. 4333 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4334 subscriber. 4336 Source-IP (IPv4/v6): The source IP address of the tunnel. 4338 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4340 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4341 belongs. 4343 7.9.11. Update Response TLV 4345 The Update Response TLV is used to return the operation result of an 4346 update request. It is carried in the Update_Response message as a 4347 response to the Update_Request message. 4349 The format of Update Response TLV is as follows: 4351 0 1 2 3 4352 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 4353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4354 | User-ID | 4355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4356 | User-Trans-ID | Oper-Code | Oper-Result | Reserved | 4357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4358 | Error-Code | 4359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4361 Figure 56: Update Response TLV 4363 Where: 4365 The TLV type: 302. 4367 The TLV length: 12. 4369 User-ID (4 bytes): A unique identifier of an user/subscriber. 4371 User-Trans-ID (1 byte): In the case of dual-stack access or when 4372 modifying a session, User-Trans-ID is used to identify a user 4373 operation transaction. It is used by the CP to correlate a 4374 response to a specific request. 4376 Oper-Code (1 byte): Operation code. 1: update, 2: delete. 4378 Oper-Result (1 byte): Operation Result. 0: Success, Others: 4379 Failure. 4381 Error-Code (4 bytes): Operation failure cause code. for details, 4382 see Section 9.5. 4384 The Reserved field MUST be sent as zero and ignored on receipt. 4386 7.9.12. Subscriber Policy TLV 4388 The Subscriber Policy TLV is used to carry the policies that will be 4389 applied to a subscriber. It is carried in the Update_Request 4390 message. 4392 The format of the TLV value part is as follows: 4394 0 1 2 3 4395 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 4396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4397 | User ID | 4398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4399 | I-Priority | E-Priority | Reserved | 4400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4401 ~ sub-TLVs ~ 4402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4404 Figure 57: User QoS Policy Information TLV 4406 Where: 4408 The TLV type: 6. 4410 The TLV length: variable. 4412 User-ID (4 bytes): The identifier of a user/subscriber. 4414 Ingress-Priority (1 byte): Indicates the upstream priority. The 4415 value range is 0~7. 4417 Egress-Priority (1 byte): Indicates the downstream priority. The 4418 value range is 0~7. 4420 sub-TLVs: The sub-TLVs that are present can occur in any order. 4422 Ingress-CAR sub-TLV: Upstream CAR. 4424 Egress-CAR sub-TLV: Downstream CAR. 4426 Ingress-QoS-Profile sub-TLV: Indicates the name of the QoS- 4427 Profile profile in the upstream direction. 4429 Egress-QoS-Profile Sub-TLV: Indicates the name of the QoS- 4430 Profile profile in the downstream direction. 4432 User-ACL-Policy Sub-TLV: All ACL user policies, including 4433 v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, 4434 v4SpecialACL, and v6SpecialACL. 4436 Multicast-Profile4 Sub-TLV: IPv4 multicast policy name. 4438 Multicast-Profile6 Sub-TLV: IPv6 multicast policy name. 4440 NAT-Instance Sub-TLV: Indicates the instance ID of a NAT user. 4442 The Reserved field MUST be sent as zero and ignored on receipt. 4444 7.9.13. Subscriber CGN Port Range TLV 4446 The Subscriber CGN Port Range TLV is used to carry the NAT public 4447 address and port range. It will be carried in the Update_Response 4448 message when CGN is used. 4450 The format of this TLV is as follows: 4452 0 1 2 3 4453 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 4454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4455 | User ID | 4456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4457 | NAT-Port-Start | NAT-Port-End | 4458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4459 | NAT-Address | 4460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4462 Figure 58: Subscriber CGN Port Range TLV 4464 Where: 4466 The TLV type: 15. 4468 The TLV length: 12 octets. 4470 User-ID (4 bytes): The identifier of a user/subscriber. 4472 NAT-Port-Start (2 bytes): The start port number. 4474 NAT-Port-End (2 bytes): The end port number. 4476 NAT-Address (4 bytes): The NAT public network address. 4478 7.10. Device Status TLVs 4480 The TLVs in this section are for reporting Interface and Board level 4481 information from the UP to the CP. 4483 7.10.1. Interface Status TLV 4485 The Interface Status TLV is used to carry the status information of 4486 an interface on a UP. It is carried in a Report message. 4488 The format of the value part of this TLV is as follows: 4490 0 1 2 3 4491 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 4492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4493 | If-Index | 4494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4495 | MAC Address (upper part) | 4496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4497 | MAC Address (lower part) | Phy-State | Reserved | 4498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4499 | MTU | 4500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4501 | sub-TLVs (optional) | 4502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4504 Figure 59: Interface Status TLV 4506 Where: 4508 The TLV type: 200. 4510 The TLV length: variable. 4512 If-Index (4 bytes): Indicates the interface index. 4514 MAC-Address (MAC-Addr type): Interface MAC address. 4516 Phy-State (1 byte): Physical status of the interface. 0: down, 1: 4517 Up 4519 MTU (4 bytes): Interface MTU value. 4521 sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried. 4523 The Reserved field MUST be sent as zero and ignored on receipt. 4525 7.10.2. Board Status TLV 4527 The Board Status TLV is used to carry the status information of a 4528 board on an UP. It is carried in a Report message. 4530 The format of Board Status TLV is as follows: 4532 0 1 2 3 4533 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 4534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4535 | Board-Type | Board-State | Reserved | Chassis | 4536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4537 | Slot | Reserved | 4538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 Figure 60: Interface Resource TLV 4542 Where: 4544 The TLV type: 201. 4546 The TLV length: 8 octets. 4548 Chassis (1 byte): The chassis number of the Board. 4550 Slot (1 byte): The slot number of the Board. 4552 Sub-Slot (1 byte): The sub-slot number of the Board. 4554 Board-Type (1 byte): 4555 1: CGN Service Process Unit (SPU) board. 4556 2: Line Process Unit (LPU) Board. 4558 Board-State (1 byte): 4559 0: Normal. 4560 1: Abnormal. 4562 The reserved field MUST be sent as zero and ignored on receipt. 4564 7.11. CGN TLVs 4566 7.11.1. Address Allocation Request TLV 4568 The Address Allocation Request TLV is used to request address 4569 allocation from CP. An address Pool-Name sub-TLV is carried to 4570 indicate from which address pool to allocate addresses. The Address 4571 Allocation Request TLV is carried in the Addr_Allocation_Req message. 4573 The format of the value part of this TLV is as follows: 4575 0 1 2 3 4576 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 4577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4578 ~ Pool-Name sub-TLV ~ 4579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4581 Figure 61: Address Allocation Request TLV 4583 Where: 4585 The TLV type: 400. 4587 The TLV length: variable. 4589 Pool-Name sub-TLV: Indicates from which Address pool to allocate 4590 address. 4592 7.11.2. Address Allocation Response TLV 4594 The Address Allocation Response TLV is used to return the address 4595 allocation result, it is carried the Addr_Allocation_Ack message. 4597 The value part of the Address Allocation Response TLV is formatted as 4598 follows: 4600 0 1 2 3 4601 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 4602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4603 | Lease Time | 4604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4605 | IPv4 Addr and Mask | 4606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4607 | IPv4 Addr and Mask continued | 4608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4609 | Error-Code | 4610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4611 ~ Pool-Name sub-TLV ~ 4612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4614 Figure 62: Address Assignment Response TLV 4616 Where: 4618 The TLV type: 401. 4620 The TLV length: variable. 4622 Lease Time (4 bytes): Duration of address lease in seconds. 4624 IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4 4625 address. 4627 Error-Code (4 bytes): Indicates success or an error. 4629 0: Success. 4631 1: Failure. 4633 3001 (Pool-Mismatch): The corresponding address pool cannot be 4634 found. 4636 3002 (Pool-Full): The address pool is fully allocated and no 4637 address segment is available. 4639 Pool-Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4640 Address pool the address is allocated. 4642 7.11.3. Address Renewal Request TLV 4644 The Address Renewal Request TLV is used to request address renewal 4645 from the CP. It is carried the Addr_Renew_Req message. 4647 The format of this TLV value is as follows: 4649 0 1 2 3 4650 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 4651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4652 | IPv4 Address and Mask | 4653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4654 | IPv4 Address and Mask continued | 4655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4656 ~ Pool-Name sub-TLV ~ 4657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4659 Figure 63: Address Renewal Request TLV 4661 Where: 4663 The TLV type: 402. 4665 The TLV length: variable. 4667 IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed. 4669 Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4670 Address pool to renew the address. 4672 7.11.4. The Address Renewal Response TLV 4674 The Address Renewal Response TLV is used to return the address 4675 renewal result. It is carried in the Addr_Renew_Ack message. 4677 The format of this TLV value is as follows: 4679 0 1 2 3 4680 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 4681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4682 | IPv4 Address and Mask | 4683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4684 | IPv4 Address and Mask continued | 4685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4686 | Error-Code | 4687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4688 ~ Pool-Name sub-TLV ~ 4689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4691 Figure 64: Address Renewal Response TLV 4693 Where: 4695 The TLV type: 403. 4697 The TLV length: variable. 4699 Client-IP (IPv4-Address type): The renewed IPv4 address. 4701 Error Code (4 bytes): Indicates success or an error: 4703 0: Renew success. 4705 1: Renew failed. 4707 3001 (Pool-Mismatch): The corresponding address pool cannot be 4708 found. 4710 3002 (Pool-Full): The address pool is fully allocated and no 4711 address segment is available. 4713 3003 (Subnet-Mismatch): The address pool subnet cannot be 4714 found. 4716 3004 (Subnet-Conflict): Subnets in the address pool have been 4717 assigned to other clients. 4719 Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4720 Address pool to renew the address. 4722 7.11.5. Address Release Request TLV 4724 The Address Release Request TLV is used to release an IPv4 address. 4725 It is carried in the Addr_Release_Req message. 4727 The value part of this TLV is formatted as follows: 4729 0 1 2 3 4730 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 4731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4732 | IPv4 Address and Mask | 4733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4734 | IPv4 Address and Mask continued | 4735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4736 ~ Pool-Name sub-TLV ~ 4737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4739 Figure 65: Address Release Request TLV 4741 Where: 4743 The TLV type: 404. 4745 The TLV length: variable. 4747 IPv4 Address and Mask (IPv4-Address type): The IPv4 address be 4748 released. 4750 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4751 Address pool to release the address. 4753 7.11.6. The Address Release Response TLV 4755 The Address Release Response TLV is used to return the address 4756 release result. It is carried in the Addr_Release_Ack message. 4758 The format of this TLV is as follows: 4760 0 1 2 3 4761 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 4762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4763 | IPv4 Address and Mask | 4764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4765 | IPv4 Address and Mask continued | 4766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4767 | Error-Code | 4768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4769 ~ Pool-Name sub-TLV ~ 4770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4772 Figure 66: Address Renewal Response TLV 4774 Where: 4776 The TLV type: 405. 4778 The TLV length: variable. 4780 Client-IP (IPv4-Address type): The released IPv4 address. 4782 Error-Code (4 bytes): Indicates success or an error. 4784 0: Address release success. 4786 1: Address release failed. 4788 3001 (Pool-Mismatch): The corresponding address pool cannot be 4789 found. 4791 3003 (Subnet-Mismatch): The address cannot be found. 4793 3004 (Subnet-Conflict): The address has been allocated to 4794 another subscriber. 4796 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4797 address pool to release the address. 4799 7.12. Event TLVs 4800 7.12.1. Subscriber Traffic Statistics TLV 4802 The Subscriber Traffic Statistics TLV is used to return the traffic 4803 statistics of a user/subscriber. The format of this TLV is as 4804 follows: 4806 0 1 2 3 4807 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 4808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4809 | User-ID | 4810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4811 | Statistics Type | 4812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4813 | Ingress Packets (upper part) | 4814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4815 | Ingress Packets (lower part) | 4816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4817 | Ingress Bytes (upper part) | 4818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4819 | Ingress Bytes (lower part) | 4820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4821 | Ingress Loss Packets (upper part) | 4822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4823 | Ingress Loss Packets (lower part) | 4824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4825 | Ingress Loss Bytes (upper part) | 4826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4827 | Ingress Loss Bytes (lower part) | 4828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4829 | Egress Packets (upper part) | 4830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4831 | Egress Packets (lower part) | 4832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4833 | Egress Bytes (upper part) | 4834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4835 | Egress Bytes (lower part) | 4836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4837 | Egress Loss Packets (upper part) | 4838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4839 | Egress Loss Packets (lower part) | 4840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4841 | Egress Loss Bytes (upper part) | 4842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4843 | Egress Loss Bytes (lower part) | 4844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4846 Figure 67: Subscriber Traffic Statistics TLV 4848 Where: 4850 The TLV type: 300. 4852 The TLV length: 72 octets. 4854 User-ID (4 bytes): The user/subscriber identifier. 4856 Statistics-Type (4 bytes): Traffic type. It can be one of the 4857 following options: 4859 0: IPv4 traffic. 4860 1: IPv6 traffic. 4861 2: Dual stack traffic. 4863 Ingress Packets (8 bytes): The number of the packets in upstream 4864 direction. 4866 Ingress Bytes (8 bytes): The bytes of the upstream traffic. 4868 Ingress Loss Packets (8 bytes): The number of the lost packets in 4869 upstream direction. 4871 Ingress Loss Bytes (8 bytes): The bytes of the lost upstream 4872 packets. 4874 Egress Packets (8 bytes): The number of the packets in downstream 4875 direction. 4877 Egress Bytes (8 bytes): The bytes of the downstream traffic. 4879 Egress Loss Packets (8 bytes): The number of the lost packets in 4880 downstream direction. 4882 Egress Loss Bytes (8 bytes): The bytes of the lost downstream 4883 packets. 4885 7.12.2. Subscriber Detection Result TLV 4887 The Subscriber Detection Result TLV is used to return the detection 4888 result of a subscriber. Subscriber detection is a function to detect 4889 whether a subscriber is online or not. The result can be used by the 4890 CP to determine how to deal with the subscriber session. (e.g., 4891 delete the session if detection failed). 4893 The format of this TLV value part is as follows: 4895 0 1 2 3 4896 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 4897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4898 | User-ID | 4899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4900 | Detect Type | Detect Result | Reserved | 4901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4903 Figure 68: Subscriber Detection Result TLV 4905 Where: 4907 The TLV type: 301. 4909 The TLV length: 8 octets. 4911 User-ID (4 bytes): A user/subscriber identifier. 4913 Detect-Type (1 byte): 4915 0: IPv4 detection. 4917 1: IPv6 detection. 4919 2: PPP detection. 4921 Detect-Result (1 bytes): 4923 0: Indicates that the detection is successful. 4925 1: Detection failure. The UP needs report only when the 4926 detection fails. 4928 The Reserved field MUST be sent as zero and ignored on receipt. 4930 7.13. Vendor TLV 4932 The Vendor ID TLV occurs as the first TLV in the Vendor message 4933 (Section 6.6). It provides a Sub-Type that effectively extends the 4934 message type in the message header, provides for versioning of vendor 4935 TLVs, and can accommodate sub-TLVs. 4937 The value part of the Vendor TLV is formatted as follows: 4939 0 1 2 3 4940 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 4941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4942 | Vendor ID | 4943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4944 | Sub-Type | Sub-Type-Version | 4945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4946 ~ sub-TLVs (optional) ~ 4947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4949 Figure 69: Vendor TLV 4951 Where: 4953 The TLV type: 1024. 4955 The TLV length: variable. 4957 Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS [RFC2865]. 4959 Sub-Type (2 bytes): Used by the Vendor to distinguish multiple 4960 different vendor messages. 4962 Sub-Type-Version (2 bytes): Used by the Vendor to distinguish 4963 different versions of a Vendor Defined message sub-type. 4965 Sub-TLVs (variable): Sub-TLVs as specified by the vendor. 4967 Since Vendor code will be handling the TLV after the Vendor ID field 4968 is recognized, the remainder of the TLV value can be organized 4969 however the vendor wants. But it is desirable for a vendor to be able 4970 to define multiple different vendor messages and to keep track of 4971 different versions of its vendor defined messages. Thus, it is 4972 RECOMMENDED that the vendor assign a Sub-Type value for each vendor 4973 message that it defines different from other Sub-Type values that 4974 vendor has used. Also, when modifying a vendor defined message in a 4975 way potentially incompatible with a previous definition, the vendor 4976 SHOULD increase the value it is using in the Sub-Type-Version field. 4978 8. Implementation Status 4980 RFC Editor: Please remove this section before publication. 4982 This section discusses the status of implementations that have 4983 provided information and the testing of this protocol at the time of 4984 posting of this Internet-Draft, and is based on the proposal in 4985 [RFC7942] ("Improving Awareness of Running Code: The Implementation 4986 Status Section"). The description of implementations in this section 4987 is intended to assist in processing drafts to RFCs. 4989 Please note that the listing of any individual implementation or test 4990 results here does not imply endorsement by the RFC Editor or the 4991 IETF. Furthermore, no effort has been spent to verify the 4992 information presented here that was supplied by contributors. This 4993 is not intended as, and must not be construed to be, a catalog of 4994 available implementations or their testing or features. Readers are 4995 advised to note that other implementations may exist. 4997 According to [RFC7942], "this will allow reviewers ... to assign due 4998 consideration to documents that have the benefit of running code, 4999 which may serve as evidence of valuable experimentation and feedback 5000 that have made the implemented protocols more mature.". 5002 8.1. Implementations 5004 Information on three S-CUSP implementations appears below. 5006 8.1.1. Huawei Technologies 5008 Name: Cloud-based BNG. 5010 Maturity: Production. 5012 Coverage: According to S-CUSP protocol. 5014 Contact information: 5015 Zhouyi Yu: yuzhouyi@huawei.com 5017 Date: 2018-11-01 5019 8.1.2. ZTE 5021 Name: ZXR10 V6000 vBRAS 5023 Maturity: Production 5025 Coverage: According to S-CUSP protocol. 5027 Contact information: 5028 Yong Chen: 10056167@zte.com.cn 5029 Huaibin Wang: 10008729@zte.com.cn 5031 Date: 2018-12-01 5033 8.1.3. H3C 5035 Name: CUSP protocol for BRAS Control Plane and User Plan 5036 Separation 5038 Maturity: Research 5040 Coverage: According to S-CUSP protocol 5042 Contact information: mengdan@h3c.com; liuhanlei@h3c.com 5044 Date: 2019-1-30 5046 8.2. Hackathon 5048 Successful use of the protocol at the IETF-102 Hackathon, Montreal, 5049 Quebec, in 2018. 5051 Hackathon Project: Control Plane and User Plane Separation BNG 5052 control channel Protocol (CUSP) 5054 Champions: Zhenqiang Li, Michael Wang 5056 Report: See 5057 github.com/IETF-Hackathon/ietf102-project-presentations/blob/ 5058 master/IETF102-hackathon-presentation-CUSP.pptx 5060 8.3. EANTC Testing 5062 EANTC (European Advanced Networking Test Center (www.eantc.de)) 5063 tested the Huawei implementation. Their summary was as follows: 5064 "EANTC tested advanced aspects of the Cloud-based Broadband Network 5065 Gateway (vBNG) with a focus on performance, scalability and high 5066 availability with up to 20 Million emulated subscribers. The solution 5067 performed very well across all test scenarios." 5069 See report at 5070 www.eantc.de/fileadmin/eantc/downloads/News/2018/EANTC-vBRAS- 5071 phase2.pdf 5073 9. Summary of Major S-CUSP Codepoints 5075 This section provides tables of the major S-CUSP codepoints, 5076 particularly message types, TLV types, TLV operation codes, sub-TLV 5077 types, and error codes. In most cases, references are provided to 5078 relevant sections elsewhere in this document. 5080 9.1. Message Types 5082 Type Name Section of this document 5083 ------- ---------------- ------------------------ 5084 0 - Reserved 5085 1 Hello 6.2.1. 5086 2 Keepalive 6.2.2. 5087 3 Sync_Request 6.2.3. 5088 4 Sync_Begin 6.2.4. 5089 5 Sync_Data 6.2.5. 5090 6 Sync_End 6.2.6. 5091 7 Update_Request 6.2.7. 5092 8 Update_Response 6.2.8. 5093 9 Report 6.4. 5094 10 Event 6.3. 5095 11 Vendor 6.6. 5096 12 Error 6.7. 5097 13-199 - Unassigned 5098 200 Addr_Allocation_Req 6.5.1. 5099 201 Addr_Allocation_Ack 6.5.2. 5100 202 Addr_Renew_Req 6.5.3. 5101 203 Addr_Renew_Ack 6.5.4. 5102 204 Addr_Release_Req 6.5.5. 5103 205 Addr_Release_Ack 6.5.6. 5104 206-254 - Unassigned 5105 255 - Reserved 5107 9.2. TLV Types 5109 Type Name Usage Description 5110 ------ ------------ -------------------------- 5111 0 reserved - 5112 1 BAS Function Carries the BNG access 5113 functions to be enabled or 5114 disabled on specified 5115 interfaces. 5116 2 Basic Subscriber Carries the basic information 5117 about a BNG subscriber. 5118 3 PPP Subscriber Carries the PPP information 5119 about a BNG subscriber. 5120 4 IPv4 Subscriber Carries the IPv4 address of a 5121 BNG subscriber. 5122 5 IPv6 Subscriber Carries the IPv6 address of a 5123 BNG subscriber. 5124 6 Subscriber Policy Carries the policy information 5125 applied to a BNG subscriber. 5126 7 IPv4 Routing Carries the IPv4 network 5127 routing information. 5128 8 IPv6 Routing Carries the IPv6 network 5129 routing information. 5130 9 IPv4 Static Subscriber Detect Carries the IPv4 static 5131 subscriber detect information. 5132 10 IPv6 Static Subscriber Detect Carries the IPv6 static 5133 subscriber detect information. 5134 11 L2TP-LAC Subscriber Carries the L2TP LAC 5135 subscriber information. 5136 12 L2TP-LNS Subscriber Carries the L2TP LNS 5137 subscriber information. 5138 13 L2TP-LAC-Tunnel Carries the L2TP LAC tunnel 5139 subscriber information. 5140 14 L2TP-LNS-Tunnel Carries the L2TP LNS tunnel 5141 subscriber information. 5142 15 Subscriber CGN Port Range Carries the public IPv4 5143 address and related port range 5144 of a BNG subscriber. 5145 16-99 unassigned - 5146 100 Hello Used for version and Keep 5147 Alive timers negotiation. 5148 101 Error Information Carried in the Ack of the 5149 control message. Carries the 5150 processing result, success, or 5151 error. 5152 102 Keep Alive Carried in the Hello message 5153 for Keep Alive timers 5154 negotiation. 5155 103-199 unassigned - 5156 200 Interface Status Interfaces status reported by 5157 the UP including physical 5158 interfaces, sub-interfaces, 5159 trunk interfaces, and tunnel 5160 interfaces. 5161 201 Board Status Board information reported by 5162 the UP including the board 5163 type and in-position status. 5164 202-299 unassigned - 5165 300 Subscriber Traffic Statistics User traffic statistics. 5166 301 Subscriber Detection Results User detection information. 5167 302 Update Response The processing result of a 5168 subscriber session update. 5170 303-299 unassigned - 5171 400 Address Allocation Request Request address allocation. 5172 401 Address Allocation Response Address allocation response. 5173 402 Address Renewal Request Request for address lease 5174 renewal. 5175 403 Address Renewal Response Response to a request for 5176 extending an IP address lease. 5177 404 Address Release Request Request to release the 5178 address. 5179 405 Address Release Response Ack of a message releasing an 5180 IP address. 5181 406-1023 unassigned - 5182 1024 Vendor As implemented by vendor. 5183 1039-4095 unassigned - 5185 9.3. TLV Operation Codes 5187 TLV operation codes appear in the Oper field in the header of some 5188 TLVs. See Section 7.1. 5190 Code Operation 5191 ---- ---------- 5192 0 - reserved 5193 1 Update 5194 2 Delete 5195 3-15 - unassigned 5197 9.4. Sub-TLV Types 5199 See Section 7.3. 5201 Type Name Section of this document 5202 ---- ------------------ ------------------------ 5203 0 - reserved 5204 1 VRF Name 7.3.1. 5205 2 Ingress-QoS-Profile 7.3.1. 5206 3 Egress-QoS-Profile 7.3.1. 5207 4 User-ACL-Policy 7.3.1. 5208 5 Multicast-ProfileV4 7.3.1. 5209 6 Multicast-ProfileV6 7.3.1. 5210 7 Ingress-CAR 7.3.2. 5211 8 Egress-CAR 7.3.3. 5212 9 NAT-Instance 7.3.1. 5213 10 Pool-Name 7.3.1. 5214 11 If-Desc 7.3.4. 5215 12 IPv6-Address List 7.3.5. 5216 13 Vendor 7.3.6. 5217 12-64534 - unassigned 5218 65535 - reserved 5220 9.5. Error Codes 5222 Value Name Remarks 5223 ------- ------- -------- 5224 0 Success Success 5226 1 Fail Malformed message received. 5227 2 TLV-Unknown One or more of the TLVs was not 5228 understood. 5229 3 TLV-Length The TLV length is abnormal. 5230 4-999 - unassigned Unassigned basic error codes. 5231 1000 - reserved 5232 1001 Version-Mismatch The version negotiation fails. Terminate. 5233 The subsequent service processes 5234 corresponding to the UP are suspended. 5235 1002 Keepalive Error The keepalive negotiation fails. 5236 1003 Timer Expires The establishment timer expired. 5237 1004-1999 - unassigned Unassigned error codes for version 5238 negotiation. 5239 2000 - reserved 5240 2001 Synch-NoReady The data to be smoothed is not ready. 5241 2002 Synch-Unsupport The request for smooth data is not 5242 supported. 5243 2003-2999 - unassigned Unassigned data synchronization error 5244 codes. 5246 3000 - reserved 5247 3001 Pool-Mismatch The corresponding address pool cannot be 5248 found. 5249 3002 Pool-Full The address pool is fully allocated and no 5250 address segment is available. 5251 3003 Subnet-Mismatch The address pool subnet cannot be found. 5252 3004 Subnet-Conflict Subnets in the address pool have been 5253 classified into other clients. 5254 3005-3999 - unassigned Unassigned error codes for address 5255 allocation. 5256 4000 - reserved 5257 4001 Update-Fail-No-Res The forwarding table fails to be 5258 delivered because the forwarding resources 5259 are insufficient. 5260 4002 QoS-Update-Success The QoS policy takes effect. 5261 4003 QoS-Update-Sq-Fail Failed to process the queue in the QoS 5262 policy. 5263 4004 QoS-Update-CAR-Fail Processing of the CAR in the QoS 5264 policy fails. 5265 4005 Statistic-Fail-No-Res Statistics processing failed due to 5266 insufficient statistics resources. 5267 4006-4999 - unassigned forwarding table delivery error codes. 5269 5000-4294967295 - reserved 5271 10. IANA Considerations 5273 This document requires no IANA actions. 5275 11. Security Considerations 5277 The Service, Control, and Management Interfaces between the CP and UP 5278 might be across the general Internet or other hostile environment. 5279 The ability of an adversary to block or corrupt messages or introduce 5280 spurious messages on any one or more of these interfaces would give 5281 the adversary the ability to stop subscribers from accessing network 5282 services, disrupt existing subscriber sessions, divert traffic, mess 5283 up accounting statistics, and generally cause havoc. Damage would not 5284 necessarily be limited to one or a few subscribers but could disrupt 5285 routing or deny service to one or more instances of the CP or 5286 otherwise cause extensive interference. If the adversary knows the 5287 details of the UP equipment and its forwarding rule capabilities, the 5288 adversary may be able to cause a copy of most or all user data to be 5289 sent to an address of the adversary's choosing, thus enabling 5290 eavesdropping. 5292 Thus, appropriate protections MUST be implemented to provide 5293 integrity, authenticity, and secrecy of traffic over those 5294 interfaces. Whether such protection is used is a network operator 5295 decision. See [RFC6241] for Management Interface / NETCONF security. 5296 Security on the Service Interface is dependent on the tunneling 5297 protocol used which is out of scope for this document. Security for 5298 the Control Interface, over which the S-CUSP protocol flows, is 5299 further discussed below. 5301 S-CUSP messages do not provide security. Thus, if these messages are 5302 exchanged in an environment where security is a concern, that 5303 security MUST be provided by another protocol such as TLS 1.3 5304 [RFC8446] or IPSEC. TLS 1.3 is the mandatory to implement protocol 5305 for interoperability. The use of a particular security protocol on 5306 the Control Interface is determined by configuration. Such security 5307 protocols need not always be used and lesser security precautions 5308 might be appropriate because, in some cases, the communication 5309 between the CP and UP is in a benign environment. 5311 Contributors 5313 Zhouyi Yu 5314 Huawei Technologies 5316 Email: yuzhouyi@huawei.com 5318 Chengguang Niu 5319 Huawei Technologies 5321 Email: chengguang.niu@huawei.com 5323 Zitao Wang 5324 Huawei Technologies 5326 Email: wangzitao@huawei.com 5328 Jun Song 5329 Huawei Technologies 5331 Email: song.jun@huawei.com 5333 Dan Meng 5334 H3C Technologies 5335 No.1 Lixing Center 5336 No.8 guangxun south street, Chaoyang District, 5337 Beijing, 100102 5338 China 5340 Email: mengdan@h3c.com 5342 Hanlei Liu 5343 H3C Technologies 5344 No.1 Lixing Center 5345 No.8 guangxun south street, Chaoyang District, 5346 Beijing, 100102 5347 China 5349 Email: hanlei_liu@h3c.com 5351 Normative References 5353 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 5354 20, DOI 10.17487/RFC0020, October 1969, . 5357 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 5358 DOI 10.17487/RFC0793, September 1981, . 5361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5362 Requirement Levels", BCP 14, RFC 2119, DOI 5363 10.17487/RFC2119, March 1997, . 5366 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 5367 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 5368 2661, DOI 10.17487/RFC2661, August 1999, . 5371 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 5372 "Remote Authentication Dial In User Service (RADIUS)", RFC 5373 2865, DOI 10.17487/RFC2865, June 2000, . 5376 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5377 and A. Bierman, Ed., "Network Configuration Protocol 5378 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5379 . 5381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 5382 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 5383 2017, . 5385 Informative References 5387 [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area 5388 networks / Bridges and Bridged Networks", IEEE Std 5389 802.1Q-2014, 3 November 2013. 5391 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 5392 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 5393 . 5395 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 5396 DOI 10.17487/RFC2131, March 1997, . 5399 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 5400 and R. Wheeler, "A Method for Transmitting PPP Over 5401 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 5402 1999, . 5404 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 5405 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 5406 . 5408 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 5409 Address Translator (Traditional NAT)", RFC 3022, DOI 5410 10.17487/RFC3022, January 2001, 5413 [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over 5414 Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 5415 3336, DOI 10.17487/RFC3336, December 2002, 5416 . 5418 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used 5419 to Form Encoding Rules in Various Routing Protocol 5420 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 5421 2009, . 5423 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 5424 IETF Protocol and Documentation Usage for IEEE 802 5425 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 5426 October 2013, . 5428 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 5429 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 5430 eXtensible Local Area Network (VXLAN): A Framework for 5431 Overlaying Virtualized Layer 2 Networks over Layer 3 5432 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 5433 . 5435 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5436 Code: The Implementation Status Section", BCP 205, RFC 5437 7942, DOI 10.17487/RFC7942, July 2016, . 5440 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5441 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5442 . 5444 [TR-384] Broadband Forum, "Cloud Central Office Reference 5445 Architectural Framework", BBF TR-384, 2018. 5447 Authors' Addresses 5449 Shujun Hu 5450 China Mobile 5451 32 Xuanwumen West Ave, Xicheng District 5452 Beijing, Beijing 100053 5453 China 5455 Email: hushujun@chinamobile.com 5457 Donald Eastlake, 3rd 5458 Futurewei Technologies 5459 1424 Pro Shop Court 5460 Davenport, FL 33896 5461 USA 5463 Phone: +1-508-333-2270 5464 Email: d3e3e3@gmail.com 5466 Mach (Guoyi) Chen 5467 Huawei Technologies 5468 Huawei Bldg., No. 156 Beiqing Road 5469 Beijing 100095 China 5471 Email: mach.chen@huawei.com 5473 Fengwei Qin 5474 China Mobile 5475 32 Xuanwumen West Ave, Xicheng District 5476 Beijing, Beijing 100053 5477 China 5479 Email: qinfengwei@chinamobile.com 5481 Zhenqiang Li 5482 China Mobile 5483 32 Xuanwumen West Ave, Xicheng District 5484 Beijing, Beijing 100053 5485 China 5487 Email: lizhenqiang@chinamobile.com 5488 Tee Mong Chua 5489 Singapore Telecommunications Limited 5490 31 Exeter Road, #05-04 Comcentre Podium Block 5491 Singapore City 239732 5492 Singapore 5494 Email: teemong@singtel.com 5496 Daniel Huang 5497 ZTE 5499 Email: huang.guangping@zte.com.cn 5501 Copyright, Disclaimer, and Additional IPR Provisions 5503 Copyright (c) 2019 IETF Trust and the persons identified as the 5504 document authors. All rights reserved. 5506 This document is subject to BCP 78 and the IETF Trust's Legal 5507 Provisions Relating to IETF Documents 5508 (http://trustee.ietf.org/license-info) in effect on the date of 5509 publication of this document. Please review these documents 5510 carefully, as they describe your rights and restrictions with respect 5511 to this document. Code Components extracted from this document must 5512 include Simplified BSD License text as described in Section 4.e of 5513 the Trust Legal Provisions and are provided without warranty as 5514 described in the Simplified BSD License.