< draft-cuspdt-rtgwg-cu-separation-bng-protocol-03.txt   draft-cuspdt-rtgwg-cu-separation-bng-protocol-04.txt >
INTERNET-DRAFT S. Hu INTERNET-DRAFT S. Hu
Intended status: Proposed Standard China Mobile Intended status: Proposed Standard China Mobile
D. Eastlake D. Eastlake
Z. Wang M. Chen
Huawei Huawei Technologies
F. Qin F. Qin
Z. Li Z. Li
China Mobile China Mobile
J. Song J. Song
Huawei Huawei Technologies
T. Chua T. Chua
Singapore Telecommunications Ltd Singapore Telecommunications
Expires: May 29, 2018 November 30, 2018 Expires: September 10, 2019 March 11, 2019
Control-Plane and User-Plane Separation BNG Control Channel Protocol Control-Plane and User-Plane Separation BNG
draft-cuspdt-rtgwg-cu-separation-bng-protocol-03.txt Simple Control Channel Protocol
draft-cuspdt-rtgwg-cu-separation-bng-protocol-04.txt
Abstract Abstract
This document specifies the CU Separation Broadband Network Gateway This document specifies the Simple Control Plane (CP) and User Plane
(BNG) control channel Protocol (CUSP) for communications between a (UP) Separation Broadband Network Gateway (BNG) control channel
Control Plane (CP) and a set of User Planes (UPs). CUSP is designed Protocol (S-CUSP) for communications between a CP and a UP. S-CUSP is
to be flexible and extensible so as to easily allow for the addition designed to be flexible and extensible so as to easily allow for the
of further messages and objects, should further requirements be addition of further messages and data items, should requirements be
expressed in the future. expressed in the future.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the authors or the RGTWG working group mailing list: to the authors or the RGTWG working group mailing list:
rtgwg@ietf.org. rtgwg@ietf.org.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
INTERNET-DRAFT CU Separation Protocol INTERNET-DRAFT BNG Simple CUSP
Table of Contents Table of Contents
1. Introduction............................................3 1. Introduction............................................5
2. Concept and Terminology.................................4 2. Terminology.............................................6
2.1 Terminology............................................4 2.1 Acronyms...............................................6
3. Protocol Overview.......................................5 3. Protocol Overview.......................................8
3.1 Initialization Phase...................................5 3.1 S-CUSP Configuration...................................8
3.2 Network Resource Report................................5 3.2 S-CUSP Session Establishment...........................9
3.3 IPoE Session Establishment.............................6 3.3 Overview of S-CUSP Procedures..........................9
3.4 PPPoE Session Establishment............................7 3.4 Network Resource Report...............................10
3.5 Setting the User's QoS Information.....................9 3.5 BNG Access Procedures.................................11
3.6 CUSP Session Statistics...............................10 3.5.1 IPoE Access.........................................11
3.5.2 PPPoE Access........................................12
3.5.3 L2TP LAC Access.....................................13
3.5.4 L2TP LNS Access.....................................13
3.5.5 L2TP LTS Access.....................................15
3.6 Setting the User's QoS Information....................15
3.7 CP and UP Synchronization.............................16
3.8 CGN Address Allocation................................17
4. CUSP Common Header.....................................11 4. S-CUSP Message Formats.................................18
4.1 Common Message Header.................................18
4.1.1 Control Messages....................................19
4.1.2 Flow Table Message..................................19
4.1.3 Resource Reporting Message..........................19
4.1.4 Event Reporting Message.............................19
4.1.5 Vendor Message......................................20
4.1.6 Resource Allocation Messages........................20
4.2 Common Message TLV Format.............................20
4.3 Basic Data Fields.....................................21
4.4 Sub-TLV Format and Specific Sub-TLVs..................22
4.4.1 VRF-Name............................................22
4.4.2 Ingress-QoS-Profile.................................22
4.4.3 Egress-QoS-Profile..................................23
4.4.4 User-ACL-Policy.....................................23
4.4.5 Multicast-Profile-v4................................23
4.4.6 Multicast-Profile-v6................................23
4.4.7 Ingress-CAR.........................................23
4.4.8 Egress-CAR..........................................24
4.4.9 NAT-Instance........................................24
4.4.10 Pool-Name..........................................24
4.4.11 If-Desc............................................25
5. Objective Message Formats..............................12 5. Basic TLVs.............................................26
5.1 Objective TLV Format..................................12 5.1 Interface Information TLV.............................26
5.2 Basic User Information TLVs...........................28
5.2.1 Basic User Information TLV..........................28
5.2.2 User PPP Information TLV............................30
5.3 User IPv4 Information TLV.............................31
6. Control Message Format.................................14 INTERNET-DRAFT BNG Simple CUSP
6.1 Control TLV Format....................................14
6.2 Hello Message.........................................15
6.3 Statistics Message....................................15
7. Event TLV Format.......................................17 Table of Contents (continued)
7.1 Event TLV Format......................................17
7.2 USER_TRAFFIC_INFORMATION Message......................18
7.3 USER_DETECT_RESULT_INFORMATION Message................18
8. Resource Report TLV Format.............................20 5.4 User IPv6 Information.................................32
8.1 Resource Report TLV Format............................20 5.5 User QoS Policy Information TLV.......................33
5.6 Routing Table TLVs....................................34
5.6.1 IPv4 Routing Information TLV........................34
5.6.2 IPv6 Routing Information TLV........................35
5.7 Static User Information TLVs..........................36
5.7.1 Static IPv4 User Information TLV....................37
5.7.2 Static IPv6 User Information TLV....................38
5.8 L2TP User Information TLVs............................39
5.8.1 L2TP-LAC User Information TLV.......................39
5.8.2 L2TP-LNS User Information TLV.......................39
5.8.3 L2TP-LAC Tunnel TLV.................................40
5.8.4 L2TP-LNS Tunnel TLV.................................41
5.9 NAT User Information TLV..............................41
5.10 Vendor Defined TLV...................................42
9. Error Message Format..................................21 6. Control TLVs...........................................44
6.1 Hello TLV.............................................44
6.2 Error Information TLV.................................44
10. Security Considerations...............................22 7. Resource Reporting TLVs................................46
7.1 Interface Resource Information TLV....................46
7.2 UP Board Status Report Information TLV................46
11. IANA Considerations...................................22 8. Event TLVs.............................................48
11.1 Message Types........................................22 8.1 User Traffic Statistics Report TLV....................48
11.2 TLV Types Values.....................................22 8.2 User Detection Result Report TLV......................49
11.3 ERRID Codes..........................................22 8.3 User Basic Table Operation Result TLV.................50
Normative References......................................23 9. Resource Allocation TLVs...............................51
Informative References....................................23 9.1 Request Address Allocation TLV........................51
9.2 Address Assignment Response TLV.......................51
9.3 Address Renewal Request TLV...........................52
9.4 Address Renewal Response TLV..........................53
9.5 Address Release Request TLV...........................53
9.6 Address Release Response TLV..........................54
Authors' Addresses........................................24 10. Implementation Status.................................55
10.1 Implementations......................................55
10.1.1 Huawei Technologies................................55
10.1.2 ZTE................................................56
10.1.3 H3C................................................56
10.2 Hackathon............................................56
10.3 EANTC Testing........................................57
INTERNET-DRAFT CU Separation Protocol 11. Security Considerations...............................58
12. IANA Considerations...................................59
12.1 Service Name and Port Number.........................59
INTERNET-DRAFT BNG Simple CUSP
Table of Contents (continued)
12.2 S-CUSP Parameters....................................59
12.2.1 Message Types......................................59
12.2.2 TLV Types..........................................60
12.2.3 TLV Operation Codes................................61
12.2.4 Sub-TLV Types......................................61
12.2.5 ERRID Codes........................................62
Contributors..............................................64
Normative References......................................65
Informative References....................................65
Authors' Addresses........................................67
INTERNET-DRAFT BNG Simple CUSP
1. Introduction 1. Introduction
A Broadband Network Gateway (BNG) is an Ethernet-centric IP edge A Broadband Network Gateway (BNG) is an Ethernet-centric IP edge
router, and the aggregation point for user traffic. To provide router, and the aggregation point for user traffic. To provide
centralized session management, flexible address allocation, high centralized session management, flexible address allocation, high
scalability for subscriber management capacity, and cost-efficient scalability for subscriber management capacity, and cost-efficient
redundancy, the Control/User (CU) separated BNG is descried in redundancy, the Control/User (CU) separated BNG framework is
[TR-384]. The CU separated Service Control Plane, which is described in [TR-384]. The CU separated Service Control Plane (CP),
responsible for user access authentication and setting forwarding which is responsible for user access authentication and setting
entries in User Planes, can be virtualized and centralized. The forwarding entries in User Planes (UPs), can be virtualized and
routing control and forwarding plane, i.e. the BNG user plane centralized. The routing control and forwarding plane, i.e. the BNG
(local), can be distributed across the infrastructure. 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 CU Separation BNG control channel This document specifies the simple CU Separation BNG control channel
Protocol (CUSP) for communications between a BNG Control Plane (CP) Protocol (S-CUSP) for communications between a BNG Control Plane (CP)
and a set of User Planes (UPs). CUSP is designed to be flexible and and a set of User Planes (UPs). S-CUSP is designed to be flexible
extensible so as to easily allow for additional messages and objects, and extensible so as to easily allow for additional messages and data
should further requirements be expressed in the future. items, should further requirements be expressed in the future.
INTERNET-DRAFT CU Separation Protocol INTERNET-DRAFT BNG Simple CUSP
2. Concept and Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1 Terminology 2.1 Acronyms
ACK: Acknowledgement message.
BNG: Broadband Network Gateway. A broadband remote access server BNG: Broadband Network Gateway. A broadband remote access server
(BRAS, B-RAS or BBRAS) routes traffic to and from broadband (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic
remote access devices such as digital subscriber line access to and from broadband remote access devices such as digital
multiplexers (DSLAM) on an Internet service provider's (ISP) subscriber line access multiplexers (DSLAM) on an Internet
network. BRAS can also be referred to as a Broadband Network Service Provider's (ISP) network. BRAS can also be referred to
Gateway (BNG). 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 CP: Control Plane. CP is a user control management component which
supports the management of the UP's resources such as the user supports the management of the UP's resources such as the user
entry and forwarding policy. entry and forwarding policy.
CU: Control / User. CU: Control-plane / User-plane.
CUSP: Control and User Separate Protocol. 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.
LAC: L2TP Access Concentrator
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 UP: User Plane. UP is a network edge and user policy implementation
component. The traditional router's Control Plane and Forwarding component. The traditional router's Control Plane and Forwarding
Plane are both preserved on BNG devices in the form of a user Plane are both preserved on BNG devices in the form of a user
plane. plane.
INTERNET-DRAFT CU Separation Protocol URPF: Unicast Reverse Path Forwarding.
user: Equivalent to "customer".
VRF: Virtual Routing and Forwarding.
INTERNET-DRAFT BNG Simple CUSP
3. Protocol Overview 3. Protocol Overview
3.1 Initialization Phase This section shows example message exchanges.
UP CP 3.1 S-CUSP Configuration
| |
| TCP Session Establishment |
|<----------------------------->|
| |
| |
| HELLO (version) |
|------------------------------>|
| |
| |
| HELLO (version) |
|<----------------------------- |
| |
| |
The initialization phase consists of two successive steps: 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 is the protocol used on the Manaegment 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 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.
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 connection (3-way handshake) between the CP 1) Establishment of a TCP connection (3-way handshake) between the CP
and the UP using port tbd1. and the UP using port tbd1.
2) Establishment of a CUSP session over the TCP connection. 2) Establishment of a S-CUSP session over the TCP connection.
Once the TCP connection is established, the CP and the UP initialize Once the TCP connection is established, the CP and the UP initialize
the CUSP session during which the version negotiation is performed. the S-CUSP session during which the version negotiation is performed.
The version information is carried within Hello messages (see Section The version information is carried within Hello messages (see Section
6.2). If the CUSP session establishment phase fails because the CP 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 or UP disagree on the version parameters or one of the CP or UP does
not answer after the expiration of the establishment timer, the TCP not answer after the expiration of the establishment timer. When the
connection is immediately closed. S-CUSP session establishment fails, the TCP connection is promptly
closed.
3.2 Network Resource Report 3.3 Overview of S-CUSP Procedures
The CP configures the BNG's access interface via NETCONF, and UPs UP CP
report the attributes of their interfaces and slots.
INTERNET-DRAFT CU Separation Protocol 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 |
|-----to CP via S-CUSP--------------->|
| |
UP CP INTERNET-DRAFT BNG Simple CUSP
| |
| slot attributes report |
| via CUSP |
|----------------------------->|
| |
| port attributes report |
| via CUSP |
|----------------------------->|
| |
| Configure BNG access |
| interface via NETCONF |
|<---------------------------->|
| |
| |
Details of the Resource Report Message can be found in Sections 8. 2.
| UP relays User Dial-up Request |
|-----to CP via Si------------------->|
| |
| CP sends User Dial-up Response |
|<----to UPs via Si-------------------|
| |
3.3 IPoE Session Establishment 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----------------|
| |
UP CP 4.
| | | CGN Address Allocation via S-CUSP|
| UP reports its resources | |<----------------------------------->|
|----via CUSP------------------->| | |
| |
| Configure BNG access |
|<---interface via NETCONF-------|
| |
| CP sends ACCESS_IF_INFO |
|<---to UPs via CUSP-------------|
| |
| User dialup via VXLAN |
|<------------------------------>|
| |
| CP sends USER_BASEC_INFO |
|<---to UPs via CUSP-------------|
| |
| CP sends USER_IPV4_INFO |
|<---to UPs via CUSP-------------|
| |
| CP sends ROUTEV4 INFO |
|<---to UPs via CUSP-------------|
| |
| UP reports the USER_DETECT_RESULT_INFO
|----to CP via CUSP------------->|
| |
| UP reports the USER_TRAFFIC_INFO
|----to CP via CUSP------------->|
INTERNET-DRAFT CU Separation Protocol 5.
| Data Synchronization via S-CUSP |
|<----------------------------------->|
| |
| | 3.4 Network Resource Report
Once a CUSP session has been established, if an IPoE session is Once an S-CUSP session is established between a CP and an UP. The UP
required, the UPs report attributes of the interfaces and slots to be will begin to report the status/attributes of its slots, interfaces,
used for the IPoE session via CUSP, and the CP initiate a NETCONF and sub-interfaces.
session to configure the requested access interface of BNG.
Once the above process has been accomplished, the CP sends to the UP INTERNET-DRAFT BNG Simple CUSP
the ACCESS_IF_INFO (Access Interface Information) message that
contains a variety of objects that specify the set of constrains and
attributes for the BNG access interface. For example, ifname = 0001
[RFC2863], BNG service enable, IPv4 connection trigger enable,
neighbor detection enable, etc.
Then the user dials up via VXLAN, the CP sends to the UP the UP CP
USER_BASIC_INFOR message USER_IPV4_INFOR, and USER_ROUTEV4_INFO that | |
contains a variety of objects that specify the attributes for the | Slot attributes report |
user's basic information, user's ipv4 information, and routing | via S-CUSP |
information. |------------------------------->|
| |
| Port attributes report |
| via S-CUSP |
|------------------------------->|
| |
| Sub-interface attributes report|
| via S-CUSP |
|------------------------------->|
| |
Upon receiving the above messages from a CP, the UPs reports the user Details of the Resource Report Message can be found in Sections 8.
detection results and user's traffic status via the
USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, message.
3.4 PPPoE Session Establishment 3.5 BNG Access Procedures
INTERNET-DRAFT CU Separation Protocol
UP CP 3.5.1 IPoE Access
| |
| UP reports the resources |
|----via CUSP------------------->|
| |
| Configure BNG access |
|<-------interface via NETCONF-->|
| |
| CP sends ACCESS_IF_INFO |
|<---to UPs via CUSP-------------|
| |
| User dialup via VXLAN |
|<------------------------------>|
| |
| CP sends USER_BASEC_INFO |
|<---to UPs via CUSP-------------|
| |
| CP sends USER_IPV4_INFO |
|<---to UPs via CUSP-------------|
| |
| CP sends ROUTEV4 INFO |
|<---to UPs via CUSP-------------|
| |
| CP sends USER_PPP_INFO |
|<---to UPs via CUSP-------------|
| |
| UP reports the USER_DETECT_RESULT_INFO
|----to CP via CUSP------------->|
| |
| UP reports the USER_TRAFFIC_INFO
|----to CP via CUSP------------->|
| |
Once a CUSP session has been established, if an PPPoE session is UP CP
required, the UPs report attributes of the corresponding interfaces | |
and slots to be used for the PPPoE session via CUSP, and the CP | DHCP Negotiation Messages |
initiate a NETCONF session to configure requested access interface of |<------------via Si------------------->|
the BNG. | |
| 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----------------->|
| |
Once the above process has been accomplished, the CP sends to the UP INTERNET-DRAFT BNG Simple CUSP
the ACCESS_IF_INFO (Access Interface Information) message that
contains a variety of objects that specify the set of constrains and
attributes for the BNG access interface. For example, ifname = 0001
[RFC2863], BNG service enable, IPv4 connection trigger enable,
neighbor detection enable, etc.
Then the user dials up via VXLAN, the CP sends to the UP the 3.5.2 PPPoE Access
USER_BASIC_INFOR message, the USER_PPP_INFO message, USER_IPV4_INFOR
message, and USER_ROUTEV4_INFO message that contains a variety of
objects that specify the attributes of the user's basic information,
INTERNET-DRAFT CU Separation Protocol 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----------------->|
| |
user's PPP information, user's ipv4 information, and routing INTERNET-DRAFT BNG Simple CUSP
information.
Upon receiving the above messages from a CP, the UPs reports the user 3.5.3 L2TP LAC Access
detection results and user's traffic status via
USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, etc.
3.5 Setting the User's QoS Information 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--------------->| |
| | |
UP CP 3.5.4 L2TP LNS Access
| | INTERNET-DRAFT BNG Simple CUSP
| UP reports the resources |
|----via CUSP------------------->|
| |
| Configure BNG Access interface
|<-----via NETCONF---------------|
| |
| Configure QOS template |
|<-----via NETCONF---------------|
| |
| User dials up via VXLAN |
|<---CP sends objective TLV/Event|
| report, etc. |
| |
| CP sends USER_QOS_INFO |
|<---to UPs via CUSP-------------|
| |
Once a CUSP session has been established, if a user's Quality of |UP CP| LAC|
Service (QoS) needs to be set dynamically, then the UPs report | LNS Tunnel Negotiation Messages | |
attributes of the relevant interfaces and slots via CUSP, and the CP |<-----------via Si------------------>| |
initiate a NETCONF session to configure the requested access | /\ | |
interfaces of the BNG and User's configuration template. Then the | || forward | |
user dials up via VXLAN, the CP sends the USER_BASIC_INFOR message, | \/ | |
USER_IPV4_INFOR message, and USER_ROUTEV4_INFO message to the UP, the | ------------------ LNS Tunnel Negotiation --------->|
UPs reports the user detection results and user's traffic status. | | |
| 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--------------->| |
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
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 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 above process has been accomplished, the CP sends the Once above process has been accomplished, the CP sends the
USER_QOS_AUTH_INFO message to the UPs; this message contains a USER_QOS_AUTH_INFO message to the UPs; this message contains a
variety of objects that specify the set of constrains and attributes variety of objects that specify the set of constrains and attributes
for the user's required QoS. (The format of these QoS attributes for the user's required QoS. (The format of these QoS attributes
should be parallel to the QoS configuration templates.) should be parallel to the QoS configuration templates.)
INTERNET-DRAFT CU Separation Protocol 3.7 CP and UP Synchronization
3.6 CUSP Session Statistics 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-------------->|
| |
| UP sends Synchronization End |
|------to CP via S-CUSP-------------->|
| |
UP CP INTERNET-DRAFT BNG Simple CUSP
| |
| |
|<-----statistic_REQUEST ------------|
| |
|------statistic_REQUEST (ACK)------>|
| |
|------statistic_BEGIN-------------->|
| |
|<-----statistic_BEGIN (ACK)---------|
| |
|------statistic_DATA--------------->|
| |
|------statistic_END---------------->|
| |
|<-----statistic_END (ACK)-----------|
| |
| |
If the CUSP session goes down, the CU separation BNG is required to | UP sends NAT Address Renew Req. |
save the users' information. And if the CUSP session restarts, the |------to CP via S-CUSP-------------->|
CP may request that the UP send the previous session's statistics to | |
synchronize user information. The above figure shows this process, | CP sends NAT Address Renew Res. |
and the details of the session statistic message can be found in |<-----to UP via S-CUSP---------------|
Sections 6.3. | |
INTERNET-DRAFT CU Separation Protocol | UP sends Snychronization 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---------------|
| |
4. CUSP Common Header 3.8 CGN Address Allocation
A CUSP message consists of a common header followed by a variable- UP CP
length body made of a set of objects. Receiving a CUSP message with | |
a missing mandatory object MUST trigger an Error message (see Section | UP sends Address Allocation Req. |
5.6). Conversely, if an object is optional, the object may or may |------to CP via S-CUSP-------------->|
not be present. | |
| CP sends Address Allocation Res. |
|<-----to UP via S-CUSP---------------|
| |
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 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: Common header:
0 1 2 3 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 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 |F| Resv | Message-Length | | Ver | Resv | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction id | | Reserved | Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CUSP Message Common Header S-CUSP Message Common Header
Message-Type (8 bits): The following message types are defined in Ver (3 bits): The version of the protocol. This document
this document: specifies version 1.
Value Meaning Resv (4 bits): Reserved. MUST be sent as zero and ignored on
----- ------------------ receipt.
1 Update objective
2 Hello
3 statistics Request
4 statistics Begin
5 statistics Data
6 statistics End
7 Source Report
8 Event Report
9 Error
F (1 bit): Setting the F bit to one enables the control message ACK Message-Type (8 bits): The set of message types specified in this
mode and setting the F bit to zero disables that mode. document is listed in Section 12.2.1.
Resv (7 bits): Reserved bits. They MUST be set to zero on Message-Length (16 bits): Total length of the CUSP message
transmission and MUST be ignored on receipt. including the common header, expressed in number of
bytes as an unsigned integer.
Message-Length (16 bits): Total length of the CUSP message including Transaction ID (16 bits): This field is used to identify
the common header, expressed in bytes as an unsigned requests. It is echoed back in any corresponding ACK /
integer. response / Error message.
Transaction ID (32 bits): This field is used to identify requests. It INTERNET-DRAFT BNG Simple CUSP
is echoed back in the corresponding ACK / response / Error
message.
INTERNET-DRAFT CU Separation Protocol 4.1.1 Control Messages
5. Objective Message Formats Control messages are listed below.
CUSP objects have a common format. They begin with a CUSP common Type Name Notes and TLVs that can be carried
header (see Section 4). This is followed by object-specific fields ---- ---- ------------------------------------
defined for each different object. The object may also include one 1 Hello Capability negotiation.
or more type-length-value (TLV) encoded data sets. Each TLV has the 2 Keepalive Keepalive.
same structure as described in Section 5.1. 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.
5.1 Objective TLV Format 4.1.2 Flow Table Message
A CUSP object may include a set of one or more optional TLVs. All Flow Table messages are listed below.
CUSP objective TLVs have the following format:
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.
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
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 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 | TLV-Length | | Oper | TLV-Type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | 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.
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.
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 Type (2 bytes): The Type of a Sub-TLV, that is the meaning and
TLV-Length: 2 bytes format of the Value part, are determined by the Type
Value: variable of the TLV. See Section 12.2.4.
A CUSP objective TLV is comprised of 2 bytes for the type, 2 bytes Length (2 bytes): The length of the Value portion of the TLV in
specifying the TLV-Length, and a value field. The Type and TLV-Length bytes as an unsigned integer.
fields are unsigned integers.
The first 4 bits of Type field indicate the operation of this TLV, Value (variable length): This is the value portion of the TLV
currently, there are two types: 0 - update the objectives; 1 - delete whose size is given by TLV-Length.
the object. Updating a non-existent object creates it.
The remaining bits of the Type field indicate the TLV's type (4-15 The sub-TLVs currently specified are specified in the following
bits) which is the object to which it applies. The following objects subsections.
/ types are currently defined:
Value Meaning 4.4.1 VRF-Name
----- --------------
0 USER_BASIC_INFO
1 USER_PPP_INFO
2 ACCESS_IFSRV_INFO
3 USER_IPV4_INFO
4 USER_IPV6_INFO
5 USER_QOS_AUTH_INFO
6 ROUTEV4_INFO
7 ROUTEV6_INFO
8 STATIC_USER_INFO
INTERNET-DRAFT CU Separation Protocol The name of the VRF (Virtual Routing and Forwarding instance) that
the BNG user accesses. Optional.
The TLV-Length field defines the length of the value portion in Sub-TLV Type: 1, VRF Name
bytes. The TLV is padded to 4-bytes alignment; padding is not Length: 1-255 octets.
included in the Length field (so a 3-byte value would have a length Value: STRING.
of 3, but the total size of the TLV would be 8 bytes).
Unrecognized TLVs MUST be ignored. 4.4.2 Ingress-QoS-Profile
IANA management of the CUSP Object TLV type identifier codespace is Indicates the upstream QoS Profile Name. Optional.
described in Section 11.
The details of the attributes of the Objective TLV are specified in Sub-TLV Type: 2, Ingress QoS Profile Name
Section 4.1 of [InforModel]. Length: 1-255 octets.
Value: STRING.
INTERNET-DRAFT CU Separation Protocol INTERNET-DRAFT BNG Simple CUSP
6. Control Message Format 4.4.3 Egress-QoS-Profile
CUSP Control messages have a common format. They begin with the CUSP Indicates the downstream QoS Profile Name. Optional.
common header (see Section 4) followed by control TLVs fields for the
different control operations. It may also include one or more type-
length-value (TLV) encoded control data sets. Each TLV has the same
structure as described in Section 6.1.
For each CUSP message type, rules are defined that specify the set of Sub-TLV Type: 3, Egress QoS Profile Name
objects that the message can carry. We use the Backus-Naur Form Length: 1-255 octets.
(BNF) (see [RFC5511]) to specify such rules. Square brackets refer Value: STRING.
to optional sub-sequences. An implementation MUST form the CUSP
messages using the object ordering specified in this document.
6.1 Control TLV Format 4.4.4 User-ACL-Policy
A CUSP control may include a set of one or more optional TLVs. All Indicates the name of the ACL policy group to which the user belongs.
CUSP control TLVs have the following format: Optional.
Type: 2 bytes Sub-TLV Type: 4, User ACL Policy Name
TLV-Length: 2 bytes Length: 1-255 octets.
Value: variable Value: STRING.
A CUSP control TLV consists of 2 bytes for the type, 2 bytes 4.4.5 Multicast-Profile-v4
specifying the TLV length, and a value field.
Control Type (8 bits): The following message types are currently Name of the IPv4 multicast program list a user can order. Optional.
defined:
Value Meaning Sub-TLV Type: 5, Multicast Profile of IPv4.
----- ---------- Length: 1-255 octets.
0 Hello Value: STRING.
1 Statistics
The Length field defines the length of the value portion in bytes. 4.4.6 Multicast-Profile-v6
The TLV is padded to 4-bytes alignment; padding is not included in
the Length field (so a 3-byte value would have a length of 3, but the
total size of the TLV would be 8 bytes).
Unrecognized TLVs MUST be ignored. Name of the IPv6 multicast program list a user can order. Optional.
IANA management of the CUSP Object TLV type identifier codespace is Sub-TLV Type: 6, Multicast Profile of IPv6.
described in Section 11. Length: 1-255 octets.
Value: STRING.
INTERNET-DRAFT CU Separation Protocol 4.4.7 Ingress-CAR
6.2 Hello Message Indicates the authorized upstream Committed Access Rate (CAR)
parameters. Optional.
The Hello message is a CUSP message sent by a UP to a CP and by a CP Sub-TLV Type: 7, Ingress CAR.
to a UP in order to establish a CUSP session. The Type field of the Length: 16 Octets.
CUSP common header for the Hello message is set to 2. Value: The following four fields in the order given:
Once the TCP connection has been successfully established, the first INTERNET-DRAFT BNG Simple CUSP
message sent by the UP to the CP or by the CP to the UP MUST be a
Hello message.
Any message received prior to a Hello message MUST trigger a protocol Name Type Description
error condition causing an ERROR message to be sent with Error-Type ------ ------- ---------------------------------
Version_ Negotiation_Failed and the CUSP session establishment CIR 4 bytes Guaranteed rate in bits/second.
attempt MUST be terminated by closing the TCP connection. PIR 4 bytes Burst rate in bits/second.
CBS 4 bytes The token bucket in bytes.
PBS 4 bytes Burst token bucket in bytes.
The Hello message is used to establish a CUSP session between the 4.4.8 Egress-CAR
CUSP peers. During the establishment phase, the CUSP peers exchange
version information. If both parties agree on such version
negotiation, the CUSP session is successfully established.
The format of a Hello message is as follows: Indicates the authorized downstream Committed Access Rate (CAR)
parameters. Optional.
<Hello Message>::= <Common Header> Sub-TLV Type: 8, Egress CAR.
<HELLO_TLV> Length: 16 Octets.
<HELLO_TLV>:: = <version> Value: The following four fields in the order given:
Version (4 bytes): specifies the CP/UP supported CUSP's version, Name Type Description
currently, the version is 1. ------ ------- ---------------------------------
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.
6.3 Statistics Message 4.4.9 NAT-Instance
If the CUSP session goes down, the CU separation BNG is required to Name of the Network Address Translation (NAT) Instance to which the
preserve the users' information. If the CUSP session restarts, the user belongs. Optional.
CP may request the UP to report the previous session's statistics to
synchronize user information.
The Type field of the CUSP common header for the Statistics messages Sub-TLV Type: 9, NAT Instance Name.
is set to 3, 4, 5, or 6. Length: 1-255 octets.
Value: STRING.
The format of a Statistics message is as follows: 4.4.10 Pool-Name
<Statistics Message>::= <Common Header> Indicates the name of the address pool to which the public network
<Statistics_TLV> segment belongs. Optional.
<Statistics_TLV>::= <ClassID><Event><Resv>
ClassID (2 bytes): This field specifies the statistics type of CUS Sub-TLV Type: 10, IP Address Pool Name.
session, the following statistics types are currently defined: Length: 1-255 octets.
Value: STRING.
INTERNET-DRAFT CU Separation Protocol INTERNET-DRAFT BNG Simple CUSP
Value Meaning 4.4.11 If-Desc
----- -------------------------------
0 objective message statistic
1 Source report message statistic
2 Event report message statistic
Event (2 bytes): specified the Statistics message's subtypes, the Description of an interface. Mandatory.
following subtypes are currently defined:
Value Meaning Sub-TLV Type: 11, Interface Description
----- ------- Length: 12
0 request Statistics message Value: Several fields structured as follows:
1 begin Statistics message
2 Statistics data message
3 End Statistics message
Note that, the event value MUST be synchronized with the type of 0 1 2 3
comment header. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INTERNET-DRAFT CU Separation Protocol 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
7. Event TLV Format INTERNET-DRAFT BNG Simple CUSP
CUSP Event TLVs have a common format. They begin with a CUSP common 5. Basic TLVs
header (see Section 4). It is followed by Event TLV fields defined
for each different Events. It may also include one or more type-
length-value (TLV) encoded Event data sets. Each TLV has the same
structure as described in Section 7.1.
For each CUSP message type, rules are defined that specify the set of This section describes basic TLVs.
objects that the message can carry. We use the Backus-Naur Form
(BNF) (see [RFC5511]) to specify such rules. Square brackets refer
to optional sub-sequences. An implementation MUST form the CUSP
messages using the object ordering specified in this document.
7.1 Event TLV Format 5.1 Interface Information TLV
A CUSP Event may include a set of one or more optional TLVs. All The Interface Information TLV can be used by a CP to control the
CUSP Event TLVs have the following format: access mode, authentication methods, and other related functions of
an interface.
Type: 2 bytes The format of the Interface Information TLV value part is as below:
Length: 2 bytes
Value: variable
A CUSP Event TLV consists of 2 bytes for the type, 2 bytes specifying 0 1 2 3
the TLV length, and a value field. 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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Event Type (8 bits): The following message types are currently Figure 5.1: Interface Information TLV
defined:
Type Meaning Function: Service information about the user access interface
----- ------------------------------ on the BNG.
0 USER_TRAFFIC_INFORMATION TLV Type: 1
1 USER_DETECT_RESULT_INFORMATION TLV Length: variable
The Length field defines the length of the value portion in bytes. TLV fields:
The TLV is padded to 4-bytes alignment; padding is not included in If-Index: 4 bytes in length, a unique identifier of an interface
the Length field (so a 3-byte value would have a length of 3, but the of a BNG.
total size of the TLV would be 8 bytes). 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.
Unrecognized TLVs MUST be ignored. 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;
IANA management of the CUSP Object TLV type identifier codespace is INTERNET-DRAFT BNG Simple CUSP
described in Section 11.
INTERNET-DRAFT CU Separation Protocol 0x2: DOT1X authentication;
0x4: Web authentication;
0x8: Web fast authentication;
0x10: Binding authentication.
7.2 USER_TRAFFIC_INFORMATION Message 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 USER_TRAFFIC_INFORMATION Message be used by the UP to reported The flags field is defined as below:
the user's traffic statistics.
The format of a USER_TRAFFIC_INFORMATION message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<USER_TRAFFIC_INFORMATION Message>::= <Common Header> Figure 5.2: Interface Flags
<USER_TRAFFIC_INFORMATION_TLV>
<USER_TRAFFIC_INFORMATION_TLV>::= <UserId><StatisticsType>
<IngressPackets><IngressBytes>
<EngressPackets><EgressBytes>
USER_ID (4 bytes): is the identifier of user. This parameter is Where:
unique and mandatory. This attribute is used to distinguish
different users.
StatisticsType (4 bytes): be used to indicate the Statistics type, F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a
the following types are currently defined: subscriber go to online.
1: enabled, 0: disabled.
Value Meaning S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a
----- ----------------------- subscriber go to online.
0 IPv4 traffic statistics 1: enabled, 0: disabled.
1 IPv6 traffic statistics
IngressPackets (8 bytes): be used to present the ingress packets. A (ARP Trigger) bit: Indicates whether ARP packets can trigger a
subscriber go to online.
1: enabled, 0: disabled.
IngressBytes (8 bytes): be used to present the ingress bytes. N (ND Trigger) bit: Indicates whether ND packets can trigger a
subscriber go to online.
1: enabled, 0: disabled.
EgressPackets (8 bytes): be used to present the egress packets. I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable traffic
detection. 0: Disable traffic detection.
EgressBytes (8 bytes): be used to present the egress bytes. P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable traffic
detection. 0: Disable traffic detection.
7.3 USER_DETECT_RESULT_INFORMATION Message INTERNET-DRAFT BNG Simple CUSP
The USER_TRAFFIC_INFORMATION Message is used to reported the failure X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy and can
of user detection by the UP. 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.
The format of a USER_DETECT_RESULT_INFORMATION message is as follows: 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.
<USER_DETECT_RESULT_INFORMATION Message>::= <Common Header> MBZ: Reserved bits that MUST be sent as zero and ignored on receipt.
<USER_DETECT_RESULT_ INFORMATION_TLV>
<USER_DETECT_RESULT_INFORMATION_TLV>::= <UserId><DetectFail>
USER_ID (4 bytes): is the identifier of user. This parameter is 5.2 Basic User Information TLVs
unique and mandatory. This attribute is used to distinguish different
users.
INTERNET-DRAFT CU Separation Protocol The Basic User Information TLVs are defined for a CP to carry the
basic information about a user to an UP.
DetectFail (2 bytes): be used to indicate that the user detect fail. 5.2.1 Basic User Information TLV
INTERNET-DRAFT CU Separation Protocol The format of the Basic User Information TLV value part is as below:
8. Resource Report TLV Format 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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CUSP Resource Report TLVs have a common format. They begin with a Figure 5.3: Basic User Information TLV
CUSP common header (see Section 4). It is followed by Event TLV
fields defined for each different Resource. It may also include one
or more type-length-value (TLV) encoded Resource Report data sets.
Each TLV has the same structure as described in Section 7.1.
8.1 Resource Report TLV Format INTERNET-DRAFT BNG Simple CUSP
A CUSP Resource Report may include a set of one or more optional Function: Basic information about a BNG user.
TLVs. All CUSP Resource Report TLVs have the following format: TLV Type: 2
TLV Length: variable in length;
Type: 2 bytes TLV Fields:
Length: 2 bytes Name Length Description
Value: variable -------------- ------ ----------------------
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.
A CUSP Resource Report TLV is comprised of 2 bytes for the type, 2 The Reserved field MUST be sent as zero and ignored on receipt.
bytes specifying the TLV length, and a value field.
Resource Type (8 bits): The following message types are currently INTERNET-DRAFT BNG Simple CUSP
defined:
Value Meaning 5.2.1.1 Access Types Table
----- -------
0 RESOURCE_IF_INFO
1 RESOURCE_SLOT_INFO
The Length field defines the length of the value portion in bytes. Value Meaning
The TLV is padded to 4-bytes alignment; padding is not included in ----- ---------
the Length field (so a 3-byte value would have a length of 3, but the 1 PPP access (PPP)
total size of the TLV would be 8 bytes). 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)
Unrecognized TLVs MUST be ignored. 5.2.2 User PPP Information TLV
IANA management of the CUSP Object TLV type identifier codespace is The User PPP Information TLV is defined to carry PPP information of a
described in Section 11. User, from a CP to an UP.
The details about the attributes of Resource Report TLV are specified The format of the TLV value part is as below:
in Section 4.2 of [InforModel]
INTERNET-DRAFT CU Separation Protocol 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Error Message Format Figure 5.4: User PPP Information TLV
Error messages are used by the CP or UPs to notify the other side of Function: PPP [RFC1661] information for a BNG user.
the connection of problems. They are mostly used by the UPs to TLV Type: 3
indicate a failure of a request initiated by the CP. TLV Length: 20 bytes in length
The format of an Error message is as follows: INTERNET-DRAFT BNG Simple CUSP
<Err Message> ::= <Common Header> TLV Fields:
<ERRID> 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 PPoE local MRU.
Magic-Number 4 bytes Local magic number in PPP negotiation
packets.
Peer-Magic-Number 4 bytes Remote peer magic number.
ERRID (4 bytes): Used to indicate the error type. The following types The Reserved fields MUST be sent as zero and ignored on receipt.
are currently defined:
Value Meaning 5.3 User IPv4 Information TLV
------- --------------------------------
00~1000 Reserved
1001 version negotiation failed
1002 TLV type cannot be recognized
1003 TLV length Anomaly
1004 TLV objective Anomaly
1005 Statistics failed
1006 Statistics request not supported
INTERNET-DRAFT CU Separation Protocol The User IPv4 Information TLV is defined to carry IPv4 related
information for a BNG user.
10. Security Considerations The format of the TLV value part is as below:
TBD. 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11. IANA Considerations Figure 5.5: User IPv4 Information TLV
IANA is registered to assign a port for CUSP as follows: Function: IPv4 information for a BNG user.
TLV Type: 4
TLV Length: variable
Service Port Transport TLV fields:
Name Number Protocol Description Reference Name Type Description
------- ------ --------- ------------ --------------- -------------- ------ ----------------------
cusp tbd1 tcp Control User [this document] User-ID 4 bytes User ID.
Separation User-IPv4 IPv4 User IPv4 address.
Protocol Gateway-IPv4 IPv4 User gateway.
Portal Force 1 bit (P) Push advertisement switch, 0: off, 1:
IANA is requested to create a "CUSP Parameters" web page and include INTERNET-DRAFT BNG Simple CUSP
there of the registries set up below in this Section.
11.1 Message Types 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.
TBD. The Reserved field MUST be sent as zero and ignored on receipt.
11.2 TLV Types Values 5.4 User IPv6 Information
TBD. The User IPv6 Information TLV is defined to carry IPv6 related
information of a BNG user.
11.3 ERRID Codes The format of the TLV value part is as below:
TBD. 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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INTERNET-DRAFT CU Separation Protocol Figure 5.6: User IPv6 Information TLV
Normative References Function: IPv6 information for a BNG user.
TLV Type: 5
TLV Length: variable
[cuspdt-rtgwg-cu-separation-bng-deployment] Gu, R., Hu, S., and Z. INTERNET-DRAFT BNG Simple CUSP
Wang, "Deployment Model of Control Plane and User Plane
Separation BNG", draft-cuspdt-rtgwg-cu-separation-bng-
deployment (work in progress), October 2017.
[InforModel] Wang, Z., Gu, R., Lopezalvarez, V., and S. Hu, TLV fields:
"Information Model of Control-Plane and User-Plane Name Type Description
separation BNG", draft-cuspdt-rtgwg-cu-separation-infor- -------------- ------ ----------------------
model (work in progress), October 2018. 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.
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
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
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.
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
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.
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
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 dintinguish 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 desireable 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 assigne a Sub-Type value for each vendor
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6.1: Hello TLV
Function: Hello Message.
TLV Type: 100
TLV Length: 8
TLV Fields:
Name Type Description
-------------- ------ ----------------------
Version 4 bytes Version number. Each bit corresponds to a
version. 0 is reserved and starts from 1.
Vendor-ID 4 bytes Vendor ID, which is defined in RADIUS
[RFC2865].
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
INTERNET-DRAFT BNG Simple CUSP
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).
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
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.
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
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.
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.
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
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.
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
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.
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 and working groups
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.
It is up to the individual working groups to use this information as
they see fit".
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
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 Separattion 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
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
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].
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
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]
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
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 a 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]
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.
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
INTERNET-DRAFT BNG Simple CUSP
Contributors
Zitao Wang
Huawei Technologies
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangzitao@huawei.com
INTERNET-DRAFT BNG Simple CUSP
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc- 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>. <https://www.rfc-
editor.org/info/rfc2863>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/info/rfc2863>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
to Form Encoding Rules in Various Routing Protocol "Remote Authentication Dial In User Service (RADIUS)", RFC
Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-
2009, <https://www.rfc-editor.org/info/rfc5511>. editor.org/info/rfc2865>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>. 2017, <https://www.rfc-editor.org/info/rfc8174>.
Informative References Informative References
[cuspdt-rtgwg-cusp-requirements] Hu, S., Gu, R., Lopezalvarez, V., [SCUSP-architecture] Hu, S., Qin, G. Li, Z., Chua, T., Lopez, V.,
Song, J., and Z. Wang, "Requirements for Control Plane and Eastlake, D., Wang, Z., and J. Song, "Architecture for
User Plane Separated BNG Protocol", draft-cuspdt-rtgwg- Control Plane and User Plane Separated BNG",
cusp-requirements (work in progress), October 2018. draft-cuspdt-rtgwg-cu-separation-bng-architecture-03 (work
in progress), December 2018.
[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,
<https://www.rfc-editor.org/info/rfc1661>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, DOI
10.17487/RFC3022, January 2001, <https://www.rfc-
editor.org/info/rfc3022>
[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, <https://www.rfc-
editor.org/info/rfc7942>.
INTERNET-DRAFT BNG Simple CUSP
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[TR-384] Broadband Forum, "Cloud Central Office Reference [TR-384] Broadband Forum, "Cloud Central Office Reference
Architectural Framework", BBF TR-384, 2018. Architectural Framework", BBF TR-384, 2018.
INTERNET-DRAFT CU Separation Protocol INTERNET-DRAFT BNG Simple CUSP
Authors' Addresses Authors' Addresses
Shujun Hu Shujun Hu
China Mobile China Mobile
32 Xuanwumen West Ave, Xicheng District 32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053 Beijing, Beijing 100053
China China
Email: hushujun@chinamobile.com Email: hushujun@chinamobile.com
Donald Eastlake, 3rd Donald Eastlake, 3rd
Huawei Huawei Technologies
1424 Pro Shop Court 1424 Pro Shop Court
Davenport, FL 33896 Davenport, FL 33896
USA USA
Phone: +1-508-333-2270 Phone: +1-508-333-2270
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
Zitao Wang Mach Chen
Huawei Huawei Technologies
101 Software Avenue, Yuhua District Huawei Bldg., No. 156 Beiqing Road
Nanjing, Jiangsu 210012 Beijing 100095 China
China
Email: wangzitao@huawei.com Email: mach.chen@huawei.com
Fengwei Qin Fengwei Qin
China Mobile China Mobile
32 Xuanwumen West Ave, Xicheng District 32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053 Beijing, Beijing 100053
China China
Email: qinfengwei@chinamobile.com Email: qinfengwei@chinamobile.com
Zhenqiang Li Zhenqiang Li
China Mobile China Mobile
32 Xuanwumen West Ave, Xicheng District 32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053 Beijing, Beijing 100053
China China
Email: lizhenqiang@chinamobile.com Email: lizhenqiang@chinamobile.com
Jun Song INTERNET-DRAFT BNG Simple CUSP
Huawei
INTERNET-DRAFT CU Separation Protocol
Jun Song
Huawei Technologies
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: song.jun@huawei.com Email: song.jun@huawei.com
Tee Mong Chua Tee Mong Chua
Singapore Telecommunications Limited Singapore Telecommunications Limited
31 Exeter Road, #05-04 Comcentre Podium Block 31 Exeter Road, #05-04 Comcentre Podium Block
Singapore City 239732 Singapore City 239732
Singapore Singapore
Email: teemong@singtel.com Email: teemong@singtel.com
INTERNET-DRAFT CU Separation Protocol INTERNET-DRAFT BNG Simple CUSP
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
 End of changes. 208 change blocks. 
602 lines changed or deleted 2455 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/