INTERNET-DRAFT S. Hu Intended status: Informational China Mobile D. Eastlake Futurewei Technologies M. Chen Huawei Technologies F. Qin Z. Li China Mobile T. Chua Singapore Telecommunications D. Huang ZTE Expires: December 26, 2019 June 27, 2019 The China Mobile, Huawei, and ZTE BNG Simple Control and User Plane Separation Protocol (S-CUSP) draft-chz-simple-cu-separation-bng-protocol-03 Abstract To support Control Plane (CP) and User Plane (UP) Separation (CUPS) for fixed network Broadband Network Gateway (BNG) service providers, China Mobile, Huawei Technologies, and ZTE have developed a simple CUPS control channel Protocol (S-CUSP). This document is not an IETF standard and does not have IETF consensus. It is presented here to make the S-CUSP specification conveniently available to the Internet community to enable diagnosis and interoperability. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the authors. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Hu, et al [Page 1] INTERNET-DRAFT Simple BNG CUSP The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Hu, et al [Page 2] INTERNET-DRAFT Simple BNG CUSP Table of Contents 1. Introduction...........................................6 2. Terminology............................................7 2.1. Implementation Requirement Keywords................7 2.2. Terms..............................................7 3. BNG CUPS Overview.....................................10 3.1. BNG CUPS Motivation...............................10 3.2. BNG CUPS Architecture Overview....................10 3.3. BNG CUPS Interfaces...............................12 3.3.1. Service Interface...............................13 3.3.2. Control Interface...............................14 3.3.3. Management Interface............................14 3.4. BNG CUPS Procedure Overview.......................14 4. S-CUSP Protocol Overview..............................18 4.1. Control Channel Related Procedures................18 4.1.1. S-CUSP Session Establishment....................18 4.1.2. Keep Alive......................................19 4.2. Node Related Procedures...........................20 4.2.1. UP Resource Report..............................20 4.2.2. Update BAS Function on Access Interface.........21 4.2.3. Update Network Routing..........................21 4.2.4. CGN Public IP Address Allocation................22 4.2.5. Data Synchronization between the CP and UP......23 4.3. Subscriber Session Related Procedures.............24 4.3.1. Create Subscriber Session.......................25 4.3.2. Update Subscriber Session.......................26 4.3.3. Delete Subscriber Session.......................27 4.3.4. Subscriber Session Events Report................27 5. S-CUSP Call Flows.....................................29 5.1. IPoE..............................................29 5.1.1. DHCPv4 Access...................................29 5.1.2. DHCPv6 Access...................................30 5.1.3. IPv6 SLAAC Access...............................32 5.1.4. DHCPv6 + SLAAC Access...........................33 5.1.5. DHCP Dual Stack Access..........................35 5.1.6. L2 Static Subscriber Access.....................37 5.2. PPPoE.............................................40 5.2.1. IPv4 PPPoE Access...............................40 5.2.2. IPv6 PPPoE Access...............................41 5.2.3. PPPoE Dual Stack Access.........................43 5.3. WLAN Access.......................................45 5.4. L2TP..............................................47 5.4.1. L2TP LAC Access.................................47 5.4.2. L2TP LNS IPv4 Access............................49 5.4.3. L2TP LNS IPv6 Access............................51 5.5. CGN (Carrier Grade NAT)...........................54 Hu, et al [Page 3] INTERNET-DRAFT Simple BNG CUSP Table of Contents (continued) 5.6. L3 Leased Line Access.............................55 5.6.1. Web Authentication..............................55 5.6.2. User Traffic Trigger............................57 5.7. Multicast Access..................................58 6. S-CUSP Message Formats................................60 6.1. Common Message Header.............................60 6.2. Control Messages..................................61 6.2.1. Hello Message...................................61 6.2.2. Keepalive Message...............................62 6.2.3. Sync_Request Message............................62 6.2.4. Sync_Begin Message..............................62 6.2.5. Sync_Data Message...............................63 6.2.6. Sync_End Message................................63 6.2.7. Update_Request Message..........................64 6.2.8. Update_Response Message.........................64 6.3. Event Message.....................................65 6.4. Report Message....................................66 6.5. CGN Messages......................................66 6.5.1. Addr_Allocation_Req Message.....................66 6.5.2. Addr_Allocation_Ack Message.....................66 6.5.3. Addr_Renew_Req Message..........................67 6.5.4. Addr_Renew_Ack Message..........................67 6.5.5. Addr_Release_Req Message........................67 6.5.6. Addr_Release_Ack Message........................67 6.6. Vendor Message....................................67 6.7 Error Message.......................................68 7. S-CUSP TLVs and Sub-TLVs..............................69 7.1. Common TLV Header.................................69 7.2. Basic Data Fields.................................70 7.3. Sub-TLV Format and Sub-TLVs.......................71 7.3.1. Name sub-TLVs...................................71 7.3.2. Ingress-CAR sub-TLV.............................72 7.3.3. Egress-CAR sub-TLV..............................72 7.3.4. If-Desc sub-TLV.................................73 7.3.5. IPv6 Address List sub-TLV.......................75 7.3.6. Vendor sub-TLV..................................75 7.4. The Hello TLV.....................................77 7.5. The Keep Alive TLV................................78 7.6. The Error Information TLV.........................79 7.7. BAS Function TLV..................................79 7.8. Routing TLVs......................................82 7.8.1. IPv4 Routing TLV................................82 7.8.2. IPv6 Routing TLV................................84 7.9. Subscriber TLVs...................................85 7.9.1. Basic Subscriber TLV............................86 7.9.2. PPP Subscriber TLV..............................88 7.9.3. IPv4 Subscriber TLV.............................89 Hu, et al [Page 4] INTERNET-DRAFT Simple BNG CUSP Table of Contents (continued) 7.9.4. IPv6 Subscriber TLV.............................90 7.9.5. IPv4 Static Subscriber Detect TLV...............91 7.9.6. IPv6 Static Subscriber Detect TLV...............93 7.9.7. L2TP-LAC Subscriber TLV.........................94 7.9.8. L2TP-LNS Subscriber TLV.........................95 7.9.9. L2TP-LAC Tunnel TLV.............................95 7.9.10. L2TP-LNS Tunnel TLV............................96 7.9.11. Update Response TLV............................97 7.9.12. Subscriber Policy TLV..........................98 7.9.13. Subscriber CGN Port Range TLV.................100 7.10. Device Status TLVs..............................100 7.10.1. Interface Status TLV..........................101 7.10.2. Board Status TLV..............................101 7.11. CGN TLVs........................................102 7.11.1. Address Allocation Request TLV................102 7.11.2. Address Allocation Response TLV...............103 7.11.3. Address Renewal Request TLV...................104 7.11.4. The Address Renewal Response TLV..............105 7.11.5. Address Release Request TLV...................106 7.11.6. The Address Release Response TLV..............106 7.12. Event TLVs......................................107 7.12.1. Subscriber Traffic Statistics TLV..............108 7.12.2. Subscriber Detection Result TLV...............109 7.13. Vendor TLV......................................110 8. Implementation Status................................112 8.1. Implementations..................................112 8.1.1. Huawei Technologies............................112 8.1.2. ZTE............................................113 8.1.3. H3C............................................113 8.2. Hackathon........................................113 8.3. EANTC Testing....................................114 9. Summary of Major S-CUSP Codepoints...................115 9.1. Message Types....................................115 9.2. TLV Types........................................115 9.3. TLV Operation Codes..............................117 9.4. Sub-TLV Types....................................118 9.5. Error Codes......................................118 10. IANA Considerations.................................120 11. Security Considerations.............................121 Contributors.............................................122 Normative References.....................................123 Informative References...................................124 Authors' Addresses.......................................126 Hu, et al [Page 5] INTERNET-DRAFT Simple BNG CUSP 1. Introduction A fixed network Broadband Network Gateway (BNG) is an Ethernet- centric IP edge router, and the aggregation point for user traffic. To provide centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, the Control/User (CU) separated BNG framework is described in [TR-384]. The CU separated service Control Plane (CP), which is responsible for user access authentication and setting forwarding entries in User Planes (UPs), can be virtualized and centralized. The routing control and forwarding plane, i.e. the BNG user plane (local), can be distributed across the infrastructure. Other structures can also be supported such as both CP and UP being virtual or both being physical. This document specifies the Simple CU Separation BNG control channel Protocol (S-CUSP) for communications between a BNG Control Plane (CP) and a set of User Planes (UPs). S-CUSP is designed to be flexible and extensible so as to easily allow for additional messages and data items, should further requirements be expressed in the future. This document is not an IETF standard and does not have IETF consensus. S-CUSP was designed by China Mobile, Huawei Technologies, and ZTE, it is presented here to make the S-CUSP specification conveniently available to the Internet community to enable diagnosis and interoperability. Hu, et al [Page 6] INTERNET-DRAFT Simple BNG CUSP 2. Terminology This section specifies implementation requirement keywords and terms used in this document. S-CUSP messages are described in this document using Routing Backus-Naur Form (RBNF) as defined in [RFC5511]. 2.1. Implementation Requirement Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Terms This section specifies terms used in this document. AAA: Authentication Authorization Accounting. ACK: Acknowledgement message. BAS: Broadband Access Server (BRAS, BNG). BNG: Broadband Network Gateway. A broadband remote access server (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic to and from broadband remote access devices such as digital subscriber line access multiplexers (DSLAM) on an Internet Service Provider's (ISP) network. BRAS can also be referred to as a Broadband Network Gateway (BNG). BRAS: BRoadband Access Server (BNG). CAR: Committed Access Rate. CBS: Committed Burst Size. CGN: Carrier Grade NAT. Ci: Control Interface. CIR: Committed Information Rate. CoA: Change of Authorization. Hu, et al [Page 7] INTERNET-DRAFT Simple BNG CUSP CP: Control Plane. CP is a user control management component which supports the management of the UP's resources such as the user entry and forwarding policy. CPE: Customer Premises Equipment. CU: Control-plane / User-plane. CUSP: Control and User plane Separation Protocol. DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the priority and before the VLAN ID. (This bit was formerly the CFI (Canonical Format Indicator).) [802.1Q] DHCP: Dynamic Host Configuration Protocol [RFC2131]. dial-up: This refers to the initial connection messages when a new user appears. The name is left over from when users literally dialed up on a modem equipped phone line but herein is applied to other initial connection techniques. Initial connection is frequently indicated by the receipt of packets over PPPoE [RFC2516] or IPoE. EMS: Element Management System. IPoE: IP over Ethernet. L2TP: Layer 2 Tunneling Protocol [RFC2661]. LAC: L2TP Access Concentrator. LNS: L2TP Network Server. MAC: 48-bit Media Access Control address [RFC7042]. MANO: Management and Orchestration. Mi: Management Interface. MSS: Maximum Segment Size. MRU: Maximum Receive Unit. NAT: Network Address Translation [RFC3022]. ND: Neighbor Discovery. NFV: Network Function Virtualization. Hu, et al [Page 8] INTERNET-DRAFT Simple BNG CUSP NFVI: NFV Infrastructure PBS: Peak Burst Size. PD: Prefix Delegation. PIR: Peak Information Rate. PPP: Point to Point Protocol [RFC1661]. PPPoE: PPP over Ethernet [RFC2516]. RBNF: Routing Backus-Naur Form [RFC5511]. RG: Residential Gateway. S-CUSP: Simple Control and User Plane Separation Protocol. Si: Service Interface. TLV: Type, Length, Value. See Sections 7.1 and 7.3. UP: User Plane. UP is a network edge and user policy implementation component. The traditional router's Control Plane and Forwarding Plane are both preserved on BNG devices in the form of a user plane. URPF: Unicast Reverse Path Forwarding. User: Equivalent to "customer" or "subscriber". VRF: Virtual Routing and Forwarding. Hu, et al [Page 9] INTERNET-DRAFT Simple BNG CUSP 3. BNG CUPS Overview 3.1. BNG CUPS Motivation The rapid development of new services, such as 4K TV, IoT, etc., and increasing numbers of home broadband service users present some new challenges for BNGs such as: Low resource utilization: The traditional BNG acts as both a gateway for user access authentication and accounting and an IP network's Layer 3 edge. The mutually affecting nature of the tightly coupled control plane and forwarding plane makes it difficult to achieve the maximum performance of either plane. Complex management and maintenance: Due to the large numbers of traditional BNGs, configuring each device in a network is very tedious when deploying global service policies. As the network expands and new services are introduced, this deployment mode will cease to be feasible as it is unable to manage services effectively and rectify faults rapidly. Slow service provisioning: The coupling of control plane and forwarding plane, in addition to a distributed network control mechanism, means that any new technology has to rely heavily on the existing network devices. To address these challenges for fixed networks, the framework for a cloud-based BNG with Control Plane and User Plane (CU) separation is described in [TR-384]. The main idea of CU separation is to extract and centralize the user management functions of multiple BNG devices, forming a unified and centralized Control Plane (CP). And the traditional router's Control Plane and Forwarding Plane are both preserved on BNG devices in the form of a User Plane (UP). 3.2. BNG CUPS Architecture Overview The functions in a traditional BNG can be divided into two parts: one is the user access management function, the other is the router function. The user management function can be centralized and deployed as a concentrated module or device, called the BNG Control Plane (BNG-CP). The other functions, such as the router function and forwarding engine, can be deployed in the form of the BNG User Plane (BNG-UP). Hu, et al [Page 10] INTERNET-DRAFT Simple BNG CUSP The following figure shows the architecture of CU separated BNG: +------------------------------------------------------------------+ | Neighboring policy and resource management systems | | | | +-------------+ +-----------+ +---------+ +----------+ | | |AAA Server| |DHCP Server| | EMS | | MANO | | | +-------------+ +-----------+ +---------+ +----------+ | +------------------------------------------------------------------+ +------------------------------------------------------------------+ | CU-separated BNG system | | +--------------------------------------------------------------+ | | | +----------+ +----------+ +------++------++-----------+ | | | | | Address | |Subscriber| | AAA ||Access|| UP | | | | | |management| |management| | || Mgt ||management | | | | | +----------+ +----------+ +------++------++-----------+ | | | | CP | | | +--------------------------------------------------------------+ | | | | | | | | +---------------------------+ +--------------------------+ | | | +------------------+ | | +------------------+ | | | | | Routing control | | | | Routing control | | | | | +------------------+ | ... | +------------------+ | | | | +------------------+ | | +------------------+ | | | | |Forwarding engine | | | |Forwarding engine | | | | | +------------------+ UP | | +------------------+ UP| | | +---------------------------+ +--------------------------+ | +------------------------------------------------------------------+ Figure 1: Architecture of CU Separated BNG As shown in Figure 1, the BNG Control Plane could be virtualized and centralized, which provides benefits such as centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, etc. The functional components inside the BNG Service Control Plane can be implemented as Virtual Network Functions (VNFs) and hosted in a Network Function Virtualization Infrastructure (NFVI). The User Plane Management module in the BNG Control Plane centrally manages the distributed BNG User Planes (e.g. load balancing), as well as the setup, deletion, and maintenance of channels between Control Planes and User Planes. Other modules in the BNG control plane, such as address management, AAA, etc., are responsible for the connection with outside subsystems in order to fulfill those services. Note that the User Plane SHOULD support both physical and virtual network functions. For example, BNG user plane L3 forwarding Hu, et al [Page 11] INTERNET-DRAFT Simple BNG CUSP related network functions can be disaggregated and distributed across the physical infrastructure. And the other control plane and management plane functions in the CU Separation BNG can be moved into the NFVI for virtualization [TR-384]. The details of CU separated BNG's function components are as following: The Control Plane is responsible for the following: 1. Address management: unified address pool management and CGN subscriber address traceability management. 2. AAA: This component performs Authentication, Authorization and Accounting, together with RADIUS/DIAMETER. The BNG communicates with the AAA server to check whether the subscriber who sent an Access-Request has network access authority. Once the subscriber goes online, this component together with the Service Control component implement accounting, data capacity limitation, and QoS enforcement policies. 3. Subscriber management: user entry management and forwarding policy management. 4. Access management: process user dial-up packets, such as PPPoE, DHCP, L2TP, etc. 5. UP management: management of UP interface status, and the setup, deletion, and maintenance of channels between CP and UP. The User Plane is responsible for the following: 1. Routing control functions: responsible for constructing routing forwarding plane (e.g., routing, multicast, MPLS, etc.). 2. Routing and Service Forwarding plane functions: responsible including traffic forwarding, QoS and traffic statistics collection. Subscriber detection: responsible for detecting whether a subscriber is still online. 3.3. BNG CUPS Interfaces To support the communication between the Control Plane and User Plane, three interfaces are assumed. These are referred to as the Service Interface (Si), Control Interface (Ci), and Management Interface (Mi) as shown in Figure 2. Hu, et al [Page 12] INTERNET-DRAFT Simple BNG CUSP +-----------------------------------+ | | | BNG-CP | | | +--+--------------+--------------+--+ | | | 1. Service | 2. Control | 3. Management| Interface | Interface | Interface | (Si) | (Ci) | (Mi) | | | | | ___|___ | | ___( )___ | _|______( )______|_ ( ) ( Network/Internet ) (________ ________) | (___ ___) | | (_______) | | | | | | | +--+--------------+--------------+--+ | | | BNG-UP | | | +-----------------------------------+ Figure 2: Interfaces Between the CP and UP of the BNG 3.3.1. Service Interface For a traditional BNG (without CU separation), the user dial-up signals are terminated and processed by the control plane of a BNG. When the CP and UP of a BNG are separated, there needs to be a way to relay these signals between the CP and the UP. The Service Interface (Si) is used to establish tunnels between the CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, and L2TP related control packets that are received from a Residential Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN [RFC7348]. The detailed definition of Si is out of scope for this document. Hu, et al [Page 13] INTERNET-DRAFT Simple BNG CUSP 3.3.2. Control Interface The CP uses the Control Interface to deliver subscriber session states, network routing entries, etc. to the UP (see Section 6.2.7)). The UP uses this interface to report subscriber service statistics, subscriber detection results, etc. to the CP (see Sections 6.3 and 6.4). A carrying protocol for this interface is specified in this document. 3.3.3. Management Interface NETCONF [RFC6241] is the protocol used on the Management Interface between a CP and UP. It is used to configure the parameters of the Control Interface, Service Interface, the Access interfaces and QoS/ACL Templates. It is expected that implementations will make use of existing YANG models where possible, but that new YANG models specific to S-CUSP will need to be defined. The definitions of the parameters are out of scope for this document. 3.4. BNG CUPS Procedure Overview The following numbered sequences (Figure 3) gives a high level view of the main BNG CUPS procedures. RG UP CP AAA | | | | | |Establish S-CUSP Channel| | | 1|<---------------------->| | | | | | | | Report Board | | | | interface | | | | information | | | 2|------to CP via Ci----->| | | | | | | | Update BAS function | | | 3| request / response | | | |<-----on UP via Ci----->| | | | | | | | Update network routing | | | | request / response | | | 4|<------- via Ci-------->| | | | | | | Online Req | | | 5.1|-------------->| | | | | Relay the Online Req | | | 5.2|-----to CP via Si------>| Authentication| Hu, et al [Page 14] INTERNET-DRAFT Simple BNG CUSP | | | Req/Rep | | | 5.3|<------------->| | | Send the Online Rep | | | 5.4|<----to UP via Si-------| | | Online Rep | | | 5.5|<--------------| | | | | Create subscriber | | | | session on UP | | | 5.6|<--------via Ci-------->| | | | | CoA Request | | | 6.1|<--------------| | | Update session on UP | | | 6.2|<--------via Ci-------->| | | | | CoA Response | | | 6.3|-------------->| | | | | | Offline Req | | | 7.1|-------------->| | | | | Relay the Offline Req | | | 7.2|------to CP via Si----->| | | | | | | | Send the Offline Rep | | | 7.3|<-----to UP via Si------| | | Offline Rep | | | 7.4|<--------------| | | | | Delete session on UP | | | 7.5|<--------via Ci-------->| | | | | | | | Event report | | | 8|---------via Ci-------->| | | | | | | | Data Synchronization | | | 9|<--------via Ci-------->| | | | | | | | CGN Address Allocation | | | 10|<--------via Ci-------->| | | | | | Figure 3: BNG CUPS Procedures Overview 1. S-CUSP session establishment: This is the first step of BNG CUPS procedures. Once the Control Interface parameters are configured on a UP. It will start to setup S-CUSP sessions with the specified CPs. The detailed definition of S-CUSP session establishment can be found in Section 4.1.1. 2. Board and interface report: Once the S-CUSP session is established between the UP and a CP, the UP will report status information on the boards and subscriber side interfaces of this UP to the CP. A board can also be called a Line/Service Process Hu, et al [Page 15] INTERNET-DRAFT Simple BNG CUSP Unit (LPU/SPU) card. The subscriber side interfaces refer to the interfaces that connect the Acess Network nodes (e.g., OLT: Optical Line Terminal, DSLAM: Digital Subscriber Line Access Multiplexer, etc.). The CP can use this information to enable the Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, etc.) on the specified interfaces. See Sections 4.2.1 and 7.10 for more details on Resource reporting. 3. BAS (Broadband Access Service) function enable: To enable the BAS function on the specified interfaces of a UP. 4. Subscriber network route advertisement: The CP will allocate one or more IP address blocks to a UP. Each address block contains a series of IP addresses. Those IP addresses will be allocated to subscribers who are dialing up from the UP. To enable other nodes in the network to learn how to reach the subscribers, the CP needs to notify the UP to advertise to the network the routes that can reach those IP addresses. 5. 5.1-5.6 is a complete call flow of a subscriber dial-up process. When a UP receives a dial-up request, it will relay the request packet to a CP through the Service Interface. The CP will parse the request. If everything is OK, it will send an authentication request to the AAA server to authenticate the subscriber. Once the subscriber passes the authentication, the AAA server will return a positive response to the CP. Then the CP will send the dial-up response packet to the UP and the UP will forward the response packet to the subscriber (RG). At the same time, the CP will create a subscriber session on the UP, which enables the subscriber to access the network. For different access types, the process may be a bit different. But the high-level process is similar. For each access type, the detail process can be found in Section 5. 6. 6.1-6.3 is the sequence when updating an existing subscriber session. The AAA server initiates a Change of Authorization (CoA) and sends the CoA to the CP. The CP will then update the session according to the CoA. See Section 4.3.2 for more detail on CP messages updating UP tables. 7. 7.1-7.5 is the sequence for deleting an existing subscriber session. When a UP receives an offline request, it will relay the request to a CP through the Service Interface. The CP will send back a response to the UP through the Service Interface. The UP will then forward the offline response to the subscriber. Then the CP will delete the session on the UP through the Control Interface. Hu, et al [Page 16] INTERNET-DRAFT Simple BNG CUSP 8. Event reports include the following two parts (more detail can be found in Section 4.3.4) Both are reported using the Event message. 8.1. Subscriber Traffic Statistics Report 8.2. Subscriber Detection Result Report 9. Data synchronization: See Sections 4.2.5 for more detail on CP and UP Synchronization. 10. CGN address allocation: See Sections 4.2.4 for more detail on CGN Address Allocation. Hu, et al [Page 17] INTERNET-DRAFT Simple BNG CUSP 4. S-CUSP Protocol Overview 4.1. Control Channel Related Procedures 4.1.1. S-CUSP Session Establishment A UP is associated with a CP and is controlled by that CP. In the case of a hot-standby or cold-standby, a UP is associated with two CPs, one called the Master CP and the other called the Standby CP. The association between a UP and its CPs is implemented by dynamic configuration. Once a UP knows its CPs, the UP starts to establish S-CUSP sessions with those CPs as shown in Figure 4. UP CP | | | TCP Session Establishment | |<------------------------------->| | | | HELLO (version, capability) | |-------------------------------->| | | | HELLO (version, capability) | |<--------------------------------| | | Figure 4: S-CUSP Session Establishment The S-CUSP session establishment consists of two successive steps: 1. Establishment of a TCP [RFC793] connection (3-way handshake) between the CP and the UP using a configured port from the dynamic port range (49152-65535). 2. Establishment of a S-CUSP session over the TCP connection. Once the TCP connection is established, the CP and the UP initialize the S-CUSP session during which the version and Keepalive timers are negotiated. The version information (Hello TLV, see Section 7.4) is carried within Hello messages (see Section 6.2.1). A CP can support multiple versions, but a UP can only support one version. So, the version negotiation is based on whether a version can be support by both the CP and the UP. For a CP or UP, if a Hello message is received that Hu, et al [Page 18] INTERNET-DRAFT Simple BNG CUSP does not indicate a version supported by both, a subsequent Hello message with an Error Information TLV will be sent to the peer to notify the peer of the "Version-Mismatch" error and the session establishment phase fails. Keepalive negotiation is performed by carrying a Keepalive TLV in the Hello message. The Keepalive TLV includes a Keepalive timer and Dead Timer field. The CP and UP have to agree on the Keepalive Timer and Dead Timer. Otherwise, a subsequent Hello message with an Error Information TLV will be sent to its peer and the session establishment phase fails. The S-CUSP session establishment phase fails if the CP or UP disagree on the version and keepalive parameters or if one of the CP or UP does not answer after the expiration of the Establishment timer. When the S-CUSP session establishment fails, the TCP connection is promptly closed. Successive retries are permitted but an implementation SHOULD make use of an exponential back-off session establishment retry procedure. The S-CUSP session timer values that need to be configured are summarized in the table below. Timer Range in Default Name seconds Value ------------- ------- ------- Establishment 1-32767 45 Keepalive 0-255 30 DeadTimer 1-32767 4 * Keepalive 4.1.2. Keep Alive Once an S-CUSP session has been established, a UP or CP may want to know that its S-CUSP peer is still available for use. Each end of a S-CUSP session runs a Keepalive timer. It restarts the timer every time it sends a message on the session. When the timer expires, it sends a Keepalive message. The ends of the S-CUSP session also run DeadTimers, and they restart the timers whenever a message is received on the session. If one end of the session receives no message after the DeadTimer expires, it declares the session dead. The session will be closed. The minimum value of the Keepalive timer is 1 second, and it is specified in units of 1 second. The RECOMMENDED default value is 30 seconds. The timer may be disabled by setting it to zero. Hu, et al [Page 19] INTERNET-DRAFT Simple BNG CUSP The recommended default for the DeadTimer is 4 times the value of the Keepalive timer used by the remote peer. This implies there is essentially no risk of TCP congestion due to excessive Keepalive messages. The Keepalive timer and DeadTimer are initially negotiated through the Keepalive TLV carried in the Hello Message. 4.2. Node Related Procedures 4.2.1. UP Resource Report Once an S-CUSP session has been established between a CP and an UP. The UP reports the information of the Boards and access side interfaces on this UP to the CP as shown in Figure 5. Report messages are unacknowledged and are assumed to be delivered because the session runs over TCP. The CP can use that information to activate/enable the Broadband Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the specified interfaces. In addition, the UP resource report may trigger a UP warm-standby process. In the case of warm-standby, a failure on an UP may trigger the CP to start a warm-standby process, by moving the on-line subscriber sessions to a standby UP and then direct the affected subscribers to access the Internet through the standby UP. UP CP | | | Report Board Status | |------to CP via Ci----->| | | | Report Interface Status| |------to CP via Ci----->| | | Figure 5: UP Board and Interface Report Board status information is carried in the Board Status TLV (Section 7.10.2) and Interface status information is carried in Interface Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are carried in the Report Message (Section 6.4). Hu, et al [Page 20] INTERNET-DRAFT Simple BNG CUSP 4.2.2. Update BAS Function on Access Interface Once the CP collects the interface status of a UP, it will activate/de-activate/modify the BAS functions on specified interfaces through the Update_Request and Update_Response message (Section 6.2) exchanges carrying the BAS Function TLV (Section 7.7). UP CP | | | Update BAS function | | Request | |<-----on UP via Ci-------| | | | Update BAS function | | Response | |------on UP via Ci------>| | | Figure 6: Update BAS Function 4.2.3. Update Network Routing The CP will allocate one or more address blocks to a UP. Each address block contains a series of IP addresses. Those IP addresses will be allocated to subscribers who are dialing up to the UP. To enable the other nodes in the network to learn how to reach the subscribers, the CP needs to install the routes on the UP and notify the UP to advertise the routes to the network. UP CP | | | Subscriber network route| | update request | |<------- via Ci----------| | | | Subscriber network route| | update response | |-------- via Ci--------->| | | Figure 7: Update Network Routing The subscriber network routing update request and response are achieved through the Update Request and Response Message exchanges by carrying the IPv4/IPv6 Routing Information TLVs (Section 7.8). Hu, et al [Page 21] INTERNET-DRAFT Simple BNG CUSP 4.2.4. CGN Public IP Address Allocation The following sequences describe the CGN address management related procedures. Three independent procedures are defined, one each for CGN address allocation request/response, CGN address renewal request/response, and CGN address release request/response. CGN address allocation/renew/release procedures are designed for the case where the CGN function is running on the UP. The UP has to map the subscriber private IP addresses to a public IP addresses, and such mapping is performed by the UP locally when a subscriber dials- up. That means the UP has to ask for public IPv4 address blocks for CGN subscribers from the CP. In addition, when a public IP address is allocated to a UP, there will be a lease time (e.g., one day). Before the lease time expires, the UP can ask for renewal of the IP address lease from the CP. It is achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack messages. If the public IP address will not be used anymore, the UP SHOULD release the address by sending an Addr_Release_Req message to the CP. If the CP wishes to withdraw addresses that it has previously leased to a UP, it uses the same procedures as above. The "Oper" code in the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the request is an update or withdraw. The relevant messages are defined in Section 6.5. Hu, et al [Page 22] INTERNET-DRAFT Simple BNG CUSP UP CP | | | CGN Address Allocation | | Request | 1.1|-------- via Ci--------->| | CGN Address Allocation | | Response | 1.2|<------- via Ci----------| | | | CGN Address Renew | | Request | 2.1|-------- via Ci--------->| | CGN Address Renew | | Response | 2.2|<------- via Ci----------| | | | CGN Address Release | | Request | 3.1|-------- via Ci--------->| | CGN Address Release | | Response | 3.3|<------- via Ci----------| | | Figure 8: CGN Public IP Address Allocation 4.2.5. Data Synchronization between the CP and UP For a CU separated BNG, the UP will continue to function using the state that has been installed in it even if the CP fails or the session between the UP and CP fails. Under some circumstances it is necessary to synchronize state between the CP and UP, for example if a CP fails and the UP is switched to a different CP. Synchronization includes two directions. One direction is from UP to CP; in that case, the synchronization information is mainly about the board/interface status of the UP. The other direction is from CP to UP; in that case, the subscriber sessions, subscriber network routes, L2TP tunnels, etc. will be synchronized to the UP. The synchronization is triggered by a Sync_Request message, to which the receiver will (1) reply with a Sync_Begin message to notify the requester that synchronization will begin, and (2) then start the synchronization using the Sync_Data message. When synchronization finished, a Sync_End message will be sent. Hu, et al [Page 23] INTERNET-DRAFT Simple BNG CUSP The following figure shows the process of data synchronization between a UP and a CP. UP CP | | | Synchronization Request | |<------- via Ci----------| | | | Synchronization Begin | |-------- via Ci--------->| | | | Board/Interface Report | |-------- via Ci--------->| | | | Synchronization End | |-------- via Ci--------->| | | 1) Synchronization from UP to CP UP CP | | | Synchronization Request | |-------- via Ci--------->| | | | Synchronization Begin | |<-------- via Ci---------| | | | Synchronizes | |Subscriber Session States| | Network Route Entries | |<------- via Ci----------| | | | Synchronization End | |<-------- via Ci---------| | | 2) Synchronization from CP to UP Figure 9: Data Synchronization 4.3. Subscriber Session Related Procedures A subscriber session consists of a set of forwarding states, policies, and security rules that are applied to the subscriber. It is used for forwarding subscriber traffic in a UP. To initialize a session on a UP, a set of hardware resource have to be allocated (e.g., NP, TCAM etc.) to a session. Subscriber session related procedures include subscriber session Hu, et al [Page 24] INTERNET-DRAFT Simple BNG CUSP create, update, delete, and statistics report. The following sub- sections give a high level view of the procedures. 4.3.1. Create Subscriber Session The below sequence describes the DHCP IPv4 dial-up process, it is an example that shows how a subscriber session is created. (An example for IPv6 appears in Section 5.1.2.) RG UP CP AAA | | | | | Online Request| | | 1|-------------->| | | | |Relay the Online Request| | | 2|-----to CP via Si------>| Authentication| | | | Req/Rep | | | 3|<------------->| | | Create subscriber | | | | session Request | | | 4|<--------via Ci---------| | | | | | | | Create subscriber | | | | session Response | | | 5|---------via Ci-------->| | | | | | | | | Accounting | | | 6|<------------->| | | | | | | Send Online Response | | | 7|<----to UP via Si-------| | | | | | |Online Response| | | 12|<--------------| | | | | | | Figure 10: Subscriber Session Create The request starts from an Online Request message (step 1) from the RG (for example, a DHCP Discovery packet). When the UP receives the Online Request from the RG, it will tunnel the Online Request to the CP through the Service Interface (Step 2). The Service Interface is implemented by a tunneling technology. When the CP receives the Online Request from the UP, it will send an authentication request to the AAA server to authenticate and authorize the subscriber (step 3). When a positive reply is received from the AAA sever, the CP starts to create a subscriber session for the request. Relevant resources (e.g., IP address, bandwidth, etc.) Hu, et al [Page 25] INTERNET-DRAFT Simple BNG CUSP will be allocated to the subscriber, policies and security rules will be generated for the subscriber Then the CP sends a session create request to the UP through the Control Interface (Ci) (step 4), and a response is expected from the UP to confirm the creation (step 5). Finally, the CP will notify the AAA server to start accounting (step 6). At the same time, an Online Response message (for example, a DHCP Ack packet) will be sent to the UP through the Si (step 7). And the UP will forward the Online Response to the RG (step 8). This completes the subscriber online process. 4.3.2. Update Subscriber Session The following numbered sequence shows the process of subscriber session update. UP CP AAA | | COA Request | | 1|<--------------| | Session update Request | | 2|<--------via Ci---------| | | | | | Session update Response| | 3|---------via Ci-------->| | | | COA Response | | 4|-------------->| | | | Figure 11: Subscriber Session Update When a subscriber session has been created on a UP, there may be requirements to update the session with new parameters (e.g., Bandwidth, QoS, policies, etc.). This procedure is triggered by a Change of Authorization (COA) request message sent by the AAA server. The CP will update the session on the UP according to the new parameters through the Control Interface. Hu, et al [Page 26] INTERNET-DRAFT Simple BNG CUSP 4.3.3. Delete Subscriber Session The below call flow shows generally how S-CUPS deals with a subscriber offline request. RG UP CP | | | |Offline Request | | 1|--------------->| | | | Relay the Offline | | | Request | | 2|------to CP via Si----->| | | | | | Send the Offline | | | Response | | 3|<-----to UP via Si------| |Offline Response| | 4|<---------------| | | | Session delete | | | Request | | |<--------via Ci---------| | | Session delete | | | Response | | |---------via Ci-------->| | | | Figure 12: Subscriber Session Delete Similar to the session creation process, when a UP receives an offline request from a RG, it will tunnel the request to a CP through the Si. When the CP receives the offline request, it will withdraw/release the resources (e.g., IP address, bandwidth) that have been allocated to the subscriber. Then, it sends a reply to the UP through the Service Interface and the UP will forward the reply to the RG. At the same time, it will delete all the status of the session on the UP through the Ci. 4.3.4. Subscriber Session Events Report UP CP | | | Statistic/Detect report| |---------via Ci-------->| | | Figure 13: Events Report Hu, et al [Page 27] INTERNET-DRAFT Simple BNG CUSP When a session is created on an UP, the UP will periodically report statistics information and detect results of the session to the CP. Hu, et al [Page 28] INTERNET-DRAFT Simple BNG CUSP 5. S-CUSP Call Flows The subsections below give an overview of various "dial-up" interactions over the Service Interface followed by an overview of the setting of various information in the UP by the CP using S-CUSP over the Control Interface. S-CUSP messages are described in this document using Routing Backus Naur Form (RBNF) as defined in [RFC5511]. 5.1. IPoE 5.1.1. DHCPv4 Access The following sequence shows detailed procedures for DHCPv4 access. RG UP CP AAA | | | | | DHCP Discovery| | | 1|-------------->| | | | |Relay the DHCP Discovery| | | 2|-----to CP via Si------>| AAA | | | | Req/Rep | | | 3|<------------->| | | | | | | Send the DHCP Offer | | | 4|<----to UP vis Si-------| | | DHCP Offer | | | 5|<--------------| | | | DHCP Request | | | 6|-------------->| | | | | Relay the DHCP Request| | | 7|-----to CP via Si------>| | | | | | | | Create subscriber | | | | session Request | | | 8|<--------via Ci---------| | | | Create subscriber | | | | session Response | | | 9|---------via Ci-------->| | | | | Accounting | | | 10|<------------->| | | | | | | Send DHCP ACK | | | 11|<----to UP via Si-------| | | | | | Hu, et al [Page 29] INTERNET-DRAFT Simple BNG CUSP | DHCP ACK | | | 12|<--------------| | | | | | | Figure 14: DHCPv4 Access Step 8 and 9 are implemented by the S-CUSP protocol. When a subscriber is authenticated and authorized by the AAA server, the CP will create a subscriber session on the UP. This is achieved by sending an Update_Request message to the UP. The format of the Update_Request message is shown as follows using RBNF: ::= [] The UP will reply with an Update_Response message, the format of the Update_Response message is as follows: ::= [] 5.1.2. DHCPv6 Access The following sequence shows detailed procedures for DHCPv6 access. RG UP CP AAA | | | | | Solicit | | | 1|-------------->| | | | | Relay the Solicit | | | 2|-----to CP via Si------>| AAA | | | | Req/Rep | | | 3|<------------->| | | | | | | Send the Advertise | | | 4|<----to UP vis Si-------| | | Advertise | | | 5|<--------------| | | | | | | | Request | | | 6|-------------->| | | Hu, et al [Page 30] INTERNET-DRAFT Simple BNG CUSP | | Relay the Request | | | 7|-----to CP via Si------>| | | | | | | | | | | | Create subscriber | | | | session Request | | | 8|<--------via Ci-------->| | | | | | | | Create subscriber | | | | session Response | | | 9|---------via Ci-------->| | | | | | | | | Accounting | | | 10|<------------->| | | | | | | Send Reply | | | 11|<----to UP via Si-------| | | | | | | Reply | | | 12|<--------------| | | | | | | Figure 15: DHCPv6 Access Steps 1-7 are a standard DHCP IPv6 access process. The subscriber creation is triggered by a DHCP IPv6 request message. When this message is received, it means that the subscriber has passed the AAA authentication and authorization. Then the CP will create a subscriber session on the UP. This is achieved by sending an Update_Request message to the UP (Step 8). The format of the Update_Request message is as follows: ::= [] The UP will reply with an Update_Response message (Step 9). The format of the Update_Response message is as follows: ::= Hu, et al [Page 31] INTERNET-DRAFT Simple BNG CUSP 5.1.3. IPv6 SLAAC Access The following flow shows the IPv6 SLAAC access process. RG UP CP AAA | | | | | RS | | | 1|-------------->| | | | | Relay the Router | | | | Solicit (RS) | | | 2|-----to CP via Si------>| AAA | | | | Req/Rep | | | 3|<------------->| | | | | | | Create subscriber | | | | session Request | | | 4|<--------via Ci---------| | | | | | | | Create subscriber | | | | session Response | | | 5|---------via Ci-------->| | | | | | | | Send Router Advertise | | | | (RA) | | | 6|<----to UP vis Si-------| | | RA | | | 7|<--------------| | | | | | | | NS | | | 8|-------------->| | | | | Relay the Neighbor | | | | Solicit (NS) | | | 9|-----to CP via Si------>| | | | | | | | | Accounting | | | 10|<------------->| | | | | | | Send a Neighbor | | | | Advertise (NA) | | | 11|<----to UP via Si-------| | | | | | | NA | | | 12|<--------------| | | | | | | Figure 16: IPv6 SLAAC Access It starts with a Router Solicit (RS) request from an RG that is tunneled to the CP by the UP. After the AAA authentication and authorization, the CP will create a subscriber session on the UP. Hu, et al [Page 32] INTERNET-DRAFT Simple BNG CUSP This is achieved by sending an Update_Request message to the UP (step 4). The format of the Update_Request message is as follows: ::= [] The UP will reply with an Update_Response message (step 5), the format of the Update_Response message is as follows: ::= 5.1.4. DHCPv6 + SLAAC Access The following call flow shows the DHCP IPv6 and SLAAC access process. RG UP CP AAA | | | | | RS | | | 1|-------------->| | | | | Relay the Router | | | | Solicit (RA) | | | 2|-----to CP via Si------>| AAA | | | | Req/Rep | | | 3|<------------->| | | | | | | Create subscriber | | | | session Request | | | 4|<--------via Ci---------| | | | | | | | Create subscriber | | | | session Response | | | 5|---------via Ci-------->| | | | | | | | Send Router Advertise | | | | (RA) | | | 6|<----to UP vis Si-------| | | RA | | | 7|<--------------| | | | | | | |DHCPv6 Solicit | | | 8|-------------->| | | | | Relay DHCPv6 Solicit | | Hu, et al [Page 33] INTERNET-DRAFT Simple BNG CUSP | 9|-----to CP via Si------>| | | | | | | | Update subscriber | | | | session Request | | | 10|<--------via Ci---------| | | | | | | | Update subscriber | | | | session Response | | | 11|---------via Ci-------->| | | | | | | | | Accounting | | | 12|<------------->| | | | | | | Send DHCPv6 Reply | | | 13|<----to UP via Si-------| | | | | | | DHCPv6 Reply | | | 14|<--------------| | | | | | | Figure 17: DHCPv6 + SLAAC Access When a subscriber passes AAA authentication, the CP will create a subscriber session on the UP. This is achieved by sending an Update_Request message to the UP (step 4). ::= [] The UP will reply with an Update_Response message (step 5). The format of the Update_Response is as follows: ::= After receiving a DHCPv6 Solicit, the CP will update the subscriber session by sending an Update_Request message with new parameters to the UP (Step 10). The format of the Update_Request message is as follows: ::= [] Hu, et al [Page 34] INTERNET-DRAFT Simple BNG CUSP The UP will reply with an Update_Response message (step 11). The format of the Update_Response is as follows: ::= 5.1.5. DHCP Dual Stack Access The following sequence is a combination of DHCP IPv4 and DHCP IPv6 access processes. RG UP CP AAA | | | | | DHCP Discovery| | | 1|-------------->| | | | |Relay the DHCP Discovery| | | 2|-----to CP via Si------>| AAA | | | | Req/Resp | | | 3|<------------->| | | | | | | Send the DHCP Offer | | | 4|<----to UP vis Si-------| | | DHCP Offer | | | 5|<--------------| | | | DHCP Request | | | 6|-------------->| | | | | Relay the DHCP Request| | | 7|-----to CP via Si------>| | | | | | | | Create subscriber | | | | session Request | | | 8|<--------via Ci-------->| | | | Create subscriber | | | | session Response | | | 9|---------via Ci-------->| | | | | Accounting | | | 10|<------------->| | | Send DHCP ACK | | | 11|<----to UP via Si-------| | | | | | | DHCP ACK | | | 12|<--------------| | | | RS | | | 13|-------------->| | | | | Relay the Router | | | | Solicit (RA) | | | 14|-----to CP via Si------>| AAA | | | | Req/Rep | Hu, et al [Page 35] INTERNET-DRAFT Simple BNG CUSP | | 15|<------------->| | | | | | | Create subscriber | | | | session Request | | | 16|<--------via Ci---------| | | | Create subscriber | | | | session Response | | | 17|---------via Ci-------->| | | | | | | | Send Router Advertise | | | | (RA) | | | 18|<----to UP vis Si-------| | | RA | | | 19|<--------------| | | | | | | |DHCPv6 Solicit | | | 20|-------------->| | | | | Relay DHCPv6 Solicit | | | 21|-----to CP via Si------>| | | | | | | | Update subscriber | | | | session Request | | | 22|<--------via Ci---------| | | | Update subscriber | | | | session Response | | | 23|---------via Ci-------->| | | | | Accounting | | | 24|<------------->| | | Send DHCPv6 Reply | | | 25|<----to UP via Si-------| | | DHCPv6 Reply | | | 26|<--------------| | | | | | | Figure 18: DHCP Dual Stack Access The DHCP dual stack access includes three sets of Update_Request / Update_Response exchanges to create/update DHCPv4/v6 subscriber session. 1. Create DHCPv4 session (step 8 and 9) ::= [] Hu, et al [Page 36] INTERNET-DRAFT Simple BNG CUSP ::= [] 2. Create DHCPv6 session (step 16 and 17) ::= [] ::= 3. Update DHCPv6 session (step 22 and 23) ::= [] ::= 5.1.6. L2 Static Subscriber Access L2 static subscriber access processes are as follows: RG UP CP AAA | | | | | | Static Subscriber | | | | Detection Req. | | | 1|<-----to UP via Ci------| | | | Static Subscriber | | | | Detection Rep. | | | 2|------to UP via Ci----->| | | ARP/ND(REQ) | | | 3.1|<--------------| | | | ARP/ND(ACK) | | | 3.2|-------------->| | | | | Relay the ARP/ND | | | 3.3|-----to CP via Si------>| AAA | | | | Req/Rep | | | 3.4|<------------->| | | Create subscriber | | | | session Request | | Hu, et al [Page 37] INTERNET-DRAFT Simple BNG CUSP | 3.5|<--------via Ci---------| | | | Create subscriber | | | | session Response | | | 3.6|---------via Ci-------->| | | | | | | ARP/ND(REQ) | | | 4.1|-------------->| | | | | Relay the ARP/ND | | | 4.2|-----to CP via Si------>| AAA | | | | Req/Rep | | | 4.3|<------------->| | | Create subscriber | | | | session Request | | | 4.4|<--------via Ci---------| | | | Create subscriber | | | | session Response | | | 4.5|---------via Ci-------->| | | ARP/ND(ACK) | | | 4.6|<--------------| | | | | | | | IP Traffic | | | 5.1|-------------->| | | | | Relay the IP Traffic | | | 5.2|-----to CP via Si------>| AAA | | | | Req/Rep | | | 5.3|<------------->| | | Create subscriber | | | | session Request | | | 5.4|<--------via Ci-------->| | | | Create subscriber | | | | session Response | | | 5.5|---------via Ci-------->| | | | | | | ARP/ND(REQ) | | | 5.6|<--------------| | | | ARP/ND(ACK) | | | 5.7|-------------->| | | | | | | Figure 19: L2 Static Subscriber Access For L2 static subscriber access, the process starts with a CP installing a static subscriber detection list on an UP. The list determines which subscribers will be detected. This is implemented by exchanging Update_Request and Update_Response messages between CP and UP. The format of the messages are as follows: Hu, et al [Page 38] INTERNET-DRAFT Simple BNG CUSP ::= ::= For L2 Static subscriber access, there are three ways to trigger the access process: 1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP address, the access interface, and VLAN of the RG. The UP will actively trigger the access flow by sending an ARP/ND packet to the RG. If the RG is online, it will reply with an ARP/ND to the UP. The UP will tunnel the ARP/ND to the CP through the Si. The CP then triggers the authentication process. If the authentication result is positive. The CP will create a corresponding subscriber session on the UP. 2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as option 1 (triggered by UP). The difference is that the RG will actively send the ARP/ND to trigger the process. 3. Triggered by RG IP traffic (5.1-5.7): This is for the case where the RG has the ARP/ND information, but the subscriber session on the UP is lost (e.g., due to failure on the UP, or the UP restarted). That means the RG may keep sending IP packets to the UP. The packets will trigger the UP to start a new access process. From a subscriber session point of view, the procedures and the message formats for the above three cases are the same, as follows: IPv4 Case: ::= [] ::= [] IPv6 Case: ::= [] Hu, et al [Page 39] INTERNET-DRAFT Simple BNG CUSP ::= 5.2. PPPoE 5.2.1. IPv4 PPPoE Access The following figure shows the IPv4 PPPoE access call flow. RG UP CP AAA | | | | | PPPoE Disc | PPPoE Disc | | 1|<------------->|<---------via Si------->| | | | | | | PPP LCP | PPP LCP | | 2|<------------->|<---------via Si------->| | | | | AAA | | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 3|<------------->|<---------via Si------->|<------------->| | | | | | PPP IPCP | PPP IPCP | | 4|<------------->|<---------via Si------->| | | | | | | | Create subscriber | | | | session Request | | | 5|<--------via Ci---------| | | | | | | | Create subscriber | | | | session Response | | | 6|---------via Ci-------->| | | | | | | | | Accounting | | | 7|<------------->| | | | | Figure 20: IPv4 PPPoE Access From the above sequence, step 1-4 are the standard PPPoE call flow. The UP is responsible for redirecting the PPPoE control packets to the CP or RG. The PPPoE control packets are transmitted between the CP and UP through the Si. After the PPPoE call flow, if the subscriber passed the AAA authentication and authorization, the CP will create a corresponding session on the UP through the Ci. The formats of the messages are as follows: Hu, et al [Page 40] INTERNET-DRAFT Simple BNG CUSP ::= [] ::= [] 5.2.2. IPv6 PPPoE Access The following figure describes the IPv6 PPPoE access call flow. RG UP CP AAA | | | | | PPPoE Disc | PPPoE Disc | | 1|<------------->|<--------via Si-------->| | | | | | | PPP LCP | PPP LCP | | 2|<------------->|<---------via Si------->| | | | | AAA | | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 3|<------------->|<---------via Si------->|<------------->| | | | | | PPP IP6CP | PPP IP6CP | | 4|<------------->|<---------via Si------->| | | | | | | | Create subscriber | | | | session Request | | | 5|<--------via Ci---------| | | | | | | | Create subscriber | | | | session Response | | | 6|---------via Ci-------->| | | | | | | ND Negotiation| ND Negotiation | | 7|<------------->|<---------via Si------->| | | | | | | | Update subscriber | | | | session Request | | | 8|<--------via Ci---------| | | | | | | | Update subscriber | | | | session Response | | | 9|---------via Ci-------->| | | | | | Hu, et al [Page 41] INTERNET-DRAFT Simple BNG CUSP | | | Accounting | | | 10|<------------->| | | | | | DHCPv6 | DHCPv6 | | | Negotiation | Negotiation | | 7'|<------------->|<---------via Si------->| | | | | | | | Update subscriber | | | | session Request | | | 8'|<---------via Ci--------| | | | | | | | Update subscriber | | | | session Response | | | 9'|---------via Ci-------->| | | | | | | | | Accounting | | | 10'|<------------->| | | | | Figure 21: IPv6 PPPoE Access From the above sequence, steps 1-4 are the standard PPPoE call flow. The UP is responsible for redirecting the PPPoE control packets to the CP or RG. The PPPoE control packets are transmitted between the CP and UP through the Si. After the PPPoE call flow, if the subscriber passed the AAA authentication and authorization, the CP will create a corresponding session on the UP through the Ci. The formats of the messages are as follows: ::= [] ::= Then, the RG will initialize a ND/DHCPv6 negotiation process with the CP (see step 7 and 7'), after that, it will trigger an update (8-9, 8'-9') to the subscriber session. The formats of the update messages are as follows: Hu, et al [Page 42] INTERNET-DRAFT Simple BNG CUSP ::= [] ::= 5.2.3. PPPoE Dual Stack Access The following figure shows a combination of IPv4 and IPv6 PPPoE access call flow. RG UP CP AAA | | | | |PPPoE Discovery| PPPoE Discovery | | 1|<------------->|<---------via Si------->| | | | | | | PPP LCP | PPP LCP | | 2|<------------->|<---------via Si------->| | | | | AAA | | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | 3|<------------->|<---------via Si------->|<------------->| | | | | | PPP IPCP | PPP IPCP | | 4|<------------->|<---------via Si------->| | | | | | | | Create v4 subscriber | | | | session Request | | | 5|<--------via Ci---------| | | | Create v4 subscriber | | | | session Response | | | 6|---------via Ci-------->| | | | | Accounting | | | 7|<------------->| | PPP IP6CP | PPP IP6CP | | 4'|<------------->|<---------via Si------->| | | | | | | | Create V6 subscriber | | | | session Request | | | 5'|<--------via Ci---------| | | | Create v6 subscriber | | | | session Response | | | 6'|---------via Ci-------->| | | | | | | ND Negotiation| ND Negotiation | | Hu, et al [Page 43] INTERNET-DRAFT Simple BNG CUSP 8|<------------->|<---------via Si------->| | | | | | | | Update v6 subscriber | | | | session Request | | | 9|<---------via Ci--------| | | | Update v6 subscriber | | | | session Response | | | 10|---------via Ci-------->| | | | | Accounting | | | 7'|<------------->| | DHCPv6 | DHCPv6 | | | Negotiation | Negotiation | | 8'|<------------->|<---------via Si------->| | | | | | | | Update v6 subscriber | | | | session Request | | | 9'|<--------via Ci---------| | | | | | | | Update v6 subscriber | | | | session Response | | | 10'|---------via Ci-------->| | | | | | | | | Accounting | | | 7"|<------------->| | | | | Figure 22: PPPoE Dual Stack Access PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE access. The process is as above. The formats of the messages are as follows: 1. Create an IPv4 PPPoE subscriber session (5-6) ::= [] ::= [] 2. Create an IPv6 PPPoE subscriber session (5'-6') ::= Hu, et al [Page 44] INTERNET-DRAFT Simple BNG CUSP [] ::= 3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10') ::= [] ::= 5.3. WLAN Access The following figure shows the WLAN access call flow. RG UP CP AAA WEB Server | | | | | | DHCP | | | | | Discovery | | | | 1|------------>| | | | | | DHCP | | | | | Discovery | | | | 2|-----via Si---->| AAA | | | | DHCP Offer |<-------->| | | 3|<----via Si-----| | | | DHCP Offer | | | | 4|<------------| | | | | DHCP | | | | | Request | | | | 5|------------>| | | | | | DHCP Request | | | | 6|-----via Si---->| | | | | | | | | | Create session | | | | | Request | | | | 7|<----via Ci-----| | | | | Create session | | | | | Response | | | | 8|----via Ci----->| | | | | | | | Hu, et al [Page 45] INTERNET-DRAFT Simple BNG CUSP | | DHCP ACK | | | | 9|<----via Si-----| | | | | | | | | DHCP ACK | | | | 10|<------------| | | | | | | | | | Subscriber | | | | | HTTP Traffic| | | | 11|------------>|--> | | | | | | WEB URL | | | | Traffic | | Redirect | | | | Redirection | | | | | 12|<------------|<-+ | | | | | | | | | 13|-----------------Redirect to Web server------------->| | | 14|<----------------Push HTTP log-in page---------------| | | 15|-----------------User Authentication---------------->| | | | | | Portal Interchange | | | 16|<-------------------->| | | | | | | | AAA | | | | | Req/Rep | | | | 17|<-------->| | | | | | | | | Update session | | | | | Request | | | | 18|<----via Ci-----| | | | | | | | | | Update session | | | | | Response | | | | 19|-----via Ci---->| | | | | | | | Figure 23: WLAN Access WLAN access starts with the DHCP dial-up process (steps 1-6), after that the CP will create a subscriber session on the UP (steps 7-8). The formats of the session creation messages are as follows: IPv4 Case: ::= [] Hu, et al [Page 46] INTERNET-DRAFT Simple BNG CUSP ::= [] IPv6 Case: ::= [] ::= After step 10, the RG will be allocated an IP address and its first HTTP packet will be redirected to a WEB server for subscriber authentication (steps 11-17). After the WEB authentication, if the result is positive, the CP will update the subscriber session by using the following message exchanges: IPv4 Case: ::= [] ::= [] IPv6 Case: ::= [] ::= 5.4. L2TP 5.4.1. L2TP LAC Access RG UP(LAC) CP(LAC) AAA LNS | | | | | | PPPoE | PPPoE | | | Hu, et al [Page 47] INTERNET-DRAFT Simple BNG CUSP | Discovery | Discovery | | | 1|<---------->|<---via Si--->| | | | | | | | | PPP LCP | PPP LCP | | | 2|<---------->|<---via Si--->| | | | | | AAA | | |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| | 3|<---------->|<---via Si--->|<------>| | | | | | | | PPP IPCP | PPP IPCP | | | 4|<---------->|<---via Si--->| | | | | | | | | | L2TP tunnel | | | | | negotiation | | | | | SCCRQ/ | | | | | SCCRP/ | | | | | SCCCN | | | | 5|<---via Si--->| | | | | /\ | | | || forward | | | \/ | | |<-----------via routing---------->| | | | | | L2TP session | | | | | negotiation | | | | | ICRQ/ | | | | | ICRP/ | | | | | ICCN | | | | 6|<---via Si--->| | | | | /\ | | | || forward | | | \/ | | |<-----------via routing---------->| | | | | | Create | | | | | subscriber | | | | | session | | | | | Request | | | | 7|<---via Ci----| | | | | | | | | | Create | | | | | subscriber | | | | | session | | | | | Response | | | | 8|----via Ci--->| | | | | | | | | | | PAP/CHAP (Triggered by LNS) | 9|<-----------------via routing?---------------->| | | Hu, et al [Page 48] INTERNET-DRAFT Simple BNG CUSP Figure 24: L2TP-LAC Access Steps 1-4 are a standard PPPoE access process. After that the LAC-CP starts to negotiate an L2TP session and tunnel with the LNS. After the negotiation, the CP will create an L2TP LAC subscriber session on the UP through the following messages: ::= ::= 5.4.2. L2TP LNS IPv4 Access RG LAC UP(LNS) AAA CP(LNS) | | | | | | PPPoE | | | | | Discovery | | | | 1|<---------->| | | | | | | | | | PPP LCP | | | | 2|<---------->| | | | | AAA | | |PPP PAP/CHAP| Req/Rep | | 3|<---------->|<--------------------->| | | | | | | | | | L2TP tunnel | L2TP tunnel | | | negotiation | negotiation | | | SCCRQ/ | SCCRQ/ | | | SCCRP/ | SCCRP/ | | | SCCCN | SCCCN | | 4|<------------>|<------via Si----->| | | | | | | L2TP session | L2TP session | | | negotiation | negotiation | | | ICRQ/ | ICRQ/ | | | ICRP/ | ICRP/ | | | ICCN | ICCN | | 5|<------------>|<------via Si----->| | | | | | | | Create | | | | subscriber | | | | session | | | | Request | Hu, et al [Page 49] INTERNET-DRAFT Simple BNG CUSP | | 6|<-----via Ci-------| | | | Create | | | | subscriber | | | | session | | | | Response | | | 7|------via Ci------>| | | | PAP/CHAP (Triggered by LNS) | 8|<--------------------------------------------->| | | | | | | AAA | | | | | Req/Rep | | | | 9|<-------->| | | | | | | | PPP IPCP | 10|<--------------------------------------------->| | | | | | Update | | | | subscriber | | | | session | | | | Request | | | 11|<-----via Ci-------| | | | Update | | | | subscriber | | | | session | | | | Response | | | 12|------via Ci------>| | | | | Figure 25: IPv4 L2TP-LNS Access In this case, the BNG is running as an LNS and separated into LNS-CP and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When the L2TP session and tunnel negotiations are finished, the LNS-CP will create an L2TP LNS subscriber session on the LNS-UP. The format of messages are as follows: ::= [] ::= [] Hu, et al [Page 50] INTERNET-DRAFT Simple BNG CUSP After that, the LNS-CP will trigger an AAA authentication. If the authentication result is positive, a PPP IPCP process will follow, then the CP will update the session with the following message exchanges: ::= [] ::= [] 5.4.3. L2TP LNS IPv6 Access RG LAC UP(LNS) AAA CP(LNS) | | | | | | PPPoE | | | | | Discovery | | | | 1|<---------->| | | | | | | | | | PPP LCP | | | | 2|<---------->| | | | | AAA | | |PPP PAP/CHAP| Req/Rep | | 3|<---------->|<--------------------->| | | | | | | | | | L2TP tunnel | L2TP tunnel | | | negotiation | negotiation | | | SCCRQ/ | SCCRQ/ | | | SCCRP/ | SCCRP/ | | | SCCCN | SCCCN | | 4|<------------>|<------via Si----->| | | | | | | L2TP session | L2TP session | | | negotiation | negotiation | | | ICRQ/ | ICRQ/ | | | ICRP/ | ICRP/ | | | ICCN | ICCN | | 5|<------------>|<------via Si----->| | | | | | | | Create | Hu, et al [Page 51] INTERNET-DRAFT Simple BNG CUSP | | | subscriber | | | | session | | | | Request | | | 6|<-----via Ci-------| | | | Create | | | | subscriber | | | | session | | | | Response | | | 7|------via Ci------>| | | | PAP/CHAP (Triggered by LNS) | 8|<--------------------------------------------->| | | | | | | AAA | | | | | Req/Rep | | | | 9|<-------->| | | | | | | | | PPP IP6CP | 10|<--------------------------------------------->| | | | | | Update | | | | subscriber | | | | session | | | | Request | | | 11|<-----via Ci-------| | | | Update | | | | subscriber | | | | session | | | | Response | | | 12|------via Ci------>| | | | | | | | | ND negotiation | ND negotiation | 13|<------------------------->|<-----via Si------>| | | | | | | Update | | | | subscriber | | | | session | | | | Request | | | 14|<-----via Ci-------| | | | Update | | | | subscriber | | | | session | | | | Response | | | 15|------via Ci------>| | | | | Figure 26: L2TP-LNS IPv6 Access Hu, et al [Page 52] INTERNET-DRAFT Simple BNG CUSP Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5 finish the normal L2TP dial-up process. When the L2TP session and tunnel negotiations are finished, the LNS-CP will create an L2TP LNS subscriber session on the LNS-UP. The format of the messages is as follows: ::= [] ::= After that, the LNS-CP will trigger a AAA authentication. If the authentication result is positive, a PPP IP6CP process will follow, then the CP will update the session with the following message exchanges: ::= [] ::= Then, an ND negotiation will be triggered by the RG. After the ND negotiation, the CP will update the session with the following message exchanges: ::= [] ::= Hu, et al [Page 53] INTERNET-DRAFT Simple BNG CUSP 5.5. CGN (Carrier Grade NAT) RG UP CP AAA | | | | | | Public Address Block | | | | Allocation Request | | | 1|<--------via Ci-------->| | | | Public Address Block | | | | Allocation Reply | | | 2|---------via Ci-------->| | | | | | | Subscriber | | | | access request| Subscriber | | 3|-------------->| access request | | | 4|----------via Si------->| | | | | AAA | | | Subscriber | Req/Rep | | Subscriber | access reply 5|<------------->| | access reply 6|<---------via Si--------| | 7|<--------------| | | | | | | | | Create subscriber | | | | session Request | | | 8|<--------via Ci---------| | | | | | | | Create subscriber | | | | session Response | | | | (with NAT information) | | | 9|---------via Ci-------->| | | | | | | | | Accounting | | | | with source | | | | information | | | 10|<------------->| | | | Public IP + | | | | Port range | | | | to Private IP| | | | mapping | | | | | Figure 27: CGN Access The first steps allocate one or more CGN address blocks to the UP (steps 1-2). This is achieved by the following message exchanges between CP and UP. Hu, et al [Page 54] INTERNET-DRAFT Simple BNG CUSP ::= ::=
Steps 3-9 show the general dial-up process in the case of CGN mode. The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in above sections. If a subscriber is a CGN subscriber, once the subscriber session is created/updated, the UP will report the NAT information to the CP. This is achieved by carrying the "Subscriber CGN Port Range TLV" in the Update_Response message. 5.6. L3 Leased Line Access 5.6.1. Web Authentication RG UP CP AAA WEB Server | | | | | | User | | | | | traffic | | | | 1|------------>| | | | | | User | | | | | traffic | | | | 2|-----via Si---->| AAA | | | | | Req/Rep | | | | 3|<-------->| | | | Create session | | | | | Request | | | | 4|<----via Ci-----| | | | | | | | | | Create session | | | | | Response | | | | 5|----via Ci----->| | | | HTTP | | | | | traffic | | | | 6|------------>| | | | | | | | | | Redirect to | | | | | Web URL | | | | 7|<------------| | | | | | | | | | | 8|-----------------Redirected to Web server----------->| Hu, et al [Page 55] INTERNET-DRAFT Simple BNG CUSP | | 9|<----------------Push HTTP Log-in page---------------| | | 10|-----------------User Authentication---------------->| | | | | | Portal Interchange | | | 11|<-------------------->| | | | | | | | AAA | | | | | Req/Rep | | | | 12|<-------->| | | | | | | | | | | | | | Update session | | | | | Request | | | | 13|<----via Ci-----| | | | | | | | | | Update session | | | | | Response | | | | 14|----via Ci----->| | | | | | | | Figure 28: Web Authentication based L3 Leased Line Access In this case, IP traffic from the RG will trigger the CP to authenticate the RG by checking the source IP and the exchanges with the AAA server. Once the RG passed the authentication, the CP will create a corresponding subscriber session on the UP through the following message exchanges: IPv4 Case: ::= [] ::= [] IPv6 Case: ::= [] ::= Hu, et al [Page 56] INTERNET-DRAFT Simple BNG CUSP Then, the HTTP traffic from the RG will be redirected to a WEB server to finish the WEB authentication. Once the WEB authentication is passed, the CP will trigger another AAA authentication. After the AAA authentication, the CP will update the session with the following message exchanges: IPv4 Case: ::= [] ::= [] IPv6 Case: ::= [] ::= 5.6.2. User Traffic Trigger RG UP CP AAA | | | | | | L3 access | | | | control list | | | 1|<----via Ci-----| | | User | | | | traffic | | | 2|------------>| | | | | User | | | | traffic | | | 3|-----via Si---->| | | | | AAA | | | | Req/Rep | | | 4|<-------->| | | | | | | Create session | | | | Request | | | 5|<----via Ci-----| | | | Create session | | Hu, et al [Page 57] INTERNET-DRAFT Simple BNG CUSP | | Response | | | 6|----via Ci----->| | | | | | Figure 29: User Traffic Triggered L3 Leased Line Access In this user traffic triggered case, the CP must install an access control list on the UP, which is used by the UP to determine whether an RG is legal or not. If the traffic is from a legal RG, it will be redirected to the CP though the Si. The CP will trigger a AAA interchange with the AAA server. After that, the CP will create a corresponding subscriber session on the UP with the following message exchanges: IPv4 Case: ::= [] ::= [] IPv6 Case: ::= [] ::= 5.7. Multicast Access RG UP CP AAA | | | | | User access | User access | AAA | | request | request | Req/Rep | 1|<----------->|<----via Si---->|<-------->| | | User | | | | | | | | | | | | Create session | | | | Request | | | 2|<----via Ci---->| | Hu, et al [Page 58] INTERNET-DRAFT Simple BNG CUSP | | | | | | Create session | | | | Response | | | 3|----via Ci----->| | | | | | | Multicast | | | | negotiation | | | 4|<----------->| | | | | | | Figure 30: Multicast Access Multicast access starts with an user access request from the RG. The request will be redirected to the CP by the Si. A follow-up AAA interchange between the CP and the AAA server will be triggered. After the authentication, the CP will create a multicast subscriber session on the UP through the following messages: IPv4 Case: ::= [] ::= [] IPv6 Case: ::= [] ::= Hu, et al [Page 59] INTERNET-DRAFT Simple BNG CUSP 6. S-CUSP Message Formats An S-CUSP message consists of a common header followed by a variable- length body consisting entirely of TLVs. Receiving an S-CUSP message with an unknown message type or missing mandatory TLV MUST trigger an Error message (see Section 6.7) or a response message with an Error Information TLV (see Section 7.6). Conversely, if a TLV is optional, the TLV may or may not be present. Optional TLVs are indicated in the message formats shown in this document by being enclosed in square brackets. This section specifies the format of the common S-CUSP message header and lists the defined messages. Network byte order is used for all multi-byte fields. 6.1. Common Message Header S-CUSP Common Message Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Resv | Message-Type | Message-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6.1: S-CUSP Message Common Header o Ver (4 bits): The major version of the protocol. This document specifies version 1. Different major versions of the protocol may have significantly different message structure and format except that the Ver field will always be in the same place at the beginning of each message. A successful S-CUSP session depends on the CP and the UP both using the same major version of the protocol. o Resv (4 bits): Reserved. MUST be sent as zero and ignored on receipt. o Message-Type (8 bits): The set of message types specified in this document is listed in Section 9.1. o Message-Length (16 bits): Total length of the S-CUSP message including the common header, expressed in number of bytes as an unsigned integer. Hu, et al [Page 60] INTERNET-DRAFT Simple BNG CUSP o Transaction ID (16 bits): This field is used to identify requests. It is echoed back in any corresponding ACK / response / Error message. It is RECOMMENDED that a monotonically increasing value be used in successive message and that value wrap back to zero after 0xFFFF. The contents of this field is an opaque value that the receiver MUST NOT use for any purpose except to echo back in a corresponding response and, optionally, for logging. 6.2. Control Messages This document defines the following control messages: Type Name Notes and TLVs that can be carried ---- ---- ------------------------------------ 1 Hello Hello TLV, Keep-Alive TLV. 2 Keepalive A common header with the Keepalive message type. 3 Sync_Request Synchronization request. 4 Sync_Begin Synchronization starts. 5 Sync_Data Synchronization data: TLVs specified in Section 5. 6 Sync_End End synchronization. 7 Update_Request TLVs specified in Sections 7.6-7.9. 8 Update_Response TLVs specified in Sections 7.6-7.9. 6.2.1. Hello Message Hello message is used for S-CUSP session establishment and version negotiation. The detail of S-CUSP session establishment and version negotiation can be found in Section 4.1.1. The format of Hello message is as follows: ::= [] The return code and negotiation result will be carried in the Error Information TLV. They are listed as follows: 0: Success, version negotiation success. 1: Failure, malformed message received. Hu, et al [Page 61] INTERNET-DRAFT Simple BNG CUSP 2: One or more of the TLVs was not understood. 1001: The version negotiation fails. The S-CUSP session establishment phase fails. 1002: The keepalive negotiation fails. The S-CUSP session establishment phase fails. 1003: The establishment timer expires. session establishment phase fails. 6.2.2. Keepalive Message The Keepalive message is periodically sent by each end of an S-CUSP session. It is used to detect whether the peer end is still alive. The Keepalive procedures are defined Section 4.1.2. The format of the Keepalive message is as follows: ::= 6.2.3. Sync_Request Message The Sync_Request message is used to request synchronization from an S-CUSP peer. Both CP and UP can request their peer to synchronize data. The format of the Sync_Request message is as follows: ::= A Sync_Request message may result in a Sync_Begin message from its peer. The Sync_Begin message is defined in Section 6.2.4. 6.2.4. Sync_Begin Message The Sync_Begin message is a reply to a Sync_Request message. It is used to notify the synchronization requester whether the synchronization can be started. The format of Sync_Begin message is as follows: ::= Hu, et al [Page 62] INTERNET-DRAFT Simple BNG CUSP The return codes are carried in the Error Information TLV. The codes are listed below: 0: Success, be ready to synchronize. 1: Failure, malformed message received. 2: One or more of the TLVs was not understood. 2001: Synch-NoReady. The data to be synchronized is not ready. 2002: Synch-Unsupport. The data synchronization is not supported. 6.2.5. Sync_Data Message The Sync_Data message is used to send data being synchronized between the CP and UP. The Sync_Data message has the same function and format as the Update_Request message. The difference is that there is no ACK for a Sync_Data message. An error caused by the Sync_Data message will result in a Sync_End message. There are two scenarios: Synchronization from UP to CP: Synchronize the resource data to CP. ::= [] Synchronization from CP to UP: Synchronize all subscriber sessions to UP. As for which TLVs should be carried, it depends on the specific session data to be synchronized. This is equivalent to create the specific session. Refer to Section 5 to see more details. ::= [] [] [] [] [] 6.2.6. Sync_End Message The Sync_End message is used to indicate the end of a synchronization process. The format of a Sync_End message is as follows: Hu, et al [Page 63] INTERNET-DRAFT Simple BNG CUSP ::= The return/error codes are listed as follows: 0: Success, synchronization finished. 1: Failure, malformed message received. 2: One or more of the TLVs was not understood. 6.2.7. Update_Request Message The Update_Request message is a multi-task message, it can be used to create, update, and delete subscriber sessions on a UP. For session operations, the specific operation is controlled by the "Oper" field of the carried TLVs. As defined in Section 7.1, the "Oper" can be set to either "update" or "delete" when a TLV is carried in an Update_Request message. When the "Oper" set to update, it means to create or update a subscriber session, if the "Oper" set to delete, it indicates to delete a corresponding session on an UP. The format of Update_Request message is as follows: ::= [] [] [] [] [] Each Update_Request message will result in an Update_Response message that is defined in Section 6.2.8. 6.2.8. Update_Response Message The Update_Response message is a response to an Update_Request message. It is used to confirm the update request (or reject it in the case of an error). The format of an Update_Response message is as follows: Hu, et al [Page 64] INTERNET-DRAFT Simple BNG CUSP ::= [] The return/error codes are carried in the Error Information TLV. They are listed as follows: 0: Success. 1: Failure, malformed message received. 2: One or more of the TLVs was not understood. 3001(Pool-Mismatch): The corresponding address pool cannot be found. 3002 (Pool-Full): The address pool is fully allocated and no address segment is available. 3003 (Subnet-Mismatch): The address pool subnet cannot be found. 3004 (Subnet-Conflict): Subnets in the address pool have been classified into other clients. 4001 (Update-Fail-No-Res): The forwarding table fails to be delivered because the forwarding resources are insufficient. 4002 (QoS-Update-Success): The QoS policy takes effect. 4003 (QoS-Update-Sq-Fail): Failed to process the queue in the QoS policy. 4004 (QoS-Update-CAR-Fail): Processing of the CAR in the QoS policy fails. 4005 (Statistic-Fail-No-Res): Statistics processing failed due to insufficient statistics resources. 6.3. Event Message The Event message is used to report subscriber session traffic statistics and detection information. The format of Event message is as follows: ::= [] [] Hu, et al [Page 65] INTERNET-DRAFT Simple BNG CUSP 6.4. Report Message The Report message is used to report board and interface status on a UP. The format of Report message is as follows: ::= [] [] 6.5. CGN Messages This document defines the following resource allocation messages: Type Message Name TLV that is carried ---- ------------------- ------------------------ 200 Addr_Allocation_Req Address Allocation Request 201 Addr_Allocation_Ack Address Allocation Response 202 Addr_Renew_Req Address Renewal Request 203 Addr_Renew_Ack Address Renewal Response 204 Addr_Release_Req Address Release Request 205 Addr_Release_Ack Address Release Response 6.5.1. Addr_Allocation_Req Message The Addr_Allocation_Req message is used to request CGN address allocation. The format of Addr_Allocation_Req message is as follows: ::=
6.5.2. Addr_Allocation_Ack Message The Addr_Allocation_Ack message is a response to an Addr_Allocation_Req message. The format of Addr_Allocation_Ack message is as follows: ::=
Hu, et al [Page 66] INTERNET-DRAFT Simple BNG CUSP 6.5.3. Addr_Renew_Req Message The Addr_Renew_Req message is used to request address renewal. The format of Addr_Renew_Req message is as follows: ::=
6.5.4. Addr_Renew_Ack Message The Addr_Renew_Ack message is a response to an Addr_Renew_Req message. The format of Addr_Renew_Req message is as follows: ::=
6.5.5. Addr_Release_Req Message The Addr_Release_Req message is used to request address release. The format of Addr_Release_Req message is as follows: ::=
6.5.6. Addr_Release_Ack Message The Addr_Release_Ack message is a response to an Addr_Release_Req message. The format of Addr_Release_Ack message is as follows: ::=
6.6. Vendor Message The Vendor message is, in conjunction with the vendor TLV and vendor sub-TLV, can be used by vendors to extend the S-CUSP protocol. It's message type is 11. If the receiver does not recognize the message, an Error message will be returned to the sender. Hu, et al [Page 67] INTERNET-DRAFT Simple BNG CUSP The format of the Vendor message is as follows: ::= [] 6.7 Error Message The Error message is defined to return some critical error information to the sender. If a receiver does not know the message type of a received message, it MUST return an Error message to the sender. The format of the Error message is as below: ::= Hu, et al [Page 68] INTERNET-DRAFT Simple BNG CUSP 7. S-CUSP TLVs and Sub-TLVs This section specifies the following: o the format of the TLVs that appear in S-CUSP messages, o the format of the sub-TLVs that appear within the values of some TLVs, and o the format of some basic data fields that appear within TLVs or sub-TLVs. See Section 9 for a list of all defined TLVs and sub-TLVs. 7.1. Common TLV Header S-CUSP messages consist of the common header specified in Section 6.1 followed by TLVs formatted as specified in this section. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Oper | TLV-Type | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 32: Common TLV Header o Oper (4 bits): For Message-Types that indicate an operation on a data set, the Oper field is interpreted as Update, Delete, or Reserved as specified in Section 9.3. For all other Message-Types, the Oper field MUST be sent as zero and ignored on receipt. o TLV-Type (12 bits): The Type of a TLV, that is the meaning and format of the Value part, are determined by the TLV-Type of the TLV. See Section 9.2. o TLV-Length (2 bytes): The length of the Value portion of the TLV in bytes as an unsigned integer. o Value (variable length): This is the value portion of the TLV whose size is given by TLV-Length. The value portion consists of fields, frequently using one of the basic data field types (see Section 7.2) and sub-TLVs (see Section 7.3). Hu, et al [Page 69] INTERNET-DRAFT Simple BNG CUSP 7.2. Basic Data Fields This section specifies the binary format of several standard basic data fields that are used within other data structures in this specification. o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section 7.3) to provide the length. The use of this data type in S-CUSP is to provide convenient labels for use by network operators in configuring and debugging their networks and interpreting S-CUSP messages. These labels will not normally be seen by subscribers. They are normally interpreted as ASCII [RFC20]. o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042]. o IPv4-Address: 8 octets. 4 octets of the IPv4 address value followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX. o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4 octet integer n in the range of 0 to 128 which gives the address mask as the one's complement of 2**(128-n) - 1. o VLAN ID: 2 octets. As follows [802.1Q]: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRI |D| VLAN-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PRI: Priority. Default value 7. D: Drop Eligibility Indicator (DEI). Default value 0. VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are not valid VLAN IDs [802.1Q].) Hu, et al [Page 70] INTERNET-DRAFT Simple BNG CUSP 7.3. Sub-TLV Format and Sub-TLVs In some cases, the Value portion of a TLV, as specified above, can contain one or more Sub-TLVs formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Figure 33: Sub-TLV Header o Type (2 bytes): The Type of a Sub-TLV, that is the meaning and format of the Value part, are determined by the Type of the TLV. Sub-TLV Types numbers have the same meaning regardless of the TLV Type of the TLV within which the sub-TLV occurs. See Section 9.4. o Length (2 bytes): The length of the Value portion of the sub- TLV in bytes as an unsigned integer. o Value (variable length): This is the value portion of the sub- TLV whose size is given by Length. The sub-TLVs currently specified are defined in the following subsections. 7.3.1. Name sub-TLVs This document defines the following name sub-TLVs that are used to carry the name of the corresponding object. The length of each of these sub-TLV is variable from 1 to 255 octets. The value is of type STRING padded with zeros octets to 4-octet alignment. Type Sub-TLV Name Meaning ----- -------------------- ------------------- 1 VRF-Name The name of a VRF 2 Ingress-QoS-Profile The name of an ingress QoS profile 3 Egress-QoS-Profile The name of an egress QoS profile 4 User-ACL-Policy The name of an ACL policy 5 Multicast-ProfileV4 The name of an IPv4 multicast profile 6 Multicast-ProfileV6 The name of an IPv6 multicast profile 7 NAT-Instance The name of a NAT instance 8 Pool-Name The name of an address pool Hu, et al [Page 71] INTERNET-DRAFT Simple BNG CUSP 7.3.2. Ingress-CAR sub-TLV The Ingress-CAR sub-TLV indicates the authorized upstream Committed Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR sub-TLV is 9 and the sub-TLV length is 16. The format is as shown in Figure 34. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIR (Committed Information Rate) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIR (Peak Information Rate) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBS (Committed Burst Size) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PBS (Peak Burst Size) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 34: Ingress-CAR sub-TLV Where: CIR (4 bytes): Guaranteed rate in bits/second. PIR (4 bytes): Burst rate in bits/second. CBS (4 bytes): The token bucket in bytes. PBS (4 bytes): Burst token bucket in bytes. These fields are unsigned integers. More details about CIR, PIR, CBS, and PBS can be found in [RFC2698]. 7.3.3. Egress-CAR sub-TLV The Egress-CAR sub-TLV indicates the authorized downstream Committed Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub- TLV is 10 and its sub-TLV length is 16 octets. The format of the value part is as defined below. Hu, et al [Page 72] INTERNET-DRAFT Simple BNG CUSP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIR (Committed Information Rate) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIR (Peak Information Rate) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBS (Committed Burst Size) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PBS (Peak Burst Size) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 35: Egress-CAR sub-TLV Where: CIR (4 bytes): Guaranteed rate in bits/second. PIR (4 bytes): Burst rate in bits/second. CBS (4 bytes): The token bucket in bytes. PBS (4 bytes): Burst token bucket in bytes. These fields are unsigned integers. More details about CIR, PIR, CBS, and PBS can be found in [RFC2698]. 7.3.4. If-Desc sub-TLV The If-Desc sub-TLV is defined to designate an interface. It is an optional sub-TLV that may be carried in those TLVs that have an "if- index" or "out-if-index" field. The If-Desc sub-TLV is used as a local unique identifier within a BNG. The sub-TLV type is 11 and the sub-TLV length is 12 octets. The format depends on the If-Type. The format of the value part is as follows: Hu, et al [Page 73] INTERNET-DRAFT Simple BNG CUSP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Type (1-5)| Chassis | Slot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Slot | Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If-Desc sub-TLV (Physical Port) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Type (6-7) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Logic-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If-Desc sub-TLV (Virtual Port) Figure 36: If-Desc sub-TLV Formats Where: If-Type: 8 bits in length, indicates the type of an interface. Following types are defined in this document: 0: Reserved 1: Fast Ethernet (FE) 2: GE 3: 10GE 4: 100GE 5: Eth-Trunk 6: Tunnel 7: VE 8-255: Reserved. Chassis (8 bits): Identifies the chassis that the interface belongs to. Slot (16 bits): Identifies the slot that the interface belongs to. Sub-slot (16 bits): Identifies the sub-slot the interface belongs to. Port Number (16 bits): An identifier of a physical port/interface (e.g., If-Type: 1-5). It is locally significant within the slot/sub-slot. Hu, et al [Page 74] INTERNET-DRAFT Simple BNG CUSP Sub-port Number (32 bits): An identifier of the sub-port. Locally significant within its "parent" port (physical or virtual). Logic-ID (32 bits): An identifier of a virtual interface (e.g., If-Type: 6-7) 7.3.5. IPv6 Address List sub-TLV The IPv6 Address List sub-TLV is used to convey one or more IPv6 addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV type is 12, the sub-TLV length is variable. The format of IPv6 Addresses sub-TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 37: IPv6 Address List sub-TLV Where: IP Address (IPv6-Address): Each IP Address is an IP-Address type, carries an IPv6 address. 7.3.6. Vendor sub-TLV The Vendor sub-TLV is intended to be used inside the value portion of the Vendor TLV (Section 7.13). It provides a Sub-Type that effectively extends the sub-TLV type in the sub-TLV header and provides for versioning of vendor sub-TLVs. The value part of the Vendor sub-TLV is formatted as follows: Hu, et al [Page 75] INTERNET-DRAFT Simple BNG CUSP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Sub-Type-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ value (other as specified by vendor) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 38: Vendor sub-TLV Where: The sub-TLV type: 13. The sub-TLV length: variable. Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865]. Sub-Type (2 bytes): Used by the Vendor to distinguish multiple different sub-TLVs. Sub-Type-Version (2 bytes): Used by the Vendor to distinguish different versions of a Vendor Defined sub-TLV sub-Type. value: as specified by the vendor. Since Vendor code will be handling the sub-TLV after the Vendor ID field is recognized, the remainder of the sub-TLV can be organized however the vendor wants. But it desirable for a vendor to be able to define multiple different vendor sub-TLVs and to keep track of different versions of its vendor defined sub-TLVs. Thus, it is RECOMMENDED that the vendor assign a Sub-Type value for each of that vendor's sub-TLVs that is different from other Sub-Type values that vendor has used. Also, when modifying a vendor defined sub-TLV in a way potentially incompatible with a previous definition, the vendor SHOULD increase the value it is using in the Sub-Type-Version field. Hu, et al [Page 76] INTERNET-DRAFT Simple BNG CUSP 7.4. The Hello TLV The Hello TLV is defined to be carried in the Hello message for version and capabilities negotiation. It indicates the S-CUSP sub- version and capabilities supported. The format of Hello TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VerSupported | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 39: Hello TLV Where: The TLV type is 100. The TLV length is 12 octets. The value field consists of three parts: VerSupported: 32 bits in length. This is a bit map of the Sub- Versions of the S-CUSP protocol that the sender supports. This document specifies Sub-Version zero of Major Version 1, that is, Version 1.0. The VerSupported field MUST be non-zero. The VerSupported bits are numbered from 0 as the most significant bit. Bit 0 indicates support of Sub-Version zero, bit 1 indicates support of Sub-Version one, etc. Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS [RFC2865]. Capabilities: 32 bits in length. Flags that indicate the support of particular capabilities by the sender of the Hello. No Capabilities are defined in this document and so implementations will set this field to zero. The Capabilities field of the Hello TLV MUST be checked before any other TLVs in the Hello because capabilities defined in the future might extend existing TLVs or permit new TLVs. After the exchange of Hello messages, the CP and UP each perform a logical AND of the Sub-Version supported by the CP and the UP and separately perform a logical AND of the Capabilities bits fields for the CP and the UP. Hu, et al [Page 77] INTERNET-DRAFT Simple BNG CUSP If the result of the AND of the Sub-Versions supported is zero, then no session can be established and the connection is torn down. If the result of the AND of the Sub-Versions supported is non-zero, then the session uses the highest Sub-Version supported by both the CP and UP. For example, if one side supports Sub-Versions 1, 3, 4, and 5 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 (VerSupported = 0x38000000) then 3 and 4 are the Sub-Versions in common and 4 is the highest Sub-Version supported by both sides. So Sub-Version 4 is used for the session that has been negotiated. The result of the logical AND of the Capabilities bits will show what additional capabilities both sides support. If this result is zero, there are no such capabilities so none can be used during the session. If this result is non-zero, it shows the additional capabilities that can be used during the session. The CP and the UP MUST NOT use a capability unless both advertise support. 7.5. The Keep Alive TLV The Keep Alive TLV is defined to be carried in the Hello message. It provides timing information for the keep alive feature. The format of Hello TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Keepalive | DeadTimer | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 40: Keep Alive TLV Where: The TLV type: 102. The value of length: 4 octets. Keepalive (8 bits): Indicates the maximum period of time (in seconds) between two consecutive S-CUSP messages sent by the sender of the message containing this TLV as an unsigned integer. The minimum value for the Keepalive is 1 second. When set to 0, once the session is established, no further Keepalive messages are sent to the remote peer. A RECOMMENDED value for the Keepalive frequency is 30 seconds. DeadTimer (8 bits in length): Specifies the amount of time as an unsigned integer number of seconds after the expiration of which Hu, et al [Page 78] INTERNET-DRAFT Simple BNG CUSP the S-CUSP peer can declare the session with the sender of the Hello message to be down if no S-CUSP message has been received. The DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive. The Reserved bits MUST be sent as zero and ignored on receipt. 7.6. The Error Information TLV The Error Information TLV is a common TLV that can be used in many Response (e.g., Update_Response message) and ACK messages (e.g., Addr_Allocation_Ack message, etc.). It is used to convey the information about an error in the received S-CUSP message. The format of the Error Information TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Type | Reserved | TLV-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 41: Error Information TLV Where: The TLV type: 101. The value of length: 8 octets. Message-Type(1 byte): This parameter is the message type of the message containing an error. Reserved (1 byte): MUST be sent as zero and ignored on receipt. TLV-Type (2 bytes): Indicates which TLV caused the error. Error Code: 4 bytes in length. Indicate the specific Error Code (see Section 9.5). 7.7. BAS Function TLV The BAS Function TLV is used by a CP to control the access mode, authentication methods, and other related functions of an interface Hu, et al [Page 79] INTERNET-DRAFT Simple BNG CUSP on a UP. The format of the BAS Function TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 42: BAS Function TLV Where: The TLV type: 1. The value of length: variable. If-Index: 4 bytes in length, a unique identifier of an interface of a BNG. Access-Mode: 1 byte in length, indicates the access mode of the interface. This document defines following values: 0: Layer 2 subscriber; 1: Layer 3 subscriber; 2: Layer 2 leased line; 3: Layer 3 leased line; 4-255: Reserved. Auth-Method4: 1 byte in length, for IPv4 scenario, it indicates the authentication on this interface; this field is defined as a bitmap, this document defines following values (other bits are reserved and MUST be sent as zero and ignored on receipt): 0x1: PPPoE authentication; 0x2: DOT1X authentication; 0x4: Web authentication; 0x8: Web fast authentication; 0x10: Binding authentication. Auth-Method6: 1 byte in length, for IPv6 scenario, it indicates the authentication on this interface; this field is defined as a bitmap, this document defines following values (other bits are Hu, et al [Page 80] INTERNET-DRAFT Simple BNG CUSP reserved and MUST be sent as zero and ignored on receipt): 0x1: PPPoE authentication; 0x2: DOT1X authentication; 0x4: Web authentication; 0x8: Web fast authentication; 0x10: Binding authentication; sub-TLVs: The IF-Desc sub-TLV can be carried. If-Desc sub-TLV: carries the interface information. The flags field is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |Y|X|P|I|N|A|S|F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 43: Interface Flags Where: F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a subscriber to go online. 1: enabled, 0: disabled. S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a subscriber to go online. 1: enabled, 0: disabled. A (ARP Trigger) bit: Indicates whether ARP packets can trigger a subscriber to go online. 1: enabled, 0: disabled. N (ND Trigger) bit: Indicates whether ND packets can trigger a subscriber to go online. 1: enabled, 0: disabled. I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable traffic detection. 0: Disable traffic detection. P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable traffic detection. 0: Disable traffic detection. X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy and can process ARP requests across different Port+VLANs. 0: The ARP proxy is not enabled on the interface, and only the ARP requests of the same Port+VLAN are processed. Hu, et al [Page 81] INTERNET-DRAFT Simple BNG CUSP Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and can process ND requests across different Port+VLANs. 0: The ND proxy is not enabled on the interface, and only the ND requests of the same Port+VLAN are processed. MBZ: Reserved bits that MUST be sent as zero and ignored on receipt. 7.8. Routing TLVs Normally, after an S-CUSP session is established between a UP and a CP, the CP will allocate one or more blocks of IP addresses to the UP. Those IP addresses will be allocated to subscribers who will dial-up to the UP. In order to make sure that other nodes within the network learn how to reach those IP addresses, the CP needs to install one or more routes that can reach those IP addresses on the UP and notify the UP to advertise the routes to the network. The Routing TLVs are used by a CP to notify a UP of the network routing. They can be carried in the Update_Request message and Sync_Data message. 7.8.1. IPv4 Routing TLV The IPv4 Routing TLV is used to carry IPv4 network routing related information. Hu, et al [Page 82] INTERNET-DRAFT Simple BNG CUSP The format of the TLV value part is as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next-Hop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out-If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Type | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 44: IPv4 Routing TLV Where: The TLV Type: 7 The TLV Length: Variable User-ID: 4 bytes in length. Carries the user identifier. This field is filled with all Fs when a non-user route is delivered to the UP. Dest-Address (IPv4-Address type): Identifies the destination address. Next-Hop: (IPv4-Address type): Identifies the next hop address. Out-If-Index (4 bytes): Indicates the interface index. Cost (4 bytes): The cost value of the route. Tag (4 bytes): The tag value of the route. Route-Type (2 bytes): Indicates the route type. The options are as follows: Hu, et al [Page 83] INTERNET-DRAFT Simple BNG CUSP 0: User host route 1: Radius authorization FrameRoute 2: Network segment route 3: Gateway route 4: Radius authorized IP route 5: L2TP LNS side user route Advertise-Flag: 1 bit. Indicates whether the route should be advertised by the UP. Following flags are defined: 0: Not advertised, 1: advertised. sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried. VRF-Name sub-TLV: indicates which VRF the route belongs to. If-Desc sub-TLV: carries the interface information. The Reserved field MUST be sent as zero and ignored on receipt. 7.8.2. IPv6 Routing TLV The IPv6 Routing TLV is used to carry IPv6 network routing information. The format of this TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Dest-Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Next-Hop ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out-If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Type | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 45: IPv6 Routing TLV Where: Hu, et al [Page 84] INTERNET-DRAFT Simple BNG CUSP The TLV Type: 7 The TLV Length: Variable User-ID: 4 bytes in length. Carries the user identifier. This field is filled with all Fs when a non-user route is delivered to the UP. IPv6 Dest-Address (IPv6-Address type): Identifies the destination address. IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop address. Out-If-Index (4 bytes): Indicates the interface index. Cost (4 bytes): The cost value of the route. Tag (4 bytes): The tag value of the route. Route-Type: (2 bytes): Indicates the route type. The options are as follows: 0: User host route 1: Radius authorization FrameRoute 2: Network segment route 3: Gateway route 4: Radius authorized IP route 5: L2TP LNS side user route Advertise-Flag: 1 bit. Indicates whether the route should be advertised by the UP. Following flags are defined: 0: Not advertised, 1: advertised. sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried. VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs. If-Desc sub TLV: carries the interface information. The Reserved field MUST be sent as zero and ignored on receipt. 7.9. Subscriber TLVs The Subscriber TLVs are defined for a CP to send the basic information about a user to a UP. Hu, et al [Page 85] INTERNET-DRAFT Simple BNG CUSP 7.9.1. Basic Subscriber TLV The Basic Subscriber TLV is used to carry the basic common information for all kinds of access subscribers. It is carried in an Update_Request message. The format of the Basic Subscriber TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User MAC | Oper ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Type |Sub-access Type| Account Type | Address Family| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-VID | P-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Detect Times | Detect Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 46: Basic Subscriber TLV Where: The TLV Type: 2. The TLV Length: variable in length. User-ID (4 bytes): The identifier of a subscriber. Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero means non-PPPoE subscriber. User-Mac (MAC-Addr type): The MAC Address of a subscriber. Oper-ID (1 byte): Indicates the ID of an operation performed by a user. This field is carried in the response from the UP. Reserved (1 byte): MUST be sent as zero and ignored on receipt. Hu, et al [Page 86] INTERNET-DRAFT Simple BNG CUSP Access-Type (1 byte): 1: PPP access (PPP [RFC1661]) 2: PPP over Ethernet over ATM access (PPPoEoA) 3: PPP over ATM access (PPPoA [RFC3336]) 4: PPP over Ethernet access (PPPoE [RFC2516]) 5: PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) 6: PPP over LNS access (PPPoLNS) 7: IP over Ethernet DHCP access (IPoE_DHCP) 8: IP over Ethernet EAP authentication access (IPoE_EAP) 9: IP over Ethernet Layer 3 access (IPoE_L3) 10: IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) 11: Layer 2 Leased Line access (L2_Leased_Line) 12: Layer 2 VPN Leased Line access (L2VPN_Leased_Line) 13: Layer 3 Leased Line access (L3_Leased_Line) 14: Layer 2 Leased line Sub-User access (L2_Leased_Line_SUB_USER) 15: L2TP LAC tunnel access (L2TP_LAC) 16: L2TP LNS tunnel access (L2TP_LNS) Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP relay is used. 0: Reserved 1: PPP Relay (for LAC) 2: PPP termination (for LNS) Account-Type(1 byte): 0: Collects statistics on IPv4 and IPv6 traffic of terminals independently. 1: Collects statistics on IPv4 and IPv6 traffic of terminals. Address Family (1 byte) 1: IPv4 2: IPv6 3: dual stack C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. The default value of PRI is 7, the value of DEI is 0, and the value of VID is 1~4094. The PRI value can also be obtained by parsing terminal packets. P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that for C-VID. Detect-Times (2 bytes): Number of detection timeout times. The value 0 indicates that no detection is performed. Detect-Interval (2 bytes): Detection interval in seconds. Hu, et al [Page 87] INTERNET-DRAFT Simple BNG CUSP If-Index (4 bytes): Interface index. Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried. VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs. If-Desc sub-TLV: carries the interface information. The Reserved field MUST be sent as zero and ignored on receipt. 7.9.2. PPP Subscriber TLV The PPP Subscriber TLV is defined to carry PPP information of a User from a CP to a UP. It will be carried in an Update_Request message when PPPoE or L2TP access is used. The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSS | Reserved |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRU | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Magic Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 47: PPP Subscriber TLV Where: The TLV type: 3. The TLV length: 12 octets. User-ID (4 bytes): The identifier of a subscriber. MSS-Value (2 bytes): Indicates the MSS value (in bytes). MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled. 0: Disabled. 1: Enabled. MRU (2 bytes): PPPoE local MRU (in bytes). Hu, et al [Page 88] INTERNET-DRAFT Simple BNG CUSP Magic-Number (4 bytes): Local magic number in PPP negotiation packets. Peer-Magic-Number (4 bytes): Remote peer magic number. The Reserved fields MUST be sent as zero and ignored on receipt. 7.9.3. IPv4 Subscriber TLV The IPv4 Subscriber TLV is defined to carry IPv4 related information for a BNG user. It will be carried in an Update_Request message when IPv4 IPoE, or PPPoE access is used. The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gateway IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Reserved |U|E|W|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ VRF-Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 48: IPv4 Subscriber TLV Where: The TLV type: 4. The TLV length: variable. User-ID (4 bytes): The identifier of a subscriber. User-IPv4 (IPv4-Address): The IPv4 address of the subscriber. Gateway-IPv4 (IPv4-Address): The gateway address of the subscriber. Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on. Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on. Hu, et al [Page 89] INTERNET-DRAFT Simple BNG CUSP Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off, 1: on. IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) flag. 0: off, 1: on. MTU 2 bytes MTU value. The default value is 1500. VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. The Reserved field MUST be sent as zero and ignored on receipt. 7.9.4. IPv6 Subscriber TLV The IPv6 Subscriber TLV is defined to carry IPv6 related information for a BNG user. It will be carried in an Update_Request message when IPv6 IPoE, or PPPoE access is used. The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ User PD-Address (IPv6 Address List sub-TLV) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Gateway ND-Address (IPv6 Address List sub-TLV) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User IANA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface ID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Reserved |U|E|W|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ VRF Name sub-TLV (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 49: IPv6 Subscriber TLV Where: The TLV type: 5. The TLV length: variable. Hu, et al [Page 90] INTERNET-DRAFT Simple BNG CUSP User-ID (4 bytes): The identifier of a subscriber. User PD-Addresses (IPv6 Address List): Carries a list of Prefix Delegation (PD) addresses of the subscriber. User ND-Addresses (IPv6 Address List): Carries a list of Neighbor Discovery (ND) addresses of the subscriber. User IANA-Address (IPv6-Address): The IANA address of the subscriber. IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface. Portal Force 1 bit (P): Push advertisement, 0: off, 1: on. Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on. Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off; 1: on. IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0: off; 1: on. MTU (2 bytes): The MTU value. The default value is 1500. VRF-Name Sub-TLV: Indicates the VRF to which the subscriber belongs. The Reserved field MUST be sent as zero and ignored on receipt. 7.9.5. IPv4 Static Subscriber Detect TLV The IPv4 Static Subscriber Detect TLV is defined to carry IPv4 related information for a static access subscriber. It will be carried in an Update_Request message when IPv4 static access on a UP needs to be enabled. Hu, et al [Page 91] INTERNET-DRAFT Simple BNG CUSP The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-VID | P-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gateway Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User MAC (cont.) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 50: IPv4 Static Subscriber TLV Where: The TLV type: 6. The TLV length: variable. If-Index (4 bytes): The interface index of the interface from which the subscriber will dial-up. C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. A valid value is 1~4094. P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that of the C-VID. A valid value is 1~4094. For a single-layer VLAN, set this parameter to PeVid. User Address (IPv4-Addr): The user's IPv4 address. Gateway Address (IPv4-Addr): The gateway's IPv4 Address. User-MAC (MAC-Addr type): The MAC address of the subscriber. Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried. VRF-Name sub-TLV: Indicates the VEF to which the subscriber belongs. If-Desc sub-TLV: Carries the interface information. Hu, et al [Page 92] INTERNET-DRAFT Simple BNG CUSP The Reserved field MUST be sent as zero and ignored on receipt. 7.9.6. IPv6 Static Subscriber Detect TLV The IPv6 Static Subscriber Detect TLV is defined to carry IPv6 related information for a static access subscriber. It will be carried in an Update_Request message when needed to enable IPv6 static subscriber detection on a UP. The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-VID | P-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ User Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Gateway Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User MAC (cont.) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 51: IPv6 Static Subscriber Detect TLV Where: The TLV type: 6. The TLV length: variable. If-Index (4 bytes): The interface index of the interface from which the subscriber will dial-up. C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. A valid value is 1~4094. P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that the of C-VID. A valid value is 1~4094. For a single-layer VLAN, set this parameter to PeVid. Hu, et al [Page 93] INTERNET-DRAFT Simple BNG CUSP User Address (IPv6-Address type): The subscriber's IPv6 address. Gateway Address (IPv6-Address type): The gateway's IPv6 Address. User-MAC (MAC-Addr type): The MAC address of the subscriber. sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried VRF-Name Sub-TLV: Indicates the VRF to which the subscriber belongs. If-Desc sub-TLV: Carries the interface information. The Reserved field MUST be sent as zero and ignored on receipt. 7.9.7. L2TP-LAC Subscriber TLV The L2TP-LAC Subscriber TLV is defined to carry the related information for a L2TP LAC access subscriber. It will be carried in an Update_Request message when L2TP LAC access is used. The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Tunnel ID | Local Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Tunnel ID | Remote Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 52: L2TP-LAC Subscriber TLV Where: The TLV type: 11. The TLV length: 12 octets. User-ID (4 bytes): The identifier of a user/subscriber. Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. Local-Session-ID (2 bytes): The local session ID with the L2TP tunnel. Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. Hu, et al [Page 94] INTERNET-DRAFT Simple BNG CUSP Remote-Session-ID (2 bytes): The remote session ID of the L2TP tunnel. 7.9.8. L2TP-LNS Subscriber TLV The L2TP-LNS Subscriber TLV is defined to carry the related information for a L2TP LNS access subscriber. It will be carried in an Update_Request message when L2TP LNS access is used. The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Tunnel ID | Local Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Tunnel ID | Remote Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 53: L2TP-LNS Subscriber TLV Where: The TLV type: 12. The TLV length: 12 octets. User-ID (4 bytes): The identifier of a user/subscriber. Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. Local-Session-ID (2 bytes): The local session ID with the L2TP tunnel. Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. Remote-Session-ID (2 bytes): The remote session ID of the L2TP tunnel. 7.9.9. L2TP-LAC Tunnel TLV The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel related information. It will be carried in the Update_Request message when L2TP LAC access is used. Hu, et al [Page 95] INTERNET-DRAFT Simple BNG CUSP The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Tunnel ID | Remote Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Tunnel Source Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Tunnel Destination Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ VRF Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 54: L2TP-LAC Tunnel TLV Where: The TLV type: 13. The TLV length: variable. Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. Source-Port (2 bytes): The source UDP port number of an L2TP subscriber. Dest-Port (2 bytes): The destination UDP port number of an L2TP subscriber. Source-IP (IPv4/v6): The source IP address of the tunnel. Dest-IP (IPv4/v6): The destination IP address of the tunnel. VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel belongs. 7.9.10. L2TP-LNS Tunnel TLV The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel related information. It will be carried in the Update_Request message when L2TP LNS access is used. Hu, et al [Page 96] INTERNET-DRAFT Simple BNG CUSP The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Tunnel ID | Remote Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Tunnel Source Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Tunnel Destination Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ VRF Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 55: L2TP-LNS Tunnel TLV Where: The TLV type: 14. The TLV length: variable. Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. Source-Port (2 bytes): The source UDP port number of an L2TP subscriber. Dest-Port (2 bytes): The destination UDP port number of an L2TP subscriber. Source-IP (IPv4/v6): The source IP address of the tunnel. Dest-IP (IPv4/v6): The destination IP address of the tunnel. VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel belongs. 7.9.11. Update Response TLV The Update Response TLV is used to return the operation result of an update request. It is carried in the Update_Response message as a response to the Update_Request message. Hu, et al [Page 97] INTERNET-DRAFT Simple BNG CUSP The format of Update Response TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User-Trans-ID | Oper-Code | Oper-Result | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 56: Update Response TLV Where: The TLV type: 302. The TLV length: 12. User-ID (4 bytes): A unique identifier of an user/subscriber. User-Trans-ID (1 byte): In the case of dual-stack access or when modifying a session, User-Trans-ID is used to identify a user operation transaction. It is used by the CP to correlate a response to a specific request. Oper-Code (1 byte): Operation code. 1: update, 2: delete. Oper-Result (1 byte): Operation Result. 0: Success, Others: Failure. Error-Code (4 bytes): Operation failure cause code. for details, see Section 9.5. The Reserved field MUST be sent as zero and ignored on receipt. 7.9.12. Subscriber Policy TLV The Subscriber Policy TLV is used to carry the policies that will be applied to a subscriber. It is carried in the Update_Request message. Hu, et al [Page 98] INTERNET-DRAFT Simple BNG CUSP The format of the TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-Priority | E-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 57: User QoS Policy Information TLV Where: The TLV type: 6. The TLV length: variable. User-ID (4 bytes): The identifier of a user/subscriber. Ingress-Priority (1 byte): Indicates the upstream priority. The value range is 0~7. Egress-Priority (1 byte): Indicates the downstream priority. The value range is 0~7. sub-TLVs: The sub-TLVs that are present can occur in any order. Ingress-CAR sub-TLV: Upstream CAR. Egress-CAR sub-TLV: Downstream CAR. Ingress-QoS-Profile sub-TLV: Indicates the name of the QoS- Profile profile in the upstream direction. Egress-QoS-Profile Sub-TLV: Indicates the name of the QoS- Profile profile in the downstream direction. User-ACL-Policy Sub-TLV: All ACL user policies, including v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, v4SpecialACL, and v6SpecialACL. Multicast-Profile4 Sub-TLV: IPv4 multicast policy name. Multicast-Profile6 Sub-TLV: IPv6 multicast policy name. NAT-Instance Sub-TLV: Indicates the instance ID of a NAT user. Hu, et al [Page 99] INTERNET-DRAFT Simple BNG CUSP The Reserved field MUST be sent as zero and ignored on receipt. 7.9.13. Subscriber CGN Port Range TLV The Subscriber CGN Port Range TLV is used to carry the NAT public address and port range. It will be carried in the Update_Response message when CGN is used. The format of this TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAT-Port-Start | NAT-Port-End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAT-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 58: Subscriber CGN Port Range TLV Where: The TLV type: 15. The TLV length: 12 octets. User-ID (4 bytes): The identifier of a user/subscriber. NAT-Port-Start (2 bytes): The start port number. NAT-Port-End (2 bytes): The end port number. NAT-Address (4 bytes): The NAT public network address. 7.10. Device Status TLVs The TLVs in this section are for reporting Interface and Board level information from the UP to the CP. Hu, et al [Page 100] INTERNET-DRAFT Simple BNG CUSP 7.10.1. Interface Status TLV The Interface Status TLV is used to carry the status information of an interface on a UP. It is carried in a Report message. The format of the value part of this TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address (lower part) | Phy-State | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 59: Interface Status TLV Where: The TLV type: 200. The TLV length: variable. If-Index (4 bytes): Indicates the interface index. MAC-Address (MAC-Addr type): Interface MAC address. Phy-State (1 byte): Physical status of the interface. 0: down, 1: Up MTU (4 bytes): Interface MTU value. sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried. The Reserved field MUST be sent as zero and ignored on receipt. 7.10.2. Board Status TLV The Board Status TLV is used to carry the status information of a board on an UP. It is carried in a Report message. Hu, et al [Page 101] INTERNET-DRAFT Simple BNG CUSP The format of Board Status TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Board-Type | Board-State | Reserved | Chassis | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 60: Interface Resource TLV Where: The TLV type: 201. The TLV length: 8 octets. Chassis (1 byte): The chassis number of the Board. Slot (1 byte): The slot number of the Board. Sub-Slot (1 byte): The sub-slot number of the Board. Board-Type (1 byte): 1: CGN Service Process Unit (SPU) board. 2: Line Process Unit (LPU) Board. Board-State (1 byte): 0: Normal. 1: Abnormal. The reserved field MUST be sent as zero and ignored on receipt. 7.11. CGN TLVs 7.11.1. Address Allocation Request TLV The Address Allocation Request TLV is used to request address allocation from CP. An address Pool-Name sub-TLV is carried to indicate from which address pool to allocate addresses. The Address Allocation Request TLV is carried in the Addr_Allocation_Req message. Hu, et al [Page 102] INTERNET-DRAFT Simple BNG CUSP The format of the value part of this TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pool-Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 61: Address Allocation Request TLV Where: The TLV type: 400. The TLV length: variable. Pool-Name sub-TLV: Indicates from which Address pool to allocate address. 7.11.2. Address Allocation Response TLV The Address Allocation Response TLV is used to return the address allocation result, it is carried the Addr_Allocation_Ack message. The value part of the Address Allocation Response TLV is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lease Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Addr and Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Addr and Mask continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pool-Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 62: Address Assignment Response TLV Where: The TLV type: 401. The TLV length: variable. Hu, et al [Page 103] INTERNET-DRAFT Simple BNG CUSP Lease Time (4 bytes): Duration of address lease in seconds. IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4 address. Error-Code (4 bytes): Indicates success or an error. 0: Success. 1: Failure. 3001 (Pool-Mismatch): The corresponding address pool cannot be found. 3002 (Pool-Full): The address pool is fully allocated and no address segment is available. Pool-Name sub-TLV: A Pool-Name sub-TLV to indicate from which Address pool the address is allocated. 7.11.3. Address Renewal Request TLV The Address Renewal Request TLV is used to request address renewal from the CP. It is carried the Addr_Renew_Req message. The format of this TLV value is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pool-Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 63: Address Renewal Request TLV Where: The TLV type: 402. The TLV length: variable. IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed. Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which Hu, et al [Page 104] INTERNET-DRAFT Simple BNG CUSP Address pool to renew the address. 7.11.4. The Address Renewal Response TLV The Address Renewal Response TLV is used to return the address renewal result. It is carried in the Addr_Renew_Ack message. The format of this TLV value is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pool-Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 64: Address Renewal Response TLV Where: The TLV type: 403. The TLV length: variable. Client-IP (IPv4-Address type): The renewed IPv4 address. Error Code (4 bytes): Indicates success or an error: 0: Renew success. 1: Renew failed. 3001 (Pool-Mismatch): The corresponding address pool cannot be found. 3002 (Pool-Full): The address pool is fully allocated and no address segment is available. 3003 (Subnet-Mismatch): The address pool subnet cannot be found. 3004 (Subnet-Conflict): Subnets in the address pool have been assigned to other clients. Hu, et al [Page 105] INTERNET-DRAFT Simple BNG CUSP Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which Address pool to renew the address. 7.11.5. Address Release Request TLV The Address Release Request TLV is used to release an IPv4 address. It is carried in the Addr_Release_Req message. The value part of this TLV is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pool-Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 65: Address Release Request TLV Where: The TLV type: 404. The TLV length: variable. IPv4 Address and Mask (IPv4-Address type): The IPv4 address be released. Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which Address pool to release the address. 7.11.6. The Address Release Response TLV The Address Release Response TLV is used to return the address release result. It is carried in the Addr_Release_Ack message. Hu, et al [Page 106] INTERNET-DRAFT Simple BNG CUSP The format of this TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address and Mask continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pool-Name sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 66: Address Renewal Response TLV Where: The TLV type: 405. The TLV length: variable. Client-IP (IPv4-Address type): The released IPv4 address. Error-Code (4 bytes): Indicates success or an error. 0: Address release success. 1: Address release failed. 3001 (Pool-Mismatch): The corresponding address pool cannot be found. 3003 (Subnet-Mismatch): The address cannot be found. 3004 (Subnet-Conflict): The address has been allocated to another subscriber. Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which address pool to release the address. 7.12. Event TLVs Hu, et al [Page 107] INTERNET-DRAFT Simple BNG CUSP 7.12.1. Subscriber Traffic Statistics TLV The Subscriber Traffic Statistics TLV is used to return the traffic statistics of a user/subscriber. The format of this TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Statistics Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Packets (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Packets (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Bytes (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Bytes (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Loss Packets (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Loss Packets (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Loss Bytes (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Loss Bytes (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Packets (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Packets (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Bytes (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Bytes (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Loss Packets (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Loss Packets (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Loss Bytes (upper part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Loss Bytes (lower part) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 67: Subscriber Traffic Statistics TLV Where: Hu, et al [Page 108] INTERNET-DRAFT Simple BNG CUSP The TLV type: 300. The TLV length: 72 octets. User-ID (4 bytes): The user/subscriber identifier. Statistics-Type (4 bytes): Traffic type. It can be one of the following options: 0: IPv4 traffic. 1: IPv6 traffic. 2: Dual stack traffic. Ingress Packets (8 bytes): The number of the packets in upstream direction. Ingress Bytes (8 bytes): The bytes of the upstream traffic. Ingress Loss Packets (8 bytes): The number of the lost packets in upstream direction. Ingress Loss Bytes (8 bytes): The bytes of the lost upstream packets. Egress Packets (8 bytes): The number of the packets in downstream direction. Egress Bytes (8 bytes): The bytes of the downstream traffic. Egress Loss Packets (8 bytes): The number of the lost packets in downstream direction. Egress Loss Bytes (8 bytes): The bytes of the lost downstream packets. 7.12.2. Subscriber Detection Result TLV The Subscriber Detection Result TLV is used to return the detection result of a subscriber. Subscriber detection is a function to detect whether a subscriber is online or not. The result can be used by the CP to determine how to deal with the subscriber session. (e.g., delete the session if detection failed). Hu, et al [Page 109] INTERNET-DRAFT Simple BNG CUSP The format of this TLV value part is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Detect Type | Detect Result | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 68: Subscriber Detection Result TLV Where: The TLV type: 301. The TLV length: 8 octets. User-ID (4 bytes): A user/subscriber identifier. Detect-Type (1 byte): 0: IPv4 detection. 1: IPv6 detection. 2: PPP detection. Detect-Result (1 bytes): 0: Indicates that the detection is successful. 1: Detection failure. The UP needs report only when the detection fails. The Reserved field MUST be sent as zero and ignored on receipt. 7.13. Vendor TLV The Vendor ID TLV occurs as the first TLV in the Vendor message (Section 6.6). It provides a Sub-Type that effectively extends the message type in the message header, provides for versioning of vendor TLVs, and can accommodate sub-TLVs. Hu, et al [Page 110] INTERNET-DRAFT Simple BNG CUSP The value part of the Vendor TLV is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Sub-Type-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 69: Vendor TLV Where: The TLV type: 1024. The TLV length: variable. Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS [RFC2865]. Sub-Type (2 bytes): Used by the Vendor to distinguish multiple different vendor messages. Sub-Type-Version (2 bytes): Used by the Vendor to distinguish different versions of a Vendor Defined message sub-type. Sub-TLVs (variable): Sub-TLVs as specified by the vendor. Since Vendor code will be handling the TLV after the Vendor ID field is recognized, the remainder of the TLV value can be organized however the vendor wants. But it is desirable for a vendor to be able to define multiple different vendor messages and to keep track of different versions of its vendor defined messages. Thus, it is RECOMMENDED that the vendor assign a Sub-Type value for each vendor message that it defines different from other Sub-Type values that vendor has used. Also, when modifying a vendor defined message in a way potentially incompatible with a previous definition, the vendor SHOULD increase the value it is using in the Sub-Type-Version field. Hu, et al [Page 111] INTERNET-DRAFT Simple BNG CUSP 8. Implementation Status RFC Editor: Please remove this section before publication. This section discusses the status of implementations that have provided information and the testing of this protocol at the time of posting of this Internet-Draft, and is based on the proposal in [RFC7942] ("Improving Awareness of Running Code: The Implementation Status Section"). The description of implementations in this section is intended to assist in processing drafts to RFCs. Please note that the listing of any individual implementation or test results here does not imply endorsement by the RFC Editor or the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their testing or features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers ... to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.". 8.1. Implementations Information on three S-CUSP implementations appears below. 8.1.1. Huawei Technologies Name: Cloud-based BNG. Maturity: Production. Coverage: According to S-CUSP protocol. Contact information: Zhouyi Yu: yuzhouyi@huawei.com Date: 2018-11-01 Hu, et al [Page 112] INTERNET-DRAFT Simple BNG CUSP 8.1.2. ZTE Name: ZXR10 V6000 vBRAS Maturity: Production Coverage: According to S-CUSP protocol. Contact information: Yong Chen: 10056167@zte.com.cn Huaibin Wang: 10008729@zte.com.cn Date: 2018-12-01 8.1.3. H3C Name: CUSP protocol for BRAS Control Plane and User Plan Separation Maturity: Research Coverage: According to S-CUSP protocol Contact information: mengdan@h3c.com; liuhanlei@h3c.com Date: 2019-1-30 8.2. Hackathon Successful use of the protocol at the IETF-102 Hackathon, Montreal, Quebec, in 2018. Hackathon Project: Control Plane and User Plane Separation BNG control channel Protocol (CUSP) Champions: Zhenqiang Li, Michael Wang Report: See github.com/IETF-Hackathon/ietf102-project-presentations/blob/ master/IETF102-hackathon-presentation-CUSP.pptx Hu, et al [Page 113] INTERNET-DRAFT Simple BNG CUSP 8.3. EANTC Testing EANTC (European Advanced Networking Test Center (www.eantc.de)) tested the Huawei implementation. Their summary was as follows: "EANTC tested advanced aspects of the Cloud-based Broadband Network Gateway (vBNG) with a focus on performance, scalability and high availability with up to 20 Million emulated subscribers. The solution performed very well across all test scenarios." See report at www.eantc.de/fileadmin/eantc/downloads/News/2018/EANTC-vBRAS- phase2.pdf Hu, et al [Page 114] INTERNET-DRAFT Simple BNG CUSP 9. Summary of Major S-CUSP Codepoints This section provides tables of the major S-CUSP codepoints, particularly message types, TLV types, TLV operation codes, sub-TLV types, and error codes. In most cases, references are provided to relevant sections elsewhere in this document. 9.1. Message Types Type Name Section of this document ------- ---------------- ------------------------ 0 - Reserved 1 Hello 6.2.1. 2 Keepalive 6.2.2. 3 Sync_Request 6.2.3. 4 Sync_Begin 6.2.4. 5 Sync_Data 6.2.5. 6 Sync_End 6.2.6. 7 Update_Request 6.2.7. 8 Update_Response 6.2.8. 9 Report 6.4. 10 Event 6.3. 11 Vendor 6.6. 12 Error 6.7. 13-199 - Unassigned 200 Addr_Allocation_Req 6.5.1. 201 Addr_Allocation_Ack 6.5.2. 202 Addr_Renew_Req 6.5.3. 203 Addr_Renew_Ack 6.5.4. 204 Addr_Release_Req 6.5.5. 205 Addr_Release_Ack 6.5.6. 206-254 - Unassigned 255 - Reserved 9.2. TLV Types Type Name Usage Description ------ ------------ -------------------------- 0 reserved - 1 BAS Function Carries the BNG access functions to be enabled or disabled on specified interfaces. 2 Basic Subscriber Carries the basic information about a BNG subscriber. 3 PPP Subscriber Carries the PPP information Hu, et al [Page 115] INTERNET-DRAFT Simple BNG CUSP about a BNG subscriber. 4 IPv4 Subscriber Carries the IPv4 address of a BNG subscriber. 5 IPv6 Subscriber Carries the IPv6 address of a BNG subscriber. 6 Subscriber Policy Carries the policy information applied to a BNG subscriber. 7 IPv4 Routing Carries the IPv4 network routing information. 8 IPv6 Routing Carries the IPv6 network routing information. 9 IPv4 Static Subscriber Detect Carries the IPv4 static subscriber detect information. 10 IPv6 Static Subscriber Detect Carries the IPv6 static subscriber detect information. 11 L2TP-LAC Subscriber Carries the L2TP LAC subscriber information. 12 L2TP-LNS Subscriber Carries the L2TP LNS subscriber information. 13 L2TP-LAC-Tunnel Carries the L2TP LAC tunnel subscriber information. 14 L2TP-LNS-Tunnel Carries the L2TP LNS tunnel subscriber information. 15 Subscriber CGN Port Range Carries the public IPv4 address and related port range of a BNG subscriber. 16-99 unassigned - 100 Hello Used for version and Keep Alive timers negotiation. 101 Error Information Carried in the Ack of the control message. Carries the processing result, success, or error. 102 Keep Alive Carried in the Hello message for Keep Alive timers negotiation. 103-199 unassigned - 200 Interface Status Interfaces status reported by the UP including physical interfaces, sub-interfaces, trunk interfaces, and tunnel interfaces. 201 Board Status Board information reported by the UP including the board type and in-position status. 202-299 unassigned - 300 Subscriber Traffic Statistics User traffic statistics. 301 Subscriber Detection Results User detection information. 302 Update Response The processing result of a subscriber session update. Hu, et al [Page 116] INTERNET-DRAFT Simple BNG CUSP 303-299 unassigned - 400 Address Allocation Request Request address allocation. 401 Address Allocation Response Address allocation response. 402 Address Renewal Request Request for address lease renewal. 403 Address Renewal Response Response to a request for extending an IP address lease. 404 Address Release Request Request to release the address. 405 Address Release Response Ack of a message releasing an IP address. 406-1023 unassigned - 1024 Vendor As implemented by vendor. 1039-4095 unassigned - 9.3. TLV Operation Codes TLV operation codes appear in the Oper field in the header of some TLVs. See Section 7.1. Code Operation ---- ---------- 0 - reserved 1 Update 2 Delete 3-15 - unassigned Hu, et al [Page 117] INTERNET-DRAFT Simple BNG CUSP 9.4. Sub-TLV Types See Section 7.3. Type Name Section of this document ---- ------------------ ------------------------ 0 - reserved 1 VRF Name 7.3.1. 2 Ingress-QoS-Profile 7.3.1. 3 Egress-QoS-Profile 7.3.1. 4 User-ACL-Policy 7.3.1. 5 Multicast-ProfileV4 7.3.1. 6 Multicast-ProfileV6 7.3.1. 7 Ingress-CAR 7.3.2. 8 Egress-CAR 7.3.3. 9 NAT-Instance 7.3.1. 10 Pool-Name 7.3.1. 11 If-Desc 7.3.4. 12 IPv6-Address List 7.3.5. 13 Vendor 7.3.6. 12-64534 - unassigned 65535 - reserved 9.5. Error Codes Value Name Remarks ------- ------- -------- 0 Success Success 1 Fail Malformed message received. 2 TLV-Unknown One or more of the TLVs was not understood. 3 TLV-Length The TLV length is abnormal. 4-999 - unassigned Unassigned basic error codes. 1000 - reserved 1001 Version-Mismatch The version negotiation fails. Terminate. The subsequent service processes corresponding to the UP are suspended. 1002 Keepalive Error The keepalive negotiation fails. 1003 Timer Expires The establishment timer expired. 1004-1999 - unassigned Unassigned error codes for version negotiation. 2000 - reserved 2001 Synch-NoReady The data to be smoothed is not ready. 2002 Synch-Unsupport The request for smooth data is not supported. 2003-2999 - unassigned Unassigned data synchronization error codes. Hu, et al [Page 118] INTERNET-DRAFT Simple BNG CUSP 3000 - reserved 3001 Pool-Mismatch The corresponding address pool cannot be found. 3002 Pool-Full The address pool is fully allocated and no address segment is available. 3003 Subnet-Mismatch The address pool subnet cannot be found. 3004 Subnet-Conflict Subnets in the address pool have been classified into other clients. 3005-3999 - unassigned Unassigned error codes for address allocation. 4000 - reserved 4001 Update-Fail-No-Res The forwarding table fails to be delivered because the forwarding resources are insufficient. 4002 QoS-Update-Success The QoS policy takes effect. 4003 QoS-Update-Sq-Fail Failed to process the queue in the QoS policy. 4004 QoS-Update-CAR-Fail Processing of the CAR in the QoS policy fails. 4005 Statistic-Fail-No-Res Statistics processing failed due to insufficient statistics resources. 4006-4999 - unassigned forwarding table delivery error codes. 5000-4294967295 - reserved Hu, et al [Page 119] INTERNET-DRAFT Simple BNG CUSP 10. IANA Considerations This document requires no IANA actions. Hu, et al [Page 120] INTERNET-DRAFT Simple BNG CUSP 11. Security Considerations The Service, Control, and Management Interfaces between the CP and UP might be across the general Internet or other hostile environment. The ability of an adversary to block or corrupt messages or introduce spurious messages on any one or more of these interfaces would give the adversary the ability to stop subscribers from accessing network services, disrupt existing subscriber sessions, divert traffic, mess up accounting statistics, and generally cause havoc. Damage would not necessarily be limited to one or a few subscribers but could disrupt routing or deny service to one or more instances of the CP or otherwise cause extensive interference. If the adversary knows the details of the UP equipment and its forwarding rule capabilities, the adversary may be able to cause a copy of most or all user data to be sent to an address of the adversary's choosing, thus enabling eavesdropping. Thus, appropriate protections MUST be implemented to provide integrity, authenticity, and secrecy of traffic over those interfaces. Whether such protection is used is a network operator decision. See [RFC6241] for Management Interface / NETCONF security. Security on the Service Interface is dependent on the tunneling protocol used which is out of scope for this document. Security for the Control Interface, over which the S-CUSP protocol flows, is further discussed below. S-CUSP messages do not provide security. Thus, if these messages are exchanged in an environment where security is a concern, that security MUST be provided by another protocol such as TLS 1.3 [RFC8446] or IPSEC. TLS 1.3 is the mandatory to implement protocol for interoperability. The use of a particular security protocol on the Control Interface is determined by configuration. Such security protocols need not always be used and lesser security precautions might be appropriate because, in some cases, the communication between the CP and UP is in a benign environment. Hu, et al [Page 121] INTERNET-DRAFT Simple BNG CUSP Contributors Zhouyi Yu Huawei Technologies Email: yuzhouyi@huawei.com Chengguang Niu Huawei Technologies Email: chengguang.niu@huawei.com Zitao Wang Huawei Technologies Email: wangzitao@huawei.com Jun Song Huawei Technologies Email: song.jun@huawei.com Dan Meng H3C Technologies No.1 Lixing Center No.8 guangxun south street, Chaoyang District, Beijing, 100102 China Email: mengdan@h3c.com Hanlei Liu H3C Technologies No.1 Lixing Center No.8 guangxun south street, Chaoyang District, Beijing, 100102 China Email: hanlei_liu@h3c.com Hu, et al [Page 122] INTERNET-DRAFT Simple BNG CUSP Normative References [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, . [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, DOI 10.17487/RFC2661, August 1999, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Hu, et al [Page 123] INTERNET-DRAFT Simple BNG CUSP Informative References [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks / Bridges and Bridged Networks", IEEE Std 802.1Q-2014, 3 November 2013. [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, . [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, [RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 3336, DOI 10.17487/RFC3336, December 2002, . [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, . [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . Hu, et al [Page 124] INTERNET-DRAFT Simple BNG CUSP [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [TR-384] Broadband Forum, "Cloud Central Office Reference Architectural Framework", BBF TR-384, 2018. Hu, et al [Page 125] INTERNET-DRAFT Simple BNG CUSP Authors' Addresses Shujun Hu China Mobile 32 Xuanwumen West Ave, Xicheng District Beijing, Beijing 100053 China Email: hushujun@chinamobile.com Donald Eastlake, 3rd Futurewei Technologies 1424 Pro Shop Court Davenport, FL 33896 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Mach (Guoyi) Chen Huawei Technologies Huawei Bldg., No. 156 Beiqing Road Beijing 100095 China Email: mach.chen@huawei.com Fengwei Qin China Mobile 32 Xuanwumen West Ave, Xicheng District Beijing, Beijing 100053 China Email: qinfengwei@chinamobile.com Zhenqiang Li China Mobile 32 Xuanwumen West Ave, Xicheng District Beijing, Beijing 100053 China Email: lizhenqiang@chinamobile.com Hu, et al [Page 126] INTERNET-DRAFT Simple BNG CUSP Tee Mong Chua Singapore Telecommunications Limited 31 Exeter Road, #05-04 Comcentre Podium Block Singapore City 239732 Singapore Email: teemong@singtel.com Daniel Huang ZTE Email: huang.guangping@zte.com.cn Hu, et al [Page 127] INTERNET-DRAFT Simple BNG CUSP Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hu, et al [Page 128]