INTERNET-DRAFT S. Hu Intended status: Proposed Standard China Mobile D. Eastlake M. Chen Huawei Technologies F. Qin Z. Li China Mobile J. Song Huawei Technologies T. Chua Singapore Telecommunications Expires: October 29, 2019 April 30, 2019 Control-Plane and User-Plane Separation BNG Simple Control Channel Protocol draft-cuspdt-rtgwg-cu-separation-bng-protocol-05.txt Abstract This document specifies the Simple Control Plane (CP) and User Plane (UP) Separation Broadband Network Gateway (BNG) control channel Protocol (S-CUSP) for communications between a CP and a UP. S-CUSP is designed to be flexible and extensible so as to easily allow for the addition of further messages and data items, should requirements be expressed in the future. 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 or the RGTWG working group mailing list: rtgwg@ietf.org. 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." 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 1] INTERNET-DRAFT BNG Simple CUSP Table of Contents 1. Introduction............................................5 2. Terminology.............................................6 2.1 Acronyms...............................................6 3. Protocol Overview.......................................8 3.1 S-CUSP Configuration...................................8 3.2 S-CUSP Session Establishment...........................9 3.3 Overview of S-CUSP Procedures..........................9 3.4 Network Resource Report...............................11 3.5 BNG Access Procedures.................................11 3.5.1 IPoE Access.........................................12 3.5.2 PPPoE Access........................................13 3.5.3 L2TP LAC Access.....................................14 3.5.4 L2TP LNS Access.....................................14 3.5.5 L2TP LTS Access.....................................16 3.6 Setting the User's QoS Information....................16 3.7 CP and UP Synchronization.............................17 3.8 CGN Address Allocation................................18 4. S-CUSP Message Formats.................................19 4.1 Common Message Header.................................19 4.1.1 Control Messages....................................20 4.1.2 Table Messages......................................20 4.1.3 Resource Reporting Message..........................20 4.1.4 Event Reporting Message.............................20 4.1.5 Vendor Message......................................21 4.1.6 Resource Allocation Messages........................21 4.2 Common Message TLV Format.............................21 4.3 Basic Data Fields.....................................22 4.4 Sub-TLV Format and Specific Sub-TLVs..................23 4.4.1 VRF-Name............................................23 4.4.2 Ingress-QoS-Profile.................................23 4.4.3 Egress-QoS-Profile..................................24 4.4.4 User-ACL-Policy.....................................24 4.4.5 Multicast-Profile-v4................................24 4.4.6 Multicast-Profile-v6................................24 4.4.7 Ingress-CAR.........................................24 4.4.8 Egress-CAR..........................................25 4.4.9 NAT-Instance........................................25 4.4.10 Pool-Name..........................................25 4.4.11 If-Desc............................................26 5. Basic TLVs.............................................27 5.1 Interface Information TLV.............................27 5.2 Basic User Information TLVs...........................29 5.2.1 Basic User Information TLV..........................29 5.2.2 User PPP Information TLV............................31 5.3 User IPv4 Information TLV.............................32 Hu, et al [Page 2] INTERNET-DRAFT BNG Simple CUSP Table of Contents (continued) 5.4 User IPv6 Information.................................33 5.5 User QoS Policy Information TLV.......................34 5.6 Routing Table TLVs....................................35 5.6.1 IPv4 Routing Information TLV........................35 5.6.2 IPv6 Routing Information TLV........................36 5.7 Static User Information TLVs..........................37 5.7.1 Static IPv4 User Information TLV....................38 5.7.2 Static IPv6 User Information TLV....................39 5.8 L2TP User Information TLVs............................40 5.8.1 L2TP-LAC User Information TLV.......................40 5.8.2 L2TP-LNS User Information TLV.......................40 5.8.3 L2TP-LAC Tunnel TLV.................................41 5.8.4 L2TP-LNS Tunnel TLV.................................42 5.9 NAT User Information TLV..............................42 5.10 Vendor Defined TLV...................................43 6. Control TLVs...........................................45 6.1 Hello TLV.............................................45 6.2 Error Information TLV.................................46 7. Resource Reporting TLVs................................47 7.1 Interface Resource Information TLV....................47 7.2 UP Board Status Report Information TLV................47 8. Event TLVs.............................................49 8.1 User Traffic Statistics Report TLV....................49 8.2 User Detection Result Report TLV......................50 8.3 User Basic Table Operation Result TLV.................51 9. Resource Allocation TLVs...............................52 9.1 Request Address Allocation TLV........................52 9.2 Address Assignment Response TLV.......................52 9.3 Address Renewal Request TLV...........................53 9.4 Address Renewal Response TLV..........................54 9.5 Address Release Request TLV...........................54 9.6 Address Release Response TLV..........................55 10. Implementation Status.................................56 10.1 Implementations......................................56 10.1.1 Huawei Technologies................................56 10.1.2 ZTE................................................57 10.1.3 H3C................................................57 10.2 Hackathon............................................57 10.3 EANTC Testing........................................58 11. Security Considerations...............................59 12. IANA Considerations...................................60 12.1 Service Name and Port Number.........................60 Hu, et al [Page 3] INTERNET-DRAFT BNG Simple CUSP Table of Contents (continued) 12.2 S-CUSP Parameters....................................60 12.2.1 Message Types......................................60 12.2.2 TLV Types..........................................61 12.2.3 TLV Operation Codes................................62 12.2.4 Sub-TLV Types......................................62 12.2.5 ERRID Codes........................................63 Contributors..............................................65 Normative References......................................66 Informative References....................................66 Authors' Addresses........................................68 Hu, et al [Page 4] INTERNET-DRAFT BNG Simple 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. Hu, et al [Page 5] INTERNET-DRAFT BNG Simple CUSP 2. Terminology 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.1 Acronyms ACK: Acknowledgement message. 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. 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. 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).) IPoE: IP over Ethernet. L2TP: Layer 2 Tunneling Protocol [RFC2661]. LAC: L2TP Access Concentrator Hu, et al [Page 6] INTERNET-DRAFT BNG Simple CUSP LNS: L2TP Network Server Mi: Management Interface. MSS: Maximum Segment Size. MRU: Maximum Receive Unit. NAT: Network Address Translation [RFC3022]. ND: Neighbor Discovery. PBS: Peak Burst Size. PD: Prefix Delegation. PIR: Peak Information Rate. PPP: Point to Point Protocol [RFC1661]. PPPoE: PPP over Ethernet. S-CUSP: Simple Control and User Plane Separation Protocol. Si: Service Interface. TLV: Type, Length, Value. See Section 4.2. 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". VRF: Virtual Routing and Forwarding. Hu, et al [Page 7] INTERNET-DRAFT BNG Simple CUSP 3. Protocol Overview This section shows example message exchanges. 3.1 S-CUSP Configuration To support Control Plane and User Plane separation, as defined in [SCUSP-architecture], three interfaces are defined. These are referred to as the Control Interface (Ci), Service Interface (Si) and Management Interface (Mi). 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 and the Access interfaces. The parameters are defined in [SCUSP-YANG]. UP CP | | | Configure Control Interface | |<-----------via NETCONF-----------| | | | Configure Service Interface | |<-----------via NETCONF-----------| | | | Configure Access Interfaces | |<-----------via NETCONF-----------| | | | Configure QOS Template | |<-----------via NETCONF-----------| | | Once the parameters are configured, a UP can start to establish S- CUSP session(s) with the specified CP(s) through the S-CUSP Session Establishment as defined Section 3.2 of this document. Hu, et al [Page 8] INTERNET-DRAFT BNG Simple CUSP 3.2 S-CUSP Session Establishment UP CP | | | TCP Session Establishment | |<------------------------------->| | | | | | HELLO (version, capability) | |-------------------------------->| | | | | | HELLO (version, capability) | |<--------------------------------| | | 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 port tbd1. 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 negotiation is performed. The version information is carried within Hello messages (see Section 6.2). If the S-CUSP session establishment phase fails because the CP or UP disagree on the version parameters or 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. 3.3 Overview of S-CUSP Procedures The five sequences below give a high level view of the S-CUSP message sequences. These sequences are covered in more detail below as indicated. UP CP 1. | UP reports the Statistic INFO | |-----to CP via S-CUSP---------------->| | | | UP reports the Event INFO | |-----to CP via S-CUSP---------------->| | | | UP reports Resource INFO | Hu, et al [Page 9] INTERNET-DRAFT BNG Simple CUSP |-----to CP via S-CUSP---------------->| | | 1. See Sections 3.4 and 4.1.3 for more details on Resource reporting. See Section 4.1.4 for more details on Event reporting. Traffic statistics are also reported using the Event message. 2. | UP relays User Dial-up Request | |-----to CP via Si-------------------->| | | | CP sends User Dial-up Response | |<----to UPs via Si--------------------| | | 2. This interaction is via the Service Interface and corresponds to the initial interaction in the message sequence charged in the sub-sections of Section 3.5. 3. | CP sends User INFO | |<----to UP via S-CUSP-----------------| | | | CP sends User Policy INFO | |<----to UP via S-CUSP-----------------| | | | CP sends Route INFO | |<----to UP via S-CUSP-----------------| | | | CP sends Tunnel INFO | |<----to UP via S-CUSP-----------------| | | 3. See Section 4.1.2 for more detail on CP messages updating UP tables. 4. | CGN Address Allocation via S-CUSP | |<------------------------------------>| | | 4. See Sections 3.8 and 4.1.8 for more detail on CGN Address Allocation. 5. | Data Synchronization via S-CUSP | |<------------------------------------>| | | Hu, et al [Page 10] INTERNET-DRAFT BNG Simple CUSP 5. See Sections 3.7 and 4.1.1 for more detail on CP and UP Synchronization. 3.4 Network Resource Report Once an S-CUSP session is established between a CP and an UP. The UP will begin to report the status/attributes of its slots, interfaces, and sub-interfaces. UP CP | | | Slot attributes report | | via S-CUSP | |-------------------------------->| | | | Port attributes report | | via S-CUSP | |-------------------------------->| | | | Sub-interface attributes report | | via S-CUSP | |-------------------------------->| | | Details of the Resource Report Messages can be found in Sections 4.2.3 and 7. 3.5 BNG Access Procedures The subsection below give an overview of various "dial up" interactions over the Service Interface followed by the setting of various informatiion in the UP by the CP using S-CUSP over the Control Interface. Hu, et al [Page 11] INTERNET-DRAFT BNG Simple CUSP 3.5.1 IPoE Access UP CP | | | DHCP Negotiation Messages | |<-----------via Si-------------------->| | | | CP sends USER_BASEC_INFO | |<---to UPs via S-CUSP------------------| | | | CP sends USER_POLICY_INFO | |<---to UP via S-CUSP-------------------| | | | CP sends USER_IPV4/6_INFO | |<---to UPs via S-CUSP------------------| | | | CP sends ROUTEV4/6 INFO | |<---to UPs via S-CUSP------------------| | | | UP reports USER_DETECT_RESULT_INFO | |----to CP via S-CUSP------------------>| | | | UP reports USER_TRAFFIC_INFO | |----to CP via S-CUSP------------------>| | | Hu, et al [Page 12] INTERNET-DRAFT BNG Simple CUSP 3.5.2 PPPoE Access UP CP | | | PPPoE Negotiation Messages | |<-----------via Si-------------------->| | | | LCP Negotiation Messages | |<-----------via Si-------------------->| | | | User Authentication Messages | |<-----------via Si-------------------->| | | | IPCP Negotiation Messages | |<-----------via Si-------------------->| | | | CP sends USER_BASEC_INFO | |<----to UP via S-CUSP------------------| | | | CP sends USER_POLICY_INFO | |<----to UP via S-CUSP------------------| | | | CP sends USER_IPV4/6_INFO | |<----to UP via S-CUSP------------------| | | | CP sends ROUTEV4/6 INFO | |<----to UP via S-CUSP------------------| | | | CP sends USER_PPP_INFO | |<----to UP via S-CUSP------------------| | | | UP reports USER_DETECT_RESULT_INFO| |-----to CP via S-CUSP----------------->| | | | UP reports USER_TRAFFIC_INFO | |-----to CP via S-CUSP----------------->| | | Hu, et al [Page 13] INTERNET-DRAFT BNG Simple CUSP 3.5.3 L2TP LAC Access UP CP LNS | | | | PPPoE Negotiation Messages | | |<-----------via Si------------------>| | | | | | LCP Negotiation Messages | | |<-----------via Si------------------>| | | | | | User Authentication Messages | | |<-----------via Si------------------>| | | | | | LAC Tunnel Negotiation Messages | | | -----------via Si------------------>| | | /\ | | | || forward | | | \/ | | | ------------------ LAC Tunnel Negotiation ---------->| | | | | LAC Session Negotiation Messages | | |<-----------via Si------------------>| | | /\ | | | || forward | | | \/ | | | ------------------ LAC Session Negotiation --------->| | | | | CP sends USER_BASIC_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends LAC_TUNNEL_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends LAC_USER_INFO | | |<----to UP via S-CUSP----------------| | | | | | | | | UP reports USER_TRAFFIC_INFO | | |-----to CP via S-CUSP--------------->| | | | | 3.5.4 L2TP LNS Access Hu, et al [Page 14] INTERNET-DRAFT BNG Simple CUSP |UP CP| LAC| | LNS Tunnel Negotiation Messages | | |<-----------via Si------------------>| | | /\ | | | || forward | | | \/ | | | ------------------ LNS Tunnel Negotiation --------->| | | | | LNS Session Negotiation Messages | | |<-----------via Si------------------>| | | /\ | | | || forward | | | \/ | | | ------------------ LNS Session Negotiation -------->| | | | | LCP Negotiation Messages | | |<-----------via Si------------------>| | | | | | User Authentication Messages | | |<-----------via Si------------------>| | | | | | IPCP Negotiation Messages | | |<-----------via Si------------------>| | | | | | CP sends LNS_TUNNEL_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends USER_BASEC_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends USER_IPV4/6_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends ROUTEV4/6 INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends USER_PPP_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends LNS_USER_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends USER_POLICY_INFO | | |<----to UP via S-CUSP----------------| | | | | | UP reports USER_DETECT_RESULT_INFO | | |-----to CP via S-CUSP--------------->| | | | | | UP reports USER_TRAFFIC_INFO | | |-----to CP via S-CUSP--------------->| | Hu, et al [Page 15] INTERNET-DRAFT BNG Simple CUSP 3.5.5 L2TP LTS Access UP CP LAC/LNS | | | | LAC/LTS Tunnel Negotiation Messages | | |<-----------via Si------------------>| | | /\ | | | || forward | | | \/ | | | ------------------ LAC/LTS Tunnel Negotiation ----->| | | | | LAC/LTS Session Negotiation Messages| | |<-----------via Si------------------>| | | /\ | | | || forward | | | \/ | | | ------------------ LAC/LTS Session Negotiation ---->| | | | | CP sends LAC_TUNNEL_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends LNS_TUNNEL_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends USER_BASEC_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends LAC_USER_INFO | | |<----to UP via S-CUSP----------------| | | | | | CP sends LNS_USER_INFO | | |<----to UP via S-CUSP----------------| | | | | 3.6 Setting the User's QoS Information Hu, et al [Page 16] INTERNET-DRAFT BNG Simple CUSP UP CP AAA | | | | Configure QOS template | | |<-----via NETCONF--------------------| | | | | | User dials up via Si | | |<----------------------------------->| | | | | | CP sends USER_QOS_INFO | | |<---to UPs via S-CUSP----------------| | | |<--COA request--| | CP sends USER_QOS_INFO | | |<---to UPs via S-CUSP----------------| | | | | | UP sends ACK message | | |----to CP via S-CUSP---------------->|--COA response->| | | | Once an S-CUSP session has been established, if a user's Quality of Service (QoS) needs to be set dynamically, the CP initiate a NETCONF session to configure the requested User's QoS template. Then the user dials up via the Si, the CP sends the USER_BASIC_INFO message, USER_IPV4_INFO message, and USER_ROUTEV4_INFO messages to the UP, the UPs report the user detection results and user's traffic status. Once the above process has been accomplished, the CP sends the USER_QOS_AUTH_INFO message to the UPs; this message contains a variety of objects that specify the set of constrains and attributes for the user's required QoS. (The format of these QoS attributes should be parallel to the QoS configuration templates.) 3.7 CP and UP Synchronization Under some circumstances it is necessary to synchrnoize state between the CP and UP, for example if a CP fails and the UP is switched to a different CP. There may be multiple Resource INFO messages between the Synchronization Begin and Synchronization End. UP CP | | | CP sends Synchronization Request | |<-----to UP via S-CUSP---------------| | | | UP sends Synchronization Begin | |------to CP via S-CUSP-------------->| | | | UP reports Resource INFO | |------to CP via S-CUSP-------------->| Hu, et al [Page 17] INTERNET-DRAFT BNG Simple CUSP | | | UP sends Synchronization End | |------to CP via S-CUSP-------------->| | | | UP sends NAT Address Renew Req. | |------to CP via S-CUSP-------------->| | | | CP sends NAT Address Renew Res. | |<-----to UP via S-CUSP---------------| | | | UP sends Synchronization Request | |------to CP via S-CUSP-------------->| | | | CP sends Synchronization Begin | |<-----to UP via S-CUSP---------------| | | | CP sends User/Route/Tunnel. INFO | |<-----to UP via S-CUSP---------------| | | | CP sends Synchronization End | |<-----to UP via S-CUSP---------------| | | 3.8 CGN Address Allocation UP CP | | | UP sends Address Allocation Req. | |------to CP via S-CUSP-------------->| | | | CP sends Address Allocation Res. | |<-----to UP via S-CUSP---------------| | | See Section 4.1.6 Hu, et al [Page 18] INTERNET-DRAFT BNG Simple CUSP 4. S-CUSP Message Formats This section specifies the format of the common S-CUSP message header, the format of the TLVs that appear in S-CUSP messages, the format of the sub-TLVs that appear within the values of some TLVs, and the format of some basic data fields. 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 a missing mandatory TLV MUST trigger an Error message (see Section 5.6). Conversely, if a TLV is optional, the TLV may or may not be present. Network byte order is used for all multi-byte fields. 4.1 Common Message Header Common 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S-CUSP Message Common Header 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 UP both using the same major version of the protocol. Resv (4 bits): Reserved. MUST be sent as zero and ignored on receipt. Message-Type (8 bits): The set of message types specified in this document is listed in Section 12.2.1. Message-Length (16 bits): Total length of the CUSP message including the common header, expressed in number of bytes as an unsigned integer. Hu, et al [Page 19] INTERNET-DRAFT BNG Simple CUSP Transaction ID (16 bits): This field is used to identify requests. It is echoed back in any corresponding ACK / response / Error message. 4.1.1 Control Messages Control messages are listed below. Type Name Notes and TLVs that can be carried ---- ---- ------------------------------------ 1 Hello Capability negotiation. 2 Keepalive Keepalive. 3 Synch_Request Synchronization request. 4 Sync_Begin Synchronization starts. 5 Sync_Data Synchronization data: TLVs specified in Section 5. 6 Sync_End End synchronization. 4.1.2 Table Messages Table messages are listed below. Type Name Notes and TLVs that can be carried ---- ---- ------------------------------------ 7 Update_Request TLVs specified in Section 5. 8 Update_Response TLVs specified in Section 5. 4.1.3 Resource Reporting Message The Resource Reporting message is as follows: Type Name Notes and TLVs that can be carried ---- ---- ------------------------------------ 9 Report Interface-Info, Board-Info. 4.1.4 Event Reporting Message The Event Reporting message is as follows: Type Name Notes and TLVs that can be carried ---- ---- ------------------------------------ 10 Event Traffic-Info, Detect-Info. Hu, et al [Page 20] INTERNET-DRAFT BNG Simple CUSP 4.1.5 Vendor Message The Vendor message is as follows: Type Name Notes and TLVs that can be carried ---- ---- ------------------------------------ 11 Vendor Vendor-Defined, any other TLV(s) as implemented by the vendor. 4.1.6 Resource Allocation Messages The Resource Allocation messages are listed below. Type Name Notes and TLVs that can be carried ---- ---- ------------------------------------ 200 Addr_Allocation_Req Addr-Alloc-Req 201 Addr_Allocation_Ack Addr-Alloc-Resp 202 Addr_Renew_Req Addr-Renew-Req 203 Addr_Renew_Ack Addr-Renew-Resp 204 Addr_Release_Req Addr-Release-Req 205 Addr_Release_Ack Addr-Release-Resp 4.2 Common Message TLV Format CUSP messages consist of the common header specified in Section 4.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 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 12.2.3. For all other Message-Types, the Oper field MUST be sent as zero and ignored on receipt. 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 12.2.2. Hu, et al [Page 21] INTERNET-DRAFT BNG Simple CUSP TLV-Length (2 bytes): The length of the Value portion of the TLV in bytes as an unsigned integer. Value (variable length): This is the value portion of the TLV whose size is given by TLV-Length. 4.3 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. STRING 0 to 255 octets. Will be encoded as a sub-TLV (see Section 4.4) to provide the length. MAC-Addr 6 octets. Ethernet MAC Address. 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. 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. VLAN ID 2 octets. As follows: 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. Hu, et al [Page 22] INTERNET-DRAFT BNG Simple CUSP 4.4 Sub-TLV Format and Specific 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 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-TVL occurs. See Section 12.2.4. Length (2 bytes): The length of the Value portion of the TLV in bytes as an unsigned integer. Value (variable length): This is the value portion of the TLV whose size is given by Length. The sub-TLVs currently specified are specified in the following subsections. 4.4.1 VRF-Name The name of the VRF (Virtual Routing and Forwarding instance) that the BNG user accesses. Optional. Sub-TLV Type: 1, VRF Name Length: 1-255 octets. Value: STRING. 4.4.2 Ingress-QoS-Profile Indicates the upstream QoS Profile Name. Optional. Sub-TLV Type: 2, Ingress QoS Profile Name Length: 1-255 octets. Value: STRING. Hu, et al [Page 23] INTERNET-DRAFT BNG Simple CUSP 4.4.3 Egress-QoS-Profile Indicates the downstream QoS Profile Name. Optional. Sub-TLV Type: 3, Egress QoS Profile Name Length: 1-255 octets. Value: STRING. 4.4.4 User-ACL-Policy Indicates the name of the ACL policy group to which the user belongs. Optional. Sub-TLV Type: 4, User ACL Policy Name Length: 1-255 octets. Value: STRING. 4.4.5 Multicast-Profile-v4 Name of the IPv4 multicast program list a user can order. Optional. Sub-TLV Type: 5, Multicast Profile of IPv4. Length: 1-255 octets. Value: STRING. 4.4.6 Multicast-Profile-v6 Name of the IPv6 multicast program list a user can order. Optional. Sub-TLV Type: 6, Multicast Profile of IPv6. Length: 1-255 octets. Value: STRING. 4.4.7 Ingress-CAR Indicates the authorized upstream Committed Access Rate (CAR) parameters. Optional. Sub-TLV Type: 7, Ingress CAR. Length: 16 Octets. Value: The following four fields in the order given: Hu, et al [Page 24] INTERNET-DRAFT BNG Simple CUSP Name Type Description ------ ------- --------------------------------- 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. 4.4.8 Egress-CAR Indicates the authorized downstream Committed Access Rate (CAR) parameters. Optional. Sub-TLV Type: 8, Egress CAR. Length: 16 Octets. Value: The following four fields in the order given: Name Type Description ------ ------- --------------------------------- 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. 4.4.9 NAT-Instance Name of the Network Address Translation (NAT) Instance to which the user belongs. Optional. Sub-TLV Type: 9, NAT Instance Name. Length: 1-255 octets. Value: STRING. 4.4.10 Pool-Name Indicates the name of the address pool to which the public network segment belongs. Optional. Sub-TLV Type: 10, IP Address Pool Name. Length: 1-255 octets. Value: STRING. Hu, et al [Page 25] INTERNET-DRAFT BNG Simple CUSP 4.4.11 If-Desc Description of an interface. Mandatory. Sub-TLV Type: 11, Interface Description Length: 12 Value: Several fields structured 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-Type 4 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chassis | 1 byte +-+-+-+-+-+-+-+-+ | Slot | 1 byte +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Information | 2 bytes +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Port Number 4 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If-Type: Interface Type: 0 = Reserved, 1 = FE, 2 = GE, 3 = 10GE, 4 = 100GE, 5: Eth- Trunk, 6: Tunnel, 7: VE Chassis: Subrack Number Slot: Slot Port Information: If-Type = Physical, the Port Information consists of a 1-byte Physical Slot number followed by a 1-byte Physical port number. If-Type - virtual port, the Port Information consists of a 2 byte logical number of the virtual interface. Sub-Port: Sub-port Number Hu, et al [Page 26] INTERNET-DRAFT BNG Simple CUSP 5. Basic TLVs This section describes basic TLVs. 5.1 Interface Information TLV The Interface Information TLV can be used by a CP to control the access mode, authentication methods, and other related functions of an interface. The format of the Interface Information 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.1: Interface Information TLV Function: Service information about the user access interface on the BNG. TLV Type: 1 TLV Length: variable TLV fields: 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, 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; Hu, et al [Page 27] INTERNET-DRAFT BNG Simple CUSP 0x2: DOT1X authentication; 0x4: Web authentication; 0x8: Web fast authentication; 0x10: Binding authentication. Auth-Method6: 1 byte in length, for IPv6 scenario, 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; The flags field is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |Y|X|P|I|N|A|S|F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.2: Interface Flags Where: F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a subscriber go to online. 1: enabled, 0: disabled. S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a subscriber go to online. 1: enabled, 0: disabled. A (ARP Trigger) bit: Indicates whether ARP packets can trigger a subscriber go to online. 1: enabled, 0: disabled. N (ND Trigger) bit: Indicates whether ND packets can trigger a subscriber go to 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. Hu, et al [Page 28] INTERNET-DRAFT BNG Simple CUSP 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. 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. 5.2 Basic User Information TLVs The Basic User Information TLVs are defined for a CP to carry the basic information about a user to an UP. 5.2.1 Basic User Information TLV The format of the Basic User Information 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 5.3: Basic User Information TLV Hu, et al [Page 29] INTERNET-DRAFT BNG Simple CUSP Function: Basic information about a BNG user. TLV Type: 2 TLV Length: variable in length; TLV Fields: Name Length Description -------------- ------ ---------------------- User-ID 4 bytes User ID. User-Mac MAC-Addr User MAC Address. Oper-ID 1 byte Indicates the ID of an operation performed by a user. This field is carried in the response from the UP. Session-ID 4 bytes Session ID of a PPPoE user. Zero for non- PPPoE user. Access-Type 1 byte See Section 5.2.1.1. Sub-Access-Type 1 byte Indicates whether PPP termination or PPP relay is used. 0: N/A 1: PPP2 on the LAC side: Termination, PPP on the LNS side Account-Type 1 byte IPv4/IPv6 charging: 0 separate charging: Collects statistics on IPv4 and IPv6 traffic of terminals independently. 1: Statistics and charging Collects statistics on IPv4 and IPv6 traffic of terminals. User-IP-Type 1 byte 1:IPv4 stack and 2:IPv6 stack 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 Outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that the 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. If-Index 4 bytes Interface index. The Reserved field MUST be sent as zero and ignored on receipt. Hu, et al [Page 30] INTERNET-DRAFT BNG Simple CUSP 5.2.1.1 Access Types Table Value Meaning ----- --------- 1 PPP access (PPP) 2 PPP over Ethernet over ATM access (PPPoEoA) 3 PPP over ATM access (PPPoA) 4 PPP over Ethernet access (PPPoE) 5 PPPoE over VLAN access (PPPoEoVLAN) 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) 5.2.2 User PPP Information TLV The User PPP Information TLV is defined to carry PPP information of a User, from a CP to an UP. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSS | Reserved |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRU | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Magic Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.4: User PPP Information TLV Function: PPP [RFC1661] information for a BNG user. TLV Type: 3 TLV Length: 20 bytes in length Hu, et al [Page 31] INTERNET-DRAFT BNG Simple CUSP TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. MSS-Value 2 bytes Indicates the MSS value. MSS-Enable 1 bit Indicates whether the MSS is enabled. 0: The function is disabled. 1: Enable MRU 2 bytes PPPoE local MRU. 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. 5.3 User IPv4 Information TLV The User IPv4 Information TLV is defined to carry IPv4 related information for a BNG user. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gateway IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Reserved |U|E|W|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.5: User IPv4 Information TLV Function: IPv4 information for a BNG user. TLV Type: 4 TLV Length: variable TLV fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. User-IPv4 IPv4 User IPv4 address. Gateway-IPv4 IPv4 User gateway. Portal Force 1 bit (P) Push advertisement switch, 0: off, 1: Hu, et al [Page 32] INTERNET-DRAFT BNG Simple CUSP on. Web-Force 1 bit (W) IP4 Web push flag. 0: off, 1: on. Echo-Enable 1 bit (E) Compatible with PPP/ARP and the UP returns ARP Req or PPP Echo. 0: off, 1: on. IPv4-URPF 1 bit (U) Unicast Reverse Path Forwarding (URPF) flag of a user. 0: off, 1: on. MTU 2 bytes MTU value. The default value is 1500. VRF-Name Sub-TLV VRF name. The Reserved field MUST be sent as zero and ignored on receipt. 5.4 User IPv6 Information The User IPv6 Information TLV is defined to carry IPv6 related information of a BNG user. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ User PD-Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Gateway ND-Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User IANA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface ID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Reserved |U|E|W|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (VRF Name sub-TLV) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.6: User IPv6 Information TLV Function: IPv6 information for a BNG user. TLV Type: 5 TLV Length: variable Hu, et al [Page 33] INTERNET-DRAFT BNG Simple CUSP TLV fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. PD-Address IPv6 Prefix Delegation (PD) address. ND-Address IPv6 Neighbor Discovery (ND) address. IANA-Address IPv6 IANA address. Interface-ID 8 bytes IPv6 interface ID. Portal Force 1 bit (P) Push advertisement switch, 0: off, 1: on. Web-Force 1 bit (W) IP6 Web push flag. 0: off, 1: on. Echo-Enable 1 bit (E) Compatible with PPP/ARP and the UP returns ARP Req or PPP Echo. 0: off, 1: on. IPv6-URPF 1 bit (U) User Reverse Path Forwarding (URPF) flag of a user. 0: off, 1: on. MTU 2 bytes MTU value. The default value is 1500. VRF-Name Sub-TLV VRF name. The Reserved field MUST be sent as zero and ignored on receipt. 5.5 User QoS Policy Information TLV 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 5.7: User QoS Policy Information TLV Function: BNG user authorization information. TLV Type: 6 TLV length: variable in length TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. Ingress-Priority 1 byte Indicates the upstream priority. The value is 0~7. Egress-Priority 1 byte Indicates the downstream priority. The value is 0~7. Hu, et al [Page 34] INTERNET-DRAFT BNG Simple CUSP 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. The Reserved field MUST be sent as zero and ignored on receipt. 5.6 Routing Table TLVs 5.6.1 IPv4 Routing Information TLV 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.8: IPv4 Routing Information TLV Function: IPv4 routing information. TLV Type: 7 TLV Length: Variable length Hu, et al [Page 35] INTERNET-DRAFT BNG Simple CUSP TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. This field is filled with all Fs when a non-user route is delivered to the UP. Dest-Address IPv4 Destination address. Next-Hop IPv4 Next hop address. Out-If-Index 4 bytes Indicates the interface index. Cost 4 bytes Cost value of the route. Tag 4 bytes Route tag value. Route-Type 2 bytes Route type. The options are as follows: HOST_RT = 0 user host route FRAME_RT = 1 Radius authorization FrameRoute NET_RT = 2, network segment route GATEWAY_RT = 3, gateway route RADIUS_IP_RT = 4, Radius authorized IP route LNS_USER_RT = 5 L2TP LNS side user route Advertise-Flag 1 bit Indicates the route advertisement flag. 0: Not advertised, 1: advertised. VRF-Name Sub-TLV VRF name. The Reserved field MUST be sent as zero and ignored on receipt. 5.6.2 IPv6 Routing Information TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Dest-Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Next-Hop ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out-If-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Type | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ VRF-Name sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hu, et al [Page 36] INTERNET-DRAFT BNG Simple CUSP Figure 5.9: IPv6 Routing Information TLV Function: IPv4 routing information. TLV Type: 8 TLV Length: Variable TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. This field is filled with all Fs when a non-user route is delivered to the UP. Dest-Address IPv6 Destination address. Next-Hop IPv6 Next hop address. Out-If-Index 4 bytes Indicates the interface index. Cost 4 bytes Cost value of the route. Tag 4 bytes Route tag value. Route-Type 2 bytes Route type. The options are as follows: HOST_RT = 0 user host route FRAME_RT = 1 Radius authorization FrameRoute NET_RT = 2, network segment route GATEWAY_RT = 3, gateway route RADIUS_IP_RT = 4, Radius authorized IP route LNS_USER_RT = 5 L2TP LNS side user route Advertise-Flag 1 bit Indicates the route advertisement flag. 0: Not advertised, 1: advertised. VRF-Name Sub-TLV VRF name. The Reserved field MUST be sent as zero and ignored on receipt. 5.7 Static User Information TLVs Hu, et al [Page 37] INTERNET-DRAFT BNG Simple CUSP 5.7.1 Static IPv4 User Information TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ VRF-Name sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.10: Static IPv4 User Information TLV Function: User information which is used proactively to detect and go on line. TLV Type: 9 TLV Length: variable TLV Fields: Name Type Description -------------- ------ ---------------------- If-Index 4 bytes Indicates the interface index. C-VID VLAN-ID Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. The valid value is 1~4094. P-VID VLAN-ID Outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that the C-VID. The valid value is 1~4094. For a single-layer VLAN, set this parameter to PeVid. User Address IPv4-Addr Terminal IP address. Gateway Address IPv4-Addr Gateway IP Address. User-MAC MAC-Addr MAC address of the terminal. VRF-Name Sub-TLV VRF Name. The Reserved field MUST be sent as zero and ignored on receipt. Hu, et al [Page 38] INTERNET-DRAFT BNG Simple CUSP 5.7.2 Static IPv6 User Information TLV 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.11: Static IPv6 User Information TLV Function: User information which is used proactively to detect and go on line. TLV Type: 10 TLV Length: variable TLV Fields: Name Type Description -------------- ------ ---------------------- If-Index 4 bytes Indicates the interface index. C-VID VLAN-ID Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. The valid value is 1~4094. P-VID VLAN-ID Outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that the C-VID. The valid value is 1~4094. For a single-layer VLAN, set this parameter to PeVid. User Address IPv6-Addr User IP address. Gateway Address IPv6-Addr Gateway IP Address. User-MAC MAC-Addr MAC address of the terminal. VRF-Name Sub-TLV VRF Name. The Reserved field MUST be sent as zero and ignored on receipt. Hu, et al [Page 39] INTERNET-DRAFT BNG Simple CUSP 5.8 L2TP User Information TLVs 5.8.1 L2TP-LAC User Information TLV 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 5.12: L2TP-LAC User Information TLV Function: Information about the L2TP-LAC for a BNG user. TLV Type: 11 TLV Length: 12 TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes The User identifier. 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 with the L2TP tunnel. 5.8.2 L2TP-LNS User Information TLV 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 5.13: L2TP-LNS User Information TLV Hu, et al [Page 40] INTERNET-DRAFT BNG Simple CUSP Function: Information about the L2TP tunnel for a BNG user. TLV Type: 12 TLV Length: 12 TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes The User identifier. 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 with the L2TP tunnel. 5.8.3 L2TP-LAC Tunnel TLV 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (VRF Name sub-TLV) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.14: L2TP-LAC Tunnel TLV Function: Information about the L2TP tunnel for a BNG user. TLV Type: 13 TLV Length: variable TLV Fields: Name Type Description -------------- ------ ---------------------- 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 Indicates the source UDP port number of an L2TP user. Dest-Port 2 bytes Indicates the destination UDP port number of an L2TP user. Source-IP IPv4/v6 The source IP address of the tunnel. Dest-IP IPv4/v6 The destination IP address of the tunnel. Tunnel-VRF-Name Sub-TLV L2TP user tunnel VRG name. Hu, et al [Page 41] INTERNET-DRAFT BNG Simple CUSP 5.8.4 L2TP-LNS Tunnel TLV 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs (VRF Name sub-TLV) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.15: L2TP-LNS Tunnel TLV Function: Information about the L2TP tunnel for a BNG user. TLV Type: 14 TLV Length: variable TLV Fields: Name Type Description -------------- ------ ---------------------- 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 Indicates the source UDP port number of an L2TP user. Dest-Port 2 bytes Indicates the destination UDP port number of an L2TP user. Source-IP IPv4/v6 The source IP address of the tunnel. Dest-IP IPv4/v6 The destination IP address of the tunnel. Tunnel-VRF-Name Sub-TLV L2TP user tunnel VRG name. 5.9 NAT User Information TLV 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 5.16: NAT User Information TLV Hu, et al [Page 42] INTERNET-DRAFT BNG Simple CUSP Function: NAT [RFC3022] public network information for a BNG user. TLV Type: 15 TLV Length: 12 TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. NAT-Port-Start 2 bytes NAT start port number. NAT-Port-End 2 bytes NAT end port number. NAT-Sub-IP 4 bytes NAT public network address. 5.10 Vendor Defined TLV 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 5.17: Vendor Defined TLV Function: Used to indicate vendor, sub-type, and version for a Vendor Defined message. TLV Type: 1024 TLV Length: variable TLV Fields: Name Type Description -------------- ------ ---------------------- Vendor-ID 4 bytes Vendor ID, which is defined in the 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. 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 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 Hu, et al [Page 43] INTERNET-DRAFT BNG Simple CUSP message that it defines different from other Sub-Type values that vendor has used. Also, when modifying a vendor defined messages 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 44] INTERNET-DRAFT BNG Simple CUSP 6. Control TLVs 6.1 Hello TLV 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 6.1: Hello TLV Function: Hello Message. TLV Type: 100 TLV Length: 12 TLV Fields: Name Type Description -------------- ------ ---------------------- VerSupported 32 bits 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. Bit 0 indicates support of Sub-Version zero, bit 1 indicates support of Sub-Version one, etc. Vendor-ID 4 bytes Vendor ID, which is defined in RADIUS [RFC2865]. Capabilities 32 bits Flags that indicate the support of particular capabilities by the sender of the Hello. After the exachange of Hello messages, the CP and UP each perform a logical AND of the Sub-Version supported and of the Capabilities bits fields. 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 Hu, et al [Page 45] INTERNET-DRAFT BNG Simple CUSP 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. 6.2 Error Information TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6.2: Error TLV Function: Error response. TLV Type: 101 TLV Length: 8 TLV Fields: Name Type Description -------------- ------ ---------------------- Message-Type 4 bytes Message category. Set this parameter to the corresponding processing message code. Status-Code 4 bytes Error Code (see Section 12.2.5). Hu, et al [Page 46] INTERNET-DRAFT BNG Simple CUSP 7. Resource Reporting TLVs 7.1 Interface Resource Information TLV 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 7.1: Interface Resource TLV Function: BNG interface resource information. TLV Type: 200 TLV Length: variable TLV Fields: Name Type Description -------------- ------ ---------------------- If-Index 4 bytes Indicates the interface index. MAC-Address MAC-Addr Interface MAC address. Phy-State 1 byte Physical status of the interface. 0: down, 1: Up MTU 4 bytes Interface MTU value. The Reserved field MUST be sent as zero and ignored on receipt. 7.2 UP Board Status Report Information TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chassis | Slot | Sub-Slot | Board-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7.2: Interface Resource TLV Hu, et al [Page 47] INTERNET-DRAFT BNG Simple CUSP Function: Board information reported by the UP, including the board type and in-position status TLV Type: 201 TLV Length: 8 TLV Fields: Name Type Description -------------- ------ ---------------------- Chassis 1 byte Subrack number. Slot 1 byte Slot number. Sub-Slot 1 byte Sub-slot number. Board-Type 1 byte 1: CGN service card, 2: Interface board. State 1 byte Board status 0: Normal, 1: Abnormal. The reserved field must be sent as zero and ignored on receipt. Hu, et al [Page 48] INTERNET-DRAFT BNG Simple CUSP 8. Event TLVs 8.1 User Traffic Statistics Report TLV 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 8.1: User Traffic Statistics Report TLV Hu, et al [Page 49] INTERNET-DRAFT BNG Simple CUSP Function: User traffic statistics report. TLV Type: 300 TLV Length: 72 TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. Statistics-Type 4 bytes Traffic type. The options are as follows: 0: IPv4 traffic, 1: IPv6 traffic, 2: Dual stack traffic. Ingress-Packets 8 bytes Upstream traffic: number of packets (UNIT64). Ingress-Bytes 8 bytes Upstream traffic: byte count (UINT64). Ingress-Loss-Packets 8 bytes Upstream packet loss: number of data packets (UNIT64). Ingress-Loss-Bytes 8 bytes Upstream packet loss: byte count (UINT64). Egress-Packets 8 bytes Downstream traffic: number of packets (UNIT64). Egress-Bytes 8 bytes Downstream traffic: byte count (UINT64). Egress-Loss-Packets 8 bytes Downstream packet loss: number of data packets (UNIT64). Egress-Loss-Bytes 8 bytes Downstream packet loss: byte count (UINT64). 8.2 User Detection Result Report TLV 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 8.2: User Detection Result Report TLV Function: Report BNG user detection. TLV Type: 301 TLV Length: 8 TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. Detect-Type 1 byte 0: IPv4 detection, 1: IPv6 detection, 2: PPP detection. Hu, et al [Page 50] INTERNET-DRAFT BNG Simple CUSP 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. 8.3 User Basic Table Operation Result TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Oper ID | Oper Code | Oper Result | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8.3: User Detection Result Report TLV Function: Report the operation result of a table update. TLV Type: 302 TLV Length: 12 TLV Fields: Name Type Description -------------- ------ ---------------------- User-ID 4 bytes User ID. Oper-ID 1 byte When a user connection number, dual stack, or Modify operation is performed, the response message carries the ConnectID carried in the following table. The CP verifies the corresponding operation. 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 12.2.5. The Reserved field MUST be sent as zero and ignored on receipt. Hu, et al [Page 51] INTERNET-DRAFT BNG Simple CUSP 9. Resource Allocation TLVs 9.1 Request Address Allocation TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9.1: Request Address Allocation TLV Function: Request address allocation. TLV Type: 400 TLV Length: variable TLV Fields: Name Type Description -------------- ------ ---------------------- Pool-Name Sub-TLV Address pool name. 9.2 Address Assignment Response TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Reserved | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sub-TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9.2: Address Assignment Response TLV Function: The CGN sends a response to the address assignment request. TLV Type: 401 TLV Length: variable Hu, et al [Page 52] INTERNET-DRAFT BNG Simple CUSP TLV Fields: Name Type Description -------------- ------ ---------------------- Lease-Time 4 bytes Duration of address lease in seconds. Client-IP IPv4-Addr Start address and mask of the address segment. Result-Code 1 byte Processing Result, 0: Success, 1: Failure Pool-Name Sub-TLV Address segment address pool name. 9.3 Address Renewal Request TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9.3: Request Address Renewal TLV Function: Request address renewal. TLV Type: 402 TLV Length: variable TLV fields: Name Type Description -------------- ------ ---------------------- Client-IP IPv4-Addr Start address and mask of the address segment. Pool-Name Sub-TLV Address segment address pool name. Hu, et al [Page 53] INTERNET-DRAFT BNG Simple CUSP 9.4 Address Renewal Response TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result-Code | Reserved | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sub-TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9.4: Address Renewal Response TLV Function: Request address renewal. TLV Type: 403 TLV Length: variable TLV fields: Name Type Description -------------- ------ ---------------------- Client-IP IPv4-Addr Start address and mask of the address segment. Result-Code 1 bytes Processing Result, 0: Success, 1: Failure Pool-Name Sub-TLV Address segment address pool name. 9.5 Address Release Request TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9.5: Request Address Renewal TLV Function: The CGN request the release of IP addresses. TLV Type: 404 TLV Length: variable Hu, et al [Page 54] INTERNET-DRAFT BNG Simple CUSP TLV fields: Name Type Description -------------- ------ ---------------------- Client-IP IPv4-Addr Start address and mask of the address segment. Pool-Name Sub-TLV Address segment address pool name. 9.6 Address Release Response TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result-Code | Reserved | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sub-TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9.6: Address Renewal Response TLV Function: Request address renewal. TLV Type: 405 TLV Length: variable TLV fields: Name Type Description -------------- ------ ---------------------- Client-IP IPv4-Addr Start address and mask of the address segment. Result-Code 4 bytes Processing Result, 0: Success, 1: Failure Pool-Name Sub-TLV Address segment address pool name. Hu, et al [Page 55] INTERNET-DRAFT BNG Simple CUSP 10. Implementation Status This section is NOT intended to appear in any resulting RFC. 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 the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation or test results here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF 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.". 10.1 Implementations Information on three S-CUSP implementations appears below. 10.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 56] INTERNET-DRAFT BNG Simple CUSP 10.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 10.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 10.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 57] INTERNET-DRAFT BNG Simple CUSP 10.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 58] INTERNET-DRAFT BNG Simple CUSP 11. Security Considerations The 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]. Hu, et al [Page 59] INTERNET-DRAFT BNG Simple CUSP 12. IANA Considerations IANA is requested to perform the actions below in this section. 12.1 Service Name and Port Number IANA is requested to assign a service name and port for BNG S-CUSP as follows: Service Port Transport Name Number Protocol Description Reference ------- ------ --------- ------------- --------------- s-cusp tbd1 tcp Control-plane and [this document] User-plane Separation Protocol 12.2 S-CUSP Parameters IANA is requested to create an "S-CUSP Parameters" web page and include thereon the registries set up in the Sub-Sections below. 12.2.1 Message Types IANA is requested to create an S-CUSP Message Types registry on the S-CUSP Parameters Web Page as follows: Registry Name: S-CUSP Message Types Registration Procedure: Expert Review Reference: [this document] Type Name Reference ------ ----------- --------------- 0 - Reserved 1 Hello [this document] 2 Keepalive [this document] 3 Sync_Request [this document] 4 Sync_Begin [this document] 5 Sync_Data [this document] 6 Sync_End [this document] 7 Update_Request [this document] 8 Update_Response [this document] 9 Report [this document] 10 Event [this document] 11 Vendor [this document] Hu, et al [Page 60] INTERNET-DRAFT BNG Simple CUSP 12-199 - Unassigned 200 Addr_Allocation_Req [this document] 201 Addr_Allocation_Ack [this document] 202 Addr_Renew_Req [this document] 203 Addr_Renew_Ack [this document] 204 Addr_Release_Req [this document] 205 Addr_Release_Ack [this document] 206-254 - Unassigned 255 - Reserved 12.2.2 TLV Types IANA is requested to create an S-CUSP TLV Types registry on the S- CUSP Parameters Web Page as follows: Registry Name: S-CUSP TLV Types Registration Procedure: Expert Review Reference: [this document] Type Name Usage Description ------ ------------ -------------------------- 1 Access-IfSrv Service information about the user access interface on the BNG. 2 User-Basic Basic information about a BNG user. 3 User-PPP PPP information about a BNG user. 4 User-IPv4 IPv4 address of a BNG user. 5 User-IPv6 IPv6 address of a BNG user. 6 User-Auth QoS authorization information of a BNG user. 7 RouteV4-Info BNG IPv4 routing information. 8 RouteV6-Info BNG IPv6 routing information. 9 Static-IPv4-User Static user information on a BNG. Used to proactively detect and go online. 10 Static-IPv6-User Static user information on a BNG. Used to proactively detect and go online. 11 User-L2TP-LAC L2TP LAC user information. 12 User-L2TP-LNS L2TP LNS user information. 13 User-L2TP-LAC-Tnl L2TP LAC tunnel information. 14 User-L2TP-LNS-Tnl L2TP LNS tunnel information. 15 User-NAT Public network segment information for a NAT user. 16-99 unassigned 100 Hello-Info The CP and UP advertise versions to each other 101 Error-Info The Ack of the control message carries the processing result, success, or error. 102-199 unassigned - 200 Interface-Info Interfaces reported by the UP including Hu, et al [Page 61] INTERNET-DRAFT BNG Simple CUSP physical interfaces, sub-interfaces, trunk interfaces, and tunnel interfaces. 201 Board-Info Board information reported by the UP including the board type and in-position status. 202-299 unassigned - 300 Traffic-Info User traffic statistics. 301 Detect-Info User detection information. 302 User-TBL-Result Processing result of user forwarding table delivery. 303-299 unassigned - 400 Addr-Alloc-Req Request address allocation. 401 Addr-Alloc-Ack Address allocation response. 402 Addr-Renew-Req Request for address lease renewal. 403 Addr-Renew-Ack Response to a request for extending an IP address lease. 404 Addr-Release-Req Request to release the address. 405 Addr-Release-Ack Ack of a message releasing an IP address. 406-1023 unassigned - 1024 Vendor-Defined As implemented by vendor. 1025-65535 unassigned - 12.2.3 TLV Operation Codes IANA is requested to create an S-CUSP TLV Operation Codes registry on the S-CUSP Parameters Web Page as follows: Registry Name: S-CUSP TLV Operation Codes Registration Procedure: Expert Review Reference: [this document] Code Operation Reference ---- ---------- --------- 0 - reserved 1 Update [this document] 2 Delete [this document] 3-15 - unassigned 12.2.4 Sub-TLV Types IANA is requested to create an S-CUSP Sub-TLV Types registry on the S-CUSP Parameters Web Page as follows: Registry Name: S-CUSP Sub-TLV Types Registration Procedure: Expert Review Reference: [this document] Hu, et al [Page 62] INTERNET-DRAFT BNG Simple CUSP Code Operation Reference ----- ------------------ --------------- 0 - reserved 1 VRF Name [this document] 2 Ingress-QoS-Profile [this document] 3 Egress-QoS-Profile [this document] 4 User-ACL-Policy [this document] 5 Multicast-ProfileV4 [this document] 6 Multicast-ProfileV6 [this document] 7 Ingress-CAR [this document] 8 Egress-CAR [this document] 9 NAT-Instance [this document] 10 Pool-Name [this document] 11 If-Desc [this document] 12-64534 - unassigned 65535 -reserved 12.2.5 ERRID Codes IANA is requested to create an S-CUSP ERRID Codes registry on the S- CUSP Parameters Web Page as follows: Registry Name: S-CUSP ERRID Codes Registration Procedure: Expert Review Reference: [this document] Value Name Remarks ------ ------- -------- 0 Success Success 1 Fail Failure. The reason is not classified. 2 TLV-Unknown The TVL type cannot be identified. 3 TLV-Length The TLV length is abnormal. 4 TLV-Value The TLV value is abnormal 5-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-1999 - unassigned Unassigned version negotiation error codes. 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. 3000 - reserved 3001 Pool-Mismatch The corresponding address pool cannot be found. Hu, et al [Page 63] INTERNET-DRAFT BNG Simple CUSP 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 address allocation error codes, used in NAT 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 64] INTERNET-DRAFT BNG Simple CUSP Contributors Zitao Wang Huawei Technologies 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: wangzitao@huawei.com Hu, et al [Page 65] INTERNET-DRAFT BNG Simple CUSP Normative References [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, . [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Informative References [SCUSP-architecture] Hu, S., Qin, G. Li, Z., Chua, T., Lopez, V., Eastlake, D., Wang, Z., and J. Song, "Architecture for Control Plane and User Plane Separated BNG", draft-cuspdt-rtgwg-cu-separation-bng-architecture-04 (work in progress), March 2019. [SCUSP-YANG] Huang, G., Hu, F., Hu, S., and F. Fangwei, "YANG Data Model for Configuration Interface of Control-Plane and User-Plane separation BNG", draft-cuspdt-rtgwg-cu-separation-yang-model (work in progress), January 2019. [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, . Hu, et al [Page 66] INTERNET-DRAFT BNG Simple CUSP [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, [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 67] INTERNET-DRAFT BNG Simple CUSP Authors' Addresses Shujun Hu China Mobile 32 Xuanwumen West Ave, Xicheng District Beijing, Beijing 100053 China Email: hushujun@chinamobile.com Donald Eastlake, 3rd Huawei Technologies 1424 Pro Shop Court Davenport, FL 33896 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Mach 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 68] INTERNET-DRAFT BNG Simple CUSP Jun Song Huawei Technologies 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: song.jun@huawei.com Tee Mong Chua Singapore Telecommunications Limited 31 Exeter Road, #05-04 Comcentre Podium Block Singapore City 239732 Singapore Email: teemong@singtel.com Hu, et al [Page 69] INTERNET-DRAFT BNG Simple 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 70]