idnits 2.17.1 draft-cuspdt-rtgwg-cu-separation-bng-protocol-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 3687 has weird spacing: '...RF-Name and/o...' -- The document date (July 3, 2019) is 1731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Hu 2 Intended status: Proposed Standard 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: January 2, 2020 July 3, 2019 16 Control-Plane and User-Plane Separation BNG 17 Simple Control Channel Protocol (S-CUSP) 18 draft-cuspdt-rtgwg-cu-separation-bng-protocol-06 20 Abstract 22 This document specifies the Simple Control Plane (CP) and User Plane 23 (UP) Separation Broadband Network Gateway (BNG) control channel 24 Protocol (S-CUSP) for communications between a CP and a UP. S-CUSP is 25 designed to be flexible and extensible so as to easily allow for the 26 addition of further messages and data items to meet future 27 requirements. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Distribution of this document is unlimited. Comments should be sent 35 to the authors or the RGTWG working group mailing list: 36 rtgwg@ietf.org. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 49 Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents 54 1. Introduction............................................6 56 2. Terminology.............................................7 57 2.1 Implementation Requirement Keywords..................7 58 2.2 Terms................................................7 60 3. BNG CUPS Overview......................................10 61 3.1 BNG CUPS Motivation.................................10 62 3.2 BNG CUPS Architecture Overview......................10 63 3.3 BNG CUPS Interfaces.................................12 64 3.3.1 Service Interface.................................13 65 3.3.2 Control Interface.................................14 66 3.3.3 Management Interface..............................14 67 3.4 BNG CUPS Procedure Overview.........................14 69 4. S-CUSP Protocol Overview...............................18 70 4.1 Control Channel Related Procedures..................18 71 4.1.1 S-CUSP Session Establishment......................18 72 4.1.2 Keep Alive........................................19 73 4.2 Node Related Procedures.............................20 74 4.2.1 UP Resource Report................................20 75 4.2.2 Update BAS Function on Access Interface...........21 76 4.2.3 Update Network Routing............................21 77 4.2.4 CGN Public IP Address Allocation..................22 78 4.2.5 Data Synchronization between the CP and UP........23 79 4.3 Subscriber Session Related Procedures...............24 80 4.3.1 Create Subscriber Session.........................25 81 4.3.2 Update Subscriber Session.........................26 82 4.3.3 Delete Subscriber Session.........................27 83 4.3.4 Subscriber Session Events Report..................27 85 5. S-CUSP Call Flows......................................29 86 5.1 IPoE................................................29 87 5.1.1 DHCPv4 Access.....................................29 88 5.1.2 DHCPv6 Access.....................................30 89 5.1.3 IPv6 SLAAC Access.................................32 90 5.1.4 DHCPv6 + SLAAC Access.............................33 91 5.1.5 DHCP Dual Stack Access............................35 92 5.1.6 L2 Static Subscriber Access.......................37 93 5.2 PPPoE...............................................40 94 5.2.1 IPv4 PPPoE Access.................................40 95 5.2.2 IPv6 PPPoE Access.................................41 96 5.2.3 PPPoE Dual Stack Access...........................43 97 5.3 WLAN Access.........................................45 98 5.4 L2TP................................................47 99 5.4.1 L2TP LAC Access...................................47 100 5.4.2 L2TP LNS IPv4 Access..............................49 101 5.4.3 L2TP LNS IPv6 Access..............................51 102 5.5 CGN (Carrier Grade NAT).............................54 104 Table of Contents (continued) 106 5.6 L3 Leased Line Access...............................55 107 5.6.1 Web Authentication................................55 108 5.6.2 User Traffic Trigger..............................57 109 5.7 Multicast Access....................................58 111 6. S-CUSP Message Formats.................................60 112 6.1 Common Message Header...............................60 113 6.2 Control Messages....................................61 114 6.2.1 Hello Message.....................................61 115 6.2.2 Keepalive Message.................................62 116 6.2.3 Sync_Request Message..............................62 117 6.2.4 Sync_Begin Message................................62 118 6.2.5 Sync_Data Message.................................63 119 6.2.6 Sync_End Message..................................63 120 6.2.7 Update_Request Message............................64 121 6.2.8 Update_Response Message...........................64 122 6.3 Event Message.......................................65 123 6.4 Report Message......................................66 124 6.5 CGN Messages........................................66 125 6.5.1 Addr_Allocation_Req Message.......................66 126 6.5.2 Addr_Allocation_Ack Message.......................66 127 6.5.3 Addr_Renew_Req Message............................67 128 6.5.4 Addr_Renew_Ack Message............................67 129 6.5.5 Addr_Release_Req Message..........................67 130 6.5.6 Addr_Release_Ack Message..........................67 131 6.6 Vendor Message......................................67 132 6.7 Error Message.......................................68 134 7. S-CUSP TLVs and Sub-TLVs...............................69 135 7.1 Common TLV Header...................................69 136 7.2 Basic Data Fields...................................70 137 7.3 Sub-TLV Format and Sub-TLVs.........................71 138 7.3.1 Name sub-TLVs.....................................71 139 7.3.2 Ingress-CAR sub-TLV...............................72 140 7.3.3 Egress-CAR sub-TLV................................72 141 7.3.4 If-Desc sub-TLV...................................73 142 7.3.5 IPv6 Address List sub-TLV.........................75 143 7.3.6 Vendor sub-TLV....................................75 144 7.4 The Hello TLV.......................................77 145 7.5 The Keep Alive TLV..................................78 146 7.6 The Error Information TLV...........................79 147 7.7 BAS Function TLV....................................79 148 7.8 Routing TLVs........................................82 149 7.8.1 IPv4 Routing TLV..................................82 150 7.8.2 IPv6 Routing TLV..................................84 151 7.9 Subscriber TLVs.....................................85 152 7.9.1 Basic Subscriber TLV..............................86 153 7.9.2 PPP Subscriber TLV................................88 154 7.9.3 IPv4 Subscriber TLV...............................89 156 Table of Contents (continued) 158 7.9.4 IPv6 Subscriber TLV...............................90 159 7.9.5 IPv4 Static Subscriber Detect TLV.................91 160 7.9.6 IPv6 Static Subscriber Detect TLV.................93 161 7.9.7 L2TP-LAC Subscriber TLV...........................94 162 7.9.8 L2TP-LNS Subscriber TLV...........................95 163 7.9.9 L2TP-LAC Tunnel TLV...............................95 164 7.9.10 L2TP-LNS Tunnel TLV..............................96 165 7.9.11 Update Response TLV..............................97 166 7.9.12 Subscriber Policy TLV............................98 167 7.9.13 Subscriber CGN Port Range TLV...................100 168 7.10 Device Status TLVs................................100 169 7.10.1 Interface Status TLV............................101 170 7.10.2 Board Status TLV................................101 171 7.11 CGN TLVs..........................................102 172 7.11.1 Address Allocation Request TLV..................102 173 7.11.2 Address Allocation Response TLV.................103 174 7.11.3 Address Renewal Request TLV.....................104 175 7.11.4 The Address Renewal Response TLV................105 176 7.11.5 Address Release Request TLV.....................106 177 7.11.6 The Address Release Response TLV................106 178 7.12 Event TLVs........................................107 179 7.12.1. Subscriber Traffic Statistics TLV..............108 180 7.12.2 Subscriber Detection Result TLV.................109 181 7.13 Vendor TLV........................................110 183 8. Implementation Status.................................112 184 8.1 Implementations....................................112 185 8.1.1 Huawei Technologies..............................112 186 8.1.2 ZTE..............................................113 187 8.1.3 H3C..............................................113 188 8.2 Hackathon..........................................113 189 8.3 EANTC Testing......................................114 191 9. IANA Considerations...................................115 192 9.1 Message Types......................................115 193 9.2 TLV Types..........................................115 194 9.3 TLV Operation Codes................................117 195 9.4 Sub-TLV Types......................................118 196 9.5 Error Codes........................................118 198 10. Security Considerations..............................120 200 Contributors.............................................121 202 Normative References.....................................122 203 Informative References...................................123 205 Authors' Addresses.......................................125 207 1. Introduction 209 A fixed network Broadband Network Gateway (BNG) is an Ethernet- 210 centric IP edge router, and the aggregation point for user traffic. 211 To provide centralized session management, flexible address 212 allocation, high scalability for subscriber management capacity, and 213 cost-efficient redundancy, the Control/User (CU) separated BNG 214 framework is described in [TR-384]. The CU separated service Control 215 Plane (CP), which is responsible for user access authentication and 216 setting forwarding entries in User Planes (UPs), can be virtualized 217 and centralized. The routing control and forwarding plane, i.e. the 218 BNG user plane (local), can be distributed across the infrastructure. 219 Other structures can also be supported such as both CP and UP being 220 virtual or both being physical. 222 This document specifies the Simple CU Separation BNG control channel 223 Protocol (S-CUSP) for communications between a BNG Control Plane (CP) 224 and a set of User Planes (UPs). S-CUSP is designed to be flexible 225 and extensible so as to easily allow for additional messages and data 226 items, should further requirements be expressed in the future. 228 2. Terminology 230 This section specifies implementation requirement keywords and terms 231 used in this document. S-CUSP messages are described in this document 232 using Routing Backus-Naur Form (RBNF) as defined in [RFC5511]. 234 2.1 Implementation Requirement Keywords 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described in BCP 239 14 [RFC2119] [RFC8174] when, and only when, they appear in all 240 capitals, as shown here. 242 2.2 Terms 244 This section specifies terms used in this document. 246 AAA: Authentication Authorization Accounting. 248 ACK: Acknowledgement message. 250 BAS: Broadband Access Server (BRAS, BNG). 252 BNG: Broadband Network Gateway. A broadband remote access server 253 (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic 254 to and from broadband remote access devices such as digital 255 subscriber line access multiplexers (DSLAM) on an Internet 256 Service Provider's (ISP) network. BRAS can also be referred to 257 as a Broadband Network Gateway (BNG). 259 BRAS: BRoadband Access Server (BNG). 261 CAR: Committed Access Rate. 263 CBS: Committed Burst Size. 265 CGN: Carrier Grade NAT. 267 Ci: Control Interface. 269 CIR: Committed Information Rate. 271 CoA: Change of Authorization. 273 CP: Control Plane. 275 CP is a user control management component which supports the 276 management of the UP's resources such as the user entry and 277 forwarding policy. 279 CPE: Customer Premises Equipment. 281 CU: Control-plane / User-plane. 283 CUSP: Control and User plane Separation Protocol. 285 DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the 286 priority and before the VLAN ID. (This bit was formerly the CFI 287 (Canonical Format Indicator).) [802.1Q] 289 DHCP: Dynamic Host Configuration Protocol [RFC2131]. 291 dial-up: This refers to the initial connection messages when a new 292 user appears. The name is left over from when users literally 293 dialed up on a modem equipped phone line but herein is applied to 294 other initial connection techniques. Initial connection is 295 frequently indicated by the receipt of packets over PPPoE 296 [RFC2516] or IPoE. 298 EMS: Element Management System. 300 IPoE: IP over Ethernet. 302 L2TP: Layer 2 Tunneling Protocol [RFC2661]. 304 LAC: L2TP Access Concentrator. 306 LNS: L2TP Network Server. 308 MAC: 48-bit Media Access Control address [RFC7042]. 310 MANO: Management and Orchestration. 312 Mi: Management Interface. 314 MSS: Maximum Segment Size. 316 MRU: Maximum Receive Unit. 318 NAT: Network Address Translation [RFC3022]. 320 ND: Neighbor Discovery. 322 NFV: Network Function Virtualization. 324 NFVI: NFV Infrastructure 326 PBS: Peak Burst Size. 328 PD: Prefix Delegation. 330 PIR: Peak Information Rate. 332 PPP: Point to Point Protocol [RFC1661]. 334 PPPoE: PPP over Ethernet [RFC2516]. 336 RBNF: Routing Backus-Naur Form [RFC5511]. 338 RG: Residential Gateway. 340 S-CUSP: Simple Control and User Plane Separation Protocol. 342 Si: Service Interface. 344 TLV: Type, Length, Value. See Sections 7.1 and 7.3. 346 UP: User Plane. UP is a network edge and user policy implementation 347 component. The traditional router's Control Plane and Forwarding 348 Plane are both preserved on BNG devices in the form of a user 349 plane. 351 URPF: Unicast Reverse Path Forwarding. 353 User: Equivalent to "customer" or "subscriber". 355 VRF: Virtual Routing and Forwarding. 357 3. BNG CUPS Overview 359 3.1 BNG CUPS Motivation 361 The rapid development of new services, such as 4K TV, IoT, etc., and 362 increasing numbers of home broadband service users present some new 363 challenges for BNGs such as: 365 Low resource utilization: The traditional BNG acts as both a gateway 366 for user access authentication and accounting and an IP network's 367 Layer 3 edge. The mutually affecting nature of the tightly 368 coupled control plane and forwarding plane makes it difficult to 369 achieve the maximum performance of either plane. 371 Complex management and maintenance: Due to the large numbers of 372 traditional BNGs, configuring each device in a network is very 373 tedious when deploying global service policies. As the network 374 expands and new services are introduced, this deployment mode 375 will cease to be feasible as it is unable to manage services 376 effectively and rectify faults rapidly. 378 Slow service provisioning: The coupling of control plane and 379 forwarding plane, in addition to a distributed network control 380 mechanism, means that any new technology has to rely heavily on 381 the existing network devices. 383 To address these challenges for fixed networks, the framework for a 384 cloud-based BNG with Control Plane and User Plane (CU) separation is 385 described in [TR-384]. The main idea of CU separation is to extract 386 and centralize the user management functions of multiple BNG devices, 387 forming a unified and centralized Control Plane (CP). And the 388 traditional router's Control Plane and Forwarding Plane are both 389 preserved on BNG devices in the form of a User Plane (UP). 391 3.2 BNG CUPS Architecture Overview 393 The functions in a traditional BNG can be divided into two parts: one 394 is the user access management function, the other is the router 395 function. The user management function can be centralized and 396 deployed as a concentrated module or device, called the BNG Control 397 Plane (BNG-CP). The other functions, such as the router function and 398 forwarding engine, can be deployed in the form of the BNG User Plane 399 (BNG-UP). 401 The following figure shows the architecture of CU separated BNG: 403 +------------------------------------------------------------------+ 404 | Neighboring policy and resource management systems | 405 | | 406 | +-------------+ +-----------+ +---------+ +----------+ | 407 | |AAA Server| |DHCP Server| | EMS | | MANO | | 408 | +-------------+ +-----------+ +---------+ +----------+ | 409 +------------------------------------------------------------------+ 411 +------------------------------------------------------------------+ 412 | CU-separated BNG system | 413 | +--------------------------------------------------------------+ | 414 | | +----------+ +----------+ +------++------++-----------+ | | 415 | | | Address | |Subscriber| | AAA ||Access|| UP | | | 416 | | |management| |management| | || Mgt ||management | | | 417 | | +----------+ +----------+ +------++------++-----------+ | | 418 | | CP | | 419 | +--------------------------------------------------------------+ | 420 | | 421 | | 422 | | 423 | +---------------------------+ +--------------------------+ | 424 | | +------------------+ | | +------------------+ | | 425 | | | Routing control | | | | Routing control | | | 426 | | +------------------+ | ... | +------------------+ | | 427 | | +------------------+ | | +------------------+ | | 428 | | |Forwarding engine | | | |Forwarding engine | | | 429 | | +------------------+ UP | | +------------------+ UP| | 430 | +---------------------------+ +--------------------------+ | 431 +------------------------------------------------------------------+ 433 Figure 1: Architecture of CU Separated BNG 435 As shown in Figure 1, the BNG Control Plane could be virtualized and 436 centralized, which provides benefits such as centralized session 437 management, flexible address allocation, high scalability for 438 subscriber management capacity, and cost-efficient redundancy, etc. 439 The functional components inside the BNG Service Control Plane can be 440 implemented as Virtual Network Functions (VNFs) and hosted in a 441 Network Function Virtualization Infrastructure (NFVI). 443 The User Plane Management module in the BNG Control Plane centrally 444 manages the distributed BNG User Planes (e.g. load balancing), as 445 well as the setup, deletion, and maintenance of channels between 446 Control Planes and User Planes. Other modules in the BNG control 447 plane, such as address management, AAA, etc., are responsible for the 448 connection with outside subsystems in order to fulfill those 449 services. Note that the User Plane SHOULD support both physical and 450 virtual network functions. For example, BNG user plane L3 forwarding 451 related network functions can be disaggregated and distributed across 452 the physical infrastructure. And the other control plane and 453 management plane functions in the CU Separation BNG can be moved into 454 the NFVI for virtualization [TR-384]. 456 The details of CU separated BNG's function components are as 457 following: 459 The Control Plane is responsible for the following: 461 1. Address management: unified address pool management and CGN 462 subscriber address traceability management. 464 2. AAA: This component performs Authentication, Authorization and 465 Accounting, together with RADIUS/DIAMETER. The BNG communicates 466 with the AAA server to check whether the subscriber who sent an 467 Access-Request has network access authority. Once the subscriber 468 goes online, this component together with the Service Control 469 component implement accounting, data capacity limitation, and QoS 470 enforcement policies. 472 3. Subscriber management: user entry management and forwarding 473 policy management. 475 4. Access management: process user dial-up packets, such as PPPoE, 476 DHCP, L2TP, etc. 478 5. UP management: management of UP interface status, and the setup, 479 deletion, and maintenance of channels between CP and UP. 481 The User Plane is responsible for the following: 483 1. Routing control functions: responsible for constructing routing 484 forwarding plane (e.g., routing, multicast, MPLS, etc.). 486 2. Routing and Service Forwarding plane functions: responsible 487 including traffic forwarding, QoS and traffic statistics 488 collection. 490 Subscriber detection: responsible for detecting whether a subscriber 491 is still online. 493 3.3 BNG CUPS Interfaces 495 To support the communication between the Control Plane and User 496 Plane, three interfaces are assumed. These are referred to as the 497 Service Interface (Si), Control Interface (Ci), and Management 498 Interface (Mi) as shown in Figure 2. 500 +-----------------------------------+ 501 | | 502 | BNG-CP | 503 | | 504 +--+--------------+--------------+--+ 505 | | | 506 1. Service | 2. Control | 3. Management| 507 Interface | Interface | Interface | 508 (Si) | (Ci) | (Mi) | 509 | | | 510 | ___|___ | 511 | ___( )___ | 512 _|______( )______|_ 513 ( ) 514 ( Network/Internet ) 515 (________ ________) 516 | (___ ___) | 517 | (_______) | 518 | | | 519 | | | 520 +--+--------------+--------------+--+ 521 | | 522 | BNG-UP | 523 | | 524 +-----------------------------------+ 526 Figure 2: Interfaces Between the CP and UP of the BNG 528 3.3.1 Service Interface 530 For a traditional BNG (without CU separation), the user dial-up 531 signals are terminated and processed by the control plane of a BNG. 532 When the CP and UP of a BNG are separated, there needs to be a way to 533 relay these signals between the CP and the UP. 535 The Service Interface (Si) is used to establish tunnels between the 536 CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, 537 and L2TP related control packets that are received from a Residential 538 Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN 539 [RFC7348]. 541 The detailed definition of Si is out of scope for this document. 543 3.3.2 Control Interface 545 The CP uses the Control Interface to deliver subscriber session 546 states, network routing entries, etc. to the UP (see Section 6.2.7)). 547 The UP uses this interface to report subscriber service statistics, 548 subscriber detection results, etc. to the CP (see Sections 6.3 and 549 6.4). A carrying protocol for this interface is specified in this 550 document. 552 3.3.3 Management Interface 554 NETCONF [RFC6241] is the protocol used on the Management Interface 555 between a CP and UP. It is used to configure the parameters of the 556 Control Interface, Service Interface, the Access interfaces and 557 QoS/ACL Templates. It is expected that implementations will make use 558 of existing YANG models where possible, but that new YANG models 559 specific to S-CUSP will need to be defined. The definitions of the 560 parameters are out of scope for this document. 562 3.4 BNG CUPS Procedure Overview 564 The following numbered sequences (Figure 3) gives a high level view 565 of the main BNG CUPS procedures. 567 RG UP CP AAA 568 | | | | 569 | |Establish S-CUSP Channel| | 570 | 1|<---------------------->| | 571 | | | | 572 | | Report Board | | 573 | | interface | | 574 | | information | | 575 | 2|------to CP via Ci----->| | 576 | | | | 577 | | Update BAS function | | 578 | 3| request / response | | 579 | |<-----on UP via Ci----->| | 580 | | | | 581 | | Update network routing | | 582 | | request / response | | 583 | 4|<------- via Ci-------->| | 584 | | | | 585 | Online Req | | | 586 5.1|-------------->| | | 587 | | Relay the Online Req | | 588 | 5.2|-----to CP via Si------>| Authentication| 589 | | | Req/Rep | 590 | | 5.3|<------------->| 591 | | Send the Online Rep | | 592 | 5.4|<----to UP via Si-------| | 593 | Online Rep | | | 594 5.5|<--------------| | | 595 | | Create subscriber | | 596 | | session on UP | | 597 | 5.6|<--------via Ci-------->| | 598 | | | CoA Request | 599 | | 6.1|<--------------| 600 | | Update session on UP | | 601 | 6.2|<--------via Ci-------->| | 602 | | | CoA Response | 603 | | 6.3|-------------->| 604 | | | | 605 | Offline Req | | | 606 7.1|-------------->| | | 607 | | Relay the Offline Req | | 608 | 7.2|------to CP via Si----->| | 609 | | | | 610 | | Send the Offline Rep | | 611 | 7.3|<-----to UP via Si------| | 612 | Offline Rep | | | 613 7.4|<--------------| | | 614 | | Delete session on UP | | 615 | 7.5|<--------via Ci-------->| | 616 | | | | 617 | | Event report | | 618 | 8|---------via Ci-------->| | 619 | | | | 620 | | Data Synchronization | | 621 | 9|<--------via Ci-------->| | 622 | | | | 623 | | CGN Address Allocation | | 624 | 10|<--------via Ci-------->| | 625 | | | | 627 Figure 3: BNG CUPS Procedures Overview 629 1. S-CUSP session establishment: This is the first step of BNG CUPS 630 procedures. Once the Control Interface parameters are configured 631 on a UP. It will start to setup S-CUSP sessions with the 632 specified CPs. The detailed definition of S-CUSP session 633 establishment can be found in Section 4.1.1. 635 2. Board and interface report: Once the S-CUSP session is 636 established between the UP and a CP, the UP will report status 637 information on the boards and subscriber side interfaces of this 638 UP to the CP. A board can also be called a Line/Service Process 639 Unit (LPU/SPU) card. The subscriber side interfaces refer to the 640 interfaces that connect the Acess Network nodes (e.g., OLT: 641 Optical Line Terminal, DSLAM: Digital Subscriber Line Access 642 Multiplexer, etc.). The CP can use this information to enable the 643 Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, etc.) 644 on the specified interfaces. See Sections 4.2.1 and 7.10 for more 645 details on Resource reporting. 647 3. BAS (Broadband Access Service) function enable: To enable the BAS 648 function on the specified interfaces of a UP. 650 4. Subscriber network route advertisement: The CP will allocate one 651 or more IP address blocks to a UP. Each address block contains a 652 series of IP addresses. Those IP addresses will be allocated to 653 subscribers who are dialing up from the UP. To enable other nodes 654 in the network to learn how to reach the subscribers, the CP 655 needs to notify the UP to advertise to the network the routes 656 that can reach those IP addresses. 658 5. 5.1-5.6 is a complete call flow of a subscriber dial-up process. 659 When a UP receives a dial-up request, it will relay the request 660 packet to a CP through the Service Interface. The CP will parse 661 the request. If everything is OK, it will send an authentication 662 request to the AAA server to authenticate the subscriber. Once 663 the subscriber passes the authentication, the AAA server will 664 return a positive response to the CP. Then the CP will send the 665 dial-up response packet to the UP and the UP will forward the 666 response packet to the subscriber (RG). At the same time, the CP 667 will create a subscriber session on the UP, which enables the 668 subscriber to access the network. For different access types, 669 the process may be a bit different. But the high-level process is 670 similar. For each access type, the detail process can be found in 671 Section 5. 673 6. 6.1-6.3 is the sequence when updating an existing subscriber 674 session. The AAA server initiates a Change of Authorization (CoA) 675 and sends the CoA to the CP. The CP will then update the session 676 according to the CoA. See Section 4.3.2 for more detail on CP 677 messages updating UP tables. 679 7. 7.1-7.5 is the sequence for deleting an existing subscriber 680 session. When a UP receives an offline request, it will relay the 681 request to a CP through the Service Interface. The CP will send 682 back a response to the UP through the Service Interface. The UP 683 will then forward the offline response to the subscriber. Then 684 the CP will delete the session on the UP through the Control 685 Interface. 687 8. Event reports include the following two parts (more detail can be 688 found in Section 4.3.4) Both are reported using the Event 689 message. 691 8.1 Subscriber Traffic Statistics Report 692 8.2 Subscriber Detection Result Report 694 9. Data synchronization: See Sections 4.2.5 for more detail on CP 695 and UP Synchronization. 697 10. CGN address allocation: See Sections 4.2.4 for more detail on CGN 698 Address Allocation. 700 4. S-CUSP Protocol Overview 702 4.1 Control Channel Related Procedures 704 4.1.1 S-CUSP Session Establishment 706 A UP is associated with a CP and is controlled by that CP. In the 707 case of a hot-standby or cold-standby, a UP is associated with two 708 CPs, one called the Master CP and the other called the Standby CP. 709 The association between a UP and its CPs is implemented by dynamic 710 configuration. 712 Once a UP knows its CPs, the UP starts to establish S-CUSP sessions 713 with those CPs as shown in Figure 4. 715 UP CP 716 | | 717 | TCP Session Establishment | 718 |<------------------------------->| 719 | | 720 | HELLO (version, capability) | 721 |-------------------------------->| 722 | | 723 | HELLO (version, capability) | 724 |<--------------------------------| 725 | | 727 Figure 4: S-CUSP Session Establishment 729 The S-CUSP session establishment consists of two successive steps: 731 1. Establishment of a TCP [RFC793] connection (3-way handshake) 732 between the CP and the UP using a configured port from the 733 dynamic port range (49152-65535). 735 2. Establishment of a S-CUSP session over the TCP connection. 737 Once the TCP connection is established, the CP and the UP initialize 738 the S-CUSP session during which the version and Keepalive timers are 739 negotiated. 741 The version information (Hello TLV, see Section 7.4) is carried 742 within Hello messages (see Section 6.2.1). A CP can support multiple 743 versions, but a UP can only support one version. So, the version 744 negotiation is based on whether a version can be support by both the 745 CP and the UP. For a CP or UP, if a Hello message is received that 746 does not indicate a version supported by both, a subsequent Hello 747 message with an Error Information TLV will be sent to the peer to 748 notify the peer of the "Version-Mismatch" error and the session 749 establishment phase fails. 751 Keepalive negotiation is performed by carrying a Keepalive TLV in the 752 Hello message. The Keepalive TLV includes a Keepalive timer and Dead 753 Timer field. The CP and UP have to agree on the Keepalive Timer and 754 Dead Timer. Otherwise, a subsequent Hello message with an Error 755 Information TLV will be sent to its peer and the session 756 establishment phase fails. 758 The S-CUSP session establishment phase fails if the CP or UP disagree 759 on the version and keepalive parameters or if one of the CP or UP 760 does not answer after the expiration of the Establishment timer. 761 When the S-CUSP session establishment fails, the TCP connection is 762 promptly closed. Successive retries are permitted but an 763 implementation SHOULD make use of an exponential back-off session 764 establishment retry procedure. 766 The S-CUSP session timer values that need to be configured are 767 summarized in the table below. 769 Timer Range in Default 770 Name seconds Value 771 ------------- ------- ------- 772 Establishment 1-32767 45 773 Keepalive 0-255 30 774 DeadTimer 1-32767 4 * Keepalive 776 4.1.2 Keep Alive 778 Once an S-CUSP session has been established, a UP or CP may want to 779 know that its S-CUSP peer is still available for use. 781 Each end of a S-CUSP session runs a Keepalive timer. It restarts the 782 timer every time it sends a message on the session. When the timer 783 expires, it sends a Keepalive message. 785 The ends of the S-CUSP session also run DeadTimers, and they restart 786 the timers whenever a message is received on the session. If one end 787 of the session receives no message after the DeadTimer expires, it 788 declares the session dead. The session will be closed. 790 The minimum value of the Keepalive timer is 1 second, and it is 791 specified in units of 1 second. The RECOMMENDED default value is 30 792 seconds. The timer may be disabled by setting it to zero. 794 The recommended default for the DeadTimer is 4 times the value of the 795 Keepalive timer used by the remote peer. This implies there is 796 essentially no risk of TCP congestion due to excessive Keepalive 797 messages. 799 The Keepalive timer and DeadTimer are initially negotiated through 800 the Keepalive TLV carried in the Hello Message. 802 4.2 Node Related Procedures 804 4.2.1 UP Resource Report 806 Once an S-CUSP session has been established between a CP and an UP. 807 The UP reports the information of the Boards and access side 808 interfaces on this UP to the CP as shown in Figure 5. Report messages 809 are unacknowledged and are assumed to be delivered because the 810 session runs over TCP. 812 The CP can use that information to activate/enable the Broadband 813 Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the 814 specified interfaces. 816 In addition, the UP resource report may trigger a UP warm-standby 817 process. In the case of warm-standby, a failure on an UP may trigger 818 the CP to start a warm-standby process, by moving the on-line 819 subscriber sessions to a standby UP and then direct the affected 820 subscribers to access the Internet through the standby UP. 822 UP CP 823 | | 824 | Report Board Status | 825 |------to CP via Ci----->| 826 | | 827 | Report Interface Status| 828 |------to CP via Ci----->| 829 | | 831 Figure 5: UP Board and Interface Report 833 Board status information is carried in the Board Status TLV (Section 834 7.10.2) and Interface status information is carried in Interface 835 Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are 836 carried in the Report Message (Section 6.4). 838 4.2.2 Update BAS Function on Access Interface 840 Once the CP collects the interface status of a UP, it will 841 activate/de-activate/modify the BAS functions on specified interfaces 842 through the Update_Request and Update_Response message (Section 6.2) 843 exchanges carrying the BAS Function TLV (Section 7.7). 845 UP CP 846 | | 847 | Update BAS function | 848 | Request | 849 |<-----on UP via Ci-------| 850 | | 851 | Update BAS function | 852 | Response | 853 |------on UP via Ci------>| 854 | | 856 Figure 6: Update BAS Function 858 4.2.3 Update Network Routing 860 The CP will allocate one or more address blocks to a UP. Each address 861 block contains a series of IP addresses. Those IP addresses will be 862 allocated to subscribers who are dialing up to the UP. To enable the 863 other nodes in the network to learn how to reach the subscribers, the 864 CP needs to install the routes on the UP and notify the UP to 865 advertise the routes to the network. 867 UP CP 868 | | 869 | Subscriber network route| 870 | update request | 871 |<------- via Ci----------| 872 | | 873 | Subscriber network route| 874 | update response | 875 |-------- via Ci--------->| 876 | | 878 Figure 7: Update Network Routing 880 The subscriber network routing update request and response are 881 achieved through the Update Request and Response Message exchanges by 882 carrying the IPv4/IPv6 Routing Information TLVs (Section 7.8). 884 4.2.4 CGN Public IP Address Allocation 886 The following sequences describe the CGN address management related 887 procedures. Three independent procedures are defined, one each for 888 CGN address allocation request/response, CGN address renewal 889 request/response, and CGN address release request/response. 891 CGN address allocation/renew/release procedures are designed for the 892 case where the CGN function is running on the UP. The UP has to map 893 the subscriber private IP addresses to a public IP addresses, and 894 such mapping is performed by the UP locally when a subscriber dials- 895 up. That means the UP has to ask for public IPv4 address blocks for 896 CGN subscribers from the CP. 898 In addition, when a public IP address is allocated to a UP, there 899 will be a lease time (e.g., one day). Before the lease time expires, 900 the UP can ask for renewal of the IP address lease from the CP. It is 901 achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack 902 messages. 904 If the public IP address will not be used anymore, the UP SHOULD 905 release the address by sending an Addr_Release_Req message to the CP. 907 If the CP wishes to withdraw addresses that it has previously leased 908 to a UP, it uses the same procedures as above. The "Oper" code in 909 the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the 910 request is an update or withdraw. 912 The relevant messages are defined in Section 6.5. 914 UP CP 915 | | 916 | CGN Address Allocation | 917 | Request | 918 1.1|-------- via Ci--------->| 919 | CGN Address Allocation | 920 | Response | 921 1.2|<------- via Ci----------| 922 | | 923 | CGN Address Renew | 924 | Request | 925 2.1|-------- via Ci--------->| 926 | CGN Address Renew | 927 | Response | 928 2.2|<------- via Ci----------| 929 | | 930 | CGN Address Release | 931 | Request | 932 3.1|-------- via Ci--------->| 933 | CGN Address Release | 934 | Response | 935 3.3|<------- via Ci----------| 936 | | 938 Figure 8: CGN Public IP Address Allocation 940 4.2.5 Data Synchronization between the CP and UP 942 For a CU separated BNG, the UP will continue to function using the 943 state that has been installed in it even if the CP fails or the 944 session between the UP and CP fails. 946 Under some circumstances it is necessary to synchronize state between 947 the CP and UP, for example if a CP fails and the UP is switched to a 948 different CP. 950 Synchronization includes two directions. One direction is from UP to 951 CP; in that case, the synchronization information is mainly about the 952 board/interface status of the UP. The other direction is from CP to 953 UP; in that case, the subscriber sessions, subscriber network routes, 954 L2TP tunnels, etc. will be synchronized to the UP. 956 The synchronization is triggered by a Sync_Request message, to which 957 the receiver will (1) reply with a Sync_Begin message to notify the 958 requester that synchronization will begin, and (2) then start the 959 synchronization using the Sync_Data message. When synchronization 960 finished, a Sync_End message will be sent. 962 The following figure shows the process of data synchronization 963 between a UP and a CP. 965 UP CP 966 | | 967 | Synchronization Request | 968 |<------- via Ci----------| 969 | | 970 | Synchronization Begin | 971 |-------- via Ci--------->| 972 | | 973 | Board/Interface Report | 974 |-------- via Ci--------->| 975 | | 976 | Synchronization End | 977 |-------- via Ci--------->| 978 | | 979 1) Synchronization from UP to CP 981 UP CP 982 | | 983 | Synchronization Request | 984 |-------- via Ci--------->| 985 | | 986 | Synchronization Begin | 987 |<-------- via Ci---------| 988 | | 989 | Synchronizes | 990 |Subscriber Session States| 991 | Network Route Entries | 992 |<------- via Ci----------| 993 | | 994 | Synchronization End | 995 |<-------- via Ci---------| 996 | | 997 2) Synchronization from CP to UP 999 Figure 9: Data Synchronization 1001 4.3 Subscriber Session Related Procedures 1003 A subscriber session consists of a set of forwarding states, 1004 policies, and security rules that are applied to the subscriber. It 1005 is used for forwarding subscriber traffic in a UP. To initialize a 1006 session on a UP, a set of hardware resource have to be allocated 1007 (e.g., NP, TCAM etc.) to a session. 1009 Subscriber session related procedures include subscriber session 1010 create, update, delete, and statistics report. The following sub- 1011 sections give a high level view of the procedures. 1013 4.3.1 Create Subscriber Session 1015 The below sequence describes the DHCP IPv4 dial-up process, it is an 1016 example that shows how a subscriber session is created. (An example 1017 for IPv6 appears in Section 5.1.2.) 1019 RG UP CP AAA 1020 | | | | 1021 | Online Request| | | 1022 1|-------------->| | | 1023 | |Relay the Online Request| | 1024 | 2|-----to CP via Si------>| Authentication| 1025 | | | Req/Rep | 1026 | | 3|<------------->| 1027 | | Create subscriber | | 1028 | | session Request | | 1029 | 4|<--------via Ci---------| | 1030 | | | | 1031 | | Create subscriber | | 1032 | | session Response | | 1033 | 5|---------via Ci-------->| | 1034 | | | | 1035 | | | Accounting | 1036 | | 6|<------------->| 1037 | | | | 1038 | | Send Online Response | | 1039 | 7|<----to UP via Si-------| | 1040 | | | | 1041 |Online Response| | | 1042 12|<--------------| | | 1043 | | | | 1045 Figure 10: Subscriber Session Create 1047 The request starts from an Online Request message (step 1) from the 1048 RG (for example, a DHCP Discovery packet). When the UP receives the 1049 Online Request from the RG, it will tunnel the Online Request to the 1050 CP through the Service Interface (Step 2). The Service Interface is 1051 implemented by a tunneling technology. 1053 When the CP receives the Online Request from the UP, it will send an 1054 authentication request to the AAA server to authenticate and 1055 authorize the subscriber (step 3). When a positive reply is received 1056 from the AAA sever, the CP starts to create a subscriber session for 1057 the request. Relevant resources (e.g., IP address, bandwidth, etc.) 1058 will be allocated to the subscriber, policies and security rules will 1059 be generated for the subscriber Then the CP sends a session create 1060 request to the UP through the Control Interface (Ci) (step 4), and a 1061 response is expected from the UP to confirm the creation (step 5). 1063 Finally, the CP will notify the AAA server to start accounting (step 1064 6). At the same time, an Online Response message (for example, a 1065 DHCP Ack packet) will be sent to the UP through the Si (step 7). And 1066 the UP will forward the Online Response to the RG (step 8). 1068 This completes the subscriber online process. 1070 4.3.2 Update Subscriber Session 1072 The following numbered sequence shows the process of subscriber 1073 session update. 1075 UP CP AAA 1076 | | COA Request | 1077 | 1|<--------------| 1078 | Session update Request | | 1079 2|<--------via Ci---------| | 1080 | | | 1081 | Session update Response| | 1082 3|---------via Ci-------->| | 1083 | | COA Response | 1084 | 4|-------------->| 1085 | | | 1087 Figure 11: Subscriber Session Update 1089 When a subscriber session has been created on a UP, there may be 1090 requirements to update the session with new parameters (e.g., 1091 Bandwidth, QoS, policies, etc.). 1093 This procedure is triggered by a Change of Authorization (COA) 1094 request message sent by the AAA server. The CP will update the 1095 session on the UP according to the new parameters through the Control 1096 Interface. 1098 4.3.3 Delete Subscriber Session 1100 The below call flow shows generally how S-CUPS deals with a 1101 subscriber offline request. 1103 RG UP CP 1104 | | | 1105 |Offline Request | | 1106 1|--------------->| | 1107 | | Relay the Offline | 1108 | | Request | 1109 | 2|------to CP via Si----->| 1110 | | | 1111 | | Send the Offline | 1112 | | Response | 1113 | 3|<-----to UP via Si------| 1114 |Offline Response| | 1115 4|<---------------| | 1116 | | Session delete | 1117 | | Request | 1118 | |<--------via Ci---------| 1119 | | Session delete | 1120 | | Response | 1121 | |---------via Ci-------->| 1122 | | | 1124 Figure 12: Subscriber Session Delete 1126 Similar to the session creation process, when a UP receives an 1127 offline request from a RG, it will tunnel the request to a CP through 1128 the Si. 1130 When the CP receives the offline request, it will withdraw/release 1131 the resources (e.g., IP address, bandwidth) that have been allocated 1132 to the subscriber. Then, it sends a reply to the UP through the 1133 Service Interface and the UP will forward the reply to the RG. At 1134 the same time, it will delete all the status of the session on the UP 1135 through the Ci. 1137 4.3.4 Subscriber Session Events Report 1139 UP CP 1140 | | 1141 | Statistic/Detect report| 1142 |---------via Ci-------->| 1143 | | 1145 Figure 13: Events Report 1147 When a session is created on an UP, the UP will periodically report 1148 statistics information and detect results of the session to the CP. 1150 5. S-CUSP Call Flows 1152 The subsections below give an overview of various "dial-up" 1153 interactions over the Service Interface followed by an overview of 1154 the setting of various information in the UP by the CP using S-CUSP 1155 over the Control Interface. 1157 S-CUSP messages are described in this document using Routing Backus 1158 Naur Form (RBNF) as defined in [RFC5511]. 1160 5.1 IPoE 1162 5.1.1 DHCPv4 Access 1164 The following sequence shows detailed procedures for DHCPv4 access. 1166 RG UP CP AAA 1167 | | | | 1168 | DHCP Discovery| | | 1169 1|-------------->| | | 1170 | |Relay the DHCP Discovery| | 1171 | 2|-----to CP via Si------>| AAA | 1172 | | | Req/Rep | 1173 | | 3|<------------->| 1174 | | | | 1175 | | Send the DHCP Offer | | 1176 | 4|<----to UP vis Si-------| | 1177 | DHCP Offer | | | 1178 5|<--------------| | | 1179 | DHCP Request | | | 1180 6|-------------->| | | 1181 | | Relay the DHCP Request| | 1182 | 7|-----to CP via Si------>| | 1183 | | | | 1184 | | Create subscriber | | 1185 | | session Request | | 1186 | 8|<--------via Ci---------| | 1187 | | Create subscriber | | 1188 | | session Response | | 1189 | 9|---------via Ci-------->| | 1190 | | | Accounting | 1191 | | 10|<------------->| 1192 | | | | 1193 | | Send DHCP ACK | | 1194 | 11|<----to UP via Si-------| | 1195 | | | | 1196 | DHCP ACK | | | 1197 12|<--------------| | | 1198 | | | | 1200 Figure 14: DHCPv4 Access 1202 Step 8 and 9 are implemented by the S-CUSP protocol. 1204 When a subscriber is authenticated and authorized by the AAA server, 1205 the CP will create a subscriber session on the UP. This is achieved 1206 by sending an Update_Request message to the UP. 1208 The format of the Update_Request message is shown as follows using 1209 RBNF: 1211 ::= 1212 1213 1214 1215 [] 1217 The UP will reply with an Update_Response message, the format of the 1218 Update_Response message is as follows: 1220 ::= 1221 1222 [] 1224 5.1.2 DHCPv6 Access 1226 The following sequence shows detailed procedures for DHCPv6 access. 1228 RG UP CP AAA 1229 | | | | 1230 | Solicit | | | 1231 1|-------------->| | | 1232 | | Relay the Solicit | | 1233 | 2|-----to CP via Si------>| AAA | 1234 | | | Req/Rep | 1235 | | 3|<------------->| 1236 | | | | 1237 | | Send the Advertise | | 1238 | 4|<----to UP vis Si-------| | 1239 | Advertise | | | 1240 5|<--------------| | | 1241 | | | | 1242 | Request | | | 1243 6|-------------->| | | 1244 | | Relay the Request | | 1245 | 7|-----to CP via Si------>| | 1246 | | | | 1247 | | | | 1248 | | Create subscriber | | 1249 | | session Request | | 1250 | 8|<--------via Ci-------->| | 1251 | | | | 1252 | | Create subscriber | | 1253 | | session Response | | 1254 | 9|---------via Ci-------->| | 1255 | | | | 1256 | | | Accounting | 1257 | | 10|<------------->| 1258 | | | | 1259 | | Send Reply | | 1260 | 11|<----to UP via Si-------| | 1261 | | | | 1262 | Reply | | | 1263 12|<--------------| | | 1264 | | | | 1266 Figure 15: DHCPv6 Access 1268 Steps 1-7 are a standard DHCP IPv6 access process. The subscriber 1269 creation is triggered by a DHCP IPv6 request message. When this 1270 message is received, it means that the subscriber has passed the AAA 1271 authentication and authorization. Then the CP will create a 1272 subscriber session on the UP. This is achieved by sending an 1273 Update_Request message to the UP (Step 8). 1275 The format of the Update_Request message is as follows: 1277 ::= 1278 1279 1280 1281 [] 1283 The UP will reply with an Update_Response message (Step 9). The 1284 format of the Update_Response message is as follows: 1286 ::= 1287 1289 5.1.3 IPv6 SLAAC Access 1291 The following flow shows the IPv6 SLAAC access process. 1293 RG UP CP AAA 1294 | | | | 1295 | RS | | | 1296 1|-------------->| | | 1297 | | Relay the Router | | 1298 | | Solicit (RS) | | 1299 | 2|-----to CP via Si------>| AAA | 1300 | | | Req/Rep | 1301 | | 3|<------------->| 1302 | | | | 1303 | | Create subscriber | | 1304 | | session Request | | 1305 | 4|<--------via Ci---------| | 1306 | | | | 1307 | | Create subscriber | | 1308 | | session Response | | 1309 | 5|---------via Ci-------->| | 1310 | | | | 1311 | | Send Router Advertise | | 1312 | | (RA) | | 1313 | 6|<----to UP vis Si-------| | 1314 | RA | | | 1315 7|<--------------| | | 1316 | | | | 1317 | NS | | | 1318 8|-------------->| | | 1319 | | Relay the Neighbor | | 1320 | | Solicit (NS) | | 1321 | 9|-----to CP via Si------>| | 1322 | | | | 1323 | | | Accounting | 1324 | | 10|<------------->| 1325 | | | | 1326 | | Send a Neighbor | | 1327 | | Advertise (NA) | | 1328 | 11|<----to UP via Si-------| | 1329 | | | | 1330 | NA | | | 1331 12|<--------------| | | 1332 | | | | 1334 Figure 16: IPv6 SLAAC Access 1336 It starts with a Router Solicit (RS) request from an RG that is 1337 tunneled to the CP by the UP. After the AAA authentication and 1338 authorization, the CP will create a subscriber session on the UP. 1340 This is achieved by sending an Update_Request message to the UP (step 1341 4). 1343 The format of the Update_Request message is as follows: 1345 ::= 1346 1347 1348 1349 [] 1351 The UP will reply with an Update_Response message (step 5), the 1352 format of the Update_Response message is as follows: 1354 ::= 1355 1357 5.1.4 DHCPv6 + SLAAC Access 1359 The following call flow shows the DHCP IPv6 and SLAAC access process. 1361 RG UP CP AAA 1362 | | | | 1363 | RS | | | 1364 1|-------------->| | | 1365 | | Relay the Router | | 1366 | | Solicit (RA) | | 1367 | 2|-----to CP via Si------>| AAA | 1368 | | | Req/Rep | 1369 | | 3|<------------->| 1370 | | | | 1371 | | Create subscriber | | 1372 | | session Request | | 1373 | 4|<--------via Ci---------| | 1374 | | | | 1375 | | Create subscriber | | 1376 | | session Response | | 1377 | 5|---------via Ci-------->| | 1378 | | | | 1379 | | Send Router Advertise | | 1380 | | (RA) | | 1381 | 6|<----to UP vis Si-------| | 1382 | RA | | | 1383 7|<--------------| | | 1384 | | | | 1385 |DHCPv6 Solicit | | | 1386 8|-------------->| | | 1387 | | Relay DHCPv6 Solicit | | 1388 | 9|-----to CP via Si------>| | 1389 | | | | 1390 | | Update subscriber | | 1391 | | session Request | | 1392 | 10|<--------via Ci---------| | 1393 | | | | 1394 | | Update subscriber | | 1395 | | session Response | | 1396 | 11|---------via Ci-------->| | 1397 | | | | 1398 | | | Accounting | 1399 | | 12|<------------->| 1400 | | | | 1401 | | Send DHCPv6 Reply | | 1402 | 13|<----to UP via Si-------| | 1403 | | | | 1404 | DHCPv6 Reply | | | 1405 14|<--------------| | | 1406 | | | | 1408 Figure 17: DHCPv6 + SLAAC Access 1410 When a subscriber passes AAA authentication, the CP will create a 1411 subscriber session on the UP. This is achieved by sending an 1412 Update_Request message to the UP (step 4). 1414 ::= 1415 1416 1417 1418 [] 1420 The UP will reply with an Update_Response message (step 5). The 1421 format of the Update_Response is as follows: 1423 ::= 1424 1426 After receiving a DHCPv6 Solicit, the CP will update the subscriber 1427 session by sending an Update_Request message with new parameters to 1428 the UP (Step 10). 1430 The format of the Update_Request message is as follows: 1432 ::= 1433 1434 1435 1436 [] 1438 The UP will reply with an Update_Response message (step 11). The 1439 format of the Update_Response is as follows: 1441 ::= 1442 1444 5.1.5 DHCP Dual Stack Access 1446 The following sequence is a combination of DHCP IPv4 and DHCP IPv6 1447 access processes. 1449 RG UP CP AAA 1450 | | | | 1451 | DHCP Discovery| | | 1452 1|-------------->| | | 1453 | |Relay the DHCP Discovery| | 1454 | 2|-----to CP via Si------>| AAA | 1455 | | | Req/Resp | 1456 | | 3|<------------->| 1457 | | | | 1458 | | Send the DHCP Offer | | 1459 | 4|<----to UP vis Si-------| | 1460 | DHCP Offer | | | 1461 5|<--------------| | | 1462 | DHCP Request | | | 1463 6|-------------->| | | 1464 | | Relay the DHCP Request| | 1465 | 7|-----to CP via Si------>| | 1466 | | | | 1467 | | Create subscriber | | 1468 | | session Request | | 1469 | 8|<--------via Ci-------->| | 1470 | | Create subscriber | | 1471 | | session Response | | 1472 | 9|---------via Ci-------->| | 1473 | | | Accounting | 1474 | | 10|<------------->| 1475 | | Send DHCP ACK | | 1476 | 11|<----to UP via Si-------| | 1477 | | | | 1478 | DHCP ACK | | | 1479 12|<--------------| | | 1480 | RS | | | 1481 13|-------------->| | | 1482 | | Relay the Router | | 1483 | | Solicit (RA) | | 1484 | 14|-----to CP via Si------>| AAA | 1485 | | | Req/Rep | 1486 | | 15|<------------->| 1487 | | | | 1488 | | Create subscriber | | 1489 | | session Request | | 1490 | 16|<--------via Ci---------| | 1491 | | Create subscriber | | 1492 | | session Response | | 1493 | 17|---------via Ci-------->| | 1494 | | | | 1495 | | Send Router Advertise | | 1496 | | (RA) | | 1497 | 18|<----to UP vis Si-------| | 1498 | RA | | | 1499 19|<--------------| | | 1500 | | | | 1501 |DHCPv6 Solicit | | | 1502 20|-------------->| | | 1503 | | Relay DHCPv6 Solicit | | 1504 | 21|-----to CP via Si------>| | 1505 | | | | 1506 | | Update subscriber | | 1507 | | session Request | | 1508 | 22|<--------via Ci---------| | 1509 | | Update subscriber | | 1510 | | session Response | | 1511 | 23|---------via Ci-------->| | 1512 | | | Accounting | 1513 | | 24|<------------->| 1514 | | Send DHCPv6 Reply | | 1515 | 25|<----to UP via Si-------| | 1516 | DHCPv6 Reply | | | 1517 26|<--------------| | | 1518 | | | | 1520 Figure 18: DHCP Dual Stack Access 1522 The DHCP dual stack access includes three sets of Update_Request / 1523 Update_Response exchanges to create/update DHCPv4/v6 subscriber 1524 session. 1526 1. Create DHCPv4 session (step 8 and 9) 1528 ::= 1529 1530 1531 1532 [] 1534 ::= 1535 1536 [] 1538 2. Create DHCPv6 session (step 16 and 17) 1540 ::= 1541 1542 1543 1544 [] 1546 ::= 1547 1549 3. Update DHCPv6 session (step 22 and 23) 1551 ::= 1552 1553 1554 1555 [] 1557 ::= 1558 1560 5.1.6 L2 Static Subscriber Access 1562 L2 static subscriber access processes are as follows: 1564 RG UP CP AAA 1565 | | | | 1566 | | Static Subscriber | | 1567 | | Detection Req. | | 1568 | 1|<-----to UP via Ci------| | 1569 | | Static Subscriber | | 1570 | | Detection Rep. | | 1571 | 2|------to UP via Ci----->| | 1572 | ARP/ND(REQ) | | | 1573 3.1|<--------------| | | 1574 | ARP/ND(ACK) | | | 1575 3.2|-------------->| | | 1576 | | Relay the ARP/ND | | 1577 | 3.3|-----to CP via Si------>| AAA | 1578 | | | Req/Rep | 1579 | | 3.4|<------------->| 1580 | | Create subscriber | | 1581 | | session Request | | 1582 | 3.5|<--------via Ci---------| | 1583 | | Create subscriber | | 1584 | | session Response | | 1585 | 3.6|---------via Ci-------->| | 1586 | | | | 1587 | ARP/ND(REQ) | | | 1588 4.1|-------------->| | | 1589 | | Relay the ARP/ND | | 1590 | 4.2|-----to CP via Si------>| AAA | 1591 | | | Req/Rep | 1592 | | 4.3|<------------->| 1593 | | Create subscriber | | 1594 | | session Request | | 1595 | 4.4|<--------via Ci---------| | 1596 | | Create subscriber | | 1597 | | session Response | | 1598 | 4.5|---------via Ci-------->| | 1599 | ARP/ND(ACK) | | | 1600 4.6|<--------------| | | 1601 | | | | 1602 | IP Traffic | | | 1603 5.1|-------------->| | | 1604 | | Relay the IP Traffic | | 1605 | 5.2|-----to CP via Si------>| AAA | 1606 | | | Req/Rep | 1607 | | 5.3|<------------->| 1608 | | Create subscriber | | 1609 | | session Request | | 1610 | 5.4|<--------via Ci-------->| | 1611 | | Create subscriber | | 1612 | | session Response | | 1613 | 5.5|---------via Ci-------->| | 1614 | | | | 1615 | ARP/ND(REQ) | | | 1616 5.6|<--------------| | | 1617 | ARP/ND(ACK) | | | 1618 5.7|-------------->| | | 1619 | | | | 1621 Figure 19: L2 Static Subscriber Access 1623 For L2 static subscriber access, the process starts with a CP 1624 installing a static subscriber detection list on an UP. The list 1625 determines which subscribers will be detected. This is implemented 1626 by exchanging Update_Request and Update_Response messages between CP 1627 and UP. The format of the messages are as follows: 1629 ::= 1630 1631 1633 ::= 1634 1636 For L2 Static subscriber access, there are three ways to trigger the 1637 access process: 1639 1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP 1640 address, the access interface, and VLAN of the RG. The UP will 1641 actively trigger the access flow by sending an ARP/ND packet to 1642 the RG. If the RG is online, it will reply with an ARP/ND to the 1643 UP. The UP will tunnel the ARP/ND to the CP through the Si. The 1644 CP then triggers the authentication process. If the 1645 authentication result is positive. The CP will create a 1646 corresponding subscriber session on the UP. 1648 2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as 1649 option 1 (triggered by UP). The difference is that the RG will 1650 actively send the ARP/ND to trigger the process. 1652 3. Triggered by RG IP traffic (5.1-5.7): This is for the case where 1653 the RG has the ARP/ND information, but the subscriber session on 1654 the UP is lost (e.g., due to failure on the UP, or the UP 1655 restarted). That means the RG may keep sending IP packets to the 1656 UP. The packets will trigger the UP to start a new access 1657 process. 1659 From a subscriber session point of view, the procedures and the 1660 message formats for the above three cases are the same, as follows: 1662 IPv4 Case: 1663 ::= 1664 1665 1666 1667 [] 1669 ::= 1670 1671 [] 1673 IPv6 Case: 1674 ::= 1675 1676 1677 1678 [] 1680 ::= 1681 1683 5.2 PPPoE 1685 5.2.1 IPv4 PPPoE Access 1687 The following figure shows the IPv4 PPPoE access call flow. 1689 RG UP CP AAA 1690 | | | | 1691 | PPPoE Disc | PPPoE Disc | | 1692 1|<------------->|<---------via Si------->| | 1693 | | | | 1694 | PPP LCP | PPP LCP | | 1695 2|<------------->|<---------via Si------->| | 1696 | | | AAA | 1697 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1698 3|<------------->|<---------via Si------->|<------------->| 1699 | | | | 1700 | PPP IPCP | PPP IPCP | | 1701 4|<------------->|<---------via Si------->| | 1702 | | | | 1703 | | Create subscriber | | 1704 | | session Request | | 1705 | 5|<--------via Ci---------| | 1706 | | | | 1707 | | Create subscriber | | 1708 | | session Response | | 1709 | 6|---------via Ci-------->| | 1710 | | | | 1711 | | | Accounting | 1712 | | 7|<------------->| 1713 | | | | 1715 Figure 20: IPv4 PPPoE Access 1717 From the above sequence, step 1-4 are the standard PPPoE call flow. 1718 The UP is responsible for redirecting the PPPoE control packets to 1719 the CP or RG. The PPPoE control packets are transmitted between the 1720 CP and UP through the Si. 1722 After the PPPoE call flow, if the subscriber passed the AAA 1723 authentication and authorization, the CP will create a corresponding 1724 session on the UP through the Ci. The formats of the messages are as 1725 follows: 1727 ::= 1728 1729 1730 1731 1732 [] 1734 ::= 1735 1736 [] 1738 5.2.2 IPv6 PPPoE Access 1740 The following figure describes the IPv6 PPPoE access call flow. 1742 RG UP CP AAA 1743 | | | | 1744 | PPPoE Disc | PPPoE Disc | | 1745 1|<------------->|<--------via Si-------->| | 1746 | | | | 1747 | PPP LCP | PPP LCP | | 1748 2|<------------->|<---------via Si------->| | 1749 | | | AAA | 1750 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1751 3|<------------->|<---------via Si------->|<------------->| 1752 | | | | 1753 | PPP IP6CP | PPP IP6CP | | 1754 4|<------------->|<---------via Si------->| | 1755 | | | | 1756 | | Create subscriber | | 1757 | | session Request | | 1758 | 5|<--------via Ci---------| | 1759 | | | | 1760 | | Create subscriber | | 1761 | | session Response | | 1762 | 6|---------via Ci-------->| | 1763 | | | | 1764 | ND Negotiation| ND Negotiation | | 1765 7|<------------->|<---------via Si------->| | 1766 | | | | 1767 | | Update subscriber | | 1768 | | session Request | | 1769 | 8|<--------via Ci---------| | 1770 | | | | 1771 | | Update subscriber | | 1772 | | session Response | | 1773 | 9|---------via Ci-------->| | 1774 | | | | 1775 | | | Accounting | 1776 | | 10|<------------->| 1777 | | | | 1778 | DHCPv6 | DHCPv6 | | 1779 | Negotiation | Negotiation | | 1780 7'|<------------->|<---------via Si------->| | 1781 | | | | 1782 | | Update subscriber | | 1783 | | session Request | | 1784 | 8'|<---------via Ci--------| | 1785 | | | | 1786 | | Update subscriber | | 1787 | | session Response | | 1788 | 9'|---------via Ci-------->| | 1789 | | | | 1790 | | | Accounting | 1791 | | 10'|<------------->| 1792 | | | | 1794 Figure 21: IPv6 PPPoE Access 1796 From the above sequence, steps 1-4 are the standard PPPoE call flow. 1797 The UP is responsible for redirecting the PPPoE control packets to 1798 the CP or RG. The PPPoE control packets are transmitted between the 1799 CP and UP through the Si. 1801 After the PPPoE call flow, if the subscriber passed the AAA 1802 authentication and authorization, the CP will create a corresponding 1803 session on the UP through the Ci. The formats of the messages are as 1804 follows: 1806 ::= 1807 1808 1809 1810 1811 [] 1813 ::= 1814 1816 Then, the RG will initialize a ND/DHCPv6 negotiation process with the 1817 CP (see step 7 and 7'), after that, it will trigger an update (8-9, 1818 8'-9') to the subscriber session. The formats of the update messages 1819 are as follows: 1821 ::= 1822 1823 1824 1825 1826 [] 1828 ::= 1829 1831 5.2.3 PPPoE Dual Stack Access 1833 The following figure shows a combination of IPv4 and IPv6 PPPoE 1834 access call flow. 1836 RG UP CP AAA 1837 | | | | 1838 |PPPoE Discovery| PPPoE Discovery | | 1839 1|<------------->|<---------via Si------->| | 1840 | | | | 1841 | PPP LCP | PPP LCP | | 1842 2|<------------->|<---------via Si------->| | 1843 | | | AAA | 1844 | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 1845 3|<------------->|<---------via Si------->|<------------->| 1846 | | | | 1847 | PPP IPCP | PPP IPCP | | 1848 4|<------------->|<---------via Si------->| | 1849 | | | | 1850 | | Create v4 subscriber | | 1851 | | session Request | | 1852 | 5|<--------via Ci---------| | 1853 | | Create v4 subscriber | | 1854 | | session Response | | 1855 | 6|---------via Ci-------->| | 1856 | | | Accounting | 1857 | | 7|<------------->| 1858 | PPP IP6CP | PPP IP6CP | | 1859 4'|<------------->|<---------via Si------->| | 1860 | | | | 1861 | | Create V6 subscriber | | 1862 | | session Request | | 1863 | 5'|<--------via Ci---------| | 1864 | | Create v6 subscriber | | 1865 | | session Response | | 1866 | 6'|---------via Ci-------->| | 1867 | | | | 1868 | ND Negotiation| ND Negotiation | | 1870 8|<------------->|<---------via Si------->| | 1871 | | | | 1872 | | Update v6 subscriber | | 1873 | | session Request | | 1874 | 9|<---------via Ci--------| | 1875 | | Update v6 subscriber | | 1876 | | session Response | | 1877 | 10|---------via Ci-------->| | 1878 | | | Accounting | 1879 | | 7'|<------------->| 1880 | DHCPv6 | DHCPv6 | | 1881 | Negotiation | Negotiation | | 1882 8'|<------------->|<---------via Si------->| | 1883 | | | | 1884 | | Update v6 subscriber | | 1885 | | session Request | | 1886 | 9'|<--------via Ci---------| | 1887 | | | | 1888 | | Update v6 subscriber | | 1889 | | session Response | | 1890 | 10'|---------via Ci-------->| | 1891 | | | | 1892 | | | Accounting | 1893 | | 7"|<------------->| 1894 | | | | 1896 Figure 22: PPPoE Dual Stack Access 1898 PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE 1899 access. The process is as above. The formats of the messages are as 1900 follows: 1902 1. Create an IPv4 PPPoE subscriber session (5-6) 1904 ::= 1905 1906 1907 1908 1909 [] 1911 ::= 1912 1913 [] 1915 2. Create an IPv6 PPPoE subscriber session (5'-6') 1917 ::= 1918 1919 1920 1921 1922 [] 1924 ::= 1925 1927 3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10') 1929 ::= 1930 1931 1932 1933 1934 [] 1936 ::= 1937 1939 5.3 WLAN Access 1941 The following figure shows the WLAN access call flow. 1943 RG UP CP AAA WEB Server 1944 | | | | | 1945 | DHCP | | | | 1946 | Discovery | | | | 1947 1|------------>| | | | 1948 | | DHCP | | | 1949 | | Discovery | | | 1950 | 2|-----via Si---->| AAA | | 1951 | | DHCP Offer |<-------->| | 1952 | 3|<----via Si-----| | | 1953 | DHCP Offer | | | | 1954 4|<------------| | | | 1955 | DHCP | | | | 1956 | Request | | | | 1957 5|------------>| | | | 1958 | | DHCP Request | | | 1959 | 6|-----via Si---->| | | 1960 | | | | | 1961 | | Create session | | | 1962 | | Request | | | 1963 | 7|<----via Ci-----| | | 1964 | | Create session | | | 1965 | | Response | | | 1966 | 8|----via Ci----->| | | 1967 | | | | | 1968 | | DHCP ACK | | | 1969 | 9|<----via Si-----| | | 1970 | | | | | 1971 | DHCP ACK | | | | 1972 10|<------------| | | | 1973 | | | | | 1974 | Subscriber | | | | 1975 | HTTP Traffic| | | | 1976 11|------------>|--> | | | 1977 | | | WEB URL | | | 1978 | Traffic | | Redirect | | | 1979 | Redirection | | | | | 1980 12|<------------|<-+ | | | 1981 | | | | 1982 | | 1983 13|-----------------Redirect to Web server------------->| 1984 | | 1985 14|<----------------Push HTTP log-in page---------------| 1986 | | 1987 15|-----------------User Authentication---------------->| 1988 | | 1989 | | | Portal Interchange | 1990 | | 16|<-------------------->| 1991 | | | | 1992 | | | AAA | | 1993 | | | Req/Rep | | 1994 | | 17|<-------->| | 1995 | | | | | 1996 | | Update session | | | 1997 | | Request | | | 1998 | 18|<----via Ci-----| | | 1999 | | | | | 2000 | | Update session | | | 2001 | | Response | | | 2002 | 19|-----via Ci---->| | | 2003 | | | | | 2005 Figure 23: WLAN Access 2007 WLAN access starts with the DHCP dial-up process (steps 1-6), after 2008 that the CP will create a subscriber session on the UP (steps 7-8). 2009 The formats of the session creation messages are as follows: 2011 IPv4 Case: 2012 ::= 2013 2014 2015 2016 [] 2018 ::= 2019 2020 [] 2022 IPv6 Case: 2023 ::= 2024 2025 2026 2027 [] 2029 ::= 2030 2032 After step 10, the RG will be allocated an IP address and its first 2033 HTTP packet will be redirected to a WEB server for subscriber 2034 authentication (steps 11-17). After the WEB authentication, if the 2035 result is positive, the CP will update the subscriber session by 2036 using the following message exchanges: 2038 IPv4 Case: ::= 2039 2040 2041 2042 [] 2044 ::= 2045 2046 [] 2048 IPv6 Case: ::= 2049 2050 2051 2052 [] 2054 ::= 2055 2057 5.4 L2TP 2059 5.4.1 L2TP LAC Access 2061 RG UP(LAC) CP(LAC) AAA LNS 2062 | | | | | 2063 | PPPoE | PPPoE | | | 2064 | Discovery | Discovery | | | 2065 1|<---------->|<---via Si--->| | | 2066 | | | | | 2067 | PPP LCP | PPP LCP | | | 2068 2|<---------->|<---via Si--->| | | 2069 | | | AAA | | 2070 |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| | 2071 3|<---------->|<---via Si--->|<------>| | 2072 | | | | | 2073 | PPP IPCP | PPP IPCP | | | 2074 4|<---------->|<---via Si--->| | | 2075 | | | | | 2076 | | L2TP tunnel | | | 2077 | | negotiation | | | 2078 | | SCCRQ/ | | | 2079 | | SCCRP/ | | | 2080 | | SCCCN | | | 2081 | 5|<---via Si--->| | | 2082 | | /\ | 2083 | | || forward | 2084 | | \/ | 2085 | |<-----------via routing---------->| 2086 | | | 2087 | | L2TP session | | | 2088 | | negotiation | | | 2089 | | ICRQ/ | | | 2090 | | ICRP/ | | | 2091 | | ICCN | | | 2092 | 6|<---via Si--->| | | 2093 | | /\ | 2094 | | || forward | 2095 | | \/ | 2096 | |<-----------via routing---------->| 2097 | | | 2098 | | Create | | | 2099 | | subscriber | | | 2100 | | session | | | 2101 | | Request | | | 2102 | 7|<---via Ci----| | | 2103 | | | | | 2104 | | Create | | | 2105 | | subscriber | | | 2106 | | session | | | 2107 | | Response | | | 2108 | 8|----via Ci--->| | | 2109 | | | | | 2110 | | 2111 | PAP/CHAP (Triggered by LNS) | 2112 9|<-----------------via routing?---------------->| 2113 | | 2114 Figure 24: L2TP-LAC Access 2116 Steps 1-4 are a standard PPPoE access process. After that the LAC-CP 2117 starts to negotiate an L2TP session and tunnel with the LNS. After 2118 the negotiation, the CP will create an L2TP LAC subscriber session on 2119 the UP through the following messages: 2121 ::= 2122 2123 2124 2126 ::= 2127 2129 5.4.2 L2TP LNS IPv4 Access 2131 RG LAC UP(LNS) AAA CP(LNS) 2132 | | | | | 2133 | PPPoE | | | | 2134 | Discovery | | | | 2135 1|<---------->| | | | 2136 | | | | | 2137 | PPP LCP | | | | 2138 2|<---------->| | | 2139 | | AAA | | 2140 |PPP PAP/CHAP| Req/Rep | | 2141 3|<---------->|<--------------------->| | 2142 | | | 2143 | | | 2144 | | L2TP tunnel | L2TP tunnel | 2145 | | negotiation | negotiation | 2146 | | SCCRQ/ | SCCRQ/ | 2147 | | SCCRP/ | SCCRP/ | 2148 | | SCCCN | SCCCN | 2149 | 4|<------------>|<------via Si----->| 2150 | | | | 2151 | | L2TP session | L2TP session | 2152 | | negotiation | negotiation | 2153 | | ICRQ/ | ICRQ/ | 2154 | | ICRP/ | ICRP/ | 2155 | | ICCN | ICCN | 2156 | 5|<------------>|<------via Si----->| 2157 | | | | 2158 | | | Create | 2159 | | | subscriber | 2160 | | | session | 2161 | | | Request | 2162 | | 6|<-----via Ci-------| 2163 | | | Create | 2164 | | | subscriber | 2165 | | | session | 2166 | | | Response | 2167 | | 7|------via Ci------>| 2168 | | 2169 | PAP/CHAP (Triggered by LNS) | 2170 8|<--------------------------------------------->| 2171 | | 2172 | | | | AAA | 2173 | | | | Req/Rep | 2174 | | | 9|<-------->| 2175 | | | | 2176 | | 2177 | PPP IPCP | 2178 10|<--------------------------------------------->| 2179 | | 2180 | | | Update | 2181 | | | subscriber | 2182 | | | session | 2183 | | | Request | 2184 | | 11|<-----via Ci-------| 2185 | | | Update | 2186 | | | subscriber | 2187 | | | session | 2188 | | | Response | 2189 | | 12|------via Ci------>| 2190 | | | | 2192 Figure 25: IPv4 L2TP-LNS Access 2194 In this case, the BNG is running as an LNS and separated into LNS-CP 2195 and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When 2196 the L2TP session and tunnel negotiations are finished, the LNS-CP 2197 will create an L2TP LNS subscriber session on the LNS-UP. The format 2198 of messages are as follows: 2200 ::= 2201 2202 2203 2204 2205 2206 2207 [] 2209 ::= 2210 2211 [] 2213 After that, the LNS-CP will trigger an AAA authentication. If the 2214 authentication result is positive, a PPP IPCP process will follow, 2215 then the CP will update the session with the following message 2216 exchanges: 2218 ::= 2219 2220 2221 2222 2223 2224 2225 [] 2227 ::= 2228 2229 [] 2231 5.4.3 L2TP LNS IPv6 Access 2233 RG LAC UP(LNS) AAA CP(LNS) 2234 | | | | | 2235 | PPPoE | | | | 2236 | Discovery | | | | 2237 1|<---------->| | | | 2238 | | | | | 2239 | PPP LCP | | | | 2240 2|<---------->| | | 2241 | | AAA | | 2242 |PPP PAP/CHAP| Req/Rep | | 2243 3|<---------->|<--------------------->| | 2244 | | | 2245 | | | 2246 | | L2TP tunnel | L2TP tunnel | 2247 | | negotiation | negotiation | 2248 | | SCCRQ/ | SCCRQ/ | 2249 | | SCCRP/ | SCCRP/ | 2250 | | SCCCN | SCCCN | 2251 | 4|<------------>|<------via Si----->| 2252 | | | | 2253 | | L2TP session | L2TP session | 2254 | | negotiation | negotiation | 2255 | | ICRQ/ | ICRQ/ | 2256 | | ICRP/ | ICRP/ | 2257 | | ICCN | ICCN | 2258 | 5|<------------>|<------via Si----->| 2259 | | | | 2260 | | | Create | 2261 | | | subscriber | 2262 | | | session | 2263 | | | Request | 2264 | | 6|<-----via Ci-------| 2265 | | | Create | 2266 | | | subscriber | 2267 | | | session | 2268 | | | Response | 2269 | | 7|------via Ci------>| 2270 | | 2271 | PAP/CHAP (Triggered by LNS) | 2272 8|<--------------------------------------------->| 2273 | | 2274 | | | | AAA | 2275 | | | | Req/Rep | 2276 | | | 9|<-------->| 2277 | | | | | 2278 | | 2279 | PPP IP6CP | 2280 10|<--------------------------------------------->| 2281 | | 2282 | | | Update | 2283 | | | subscriber | 2284 | | | session | 2285 | | | Request | 2286 | | 11|<-----via Ci-------| 2287 | | | Update | 2288 | | | subscriber | 2289 | | | session | 2290 | | | Response | 2291 | | 12|------via Ci------>| 2292 | | | | 2293 | | | 2294 | ND negotiation | ND negotiation | 2295 13|<------------------------->|<-----via Si------>| 2296 | | | 2297 | | | Update | 2298 | | | subscriber | 2299 | | | session | 2300 | | | Request | 2301 | | 14|<-----via Ci-------| 2302 | | | Update | 2303 | | | subscriber | 2304 | | | session | 2305 | | | Response | 2306 | | 15|------via Ci------>| 2307 | | | | 2309 Figure 26: L2TP-LNS IPv6 Access 2311 Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5 2312 finish the normal L2TP dial-up process. When the L2TP session and 2313 tunnel negotiations are finished, the LNS-CP will create an L2TP LNS 2314 subscriber session on the LNS-UP. The format of the messages is as 2315 follows: 2317 ::= 2318 2319 2320 2321 2322 2323 2324 [] 2326 ::= 2327 2329 After that, the LNS-CP will trigger a AAA authentication. If the 2330 authentication result is positive, a PPP IP6CP process will follow, 2331 then the CP will update the session with the following message 2332 exchanges: 2334 ::= 2335 2336 2337 2338 2339 2340 2341 [] 2343 ::= 2344 2346 Then, an ND negotiation will be triggered by the RG. After the ND 2347 negotiation, the CP will update the session with the following 2348 message exchanges: 2350 ::= 2351 2352 2353 2354 2355 2356 2357 [] 2359 ::= 2360 2362 5.5 CGN (Carrier Grade NAT) 2364 RG UP CP AAA 2365 | | | | 2366 | | Public Address Block | | 2367 | | Allocation Request | | 2368 | 1|<--------via Ci-------->| | 2369 | | Public Address Block | | 2370 | | Allocation Reply | | 2371 | 2|---------via Ci-------->| | 2372 | | | | 2373 | Subscriber | | | 2374 | access request| Subscriber | | 2375 3|-------------->| access request | | 2376 | 4|----------via Si------->| | 2377 | | | AAA | 2378 | | Subscriber | Req/Rep | 2379 | Subscriber | access reply 5|<------------->| 2380 | access reply 6|<---------via Si--------| | 2381 7|<--------------| | | 2382 | | | | 2383 | | Create subscriber | | 2384 | | session Request | | 2385 | 8|<--------via Ci---------| | 2386 | | | | 2387 | | Create subscriber | | 2388 | | session Response | | 2389 | | (with NAT information) | | 2390 | 9|---------via Ci-------->| | 2391 | | | | 2392 | | | Accounting | 2393 | | | with source | 2394 | | | information | 2395 | | 10|<------------->| 2396 | | | Public IP + | 2397 | | | Port range | 2398 | | | to Private IP| 2399 | | | mapping | 2400 | | | | 2402 Figure 27: CGN Access 2404 The first steps allocate one or more CGN address blocks to the UP 2405 (steps 1-2). This is achieved by the following message exchanges 2406 between CP and UP. 2408 ::= 2409 2411 ::= 2412
2414 Steps 3-9 show the general dial-up process in the case of CGN mode. 2415 The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in 2416 above sections. 2418 If a subscriber is a CGN subscriber, once the subscriber session is 2419 created/updated, the UP will report the NAT information to the CP. 2420 This is achieved by carrying the "Subscriber CGN Port Range TLV" in 2421 the Update_Response message. 2423 5.6 L3 Leased Line Access 2425 5.6.1 Web Authentication 2427 RG UP CP AAA WEB Server 2428 | | | | | 2429 | User | | | | 2430 | traffic | | | | 2431 1|------------>| | | | 2432 | | User | | | 2433 | | traffic | | | 2434 | 2|-----via Si---->| AAA | | 2435 | | | Req/Rep | | 2436 | | 3|<-------->| | 2437 | | Create session | | | 2438 | | Request | | | 2439 | 4|<----via Ci-----| | | 2440 | | | | | 2441 | | Create session | | | 2442 | | Response | | | 2443 | 5|----via Ci----->| | | 2444 | HTTP | | | | 2445 | traffic | | | | 2446 6|------------>| | | | 2447 | | | | | 2448 | Redirect to | | | | 2449 | Web URL | | | | 2450 7|<------------| | | | 2451 | | | | | 2452 | | 2453 8|-----------------Redirected to Web server----------->| 2454 | | 2455 9|<----------------Push HTTP Log-in page---------------| 2456 | | 2457 10|-----------------User Authentication---------------->| 2458 | | 2459 | | | Portal Interchange | 2460 | | 11|<-------------------->| 2461 | | | | 2462 | | | AAA | | 2463 | | | Req/Rep | | 2464 | | 12|<-------->| | 2465 | | | | | 2466 | | | | | 2467 | | Update session | | | 2468 | | Request | | | 2469 | 13|<----via Ci-----| | | 2470 | | | | | 2471 | | Update session | | | 2472 | | Response | | | 2473 | 14|----via Ci----->| | | 2474 | | | | | 2476 Figure 28: Web Authentication based L3 Leased Line Access 2478 In this case, IP traffic from the RG will trigger the CP to 2479 authenticate the RG by checking the source IP and the exchanges with 2480 the AAA server. Once the RG passed the authentication, the CP will 2481 create a corresponding subscriber session on the UP through the 2482 following message exchanges: 2484 IPv4 Case: 2485 ::= 2486 2487 2488 2489 [] 2491 ::= 2492 2493 [] 2495 IPv6 Case: 2496 ::= 2497 2498 2499 2500 [] 2502 ::= 2503 2505 Then, the HTTP traffic from the RG will be redirected to a WEB server 2506 to finish the WEB authentication. Once the WEB authentication is 2507 passed, the CP will trigger another AAA authentication. After the 2508 AAA authentication, the CP will update the session with the following 2509 message exchanges: 2511 IPv4 Case: 2512 ::= 2513 2514 2515 2516 [] 2518 ::= 2519 2520 [] 2522 IPv6 Case: 2523 ::= 2524 2525 2526 2527 [] 2529 ::= 2530 2532 5.6.2 User Traffic Trigger 2534 RG UP CP AAA 2535 | | | | 2536 | | L3 access | | 2537 | | control list | | 2538 | 1|<----via Ci-----| | 2539 | User | | | 2540 | traffic | | | 2541 2|------------>| | | 2542 | | User | | 2543 | | traffic | | 2544 | 3|-----via Si---->| | 2545 | | | AAA | 2546 | | | Req/Rep | 2547 | | 4|<-------->| 2548 | | | | 2549 | | Create session | | 2550 | | Request | | 2551 | 5|<----via Ci-----| | 2552 | | Create session | | 2553 | | Response | | 2554 | 6|----via Ci----->| | 2555 | | | | 2557 Figure 29: User Traffic Triggered L3 Leased Line Access 2559 In this user traffic triggered case, the CP must install an access 2560 control list on the UP, which is used by the UP to determine whether 2561 an RG is legal or not. If the traffic is from a legal RG, it will be 2562 redirected to the CP though the Si. The CP will trigger a AAA 2563 interchange with the AAA server. After that, the CP will create a 2564 corresponding subscriber session on the UP with the following message 2565 exchanges: 2567 IPv4 Case: 2568 ::= 2569 2570 2571 2572 [] 2574 ::= 2575 2576 [] 2578 IPv6 Case: 2579 ::= 2580 2581 2582 2583 [] 2585 ::= 2586 2588 5.7 Multicast Access 2590 RG UP CP AAA 2591 | | | | 2592 | User access | User access | AAA | 2593 | request | request | Req/Rep | 2594 1|<----------->|<----via Si---->|<-------->| 2595 | | User | | 2596 | | | | 2597 | | | | 2598 | | Create session | | 2599 | | Request | | 2600 | 2|<----via Ci---->| | 2601 | | | | 2602 | | Create session | | 2603 | | Response | | 2604 | 3|----via Ci----->| | 2605 | | | | 2606 | Multicast | | | 2607 | negotiation | | | 2608 4|<----------->| | | 2609 | | | | 2611 Figure 30: Multicast Access 2613 Multicast access starts with an user access request from the RG. The 2614 request will be redirected to the CP by the Si. A follow-up AAA 2615 interchange between the CP and the AAA server will be triggered. 2616 After the authentication, the CP will create a multicast subscriber 2617 session on the UP through the following messages: 2619 IPv4 Case: 2620 ::= 2621 2622 2623 2624 2625 [] 2627 ::= 2628 2629 [] 2631 IPv6 Case: 2632 ::= 2633 2634 2635 2636 2637 [] 2639 ::= 2640 2642 6. S-CUSP Message Formats 2644 An S-CUSP message consists of a common header followed by a variable- 2645 length body consisting entirely of TLVs. Receiving an S-CUSP message 2646 with an unknown message type or missing mandatory TLV MUST trigger an 2647 Error message (see Section 6.7) or a response message with an Error 2648 Information TLV (see Section 7.6). 2650 Conversely, if a TLV is optional, the TLV may or may not be present. 2651 Optional TLVs are indicated in the message formats shown in this 2652 document by being enclosed in square brackets. 2654 This section specifies the format of the common S-CUSP message header 2655 and lists the defined messages. 2657 Network byte order is used for all multi-byte fields. 2659 6.1 Common Message Header 2661 S-CUSP Common Message Header: 2662 0 1 2 3 2663 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 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 | Ver | Resv | Message-Type | Message-Length | 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | Reserved | Transaction-ID | 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 Figure 6.1: S-CUSP Message Common Header 2672 o Ver (4 bits): The major version of the protocol. This document 2673 specifies version 1. Different major versions of the protocol 2674 may have significantly different message structure and format 2675 except that the Ver field will always be in the same place at 2676 the beginning of each message. A successful S-CUSP session 2677 depends on the CP and the UP both using the same major version 2678 of the protocol. 2680 o Resv (4 bits): Reserved. MUST be sent as zero and ignored on 2681 receipt. 2683 o Message-Type (8 bits): The set of message types specified in 2684 this document is listed in Section 9.1. 2686 o Message-Length (16 bits): Total length of the S-CUSP message 2687 including the common header, expressed in number of bytes as an 2688 unsigned integer. 2690 o Transaction ID (16 bits): This field is used to identify 2691 requests. It is echoed back in any corresponding ACK / response 2692 / Error message. It is RECOMMENDED that a monotonically 2693 increasing value be used in successive message and that value 2694 wrap back to zero after 0xFFFF. The contents of this field is 2695 an opaque value that the receiver MUST NOT use for any purpose 2696 except to echo back in a corresponding response and, 2697 optionally, for logging. 2699 6.2 Control Messages 2701 This document defines the following control messages: 2703 Type Name Notes and TLVs that can be carried 2704 ---- ---- ------------------------------------ 2705 1 Hello Hello TLV, Keep-Alive TLV. 2706 2 Keepalive A common header with the Keepalive message 2707 type. 2708 3 Sync_Request Synchronization request. 2709 4 Sync_Begin Synchronization starts. 2710 5 Sync_Data Synchronization data: TLVs specified in 2711 Section 5. 2712 6 Sync_End End synchronization. 2713 7 Update_Request TLVs specified in Sections 7.6-7.9. 2714 8 Update_Response TLVs specified in Sections 7.6-7.9. 2716 6.2.1 Hello Message 2718 Hello message is used for S-CUSP session establishment and version 2719 negotiation. The detail of S-CUSP session establishment and version 2720 negotiation can be found in Section 4.1.1. 2722 The format of Hello message is as follows: 2724 ::= 2725 2726 2727 [] 2729 The return code and negotiation result will be carried in the Error 2730 Information TLV. They are listed as follows: 2732 0: Success, version negotiation success. 2734 1: Failure, malformed message received. 2736 2: One or more of the TLVs was not understood. 2738 1001: The version negotiation fails. The S-CUSP session 2739 establishment phase fails. 2741 1002: The keepalive negotiation fails. The S-CUSP session 2742 establishment phase fails. 2744 1003: The establishment timer expires. session establishment 2745 phase fails. 2747 6.2.2 Keepalive Message 2749 The Keepalive message is periodically sent by each end of an S-CUSP 2750 session. It is used to detect whether the peer end is still alive. 2751 The Keepalive procedures are defined Section 4.1.2. 2753 The format of the Keepalive message is as follows: 2755 ::= 2757 6.2.3 Sync_Request Message 2759 The Sync_Request message is used to request synchronization from an 2760 S-CUSP peer. Both CP and UP can request their peer to synchronize 2761 data. 2763 The format of the Sync_Request message is as follows: 2765 ::= 2767 A Sync_Request message may result in a Sync_Begin message from its 2768 peer. The Sync_Begin message is defined in Section 6.2.4. 2770 6.2.4 Sync_Begin Message 2772 The Sync_Begin message is a reply to a Sync_Request message. It is 2773 used to notify the synchronization requester whether the 2774 synchronization can be started. 2776 The format of Sync_Begin message is as follows: 2778 ::= 2779 2781 The return codes are carried in the Error Information TLV. The codes 2782 are listed below: 2784 0: Success, be ready to synchronize. 2786 1: Failure, malformed message received. 2788 2: One or more of the TLVs was not understood. 2790 2001: Synch-NoReady. The data to be synchronized is not ready. 2792 2002: Synch-Unsupport. The data synchronization is not supported. 2794 6.2.5 Sync_Data Message 2796 The Sync_Data message is used to send data being synchronized between 2797 the CP and UP. The Sync_Data message has the same function and 2798 format as the Update_Request message. The difference is that there 2799 is no ACK for a Sync_Data message. An error caused by the Sync_Data 2800 message will result in a Sync_End message. 2802 There are two scenarios: 2804 Synchronization from UP to CP: Synchronize the resource data to 2805 CP. 2807 ::= 2808 [] 2810 Synchronization from CP to UP: Synchronize all subscriber sessions 2811 to UP. As for which TLVs should be carried, it depends on the 2812 specific session data to be synchronized. This is equivalent to 2813 create the specific session. Refer to Section 5 to see more 2814 details. 2816 ::= 2817 [] 2818 [] 2819 [] 2820 [] 2821 [] 2823 6.2.6 Sync_End Message 2825 The Sync_End message is used to indicate the end of a synchronization 2826 process. The format of a Sync_End message is as follows: 2828 ::= 2829 2831 The return/error codes are listed as follows: 2833 0: Success, synchronization finished. 2835 1: Failure, malformed message received. 2837 2: One or more of the TLVs was not understood. 2839 6.2.7 Update_Request Message 2841 The Update_Request message is a multi-task message, it can be used to 2842 create, update, and delete subscriber sessions on a UP. 2844 For session operations, the specific operation is controlled by the 2845 "Oper" field of the carried TLVs. As defined in Section 7.1, the 2846 "Oper" can be set to either "update" or "delete" when a TLV is 2847 carried in an Update_Request message. 2849 When the "Oper" set to update, it means to create or update a 2850 subscriber session, if the "Oper" set to delete, it indicates to 2851 delete a corresponding session on an UP. 2853 The format of Update_Request message is as follows: 2855 ::= 2856 [] 2857 [] 2858 [] 2859 [] 2860 [] 2862 Each Update_Request message will result in an Update_Response message 2863 that is defined in Section 6.2.8. 2865 6.2.8 Update_Response Message 2867 The Update_Response message is a response to an Update_Request 2868 message. It is used to confirm the update request (or reject it in 2869 the case of an error). The format of an Update_Response message is 2870 as follows: 2872 ::= 2873 [] 2874 2876 The return/error codes are carried in the Error Information TLV. 2877 They are listed as follows: 2879 0: Success. 2881 1: Failure, malformed message received. 2883 2: One or more of the TLVs was not understood. 2885 3001(Pool-Mismatch): The corresponding address pool cannot be 2886 found. 2888 3002 (Pool-Full): The address pool is fully allocated and no 2889 address segment is available. 2891 3003 (Subnet-Mismatch): The address pool subnet cannot be found. 2893 3004 (Subnet-Conflict): Subnets in the address pool have been 2894 classified into other clients. 2896 4001 (Update-Fail-No-Res): The forwarding table fails to be 2897 delivered because the forwarding resources are insufficient. 2899 4002 (QoS-Update-Success): The QoS policy takes effect. 2901 4003 (QoS-Update-Sq-Fail): Failed to process the queue in the QoS 2902 policy. 2904 4004 (QoS-Update-CAR-Fail): Processing of the CAR in the QoS 2905 policy fails. 2907 4005 (Statistic-Fail-No-Res): Statistics processing failed due to 2908 insufficient statistics resources. 2910 6.3 Event Message 2912 The Event message is used to report subscriber session traffic 2913 statistics and detection information. The format of Event message is 2914 as follows: 2916 ::= 2917 [] 2918 [] 2920 6.4 Report Message 2922 The Report message is used to report board and interface status on a 2923 UP. The format of Report message is as follows: 2925 ::= 2926 [] 2927 [] 2929 6.5 CGN Messages 2931 This document defines the following resource allocation messages: 2933 Type Message Name TLV that is carried 2934 ---- ------------------- ------------------------ 2935 200 Addr_Allocation_Req Address Allocation Request 2936 201 Addr_Allocation_Ack Address Allocation Response 2937 202 Addr_Renew_Req Address Renewal Request 2938 203 Addr_Renew_Ack Address Renewal Response 2939 204 Addr_Release_Req Address Release Request 2940 205 Addr_Release_Ack Address Release Response 2942 6.5.1 Addr_Allocation_Req Message 2944 The Addr_Allocation_Req message is used to request CGN address 2945 allocation. The format of Addr_Allocation_Req message is as follows: 2947 ::= 2948
2950 6.5.2 Addr_Allocation_Ack Message 2952 The Addr_Allocation_Ack message is a response to an 2953 Addr_Allocation_Req message. The format of Addr_Allocation_Ack 2954 message is as follows: 2956 ::= 2957
2959 6.5.3 Addr_Renew_Req Message 2961 The Addr_Renew_Req message is used to request address renewal. The 2962 format of Addr_Renew_Req message is as follows: 2964 ::= 2965
2967 6.5.4 Addr_Renew_Ack Message 2969 The Addr_Renew_Ack message is a response to an Addr_Renew_Req 2970 message. The format of Addr_Renew_Req message is as follows: 2972 ::= 2973
2975 6.5.5 Addr_Release_Req Message 2977 The Addr_Release_Req message is used to request address release. The 2978 format of Addr_Release_Req message is as follows: 2980 ::= 2981
2983 6.5.6 Addr_Release_Ack Message 2985 The Addr_Release_Ack message is a response to an Addr_Release_Req 2986 message. The format of Addr_Release_Ack message is as follows: 2988 ::= 2989
2991 6.6 Vendor Message 2993 The Vendor message is, in conjunction with the vendor TLV and vendor 2994 sub-TLV, can be used by vendors to extend the S-CUSP protocol. It's 2995 message type is 11. If the receiver does not recognize the message, 2996 an Error message will be returned to the sender. 2998 The format of the Vendor message is as follows: 3000 ::= 3001 3002 [] 3004 6.7 Error Message 3006 The Error message is defined to return some critical error 3007 information to the sender. If a receiver does not know the message 3008 type of a received message, it MUST return an Error message to the 3009 sender. 3011 The format of the Error message is as below: 3013 ::= 3014 3016 7. S-CUSP TLVs and Sub-TLVs 3018 This section specifies the following: 3020 o the format of the TLVs that appear in S-CUSP messages, 3022 o the format of the sub-TLVs that appear within the values of some 3023 TLVs, and 3025 o the format of some basic data fields that appear within TLVs or 3026 sub-TLVs. 3028 See Section 9 for a list of all defined TLVs and sub-TLVs. 3030 7.1 Common TLV Header 3032 S-CUSP messages consist of the common header specified in Section 6.1 3033 followed by TLVs formatted as specified in this section. 3035 0 1 2 3 3036 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 3037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3038 | Oper | TLV-Type | TLV-Length | 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3040 ~ Value ~ 3041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3043 Figure 32: Common TLV Header 3045 o Oper (4 bits): For Message-Types that indicate an operation on a 3046 data set, the Oper field is interpreted as Update, Delete, or 3047 Reserved as specified in Section 9.3. For all other Message-Types, 3048 the Oper field MUST be sent as zero and ignored on receipt. 3050 o TLV-Type (12 bits): The Type of a TLV, that is the meaning and 3051 format of the Value part, are determined by the TLV-Type of the 3052 TLV. See Section 9.2. 3054 o TLV-Length (2 bytes): The length of the Value portion of the TLV 3055 in bytes as an unsigned integer. 3057 o Value (variable length): This is the value portion of the TLV 3058 whose size is given by TLV-Length. The value portion consists of 3059 fields, frequently using one of the basic data field types (see 3060 Section 7.2) and sub-TLVs (see Section 7.3). 3062 7.2 Basic Data Fields 3064 This section specifies the binary format of several standard basic 3065 data fields that are used within other data structures in this 3066 specification. 3068 o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section 3069 7.3) to provide the length. The use of this data type in S-CUSP is 3070 to provide convenient labels for use by network operators in 3071 configuring and debugging their networks and interpreting S-CUSP 3072 messages. These labels will not normally be seen by subscribers. 3073 They are normally interpreted as ASCII [RFC20]. 3075 o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042]. 3077 o IPv4-Address: 8 octets. 4 octets of the IPv4 address value 3078 followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX. 3080 o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4 3081 octet integer n in the range of 0 to 128 which gives the address 3082 mask as the one's complement of 2**(128-n) - 1. 3084 o VLAN ID: 2 octets. As follows [802.1Q]: 3086 0 1 3087 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3089 | PRI |D| VLAN-ID | 3090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3092 PRI: Priority. Default value 7. 3094 D: Drop Eligibility Indicator (DEI). Default value 0. 3096 VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are 3097 not valid VLAN IDs [802.1Q].) 3099 7.3 Sub-TLV Format and Sub-TLVs 3101 In some cases, the Value portion of a TLV, as specified above, can 3102 contain one or more Sub-TLVs formatted as follows: 3104 0 1 2 3 3105 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 3106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 | Type | Length | 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 | Value | 3110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 3112 Figure 33: Sub-TLV Header 3114 o Type (2 bytes): The Type of a Sub-TLV, that is the meaning and 3115 format of the Value part, are determined by the Type of the 3116 TLV. Sub-TLV Types numbers have the same meaning regardless of 3117 the TLV Type of the TLV within which the sub-TLV occurs. See 3118 Section 9.4. 3120 o Length (2 bytes): The length of the Value portion of the sub- 3121 TLV in bytes as an unsigned integer. 3123 o Value (variable length): This is the value portion of the sub- 3124 TLV whose size is given by Length. 3126 The sub-TLVs currently specified are defined in the following 3127 subsections. 3129 7.3.1 Name sub-TLVs 3131 This document defines the following name sub-TLVs that are used to 3132 carry the name of the corresponding object. The length of each of 3133 these sub-TLV is variable from 1 to 255 octets. The value is of type 3134 STRING padded with zeros octets to 4-octet alignment. 3136 Type Sub-TLV Name Meaning 3137 ----- -------------------- ------------------- 3138 1 VRF-Name The name of a VRF 3139 2 Ingress-QoS-Profile The name of an ingress QoS profile 3140 3 Egress-QoS-Profile The name of an egress QoS profile 3141 4 User-ACL-Policy The name of an ACL policy 3142 5 Multicast-ProfileV4 The name of an IPv4 multicast profile 3143 6 Multicast-ProfileV6 The name of an IPv6 multicast profile 3144 7 NAT-Instance The name of a NAT instance 3145 8 Pool-Name The name of an address pool 3147 7.3.2 Ingress-CAR sub-TLV 3149 The Ingress-CAR sub-TLV indicates the authorized upstream Committed 3150 Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR 3151 sub-TLV is 9 and the sub-TLV length is 16. The format is as shown in 3152 Figure 34. 3154 0 1 2 3 3155 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 3156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3157 | CIR (Committed Information Rate) | 3158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 | PIR (Peak Information Rate) | 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 | CBS (Committed Burst Size) | 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 | PBS (Peak Burst Size) | 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 Figure 34: Ingress-CAR sub-TLV 3168 Where: 3170 CIR (4 bytes): Guaranteed rate in bits/second. 3172 PIR (4 bytes): Burst rate in bits/second. 3174 CBS (4 bytes): The token bucket in bytes. 3176 PBS (4 bytes): Burst token bucket in bytes. 3178 These fields are unsigned integers. More details about CIR, PIR, CBS, 3179 and PBS can be found in [RFC2698]. 3181 7.3.3 Egress-CAR sub-TLV 3183 The Egress-CAR sub-TLV indicates the authorized downstream Committed 3184 Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub- 3185 TLV is 10 and its sub-TLV length is 16 octets. The format of the 3186 value part is as defined below. 3188 0 1 2 3 3189 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 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 | CIR (Committed Information Rate) | 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3193 | PIR (Peak Information Rate) | 3194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3195 | CBS (Committed Burst Size) | 3196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3197 | PBS (Peak Burst Size) | 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 Figure 35: Egress-CAR sub-TLV 3202 Where: 3204 CIR (4 bytes): Guaranteed rate in bits/second. 3206 PIR (4 bytes): Burst rate in bits/second. 3208 CBS (4 bytes): The token bucket in bytes. 3210 PBS (4 bytes): Burst token bucket in bytes. 3212 These fields are unsigned integers. More details about CIR, PIR, CBS, 3213 and PBS can be found in [RFC2698]. 3215 7.3.4 If-Desc sub-TLV 3217 The If-Desc sub-TLV is defined to designate an interface. It is an 3218 optional sub-TLV that may be carried in those TLVs that have an "if- 3219 index" or "out-if-index" field. The If-Desc sub-TLV is used as a 3220 local unique identifier within a BNG. 3222 The sub-TLV type is 11 and the sub-TLV length is 12 octets. The 3223 format depends on the If-Type. The format of the value part is as 3224 follows: 3226 0 1 2 3 3227 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 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | If-Type (1-5)| Chassis | Slot | 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 | Sub-Slot | Port Number | 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 | Sub-Port Number | 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 If-Desc sub-TLV (Physical Port) 3237 0 1 2 3 3238 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 3239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3240 | If-Type (6-7) | Reserved | 3241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3242 | Logic-ID | 3243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 | Sub-Port Number | 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 If-Desc sub-TLV (Virtual Port) 3248 Figure 36: If-Desc sub-TLV Formats 3250 Where: 3252 If-Type: 8 bits in length, indicates the type of an interface. 3253 Following types are defined in this document: 3255 0: Reserved 3256 1: Fast Ethernet (FE) 3257 2: GE 3258 3: 10GE 3259 4: 100GE 3260 5: Eth-Trunk 3261 6: Tunnel 3262 7: VE 3263 8-255: Reserved. 3265 Chassis (8 bits): Identifies the chassis that the interface 3266 belongs to. 3268 Slot (16 bits): Identifies the slot that the interface belongs to. 3270 Sub-slot (16 bits): Identifies the sub-slot the interface belongs 3271 to. 3273 Port Number (16 bits): An identifier of a physical port/interface 3274 (e.g., If-Type: 1-5). It is locally significant within the 3275 slot/sub-slot. 3277 Sub-port Number (32 bits): An identifier of the sub-port. Locally 3278 significant within its "parent" port (physical or virtual). 3280 Logic-ID (32 bits): An identifier of a virtual interface (e.g., 3281 If-Type: 6-7) 3283 7.3.5 IPv6 Address List sub-TLV 3285 The IPv6 Address List sub-TLV is used to convey one or more IPv6 3286 addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV 3287 type is 12, the sub-TLV length is variable. 3289 The format of IPv6 Addresses sub-TLV is as follows: 3291 0 1 2 3 3292 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 3293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 ~ IPv6 Address ~ 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3296 ~ IPv6 Address ~ 3297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 ~ ... ~ 3299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3300 ~ IPv6 Address ~ 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3303 Figure 37: IPv6 Address List sub-TLV 3305 Where: 3307 IP Address (IPv6-Address): Each IP Address is an IP-Address type, 3308 carries an IPv6 address. 3310 7.3.6 Vendor sub-TLV 3312 The Vendor sub-TLV is intended to be used inside the value portion of 3313 the Vendor TLV (Section 7.13). It provides a Sub-Type that 3314 effectively extends the sub-TLV type in the sub-TLV header and 3315 provides for versioning of vendor sub-TLVs. 3317 The value part of the Vendor sub-TLV is formatted as follows: 3319 0 1 2 3 3320 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 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 | Vendor ID | 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | Sub-Type | Sub-Type-Version | 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 ~ value (other as specified by vendor) ~ 3327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3329 Figure 38: Vendor sub-TLV 3331 Where: 3333 The sub-TLV type: 13. 3335 The sub-TLV length: variable. 3337 Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865]. 3339 Sub-Type (2 bytes): Used by the Vendor to distinguish multiple 3340 different sub-TLVs. 3342 Sub-Type-Version (2 bytes): Used by the Vendor to distinguish 3343 different versions of a Vendor Defined sub-TLV sub-Type. 3345 value: as specified by the vendor. 3347 Since Vendor code will be handling the sub-TLV after the Vendor ID 3348 field is recognized, the remainder of the sub-TLV can be organized 3349 however the vendor wants. But it desirable for a vendor to be able to 3350 define multiple different vendor sub-TLVs and to keep track of 3351 different versions of its vendor defined sub-TLVs. Thus, it is 3352 RECOMMENDED that the vendor assign a Sub-Type value for each of that 3353 vendor's sub-TLVs that is different from other Sub-Type values that 3354 vendor has used. Also, when modifying a vendor defined sub-TLV in a 3355 way potentially incompatible with a previous definition, the vendor 3356 SHOULD increase the value it is using in the Sub-Type-Version field. 3358 7.4 The Hello TLV 3360 The Hello TLV is defined to be carried in the Hello message for 3361 version and capabilities negotiation. It indicates the S-CUSP sub- 3362 version and capabilities supported. The format of Hello TLV is as 3363 follows: 3365 0 1 2 3 3366 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 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 | VerSupported | 3369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3370 | Vendor ID | 3371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3372 | Capabilities | 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3375 Figure 39: Hello TLV 3377 Where: 3379 The TLV type is 100. 3381 The TLV length is 12 octets. 3383 The value field consists of three parts: 3385 VerSupported: 32 bits in length. This is a bit map of the Sub- 3386 Versions of the S-CUSP protocol that the sender supports. This 3387 document specifies Sub-Version zero of Major Version 1, that 3388 is, Version 1.0. The VerSupported field MUST be non-zero. The 3389 VerSupported bits are numbered from 0 as the most significant 3390 bit. Bit 0 indicates support of Sub-Version zero, bit 1 3391 indicates support of Sub-Version one, etc. 3393 Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS 3394 [RFC2865]. 3396 Capabilities: 32 bits in length. Flags that indicate the 3397 support of particular capabilities by the sender of the Hello. 3398 No Capabilities are defined in this document and so 3399 implementations will set this field to zero. The Capabilities 3400 field of the Hello TLV MUST be checked before any other TLVs in 3401 the Hello because capabilities defined in the future might 3402 extend existing TLVs or permit new TLVs. 3404 After the exchange of Hello messages, the CP and UP each perform a 3405 logical AND of the Sub-Version supported by the CP and the UP and 3406 separately perform a logical AND of the Capabilities bits fields for 3407 the CP and the UP. 3409 If the result of the AND of the Sub-Versions supported is zero, then 3410 no session can be established and the connection is torn down. If the 3411 result of the AND of the Sub-Versions supported is non-zero, then the 3412 session uses the highest Sub-Version supported by both the CP and UP. 3414 For example, if one side supports Sub-Versions 1, 3, 4, and 5 3415 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 3416 (VerSupported = 0x38000000) then 3 and 4 are the Sub-Versions in 3417 common and 4 is the highest Sub-Version supported by both sides. So 3418 Sub-Version 4 is used for the session that has been negotiated. 3420 The result of the logical AND of the Capabilities bits will show what 3421 additional capabilities both sides support. If this result is zero, 3422 there are no such capabilities so none can be used during the 3423 session. If this result is non-zero, it shows the additional 3424 capabilities that can be used during the session. The CP and the UP 3425 MUST NOT use a capability unless both advertise support. 3427 7.5 The Keep Alive TLV 3429 The Keep Alive TLV is defined to be carried in the Hello message. It 3430 provides timing information for the keep alive feature. The format 3431 of Hello TLV is as follows: 3433 0 1 2 3 3434 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 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | Keepalive | DeadTimer | Reserved | 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3439 Figure 40: Keep Alive TLV 3441 Where: 3443 The TLV type: 102. 3445 The value of length: 4 octets. 3447 Keepalive (8 bits): Indicates the maximum period of time (in 3448 seconds) between two consecutive S-CUSP messages sent by the 3449 sender of the message containing this TLV as an unsigned integer. 3450 The minimum value for the Keepalive is 1 second. When set to 0, 3451 once the session is established, no further Keepalive messages are 3452 sent to the remote peer. A RECOMMENDED value for the Keepalive 3453 frequency is 30 seconds. 3455 DeadTimer (8 bits in length): Specifies the amount of time as an 3456 unsigned integer number of seconds after the expiration of which 3457 the S-CUSP peer can declare the session with the sender of the 3458 Hello message to be down if no S-CUSP message has been received. 3459 The DeadTimer SHOULD be set to 0 and MUST be ignored if the 3460 Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 3461 times the value of the Keepalive. 3463 The Reserved bits MUST be sent as zero and ignored on receipt. 3465 7.6 The Error Information TLV 3467 The Error Information TLV is a common TLV that can be used in many 3468 Response (e.g., Update_Response message) and ACK messages (e.g., 3469 Addr_Allocation_Ack message, etc.). It is used to convey the 3470 information about an error in the received S-CUSP message. The 3471 format of the Error Information TLV is as follows: 3473 0 1 2 3 3474 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 3475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3476 | Message-Type | Reserved | TLV-Type | 3477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3478 | Error Code | 3479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3481 Figure 41: Error Information TLV 3483 Where: 3485 The TLV type: 101. 3487 The value of length: 8 octets. 3489 Message-Type(1 byte): This parameter is the message type of the 3490 message containing an error. 3492 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3494 TLV-Type (2 bytes): Indicates which TLV caused the error. 3496 Error Code: 4 bytes in length. Indicate the specific Error Code 3497 (see Section 9.5). 3499 7.7 BAS Function TLV 3501 The BAS Function TLV is used by a CP to control the access mode, 3502 authentication methods, and other related functions of an interface 3503 on a UP. 3505 The format of the BAS Function TLV value part is as follows: 3507 0 1 2 3 3508 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 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3510 | If-Index | 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3512 | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 | Flags | 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 | sub-TLVs (optional) | 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3519 Figure 42: BAS Function TLV 3521 Where: 3523 The TLV type: 1. 3525 The value of length: variable. 3527 If-Index: 4 bytes in length, a unique identifier of an interface 3528 of a BNG. 3530 Access-Mode: 1 byte in length, indicates the access mode of the 3531 interface. This document defines following values: 3533 0: Layer 2 subscriber; 3534 1: Layer 3 subscriber; 3535 2: Layer 2 leased line; 3536 3: Layer 3 leased line; 3537 4-255: Reserved. 3539 Auth-Method4: 1 byte in length, for IPv4 scenario, it indicates 3540 the authentication on this interface; this field is defined as a 3541 bitmap, this document defines following values (other bits are 3542 reserved and MUST be sent as zero and ignored on receipt): 3544 0x1: PPPoE authentication; 3545 0x2: DOT1X authentication; 3546 0x4: Web authentication; 3547 0x8: Web fast authentication; 3548 0x10: Binding authentication. 3550 Auth-Method6: 1 byte in length, for IPv6 scenario, it indicates 3551 the authentication on this interface; this field is defined as a 3552 bitmap, this document defines following values (other bits are 3553 reserved and MUST be sent as zero and ignored on receipt): 3555 0x1: PPPoE authentication; 3556 0x2: DOT1X authentication; 3557 0x4: Web authentication; 3558 0x8: Web fast authentication; 3559 0x10: Binding authentication; 3561 sub-TLVs: 3562 The IF-Desc sub-TLV can be carried. 3563 If-Desc sub-TLV: carries the interface information. 3565 The flags field is defined as follows: 3567 0 1 2 3 3568 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 3569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3570 | MBZ |Y|X|P|I|N|A|S|F| 3571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3573 Figure 43: Interface Flags 3575 Where: 3577 F (IPv4 Trigger) bit: Indicates whether IPv4 packets can 3578 trigger a subscriber to go online. 1: enabled, 0: disabled. 3580 S (IPv6 Trigger) bit: Indicates whether IPv6 packets can 3581 trigger a subscriber to go online. 1: enabled, 0: disabled. 3583 A (ARP Trigger) bit: Indicates whether ARP packets can trigger 3584 a subscriber to go online. 1: enabled, 0: disabled. 3586 N (ND Trigger) bit: Indicates whether ND packets can trigger a 3587 subscriber to go online. 1: enabled, 0: disabled. 3589 I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable 3590 traffic detection. 0: Disable traffic detection. 3592 P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable 3593 traffic detection. 0: Disable traffic detection. 3595 X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy 3596 and can process ARP requests across different Port+VLANs. 0: 3597 The ARP proxy is not enabled on the interface, and only the ARP 3598 requests of the same Port+VLAN are processed. 3600 Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and 3601 can process ND requests across different Port+VLANs. 0: The ND 3602 proxy is not enabled on the interface, and only the ND requests 3603 of the same Port+VLAN are processed. 3605 MBZ: Reserved bits that MUST be sent as zero and ignored on 3606 receipt. 3608 7.8 Routing TLVs 3610 Normally, after an S-CUSP session is established between a UP and a 3611 CP, the CP will allocate one or more blocks of IP addresses to the 3612 UP. Those IP addresses will be allocated to subscribers who will 3613 dial-up to the UP. In order to make sure that other nodes within the 3614 network learn how to reach those IP addresses, the CP needs to 3615 install one or more routes that can reach those IP addresses on the 3616 UP and notify the UP to advertise the routes to the network. 3618 The Routing TLVs are used by a CP to notify a UP of the network 3619 routing. They can be carried in the Update_Request message and 3620 Sync_Data message. 3622 7.8.1 IPv4 Routing TLV 3624 The IPv4 Routing TLV is used to carry IPv4 network routing related 3625 information. 3627 The format of the TLV value part is as below: 3629 0 1 2 3 3630 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 3631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3632 | User ID | 3633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3634 | Dest-Address | 3635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3636 | Next-Hop | 3637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3638 | Out-If-Index | 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 | Cost | 3641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3642 | Tag | 3643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3644 | Route Type | Reserved |A| 3645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3646 ~ sub-TLVs (optional) ~ 3647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 Figure 44: IPv4 Routing TLV 3651 Where: 3653 The TLV Type: 7 3655 The TLV Length: Variable 3657 User-ID: 4 bytes in length. Carries the user identifier. This 3658 field is filled with all Fs when a non-user route is delivered to 3659 the UP. 3661 Dest-Address (IPv4-Address type): Identifies the destination 3662 address. 3664 Next-Hop: (IPv4-Address type): Identifies the next hop address. 3666 Out-If-Index (4 bytes): Indicates the interface index. 3668 Cost (4 bytes): The cost value of the route. 3670 Tag (4 bytes): The tag value of the route. 3672 Route-Type (2 bytes): Indicates the route type. The options are 3673 as follows: 3675 0: User host route 3676 1: Radius authorization FrameRoute 3677 2: Network segment route 3678 3: Gateway route 3679 4: Radius authorized IP route 3680 5: L2TP LNS side user route 3682 Advertise-Flag: 1 bit. Indicates whether the route should be 3683 advertised by the UP. Following flags are defined: 3684 0: Not advertised, 3685 1: advertised. 3687 sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried. 3688 VRF-Name sub-TLV: indicates which VRF the route belongs to. 3689 If-Desc sub-TLV: carries the interface information. 3691 The Reserved field MUST be sent as zero and ignored on receipt. 3693 7.8.2 IPv6 Routing TLV 3695 The IPv6 Routing TLV is used to carry IPv6 network routing 3696 information. 3698 The format of this TLV is as follows: 3700 0 1 2 3 3701 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 3702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3703 | User ID | 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3705 ~ IPv6 Dest-Address ~ 3706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3707 ~ IPv6 Next-Hop ~ 3708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3709 | Out-If-Index | 3710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3711 | Cost | 3712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3713 | Tag | 3714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3715 | Route Type | Reserved |A| 3716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3717 ~ sub-TLVs (optional) ~ 3718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3720 Figure 45: IPv6 Routing TLV 3722 Where: 3724 The TLV Type: 7 3726 The TLV Length: Variable 3728 User-ID: 4 bytes in length. Carries the user identifier. This 3729 field is filled with all Fs when a non-user route is delivered to 3730 the UP. 3732 IPv6 Dest-Address (IPv6-Address type): Identifies the destination 3733 address. 3735 IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop 3736 address. 3738 Out-If-Index (4 bytes): Indicates the interface index. 3740 Cost (4 bytes): The cost value of the route. 3742 Tag (4 bytes): The tag value of the route. 3744 Route-Type: (2 bytes): Indicates the route type. The options are 3745 as follows: 3747 0: User host route 3748 1: Radius authorization FrameRoute 3749 2: Network segment route 3750 3: Gateway route 3751 4: Radius authorized IP route 3752 5: L2TP LNS side user route 3754 Advertise-Flag: 1 bit. Indicates whether the route should be 3755 advertised by the UP. Following flags are defined: 3756 0: Not advertised, 3757 1: advertised. 3759 sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried. 3760 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3761 belongs. 3762 If-Desc sub TLV: carries the interface information. 3764 The Reserved field MUST be sent as zero and ignored on receipt. 3766 7.9 Subscriber TLVs 3768 The Subscriber TLVs are defined for a CP to send the basic 3769 information about a user to a UP. 3771 7.9.1 Basic Subscriber TLV 3773 The Basic Subscriber TLV is used to carry the basic common 3774 information for all kinds of access subscribers. It is carried in an 3775 Update_Request message. 3777 The format of the Basic Subscriber TLV value part is as follows: 3779 0 1 2 3 3780 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 3781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3782 | User ID | 3783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3784 | Session ID | 3785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 | User MAC | 3787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3788 | User MAC | Oper ID | Reserved | 3789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3790 | Access Type |Sub-access Type| Account Type | Address Family| 3791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3792 | C-VID | P-VID | 3793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3794 | Detect Times | Detect Interval | 3795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3796 | If-Index | 3797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3798 ~ sub-TLVs (optional) ~ 3799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3801 Figure 46: Basic Subscriber TLV 3803 Where: 3805 The TLV Type: 2. 3807 The TLV Length: variable in length. 3809 User-ID (4 bytes): The identifier of a subscriber. 3811 Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero 3812 means non-PPPoE subscriber. 3814 User-Mac (MAC-Addr type): The MAC Address of a subscriber. 3816 Oper-ID (1 byte): Indicates the ID of an operation performed by a 3817 user. This field is carried in the response from the UP. 3819 Reserved (1 byte): MUST be sent as zero and ignored on receipt. 3821 Access-Type (1 byte): 3823 1: PPP access (PPP [RFC1661]) 3824 2: PPP over Ethernet over ATM access (PPPoEoA) 3825 3: PPP over ATM access (PPPoA [RFC3336]) 3826 4: PPP over Ethernet access (PPPoE [RFC2516]) 3827 5: PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) 3828 6: PPP over LNS access (PPPoLNS) 3829 7: IP over Ethernet DHCP access (IPoE_DHCP) 3830 8: IP over Ethernet EAP authentication access (IPoE_EAP) 3831 9: IP over Ethernet Layer 3 access (IPoE_L3) 3832 10: IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) 3833 11: Layer 2 Leased Line access (L2_Leased_Line) 3834 12: Layer 2 VPN Leased Line access (L2VPN_Leased_Line) 3835 13: Layer 3 Leased Line access (L3_Leased_Line) 3836 14: Layer 2 Leased line Sub-User access 3837 (L2_Leased_Line_SUB_USER) 3838 15: L2TP LAC tunnel access (L2TP_LAC) 3839 16: L2TP LNS tunnel access (L2TP_LNS) 3841 Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP 3842 relay is used. 3843 0: Reserved 3844 1: PPP Relay (for LAC) 3845 2: PPP termination (for LNS) 3847 Account-Type(1 byte): 3848 0: Collects statistics on IPv4 and IPv6 traffic of terminals 3849 independently. 3850 1: Collects statistics on IPv4 and IPv6 traffic of terminals. 3852 Address Family (1 byte) 3853 1: IPv4 3854 2: IPv6 3855 3: dual stack 3857 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 3858 indicates that the VLAN ID is invalid. The default value of PRI 3859 is 7, the value of DEI is 0, and the value of VID is 1~4094. The 3860 PRI value can also be obtained by parsing terminal packets. 3862 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 3863 indicates that the VLAN ID is invalid. The format is the same as 3864 that for C-VID. 3866 Detect-Times (2 bytes): Number of detection timeout times. The 3867 value 0 indicates that no detection is performed. 3869 Detect-Interval (2 bytes): Detection interval in seconds. 3871 If-Index (4 bytes): Interface index. 3873 Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried. 3874 VRF-Name sub-TLV: Indicates the VRF to which the subscriber 3875 belongs. 3876 If-Desc sub-TLV: carries the interface information. 3878 The Reserved field MUST be sent as zero and ignored on receipt. 3880 7.9.2 PPP Subscriber TLV 3882 The PPP Subscriber TLV is defined to carry PPP information of a User 3883 from a CP to a UP. It will be carried in an Update_Request message 3884 when PPPoE or L2TP access is used. 3886 The format of the TLV value part is as follows: 3888 0 1 2 3 3889 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 3890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3891 | User ID | 3892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3893 | MSS | Reserved |M| 3894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3895 | MRU | Reserved | 3896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3897 | Magic Number | 3898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3899 | Peer Magic Number | 3900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3902 Figure 47: PPP Subscriber TLV 3904 Where: 3906 The TLV type: 3. 3908 The TLV length: 12 octets. 3910 User-ID (4 bytes): The identifier of a subscriber. 3912 MSS-Value (2 bytes): Indicates the MSS value (in bytes). 3914 MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled. 3915 0: Disabled. 3916 1: Enabled. 3918 MRU (2 bytes): PPPoE local MRU (in bytes). 3920 Magic-Number (4 bytes): Local magic number in PPP negotiation 3921 packets. 3923 Peer-Magic-Number (4 bytes): Remote peer magic number. 3925 The Reserved fields MUST be sent as zero and ignored on receipt. 3927 7.9.3 IPv4 Subscriber TLV 3929 The IPv4 Subscriber TLV is defined to carry IPv4 related information 3930 for a BNG user. It will be carried in an Update_Request message when 3931 IPv4 IPoE, or PPPoE access is used. 3933 The format of the TLV value part is as follows: 3935 0 1 2 3 3936 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 3937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3938 | User ID | 3939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3940 | User IPv4 Address | 3941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3942 | Gateway IPv4 Address | 3943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3944 | MTU | Reserved |U|E|W|P| 3945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3946 ~ VRF-Name sub-TLV ~ 3947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3949 Figure 48: IPv4 Subscriber TLV 3951 Where: 3953 The TLV type: 4. 3955 The TLV length: variable. 3957 User-ID (4 bytes): The identifier of a subscriber. 3959 User-IPv4 (IPv4-Address): The IPv4 address of the subscriber. 3961 Gateway-IPv4 (IPv4-Address): The gateway address of the 3962 subscriber. 3964 Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on. 3966 Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on. 3968 Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off, 3969 1: on. 3971 IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) 3972 flag. 0: off, 1: on. 3974 MTU 2 bytes MTU value. The default value is 1500. 3976 VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. 3978 The Reserved field MUST be sent as zero and ignored on receipt. 3980 7.9.4 IPv6 Subscriber TLV 3982 The IPv6 Subscriber TLV is defined to carry IPv6 related information 3983 for a BNG user. It will be carried in an Update_Request message when 3984 IPv6 IPoE, or PPPoE access is used. 3986 The format of the TLV value part is as follows: 3988 0 1 2 3 3989 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 3990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3991 | User ID | 3992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3993 ~ User PD-Address (IPv6 Address List sub-TLV) ~ 3994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3995 ~ Gateway ND-Address (IPv6 Address List sub-TLV) ~ 3996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3997 | User IANA Address | 3998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3999 | IPv6 Interface ID | 4000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4001 | IPv6 Interface ID (cont.) | 4002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4003 | MTU | Reserved |U|E|W|P| 4004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4005 ~ VRF Name sub-TLV (optional) ~ 4006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4008 Figure 49: IPv6 Subscriber TLV 4010 Where: 4012 The TLV type: 5. 4014 The TLV length: variable. 4016 User-ID (4 bytes): The identifier of a subscriber. 4018 User PD-Addresses (IPv6 Address List): Carries a list of Prefix 4019 Delegation (PD) addresses of the subscriber. 4021 User ND-Addresses (IPv6 Address List): Carries a list of Neighbor 4022 Discovery (ND) addresses of the subscriber. 4024 User IANA-Address (IPv6-Address): The IANA address of the 4025 subscriber. 4027 IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface. 4029 Portal Force 1 bit (P): Push advertisement, 0: off, 1: on. 4031 Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on. 4033 Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off; 4034 1: on. 4036 IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0: 4037 off; 1: on. 4039 MTU (2 bytes): The MTU value. The default value is 1500. 4041 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4042 belongs. 4044 The Reserved field MUST be sent as zero and ignored on receipt. 4046 7.9.5 IPv4 Static Subscriber Detect TLV 4048 The IPv4 Static Subscriber Detect TLV is defined to carry IPv4 4049 related information for a static access subscriber. It will be 4050 carried in an Update_Request message when IPv4 static access on a UP 4051 needs to be enabled. 4053 The format of the TLV value part is as follows: 4055 0 1 2 3 4056 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 4057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4058 | If-Index | 4059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4060 | C-VID | P-VID | 4061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4062 | User Address | 4063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4064 | Gateway Address | 4065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4066 | User MAC | 4067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4068 | User MAC (cont.) | Reserved | 4069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4070 ~ sub-TLVs (optional) ~ 4071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4073 Figure 50: IPv4 Static Subscriber TLV 4075 Where: 4077 The TLV type: 6. 4079 The TLV length: variable. 4081 If-Index (4 bytes): The interface index of the interface from 4082 which the subscriber will dial-up. 4084 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4085 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4087 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4088 indicates that the VLAN ID is invalid. The format is the same as 4089 that of the C-VID. A valid value is 1~4094. For a single-layer 4090 VLAN, set this parameter to PeVid. 4092 User Address (IPv4-Addr): The user's IPv4 address. 4094 Gateway Address (IPv4-Addr): The gateway's IPv4 Address. 4096 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4098 Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried. 4099 VRF-Name sub-TLV: Indicates the VEF to which the subscriber 4100 belongs. 4101 If-Desc sub-TLV: Carries the interface information. 4103 The Reserved field MUST be sent as zero and ignored on receipt. 4105 7.9.6 IPv6 Static Subscriber Detect TLV 4107 The IPv6 Static Subscriber Detect TLV is defined to carry IPv6 4108 related information for a static access subscriber. It will be 4109 carried in an Update_Request message when needed to enable IPv6 4110 static subscriber detection on a UP. 4112 The format of the TLV value part is as follows: 4114 0 1 2 3 4115 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 4116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4117 | If-Index | 4118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4119 | C-VID | P-VID | 4120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4121 ~ User Address ~ 4122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4123 ~ Gateway Address ~ 4124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4125 | User MAC | 4126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4127 | User MAC (cont.) | Reserved | 4128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4129 ~ sub-TLVs (optional) ~ 4130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4132 Figure 51: IPv6 Static Subscriber Detect TLV 4134 Where: 4136 The TLV type: 6. 4138 The TLV length: variable. 4140 If-Index (4 bytes): The interface index of the interface from 4141 which the subscriber will dial-up. 4143 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 4144 indicates that the VLAN ID is invalid. A valid value is 1~4094. 4146 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 4147 indicates that the VLAN ID is invalid. The format is the same as 4148 that the of C-VID. A valid value is 1~4094. For a single-layer 4149 VLAN, set this parameter to PeVid. 4151 User Address (IPv6-Address type): The subscriber's IPv6 address. 4153 Gateway Address (IPv6-Address type): The gateway's IPv6 Address. 4155 User-MAC (MAC-Addr type): The MAC address of the subscriber. 4157 sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried 4158 VRF-Name Sub-TLV: Indicates the VRF to which the subscriber 4159 belongs. 4160 If-Desc sub-TLV: Carries the interface information. 4162 The Reserved field MUST be sent as zero and ignored on receipt. 4164 7.9.7 L2TP-LAC Subscriber TLV 4166 The L2TP-LAC Subscriber TLV is defined to carry the related 4167 information for a L2TP LAC access subscriber. It will be carried in 4168 an Update_Request message when L2TP LAC access is used. 4170 The format of the TLV value part is as follows: 4172 0 1 2 3 4173 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 4174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4175 | User ID | 4176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4177 | Local Tunnel ID | Local Session ID | 4178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4179 | Remote Tunnel ID | Remote Session ID | 4180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4182 Figure 52: L2TP-LAC Subscriber TLV 4184 Where: 4186 The TLV type: 11. 4188 The TLV length: 12 octets. 4190 User-ID (4 bytes): The identifier of a user/subscriber. 4192 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4194 Local-Session-ID (2 bytes): The local session ID with the L2TP 4195 tunnel. 4197 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4199 Remote-Session-ID (2 bytes): The remote session ID of the L2TP 4200 tunnel. 4202 7.9.8 L2TP-LNS Subscriber TLV 4204 The L2TP-LNS Subscriber TLV is defined to carry the related 4205 information for a L2TP LNS access subscriber. It will be carried in 4206 an Update_Request message when L2TP LNS access is used. 4208 The format of the TLV value part is as follows: 4210 0 1 2 3 4211 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 4212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4213 | User ID | 4214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4215 | Local Tunnel ID | Local Session ID | 4216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4217 | Remote Tunnel ID | Remote Session ID | 4218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4220 Figure 53: L2TP-LNS Subscriber TLV 4222 Where: 4224 The TLV type: 12. 4226 The TLV length: 12 octets. 4228 User-ID (4 bytes): The identifier of a user/subscriber. 4230 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4232 Local-Session-ID (2 bytes): The local session ID with the L2TP 4233 tunnel. 4235 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4237 Remote-Session-ID (2 bytes): The remote session ID of the L2TP 4238 tunnel. 4240 7.9.9 L2TP-LAC Tunnel TLV 4242 The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel 4243 related information. It will be carried in the Update_Request 4244 message when L2TP LAC access is used. 4246 The format of the TLV value part is as follows: 4248 0 1 2 3 4249 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 4250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4251 | Local Tunnel ID | Remote Tunnel ID | 4252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4253 | Source Port | Destination Port | 4254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4255 ~ Tunnel Source Address ~ 4256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4257 ~ Tunnel Destination Address ~ 4258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4259 ~ VRF Name sub-TLV ~ 4260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4262 Figure 54: L2TP-LAC Tunnel TLV 4264 Where: 4266 The TLV type: 13. 4268 The TLV length: variable. 4270 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4272 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4274 Source-Port (2 bytes): The source UDP port number of an L2TP 4275 subscriber. 4277 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4278 subscriber. 4280 Source-IP (IPv4/v6): The source IP address of the tunnel. 4282 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4284 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4285 belongs. 4287 7.9.10 L2TP-LNS Tunnel TLV 4289 The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel 4290 related information. It will be carried in the Update_Request 4291 message when L2TP LNS access is used. 4293 The format of the TLV value part is as follows: 4295 0 1 2 3 4296 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 4297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4298 | Local Tunnel ID | Remote Tunnel ID | 4299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4300 | Source Port | Destination Port | 4301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4302 ~ Tunnel Source Address ~ 4303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4304 ~ Tunnel Destination Address ~ 4305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4306 ~ VRF Name sub-TLV ~ 4307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4309 Figure 55: L2TP-LNS Tunnel TLV 4311 Where: 4313 The TLV type: 14. 4315 The TLV length: variable. 4317 Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. 4319 Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. 4321 Source-Port (2 bytes): The source UDP port number of an L2TP 4322 subscriber. 4324 Dest-Port (2 bytes): The destination UDP port number of an L2TP 4325 subscriber. 4327 Source-IP (IPv4/v6): The source IP address of the tunnel. 4329 Dest-IP (IPv4/v6): The destination IP address of the tunnel. 4331 VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel 4332 belongs. 4334 7.9.11 Update Response TLV 4336 The Update Response TLV is used to return the operation result of an 4337 update request. It is carried in the Update_Response message as a 4338 response to the Update_Request message. 4340 The format of Update Response TLV is as follows: 4342 0 1 2 3 4343 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 4344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4345 | User-ID | 4346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4347 | User-Trans-ID | Oper-Code | Oper-Result | Reserved | 4348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4349 | Error-Code | 4350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4352 Figure 56: Update Response TLV 4354 Where: 4356 The TLV type: 302. 4358 The TLV length: 12. 4360 User-ID (4 bytes): A unique identifier of an user/subscriber. 4362 User-Trans-ID (1 byte): In the case of dual-stack access or when 4363 modifying a session, User-Trans-ID is used to identify a user 4364 operation transaction. It is used by the CP to correlate a 4365 response to a specific request. 4367 Oper-Code (1 byte): Operation code. 1: update, 2: delete. 4369 Oper-Result (1 byte): Operation Result. 0: Success, Others: 4370 Failure. 4372 Error-Code (4 bytes): Operation failure cause code. for details, 4373 see Section 9.5. 4375 The Reserved field MUST be sent as zero and ignored on receipt. 4377 7.9.12 Subscriber Policy TLV 4379 The Subscriber Policy TLV is used to carry the policies that will be 4380 applied to a subscriber. It is carried in the Update_Request 4381 message. 4383 The format of the TLV value part is as follows: 4385 0 1 2 3 4386 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 4387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4388 | User ID | 4389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4390 | I-Priority | E-Priority | Reserved | 4391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4392 ~ sub-TLVs ~ 4393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4395 Figure 57: User QoS Policy Information TLV 4397 Where: 4399 The TLV type: 6. 4401 The TLV length: variable. 4403 User-ID (4 bytes): The identifier of a user/subscriber. 4405 Ingress-Priority (1 byte): Indicates the upstream priority. The 4406 value range is 0~7. 4408 Egress-Priority (1 byte): Indicates the downstream priority. The 4409 value range is 0~7. 4411 sub-TLVs: The sub-TLVs that are present can occur in any order. 4413 Ingress-CAR sub-TLV: Upstream CAR. 4415 Egress-CAR sub-TLV: Downstream CAR. 4417 Ingress-QoS-Profile sub-TLV: Indicates the name of the QoS- 4418 Profile profile in the upstream direction. 4420 Egress-QoS-Profile Sub-TLV: Indicates the name of the QoS- 4421 Profile profile in the downstream direction. 4423 User-ACL-Policy Sub-TLV: All ACL user policies, including 4424 v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, 4425 v4SpecialACL, and v6SpecialACL. 4427 Multicast-Profile4 Sub-TLV: IPv4 multicast policy name. 4429 Multicast-Profile6 Sub-TLV: IPv6 multicast policy name. 4431 NAT-Instance Sub-TLV: Indicates the instance ID of a NAT user. 4433 The Reserved field MUST be sent as zero and ignored on receipt. 4435 7.9.13 Subscriber CGN Port Range TLV 4437 The Subscriber CGN Port Range TLV is used to carry the NAT public 4438 address and port range. It will be carried in the Update_Response 4439 message when CGN is used. 4441 The format of this TLV is as follows: 4443 0 1 2 3 4444 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 4445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4446 | User ID | 4447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4448 | NAT-Port-Start | NAT-Port-End | 4449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4450 | NAT-Address | 4451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4453 Figure 58: Subscriber CGN Port Range TLV 4455 Where: 4457 The TLV type: 15. 4459 The TLV length: 12 octets. 4461 User-ID (4 bytes): The identifier of a user/subscriber. 4463 NAT-Port-Start (2 bytes): The start port number. 4465 NAT-Port-End (2 bytes): The end port number. 4467 NAT-Address (4 bytes): The NAT public network address. 4469 7.10 Device Status TLVs 4471 The TLVs in this section are for reporting Interface and Board level 4472 information from the UP to the CP. 4474 7.10.1 Interface Status TLV 4476 The Interface Status TLV is used to carry the status information of 4477 an interface on a UP. It is carried in a Report message. 4479 The format of the value part of this TLV is as follows: 4481 0 1 2 3 4482 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 4483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4484 | If-Index | 4485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4486 | MAC Address (upper part) | 4487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4488 | MAC Address (lower part) | Phy-State | Reserved | 4489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4490 | MTU | 4491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4492 | sub-TLVs (optional) | 4493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4495 Figure 59: Interface Status TLV 4497 Where: 4499 The TLV type: 200. 4501 The TLV length: variable. 4503 If-Index (4 bytes): Indicates the interface index. 4505 MAC-Address (MAC-Addr type): Interface MAC address. 4507 Phy-State (1 byte): Physical status of the interface. 0: down, 1: 4508 Up 4510 MTU (4 bytes): Interface MTU value. 4512 sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried. 4514 The Reserved field MUST be sent as zero and ignored on receipt. 4516 7.10.2 Board Status TLV 4518 The Board Status TLV is used to carry the status information of a 4519 board on an UP. It is carried in a Report message. 4521 The format of Board Status TLV is as follows: 4523 0 1 2 3 4524 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 4525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4526 | Board-Type | Board-State | Reserved | Chassis | 4527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4528 | Slot | Reserved | 4529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4531 Figure 60: Interface Resource TLV 4533 Where: 4535 The TLV type: 201. 4537 The TLV length: 8 octets. 4539 Chassis (1 byte): The chassis number of the Board. 4541 Slot (1 byte): The slot number of the Board. 4543 Sub-Slot (1 byte): The sub-slot number of the Board. 4545 Board-Type (1 byte): 4546 1: CGN Service Process Unit (SPU) board. 4547 2: Line Process Unit (LPU) Board. 4549 Board-State (1 byte): 4550 0: Normal. 4551 1: Abnormal. 4553 The reserved field MUST be sent as zero and ignored on receipt. 4555 7.11 CGN TLVs 4557 7.11.1 Address Allocation Request TLV 4559 The Address Allocation Request TLV is used to request address 4560 allocation from CP. An address Pool-Name sub-TLV is carried to 4561 indicate from which address pool to allocate addresses. The Address 4562 Allocation Request TLV is carried in the Addr_Allocation_Req message. 4564 The format of the value part of this TLV is as follows: 4566 0 1 2 3 4567 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 4568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4569 ~ Pool-Name sub-TLV ~ 4570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4572 Figure 61: Address Allocation Request TLV 4574 Where: 4576 The TLV type: 400. 4578 The TLV length: variable. 4580 Pool-Name sub-TLV: Indicates from which Address pool to allocate 4581 address. 4583 7.11.2 Address Allocation Response TLV 4585 The Address Allocation Response TLV is used to return the address 4586 allocation result, it is carried the Addr_Allocation_Ack message. 4588 The value part of the Address Allocation Response TLV is formatted as 4589 follows: 4591 0 1 2 3 4592 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 4593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4594 | Lease Time | 4595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4596 | IPv4 Addr and Mask | 4597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4598 | IPv4 Addr and Mask continued | 4599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4600 | Error-Code | 4601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4602 ~ Pool-Name sub-TLV ~ 4603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4605 Figure 62: Address Assignment Response TLV 4607 Where: 4609 The TLV type: 401. 4611 The TLV length: variable. 4613 Lease Time (4 bytes): Duration of address lease in seconds. 4615 IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4 4616 address. 4618 Error-Code (4 bytes): Indicates success or an error. 4620 0: Success. 4622 1: Failure. 4624 3001 (Pool-Mismatch): The corresponding address pool cannot be 4625 found. 4627 3002 (Pool-Full): The address pool is fully allocated and no 4628 address segment is available. 4630 Pool-Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4631 Address pool the address is allocated. 4633 7.11.3 Address Renewal Request TLV 4635 The Address Renewal Request TLV is used to request address renewal 4636 from the CP. It is carried the Addr_Renew_Req message. 4638 The format of this TLV value is as follows: 4640 0 1 2 3 4641 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4643 | IPv4 Address and Mask | 4644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4645 | IPv4 Address and Mask continued | 4646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4647 ~ Pool-Name sub-TLV ~ 4648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4650 Figure 63: Address Renewal Request TLV 4652 Where: 4654 The TLV type: 402. 4656 The TLV length: variable. 4658 IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed. 4660 Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which 4661 Address pool to renew the address. 4663 7.11.4 The Address Renewal Response TLV 4665 The Address Renewal Response TLV is used to return the address 4666 renewal result. It is carried in the Addr_Renew_Ack message. 4668 The format of this TLV value is as follows: 4670 0 1 2 3 4671 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 4672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4673 | IPv4 Address and Mask | 4674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4675 | IPv4 Address and Mask continued | 4676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4677 | Error-Code | 4678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4679 ~ Pool-Name sub-TLV ~ 4680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4682 Figure 64: Address Renewal Response TLV 4684 Where: 4686 The TLV type: 403. 4688 The TLV length: variable. 4690 Client-IP (IPv4-Address type): The renewed IPv4 address. 4692 Error Code (4 bytes): Indicates success or an error: 4694 0: Renew success. 4696 1: Renew failed. 4698 3001 (Pool-Mismatch): The corresponding address pool cannot be 4699 found. 4701 3002 (Pool-Full): The address pool is fully allocated and no 4702 address segment is available. 4704 3003 (Subnet-Mismatch): The address pool subnet cannot be 4705 found. 4707 3004 (Subnet-Conflict): Subnets in the address pool have been 4708 assigned to other clients. 4710 Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4711 Address pool to renew the address. 4713 7.11.5 Address Release Request TLV 4715 The Address Release Request TLV is used to release an IPv4 address. 4716 It is carried in the Addr_Release_Req message. 4718 The value part of this TLV is formatted as follows: 4720 0 1 2 3 4721 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 4722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4723 | IPv4 Address and Mask | 4724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4725 | IPv4 Address and Mask continued | 4726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4727 ~ Pool-Name sub-TLV ~ 4728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4730 Figure 65: Address Release Request TLV 4732 Where: 4734 The TLV type: 404. 4736 The TLV length: variable. 4738 IPv4 Address and Mask (IPv4-Address type): The IPv4 address be 4739 released. 4741 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4742 Address pool to release the address. 4744 7.11.6 The Address Release Response TLV 4746 The Address Release Response TLV is used to return the address 4747 release result. It is carried in the Addr_Release_Ack message. 4749 The format of this TLV is as follows: 4751 0 1 2 3 4752 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 4753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4754 | IPv4 Address and Mask | 4755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4756 | IPv4 Address and Mask continued | 4757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4758 | Error-Code | 4759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 ~ Pool-Name sub-TLV ~ 4761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4763 Figure 66: Address Renewal Response TLV 4765 Where: 4767 The TLV type: 405. 4769 The TLV length: variable. 4771 Client-IP (IPv4-Address type): The released IPv4 address. 4773 Error-Code (4 bytes): Indicates success or an error. 4775 0: Address release success. 4777 1: Address release failed. 4779 3001 (Pool-Mismatch): The corresponding address pool cannot be 4780 found. 4782 3003 (Subnet-Mismatch): The address cannot be found. 4784 3004 (Subnet-Conflict): The address has been allocated to 4785 another subscriber. 4787 Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which 4788 address pool to release the address. 4790 7.12 Event TLVs 4791 7.12.1. Subscriber Traffic Statistics TLV 4793 The Subscriber Traffic Statistics TLV is used to return the traffic 4794 statistics of a user/subscriber. The format of this TLV is as 4795 follows: 4797 0 1 2 3 4798 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 4799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4800 | User-ID | 4801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4802 | Statistics Type | 4803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4804 | Ingress Packets (upper part) | 4805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4806 | Ingress Packets (lower part) | 4807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4808 | Ingress Bytes (upper part) | 4809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4810 | Ingress Bytes (lower part) | 4811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4812 | Ingress Loss Packets (upper part) | 4813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4814 | Ingress Loss Packets (lower part) | 4815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4816 | Ingress Loss Bytes (upper part) | 4817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4818 | Ingress Loss Bytes (lower part) | 4819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4820 | Egress Packets (upper part) | 4821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4822 | Egress Packets (lower part) | 4823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4824 | Egress Bytes (upper part) | 4825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4826 | Egress Bytes (lower part) | 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4828 | Egress Loss Packets (upper part) | 4829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4830 | Egress Loss Packets (lower part) | 4831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4832 | Egress Loss Bytes (upper part) | 4833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4834 | Egress Loss Bytes (lower part) | 4835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4837 Figure 67: Subscriber Traffic Statistics TLV 4839 Where: 4841 The TLV type: 300. 4843 The TLV length: 72 octets. 4845 User-ID (4 bytes): The user/subscriber identifier. 4847 Statistics-Type (4 bytes): Traffic type. It can be one of the 4848 following options: 4850 0: IPv4 traffic. 4851 1: IPv6 traffic. 4852 2: Dual stack traffic. 4854 Ingress Packets (8 bytes): The number of the packets in upstream 4855 direction. 4857 Ingress Bytes (8 bytes): The bytes of the upstream traffic. 4859 Ingress Loss Packets (8 bytes): The number of the lost packets in 4860 upstream direction. 4862 Ingress Loss Bytes (8 bytes): The bytes of the lost upstream 4863 packets. 4865 Egress Packets (8 bytes): The number of the packets in downstream 4866 direction. 4868 Egress Bytes (8 bytes): The bytes of the downstream traffic. 4870 Egress Loss Packets (8 bytes): The number of the lost packets in 4871 downstream direction. 4873 Egress Loss Bytes (8 bytes): The bytes of the lost downstream 4874 packets. 4876 7.12.2 Subscriber Detection Result TLV 4878 The Subscriber Detection Result TLV is used to return the detection 4879 result of a subscriber. Subscriber detection is a function to detect 4880 whether a subscriber is online or not. The result can be used by the 4881 CP to determine how to deal with the subscriber session. (e.g., 4882 delete the session if detection failed). 4884 The format of this TLV value part is as follows: 4886 0 1 2 3 4887 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 4888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4889 | User-ID | 4890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4891 | Detect Type | Detect Result | Reserved | 4892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4894 Figure 68: Subscriber Detection Result TLV 4896 Where: 4898 The TLV type: 301. 4900 The TLV length: 8 octets. 4902 User-ID (4 bytes): A user/subscriber identifier. 4904 Detect-Type (1 byte): 4906 0: IPv4 detection. 4908 1: IPv6 detection. 4910 2: PPP detection. 4912 Detect-Result (1 bytes): 4914 0: Indicates that the detection is successful. 4916 1: Detection failure. The UP needs report only when the 4917 detection fails. 4919 The Reserved field MUST be sent as zero and ignored on receipt. 4921 7.13 Vendor TLV 4923 The Vendor ID TLV occurs as the first TLV in the Vendor message 4924 (Section 6.6). It provides a Sub-Type that effectively extends the 4925 message type in the message header, provides for versioning of vendor 4926 TLVs, and can accommodate sub-TLVs. 4928 The value part of the Vendor TLV is formatted as follows: 4930 0 1 2 3 4931 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 4932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4933 | Vendor ID | 4934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4935 | Sub-Type | Sub-Type-Version | 4936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4937 ~ sub-TLVs (optional) ~ 4938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4940 Figure 69: Vendor TLV 4942 Where: 4944 The TLV type: 1024. 4946 The TLV length: variable. 4948 Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS [RFC2865]. 4950 Sub-Type (2 bytes): Used by the Vendor to distinguish multiple 4951 different vendor messages. 4953 Sub-Type-Version (2 bytes): Used by the Vendor to distinguish 4954 different versions of a Vendor Defined message sub-type. 4956 Sub-TLVs (variable): Sub-TLVs as specified by the vendor. 4958 Since Vendor code will be handling the TLV after the Vendor ID field 4959 is recognized, the remainder of the TLV value can be organized 4960 however the vendor wants. But it is desirable for a vendor to be able 4961 to define multiple different vendor messages and to keep track of 4962 different versions of its vendor defined messages. Thus, it is 4963 RECOMMENDED that the vendor assign a Sub-Type value for each vendor 4964 message that it defines different from other Sub-Type values that 4965 vendor has used. Also, when modifying a vendor defined message in a 4966 way potentially incompatible with a previous definition, the vendor 4967 SHOULD increase the value it is using in the Sub-Type-Version field. 4969 8. Implementation Status 4971 RFC Editor: Please remove this section before publication. 4973 This section discusses the status of implementations that have 4974 provided information and the testing of this protocol at the time of 4975 posting of this Internet-Draft, and is based on the proposal in 4976 [RFC7942] ("Improving Awareness of Running Code: The Implementation 4977 Status Section"). The description of implementations in this section 4978 is intended to assist in processing drafts to RFCs. 4980 Please note that the listing of any individual implementation or test 4981 results here does not imply endorsement by the RFC Editor or the 4982 IETF. Furthermore, no effort has been spent to verify the 4983 information presented here that was supplied by contributors. This 4984 is not intended as, and must not be construed to be, a catalog of 4985 available implementations or their testing or features. Readers are 4986 advised to note that other implementations may exist. 4988 According to [RFC7942], "this will allow reviewers ... to assign due 4989 consideration to documents that have the benefit of running code, 4990 which may serve as evidence of valuable experimentation and feedback 4991 that have made the implemented protocols more mature.". 4993 8.1 Implementations 4995 Information on three S-CUSP implementations appears below. 4997 8.1.1 Huawei Technologies 4999 Name: Cloud-based BNG. 5001 Maturity: Production. 5003 Coverage: According to S-CUSP protocol. 5005 Contact information: 5006 Zhouyi Yu: yuzhouyi@huawei.com 5008 Date: 2018-11-01 5010 8.1.2 ZTE 5012 Name: ZXR10 V6000 vBRAS 5014 Maturity: Production 5016 Coverage: According to S-CUSP protocol. 5018 Contact information: 5019 Yong Chen: 10056167@zte.com.cn 5020 Huaibin Wang: 10008729@zte.com.cn 5022 Date: 2018-12-01 5024 8.1.3 H3C 5026 Name: CUSP protocol for BRAS Control Plane and User Plan 5027 Separation 5029 Maturity: Research 5031 Coverage: According to S-CUSP protocol 5033 Contact information: mengdan@h3c.com; liuhanlei@h3c.com 5035 Date: 2019-1-30 5037 8.2 Hackathon 5039 Successful use of the protocol at the IETF-102 Hackathon, Montreal, 5040 Quebec, in 2018. 5042 Hackathon Project: Control Plane and User Plane Separation BNG 5043 control channel Protocol (CUSP) 5045 Champions: Zhenqiang Li, Michael Wang 5047 Report: See 5048 github.com/IETF-Hackathon/ietf102-project-presentations/blob/ 5049 master/IETF102-hackathon-presentation-CUSP.pptx 5051 8.3 EANTC Testing 5053 EANTC (European Advanced Networking Test Center (www.eantc.de)) 5054 tested the Huawei implementation. Their summary was as follows: 5055 "EANTC tested advanced aspects of the Cloud-based Broadband Network 5056 Gateway (vBNG) with a focus on performance, scalability and high 5057 availability with up to 20 Million emulated subscribers. The solution 5058 performed very well across all test scenarios." 5060 See report at 5061 www.eantc.de/fileadmin/eantc/downloads/News/2018/EANTC-vBRAS- 5062 phase2.pdf 5064 9. IANA Considerations 5066 IANA is requested to create an "S-CUSP Parameters" web page and 5067 nclude thereon the registries set up in the Sub-Sections below. 5069 9.1 Message Types 5071 IANA is requested to create an S-CUSP Message Types registry on the 5072 S-CUSP Parameters Web Page as follows: 5074 Registry Name: S-CUSP Message Types 5075 Registration Procedure: Expert Review 5076 Reference: [this document] 5078 Type Name Section of [this document] 5079 ------- ---------------- -------------------------- 5080 0 - Reserved 5081 1 Hello 6.2.1. 5082 2 Keepalive 6.2.2. 5083 3 Sync_Request 6.2.3. 5084 4 Sync_Begin 6.2.4. 5085 5 Sync_Data 6.2.5. 5086 6 Sync_End 6.2.6. 5087 7 Update_Request 6.2.7. 5088 8 Update_Response 6.2.8. 5089 9 Report 6.4. 5090 10 Event 6.3. 5091 11 Vendor 6.6. 5092 12 Error 6.7. 5093 13-199 - Unassigned 5094 200 Addr_Allocation_Req 6.5.1. 5095 201 Addr_Allocation_Ack 6.5.2. 5096 202 Addr_Renew_Req 6.5.3. 5097 203 Addr_Renew_Ack 6.5.4. 5098 204 Addr_Release_Req 6.5.5. 5099 205 Addr_Release_Ack 6.5.6. 5100 206-254 - Unassigned 5101 255 - Reserved 5103 9.2 TLV Types 5105 IANA is requested to create an S-CUSP TLV Types registry on the S- 5106 CUSP Parameters Web Page as follows: 5108 Registry Name: S-CUSP TLV Types 5109 Registration Procedure: Expert Review 5110 Reference: [this document] 5112 Type Name Usage Description 5113 ------ ------------ -------------------------- 5114 0 reserved - 5115 1 BAS Function Carries the BNG access 5116 functions to be enabled or 5117 disabled on specified 5118 interfaces. 5119 2 Basic Subscriber Carries the basic information 5120 about a BNG subscriber. 5121 3 PPP Subscriber Carries the PPP information 5122 about a BNG subscriber. 5123 4 IPv4 Subscriber Carries the IPv4 address of a 5124 BNG subscriber. 5125 5 IPv6 Subscriber Carries the IPv6 address of a 5126 BNG subscriber. 5127 6 Subscriber Policy Carries the policy information 5128 applied to a BNG subscriber. 5129 7 IPv4 Routing Carries the IPv4 network 5130 routing information. 5131 8 IPv6 Routing Carries the IPv6 network 5132 routing information. 5133 9 IPv4 Static Subscriber Detect Carries the IPv4 static 5134 subscriber detect information. 5135 10 IPv6 Static Subscriber Detect Carries the IPv6 static 5136 subscriber detect information. 5137 11 L2TP-LAC Subscriber Carries the L2TP LAC 5138 subscriber information. 5139 12 L2TP-LNS Subscriber Carries the L2TP LNS 5140 subscriber information. 5141 13 L2TP-LAC-Tunnel Carries the L2TP LAC tunnel 5142 subscriber information. 5143 14 L2TP-LNS-Tunnel Carries the L2TP LNS tunnel 5144 subscriber information. 5145 15 Subscriber CGN Port Range Carries the public IPv4 5146 address and related port range 5147 of a BNG subscriber. 5148 16-99 unassigned - 5149 100 Hello Used for version and Keep 5150 Alive timers negotiation. 5151 101 Error Information Carried in the Ack of the 5152 control message. Carries the 5153 processing result, success, or 5154 error. 5155 102 Keep Alive Carried in the Hello message 5156 for Keep Alive timers 5157 negotiation. 5159 103-199 unassigned - 5160 200 Interface Status Interfaces status reported by 5161 the UP including physical 5162 interfaces, sub-interfaces, 5163 trunk interfaces, and tunnel 5164 interfaces. 5165 201 Board Status Board information reported by 5166 the UP including the board 5167 type and in-position status. 5168 202-299 unassigned - 5169 300 Subscriber Traffic Statistics User traffic statistics. 5170 301 Subscriber Detection Results User detection information. 5171 302 Update Response The processing result of a 5172 subscriber session update. 5173 303-299 unassigned - 5174 400 Address Allocation Request Request address allocation. 5175 401 Address Allocation Response Address allocation response. 5176 402 Address Renewal Request Request for address lease 5177 renewal. 5178 403 Address Renewal Response Response to a request for 5179 extending an IP address lease. 5180 404 Address Release Request Request to release the 5181 address. 5182 405 Address Release Response Ack of a message releasing an 5183 IP address. 5184 406-1023 unassigned - 5185 1024 Vendor As implemented by vendor. 5186 1039-4095 unassigned - 5188 9.3 TLV Operation Codes 5190 IANA is requested to create an S-CUSP TLV Operation Codes registry on 5191 the S-CUSP Parameters Web Page as follows: 5193 Registry Name: S-CUSP TLV Operation Codes 5194 Registration Procedure: Expert Review 5195 Reference: [this document] 5197 Code Operation 5198 ---- ---------- 5199 0 - reserved 5200 1 Update 5201 2 Delete 5202 3-15 - unassigned 5204 9.4 Sub-TLV Types 5206 IANA is requested to create an S-CUSP Sub-TLV Types registry on the 5207 S-CUSP Parameters Web Page as follows: 5209 Registry Name: S-CUSP Sub-TLV Types 5210 Registration Procedure: Expert Review 5211 Reference: [this document] 5213 Type Name Section of [this document] 5214 ---- ------------------ -------------------------- 5215 0 - reserved 5216 1 VRF Name 7.3.1. 5217 2 Ingress-QoS-Profile 7.3.1. 5218 3 Egress-QoS-Profile 7.3.1. 5219 4 User-ACL-Policy 7.3.1. 5220 5 Multicast-ProfileV4 7.3.1. 5221 6 Multicast-ProfileV6 7.3.1. 5222 7 Ingress-CAR 7.3.2. 5223 8 Egress-CAR 7.3.3. 5224 9 NAT-Instance 7.3.1. 5225 10 Pool-Name 7.3.1. 5226 11 If-Desc 7.3.4. 5227 12 IPv6-Address List 7.3.5. 5228 13 Vendor 7.3.6. 5229 12-64534 - unassigned 5230 65535 - reserved 5232 9.5 Error Codes 5234 IANA is requested to create an S-CUSP ERRID Codes registry on the S- 5235 CUSP Parameters Web Page as follows: 5237 Registry Name: S-CUSP ERRID Codes 5238 Registration Procedure: Expert Review 5239 Reference: [this document] 5241 Value Name Remarks 5242 ------- ------- -------- 5243 0 Success Success 5245 1 Fail Malformed message received. 5246 2 TLV-Unknown One or more of the TLVs was not 5247 understood. 5248 3 TLV-Length The TLV length is abnormal. 5249 4-999 - unassigned Unassigned basic error codes. 5250 1000 - reserved 5251 1001 Version-Mismatch The version negotiation fails. Terminate. 5253 The subsequent service processes 5254 corresponding to the UP are suspended. 5255 1002 Keepalive Error The keepalive negotiation fails. 5256 1003 Timer Expires The establishment timer expired. 5257 1004-1999 - unassigned Unassigned error codes for version 5258 negotiation. 5259 2000 - reserved 5260 2001 Synch-NoReady The data to be smoothed is not ready. 5261 2002 Synch-Unsupport The request for smooth data is not 5262 supported. 5263 2003-2999 - unassigned Unassigned data synchronization error 5264 codes. 5265 3000 - reserved 5266 3001 Pool-Mismatch The corresponding address pool cannot be 5267 found. 5268 3002 Pool-Full The address pool is fully allocated and no 5269 address segment is available. 5270 3003 Subnet-Mismatch The address pool subnet cannot be found. 5271 3004 Subnet-Conflict Subnets in the address pool have been 5272 classified into other clients. 5273 3005-3999 - unassigned Unassigned error codes for address 5274 allocation. 5275 4000 - reserved 5276 4001 Update-Fail-No-Res The forwarding table fails to be 5277 delivered because the forwarding resources 5278 are insufficient. 5279 4002 QoS-Update-Success The QoS policy takes effect. 5280 4003 QoS-Update-Sq-Fail Failed to process the queue in the QoS 5281 policy. 5282 4004 QoS-Update-CAR-Fail Processing of the CAR in the QoS 5283 policy fails. 5284 4005 Statistic-Fail-No-Res Statistics processing failed due to 5285 insufficient statistics resources. 5286 4006-4999 - unassigned forwarding table delivery error codes. 5288 5000-4294967295 - reserved 5290 10. Security Considerations 5292 The Service, Control, and Management Interfaces between the CP and UP 5293 might be across the general Internet or other hostile environment. 5294 The ability of an adversary to block or corrupt messages or introduce 5295 spurious messages on any one or more of these interfaces would give 5296 the adversary the ability to stop subscribers from accessing network 5297 services, disrupt existing subscriber sessions, divert traffic, mess 5298 up accounting statistics, and generally cause havoc. Damage would not 5299 necessarily be limited to one or a few subscribers but could disrupt 5300 routing or deny service to one or more instances of the CP or 5301 otherwise cause extensive interference. If the adversary knows the 5302 details of the UP equipment and its forwarding rule capabilities, the 5303 adversary may be able to cause a copy of most or all user data to be 5304 sent to an address of the adversary's choosing, thus enabling 5305 eavesdropping. 5307 Thus, appropriate protections MUST be implemented to provide 5308 integrity, authenticity, and secrecy of traffic over those 5309 interfaces. Whether such protection is used is a network operator 5310 decision. See [RFC6241] for Management Interface / NETCONF security. 5311 Security on the Service Interface is dependent on the tunneling 5312 protocol used which is out of scope for this document. Security for 5313 the Control Interface, over which the S-CUSP protocol flows, is 5314 further discussed below. 5316 S-CUSP messages do not provide security. Thus, if these messages are 5317 exchanged in an environment where security is a concern, that 5318 security MUST be provided by another protocol such as TLS 1.3 5319 [RFC8446] or IPSEC. TLS 1.3 is the mandatory to implement protocol 5320 for interoperability. The use of a particular security protocol on 5321 the Control Interface is determined by configuration. Such security 5322 protocols need not always be used and lesser security precautions 5323 might be appropriate because, in some cases, the communication 5324 between the CP and UP is in a benign environment. 5326 Contributors 5328 Zhouyi Yu 5329 Huawei Technologies 5331 Email: yuzhouyi@huawei.com 5333 Chengguang Niu 5334 Huawei Technologies 5336 Email: chengguang.niu@huawei.com 5338 Zitao Wang 5339 Huawei Technologies 5341 Email: wangzitao@huawei.com 5343 Jun Song 5344 Huawei Technologies 5346 Email: song.jun@huawei.com 5348 Dan Meng 5349 H3C Technologies 5350 No.1 Lixing Center 5351 No.8 guangxun south street, Chaoyang District, 5352 Beijing, 100102 5353 China 5355 Email: mengdan@h3c.com 5357 Hanlei Liu 5358 H3C Technologies 5359 No.1 Lixing Center 5360 No.8 guangxun south street, Chaoyang District, 5361 Beijing, 100102 5362 China 5364 Email: hanlei_liu@h3c.com 5366 Normative References 5368 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 5369 20, DOI 10.17487/RFC0020, October 1969, . 5372 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 5373 DOI 10.17487/RFC0793, September 1981, . 5376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5377 Requirement Levels", BCP 14, RFC 2119, DOI 5378 10.17487/RFC2119, March 1997, . 5381 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 5382 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 5383 2661, DOI 10.17487/RFC2661, August 1999, . 5386 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 5387 "Remote Authentication Dial In User Service (RADIUS)", RFC 5388 2865, DOI 10.17487/RFC2865, June 2000, . 5391 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5392 and A. Bierman, Ed., "Network Configuration Protocol 5393 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5394 . 5396 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 5397 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 5398 2017, . 5400 Informative References 5402 [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area 5403 networks / Bridges and Bridged Networks", IEEE Std 5404 802.1Q-2014, 3 November 2013. 5406 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 5407 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 5408 . 5410 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 5411 DOI 10.17487/RFC2131, March 1997, . 5414 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 5415 and R. Wheeler, "A Method for Transmitting PPP Over 5416 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 5417 1999, . 5419 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 5420 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 5421 . 5423 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 5424 Address Translator (Traditional NAT)", RFC 3022, DOI 5425 10.17487/RFC3022, January 2001, 5428 [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over 5429 Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 5430 3336, DOI 10.17487/RFC3336, December 2002, 5431 . 5433 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used 5434 to Form Encoding Rules in Various Routing Protocol 5435 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 5436 2009, . 5438 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 5439 IETF Protocol and Documentation Usage for IEEE 802 5440 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 5441 October 2013, . 5443 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 5444 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 5445 eXtensible Local Area Network (VXLAN): A Framework for 5446 Overlaying Virtualized Layer 2 Networks over Layer 3 5447 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 5448 . 5450 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5451 Code: The Implementation Status Section", BCP 205, RFC 5452 7942, DOI 10.17487/RFC7942, July 2016, . 5455 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5456 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5457 . 5459 [TR-384] Broadband Forum, "Cloud Central Office Reference 5460 Architectural Framework", BBF TR-384, 2018. 5462 Authors' Addresses 5464 Shujun Hu 5465 China Mobile 5466 32 Xuanwumen West Ave, Xicheng District 5467 Beijing, Beijing 100053 5468 China 5470 Email: hushujun@chinamobile.com 5472 Donald Eastlake, 3rd 5473 Futurewei Technologies 5474 1424 Pro Shop Court 5475 Davenport, FL 33896 5476 USA 5478 Phone: +1-508-333-2270 5479 Email: d3e3e3@gmail.com 5481 Mach (Guoyi) Chen 5482 Huawei Technologies 5483 Huawei Bldg., No. 156 Beiqing Road 5484 Beijing 100095 China 5486 Email: mach.chen@huawei.com 5488 Fengwei Qin 5489 China Mobile 5490 32 Xuanwumen West Ave, Xicheng District 5491 Beijing, Beijing 100053 5492 China 5494 Email: qinfengwei@chinamobile.com 5496 Zhenqiang Li 5497 China Mobile 5498 32 Xuanwumen West Ave, Xicheng District 5499 Beijing, Beijing 100053 5500 China 5502 Email: lizhenqiang@chinamobile.com 5503 Tee Mong Chua 5504 Singapore Telecommunications Limited 5505 31 Exeter Road, #05-04 Comcentre Podium Block 5506 Singapore City 239732 5507 Singapore 5509 Email: teemong@singtel.com 5511 Daniel Huang 5512 ZTE 5514 Email: huang.guangping@zte.com.cn 5516 Copyright, Disclaimer, and Additional IPR Provisions 5518 Copyright (c) 2019 IETF Trust and the persons identified as the 5519 document authors. All rights reserved. 5521 This document is subject to BCP 78 and the IETF Trust's Legal 5522 Provisions Relating to IETF Documents 5523 (http://trustee.ietf.org/license-info) in effect on the date of 5524 publication of this document. Please review these documents 5525 carefully, as they describe your rights and restrictions with respect 5526 to this document. Code Components extracted from this document must 5527 include Simplified BSD License text as described in Section 4.e of 5528 the Trust Legal Provisions and are provided without warranty as 5529 described in the Simplified BSD License.