< draft-cuspdt-rtgwg-cu-separation-bng-protocol-05.txt   draft-cuspdt-rtgwg-cu-separation-bng-protocol-06.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
Futurewei Technologies
M. Chen M. Chen
Huawei Technologies Huawei Technologies
F. Qin F. Qin
Z. Li Z. Li
China Mobile China Mobile
J. Song
Huawei Technologies
T. Chua T. Chua
Singapore Telecommunications Singapore Telecommunications
Expires: October 29, 2019 April 30, 2019 D. Huang
ZTE
Expires: January 2, 2020 July 3, 2019
Control-Plane and User-Plane Separation BNG Control-Plane and User-Plane Separation BNG
Simple Control Channel Protocol Simple Control Channel Protocol (S-CUSP)
draft-cuspdt-rtgwg-cu-separation-bng-protocol-05.txt draft-cuspdt-rtgwg-cu-separation-bng-protocol-06
Abstract Abstract
This document specifies the Simple Control Plane (CP) and User Plane This document specifies the Simple Control Plane (CP) and User Plane
(UP) Separation Broadband Network Gateway (BNG) control channel (UP) Separation Broadband Network Gateway (BNG) control channel
Protocol (S-CUSP) for communications between a CP and a UP. S-CUSP is Protocol (S-CUSP) for communications between a CP and a UP. S-CUSP is
designed to be flexible and extensible so as to easily allow for the designed to be flexible and extensible so as to easily allow for the
addition of further messages and data items, should requirements be addition of further messages and data items to meet future
expressed in the future. requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted 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.
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."
INTERNET-DRAFT Simple BNG CUSP
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 BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
Table of Contents Table of Contents
1. Introduction............................................5 1. Introduction............................................6
2. Terminology.............................................6 2. Terminology.............................................7
2.1 Acronyms...............................................6 2.1 Implementation Requirement Keywords..................7
2.2 Terms................................................7
3. Protocol Overview.......................................8 3. BNG CUPS Overview......................................10
3.1 S-CUSP Configuration...................................8 3.1 BNG CUPS Motivation.................................10
3.2 S-CUSP Session Establishment...........................9 3.2 BNG CUPS Architecture Overview......................10
3.3 Overview of S-CUSP Procedures..........................9 3.3 BNG CUPS Interfaces.................................12
3.4 Network Resource Report...............................11 3.3.1 Service Interface.................................13
3.5 BNG Access Procedures.................................11 3.3.2 Control Interface.................................14
3.5.1 IPoE Access.........................................12 3.3.3 Management Interface..............................14
3.5.2 PPPoE Access........................................13 3.4 BNG CUPS Procedure Overview.........................14
3.5.3 L2TP LAC Access.....................................14
3.5.4 L2TP LNS Access.....................................14
3.5.5 L2TP LTS Access.....................................16
3.6 Setting the User's QoS Information....................16
3.7 CP and UP Synchronization.............................17
3.8 CGN Address Allocation................................18
4. S-CUSP Message Formats.................................19 4. S-CUSP Protocol Overview...............................18
4.1 Common Message Header.................................19 4.1 Control Channel Related Procedures..................18
4.1.1 Control Messages....................................20 4.1.1 S-CUSP Session Establishment......................18
4.1.2 Table Messages......................................20 4.1.2 Keep Alive........................................19
4.1.3 Resource Reporting Message..........................20 4.2 Node Related Procedures.............................20
4.1.4 Event Reporting Message.............................20 4.2.1 UP Resource Report................................20
4.1.5 Vendor Message......................................21 4.2.2 Update BAS Function on Access Interface...........21
4.1.6 Resource Allocation Messages........................21 4.2.3 Update Network Routing............................21
4.2 Common Message TLV Format.............................21 4.2.4 CGN Public IP Address Allocation..................22
4.3 Basic Data Fields.....................................22 4.2.5 Data Synchronization between the CP and UP........23
4.4 Sub-TLV Format and Specific Sub-TLVs..................23 4.3 Subscriber Session Related Procedures...............24
4.4.1 VRF-Name............................................23 4.3.1 Create Subscriber Session.........................25
4.4.2 Ingress-QoS-Profile.................................23 4.3.2 Update Subscriber Session.........................26
4.4.3 Egress-QoS-Profile..................................24 4.3.3 Delete Subscriber Session.........................27
4.4.4 User-ACL-Policy.....................................24 4.3.4 Subscriber Session Events Report..................27
4.4.5 Multicast-Profile-v4................................24
4.4.6 Multicast-Profile-v6................................24
4.4.7 Ingress-CAR.........................................24
4.4.8 Egress-CAR..........................................25
4.4.9 NAT-Instance........................................25
4.4.10 Pool-Name..........................................25
4.4.11 If-Desc............................................26
5. Basic TLVs.............................................27 5. S-CUSP Call Flows......................................29
5.1 Interface Information TLV.............................27 5.1 IPoE................................................29
5.2 Basic User Information TLVs...........................29 5.1.1 DHCPv4 Access.....................................29
5.2.1 Basic User Information TLV..........................29 5.1.2 DHCPv6 Access.....................................30
5.2.2 User PPP Information TLV............................31 5.1.3 IPv6 SLAAC Access.................................32
5.3 User IPv4 Information TLV.............................32 5.1.4 DHCPv6 + SLAAC Access.............................33
5.1.5 DHCP Dual Stack Access............................35
5.1.6 L2 Static Subscriber Access.......................37
5.2 PPPoE...............................................40
5.2.1 IPv4 PPPoE Access.................................40
5.2.2 IPv6 PPPoE Access.................................41
5.2.3 PPPoE Dual Stack Access...........................43
5.3 WLAN Access.........................................45
5.4 L2TP................................................47
5.4.1 L2TP LAC Access...................................47
5.4.2 L2TP LNS IPv4 Access..............................49
5.4.3 L2TP LNS IPv6 Access..............................51
5.5 CGN (Carrier Grade NAT).............................54
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
Table of Contents (continued) Table of Contents (continued)
5.4 User IPv6 Information.................................33 5.6 L3 Leased Line Access...............................55
5.5 User QoS Policy Information TLV.......................34 5.6.1 Web Authentication................................55
5.6 Routing Table TLVs....................................35 5.6.2 User Traffic Trigger..............................57
5.6.1 IPv4 Routing Information TLV........................35 5.7 Multicast Access....................................58
5.6.2 IPv6 Routing Information TLV........................36
5.7 Static User Information TLVs..........................37
5.7.1 Static IPv4 User Information TLV....................38
5.7.2 Static IPv6 User Information TLV....................39
5.8 L2TP User Information TLVs............................40
5.8.1 L2TP-LAC User Information TLV.......................40
5.8.2 L2TP-LNS User Information TLV.......................40
5.8.3 L2TP-LAC Tunnel TLV.................................41
5.8.4 L2TP-LNS Tunnel TLV.................................42
5.9 NAT User Information TLV..............................42
5.10 Vendor Defined TLV...................................43
6. Control TLVs...........................................45
6.1 Hello TLV.............................................45
6.2 Error Information TLV.................................46
7. Resource Reporting TLVs................................47
7.1 Interface Resource Information TLV....................47
7.2 UP Board Status Report Information TLV................47
8. Event TLVs.............................................49 6. S-CUSP Message Formats.................................60
8.1 User Traffic Statistics Report TLV....................49 6.1 Common Message Header...............................60
8.2 User Detection Result Report TLV......................50 6.2 Control Messages....................................61
8.3 User Basic Table Operation Result TLV.................51 6.2.1 Hello Message.....................................61
6.2.2 Keepalive Message.................................62
6.2.3 Sync_Request Message..............................62
6.2.4 Sync_Begin Message................................62
6.2.5 Sync_Data Message.................................63
6.2.6 Sync_End Message..................................63
6.2.7 Update_Request Message............................64
6.2.8 Update_Response Message...........................64
6.3 Event Message.......................................65
6.4 Report Message......................................66
6.5 CGN Messages........................................66
6.5.1 Addr_Allocation_Req Message.......................66
6.5.2 Addr_Allocation_Ack Message.......................66
6.5.3 Addr_Renew_Req Message............................67
6.5.4 Addr_Renew_Ack Message............................67
6.5.5 Addr_Release_Req Message..........................67
6.5.6 Addr_Release_Ack Message..........................67
6.6 Vendor Message......................................67
6.7 Error Message.......................................68
9. Resource Allocation TLVs...............................52 7. S-CUSP TLVs and Sub-TLVs...............................69
9.1 Request Address Allocation TLV........................52 7.1 Common TLV Header...................................69
9.2 Address Assignment Response TLV.......................52 7.2 Basic Data Fields...................................70
9.3 Address Renewal Request TLV...........................53 7.3 Sub-TLV Format and Sub-TLVs.........................71
9.4 Address Renewal Response TLV..........................54 7.3.1 Name sub-TLVs.....................................71
9.5 Address Release Request TLV...........................54 7.3.2 Ingress-CAR sub-TLV...............................72
9.6 Address Release Response TLV..........................55 7.3.3 Egress-CAR sub-TLV................................72
7.3.4 If-Desc sub-TLV...................................73
7.3.5 IPv6 Address List sub-TLV.........................75
7.3.6 Vendor sub-TLV....................................75
7.4 The Hello TLV.......................................77
7.5 The Keep Alive TLV..................................78
7.6 The Error Information TLV...........................79
7.7 BAS Function TLV....................................79
7.8 Routing TLVs........................................82
7.8.1 IPv4 Routing TLV..................................82
7.8.2 IPv6 Routing TLV..................................84
7.9 Subscriber TLVs.....................................85
7.9.1 Basic Subscriber TLV..............................86
7.9.2 PPP Subscriber TLV................................88
7.9.3 IPv4 Subscriber TLV...............................89
10. Implementation Status.................................56 INTERNET-DRAFT Simple BNG CUSP
10.1 Implementations......................................56
10.1.1 Huawei Technologies................................56
10.1.2 ZTE................................................57
10.1.3 H3C................................................57
10.2 Hackathon............................................57
10.3 EANTC Testing........................................58
11. Security Considerations...............................59 Table of Contents (continued)
12. IANA Considerations...................................60 7.9.4 IPv6 Subscriber TLV...............................90
12.1 Service Name and Port Number.........................60 7.9.5 IPv4 Static Subscriber Detect TLV.................91
7.9.6 IPv6 Static Subscriber Detect TLV.................93
7.9.7 L2TP-LAC Subscriber TLV...........................94
7.9.8 L2TP-LNS Subscriber TLV...........................95
7.9.9 L2TP-LAC Tunnel TLV...............................95
7.9.10 L2TP-LNS Tunnel TLV..............................96
7.9.11 Update Response TLV..............................97
7.9.12 Subscriber Policy TLV............................98
7.9.13 Subscriber CGN Port Range TLV...................100
7.10 Device Status TLVs................................100
7.10.1 Interface Status TLV............................101
7.10.2 Board Status TLV................................101
7.11 CGN TLVs..........................................102
7.11.1 Address Allocation Request TLV..................102
7.11.2 Address Allocation Response TLV.................103
7.11.3 Address Renewal Request TLV.....................104
7.11.4 The Address Renewal Response TLV................105
7.11.5 Address Release Request TLV.....................106
7.11.6 The Address Release Response TLV................106
7.12 Event TLVs........................................107
7.12.1. Subscriber Traffic Statistics TLV..............108
7.12.2 Subscriber Detection Result TLV.................109
7.13 Vendor TLV........................................110
INTERNET-DRAFT BNG Simple CUSP 8. Implementation Status.................................112
8.1 Implementations....................................112
8.1.1 Huawei Technologies..............................112
8.1.2 ZTE..............................................113
8.1.3 H3C..............................................113
8.2 Hackathon..........................................113
8.3 EANTC Testing......................................114
Table of Contents (continued) 9. IANA Considerations...................................115
9.1 Message Types......................................115
9.2 TLV Types..........................................115
9.3 TLV Operation Codes................................117
9.4 Sub-TLV Types......................................118
9.5 Error Codes........................................118
12.2 S-CUSP Parameters....................................60 10. Security Considerations..............................120
12.2.1 Message Types......................................60
12.2.2 TLV Types..........................................61
12.2.3 TLV Operation Codes................................62
12.2.4 Sub-TLV Types......................................62
12.2.5 ERRID Codes........................................63
Contributors..............................................65 Contributors.............................................121
Normative References......................................66 Normative References.....................................122
Informative References....................................66 Informative References...................................123
Authors' Addresses........................................68 Authors' Addresses.......................................125
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
1. Introduction 1. Introduction
A fixed network Broadband Network Gateway (BNG) is an Ethernet- A fixed network Broadband Network Gateway (BNG) is an Ethernet-
centric IP edge router, and the aggregation point for user traffic. centric IP edge router, and the aggregation point for user traffic.
To provide centralized session management, flexible address To provide centralized session management, flexible address
allocation, high scalability for subscriber management capacity, and allocation, high scalability for subscriber management capacity, and
cost-efficient redundancy, the Control/User (CU) separated BNG cost-efficient redundancy, the Control/User (CU) separated BNG
framework is described in [TR-384]. The CU separated Service Control framework is described in [TR-384]. The CU separated service Control
Plane (CP), which is responsible for user access authentication and Plane (CP), which is responsible for user access authentication and
setting forwarding entries in User Planes (UPs), can be virtualized setting forwarding entries in User Planes (UPs), can be virtualized
and centralized. The routing control and forwarding plane, i.e. the and centralized. The routing control and forwarding plane, i.e. the
BNG user plane (local), can be distributed across the infrastructure. BNG user plane (local), can be distributed across the infrastructure.
Other structures can also be supported such as both CP and UP being Other structures can also be supported such as both CP and UP being
virtual or both being physical. virtual or both being physical.
This document specifies the simple CU Separation BNG control channel This document specifies the Simple CU Separation BNG control channel
Protocol (S-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). S-CUSP is designed to be flexible and a set of User Planes (UPs). S-CUSP is designed to be flexible
and extensible so as to easily allow for additional messages and data and extensible so as to easily allow for additional messages and data
items, should further requirements be expressed in the future. items, should further requirements be expressed in the future.
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
2. Terminology 2. Terminology
This section specifies implementation requirement keywords and terms
used in this document. S-CUSP messages are described in this document
using Routing Backus-Naur Form (RBNF) as defined in [RFC5511].
2.1 Implementation Requirement Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 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 Acronyms 2.2 Terms
This section specifies terms used in this document.
AAA: Authentication Authorization Accounting.
ACK: Acknowledgement message. ACK: Acknowledgement message.
BAS: Broadband Access Server (BRAS, BNG).
BNG: Broadband Network Gateway. A broadband remote access server BNG: Broadband Network Gateway. A broadband remote access server
(BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic
to and from broadband remote access devices such as digital to and from broadband remote access devices such as digital
subscriber line access multiplexers (DSLAM) on an Internet subscriber line access multiplexers (DSLAM) on an Internet
Service Provider's (ISP) network. BRAS can also be referred to Service Provider's (ISP) network. BRAS can also be referred to
as a Broadband Network Gateway (BNG). as a Broadband Network Gateway (BNG).
BRAS: BRoadband Access Server (BNG). BRAS: BRoadband Access Server (BNG).
CAR: Committed Access Rate. CAR: Committed Access Rate.
CBS: Committed Burst Size. CBS: Committed Burst Size.
CGN: Carrier Grade NAT. CGN: Carrier Grade NAT.
Ci: Control Interface. Ci: Control Interface.
CIR: Committed Information Rate. CIR: Committed Information Rate.
CP: Control Plane. CP is a user control management component which CoA: Change of Authorization.
supports the management of the UP's resources such as the user
entry and forwarding policy. INTERNET-DRAFT Simple BNG CUSP
CP: Control Plane.
CP is a user control management component which supports the
management of the UP's resources such as the user entry and
forwarding policy.
CPE: Customer Premises Equipment.
CU: Control-plane / User-plane. CU: Control-plane / User-plane.
CUSP: Control and User Plane Separation Protocol. CUSP: Control and User plane Separation Protocol.
DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the
priority and before the VLAN ID. (This bit was formerly the CFI priority and before the VLAN ID. (This bit was formerly the CFI
(Canonical Format Indicator).) (Canonical Format Indicator).) [802.1Q]
DHCP: Dynamic Host Configuration Protocol [RFC2131].
dial-up: This refers to the initial connection messages when a new
user appears. The name is left over from when users literally
dialed up on a modem equipped phone line but herein is applied to
other initial connection techniques. Initial connection is
frequently indicated by the receipt of packets over PPPoE
[RFC2516] or IPoE.
EMS: Element Management System.
IPoE: IP over Ethernet. IPoE: IP over Ethernet.
L2TP: Layer 2 Tunneling Protocol [RFC2661]. L2TP: Layer 2 Tunneling Protocol [RFC2661].
LAC: L2TP Access Concentrator LAC: L2TP Access Concentrator.
INTERNET-DRAFT BNG Simple CUSP LNS: L2TP Network Server.
LNS: L2TP Network Server MAC: 48-bit Media Access Control address [RFC7042].
MANO: Management and Orchestration.
Mi: Management Interface. Mi: Management Interface.
MSS: Maximum Segment Size. MSS: Maximum Segment Size.
MRU: Maximum Receive Unit. MRU: Maximum Receive Unit.
NAT: Network Address Translation [RFC3022]. NAT: Network Address Translation [RFC3022].
ND: Neighbor Discovery. ND: Neighbor Discovery.
NFV: Network Function Virtualization.
INTERNET-DRAFT Simple BNG CUSP
NFVI: NFV Infrastructure
PBS: Peak Burst Size. PBS: Peak Burst Size.
PD: Prefix Delegation. PD: Prefix Delegation.
PIR: Peak Information Rate. PIR: Peak Information Rate.
PPP: Point to Point Protocol [RFC1661]. PPP: Point to Point Protocol [RFC1661].
PPPoE: PPP over Ethernet. PPPoE: PPP over Ethernet [RFC2516].
RBNF: Routing Backus-Naur Form [RFC5511].
RG: Residential Gateway.
S-CUSP: Simple Control and User Plane Separation Protocol. S-CUSP: Simple Control and User Plane Separation Protocol.
Si: Service Interface. Si: Service Interface.
TLV: Type, Length, Value. See Section 4.2. TLV: Type, Length, Value. See Sections 7.1 and 7.3.
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.
URPF: Unicast Reverse Path Forwarding. URPF: Unicast Reverse Path Forwarding.
user: Equivalent to "customer". User: Equivalent to "customer" or "subscriber".
VRF: Virtual Routing and Forwarding. VRF: Virtual Routing and Forwarding.
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
3. Protocol Overview 3. BNG CUPS Overview
This section shows example message exchanges. 3.1 BNG CUPS Motivation
3.1 S-CUSP Configuration The rapid development of new services, such as 4K TV, IoT, etc., and
increasing numbers of home broadband service users present some new
challenges for BNGs such as:
To support Control Plane and User Plane separation, as defined in Low resource utilization: The traditional BNG acts as both a gateway
[SCUSP-architecture], three interfaces are defined. These are for user access authentication and accounting and an IP network's
referred to as the Control Interface (Ci), Service Interface (Si) and Layer 3 edge. The mutually affecting nature of the tightly
Management Interface (Mi). coupled control plane and forwarding plane makes it difficult to
achieve the maximum performance of either plane.
Complex management and maintenance: Due to the large numbers of
traditional BNGs, configuring each device in a network is very
tedious when deploying global service policies. As the network
expands and new services are introduced, this deployment mode
will cease to be feasible as it is unable to manage services
effectively and rectify faults rapidly.
Slow service provisioning: The coupling of control plane and
forwarding plane, in addition to a distributed network control
mechanism, means that any new technology has to rely heavily on
the existing network devices.
To address these challenges for fixed networks, the framework for a
cloud-based BNG with Control Plane and User Plane (CU) separation is
described in [TR-384]. The main idea of CU separation is to extract
and centralize the user management functions of multiple BNG devices,
forming a unified and centralized Control Plane (CP). And the
traditional router's Control Plane and Forwarding Plane are both
preserved on BNG devices in the form of a User Plane (UP).
3.2 BNG CUPS Architecture Overview
The functions in a traditional BNG can be divided into two parts: one
is the user access management function, the other is the router
function. The user management function can be centralized and
deployed as a concentrated module or device, called the BNG Control
Plane (BNG-CP). The other functions, such as the router function and
forwarding engine, can be deployed in the form of the BNG User Plane
(BNG-UP).
INTERNET-DRAFT Simple BNG CUSP
The following figure shows the architecture of CU separated BNG:
+------------------------------------------------------------------+
| Neighboring policy and resource management systems |
| |
| +-------------+ +-----------+ +---------+ +----------+ |
| |AAA Server| |DHCP Server| | EMS | | MANO | |
| +-------------+ +-----------+ +---------+ +----------+ |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| CU-separated BNG system |
| +--------------------------------------------------------------+ |
| | +----------+ +----------+ +------++------++-----------+ | |
| | | Address | |Subscriber| | AAA ||Access|| UP | | |
| | |management| |management| | || Mgt ||management | | |
| | +----------+ +----------+ +------++------++-----------+ | |
| | CP | |
| +--------------------------------------------------------------+ |
| |
| |
| |
| +---------------------------+ +--------------------------+ |
| | +------------------+ | | +------------------+ | |
| | | Routing control | | | | Routing control | | |
| | +------------------+ | ... | +------------------+ | |
| | +------------------+ | | +------------------+ | |
| | |Forwarding engine | | | |Forwarding engine | | |
| | +------------------+ UP | | +------------------+ UP| |
| +---------------------------+ +--------------------------+ |
+------------------------------------------------------------------+
Figure 1: Architecture of CU Separated BNG
As shown in Figure 1, the BNG Control Plane could be virtualized and
centralized, which provides benefits such as centralized session
management, flexible address allocation, high scalability for
subscriber management capacity, and cost-efficient redundancy, etc.
The functional components inside the BNG Service Control Plane can be
implemented as Virtual Network Functions (VNFs) and hosted in a
Network Function Virtualization Infrastructure (NFVI).
The User Plane Management module in the BNG Control Plane centrally
manages the distributed BNG User Planes (e.g. load balancing), as
well as the setup, deletion, and maintenance of channels between
Control Planes and User Planes. Other modules in the BNG control
plane, such as address management, AAA, etc., are responsible for the
connection with outside subsystems in order to fulfill those
services. Note that the User Plane SHOULD support both physical and
virtual network functions. For example, BNG user plane L3 forwarding
INTERNET-DRAFT Simple BNG CUSP
related network functions can be disaggregated and distributed across
the physical infrastructure. And the other control plane and
management plane functions in the CU Separation BNG can be moved into
the NFVI for virtualization [TR-384].
The details of CU separated BNG's function components are as
following:
The Control Plane is responsible for the following:
1. Address management: unified address pool management and CGN
subscriber address traceability management.
2. AAA: This component performs Authentication, Authorization and
Accounting, together with RADIUS/DIAMETER. The BNG communicates
with the AAA server to check whether the subscriber who sent an
Access-Request has network access authority. Once the subscriber
goes online, this component together with the Service Control
component implement accounting, data capacity limitation, and QoS
enforcement policies.
3. Subscriber management: user entry management and forwarding
policy management.
4. Access management: process user dial-up packets, such as PPPoE,
DHCP, L2TP, etc.
5. UP management: management of UP interface status, and the setup,
deletion, and maintenance of channels between CP and UP.
The User Plane is responsible for the following:
1. Routing control functions: responsible for constructing routing
forwarding plane (e.g., routing, multicast, MPLS, etc.).
2. Routing and Service Forwarding plane functions: responsible
including traffic forwarding, QoS and traffic statistics
collection.
Subscriber detection: responsible for detecting whether a subscriber
is still online.
3.3 BNG CUPS Interfaces
To support the communication between the Control Plane and User
Plane, three interfaces are assumed. These are referred to as the
Service Interface (Si), Control Interface (Ci), and Management
Interface (Mi) as shown in Figure 2.
INTERNET-DRAFT Simple BNG CUSP
+-----------------------------------+
| |
| BNG-CP |
| |
+--+--------------+--------------+--+
| | |
1. Service | 2. Control | 3. Management|
Interface | Interface | Interface |
(Si) | (Ci) | (Mi) |
| | |
| ___|___ |
| ___( )___ |
_|______( )______|_
( )
( Network/Internet )
(________ ________)
| (___ ___) |
| (_______) |
| | |
| | |
+--+--------------+--------------+--+
| |
| BNG-UP |
| |
+-----------------------------------+
Figure 2: Interfaces Between the CP and UP of the BNG
3.3.1 Service Interface
For a traditional BNG (without CU separation), the user dial-up
signals are terminated and processed by the control plane of a BNG.
When the CP and UP of a BNG are separated, there needs to be a way to
relay these signals between the CP and the UP.
The Service Interface (Si) is used to establish tunnels between the
CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE,
and L2TP related control packets that are received from a Residential
Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN
[RFC7348].
The detailed definition of Si is out of scope for this document.
INTERNET-DRAFT Simple BNG CUSP
3.3.2 Control Interface
The CP uses the Control Interface to deliver subscriber session
states, network routing entries, etc. to the UP (see Section 6.2.7)).
The UP uses this interface to report subscriber service statistics,
subscriber detection results, etc. to the CP (see Sections 6.3 and
6.4). A carrying protocol for this interface is specified in this
document.
3.3.3 Management Interface
NETCONF [RFC6241] is the protocol used on the Management Interface NETCONF [RFC6241] is the protocol used on the Management Interface
between a CP and UP. It is used to configure the parameters of the between a CP and UP. It is used to configure the parameters of the
Control Interface, Service Interface and the Access interfaces. The Control Interface, Service Interface, the Access interfaces and
parameters are defined in [SCUSP-YANG]. QoS/ACL Templates. It is expected that implementations will make use
of existing YANG models where possible, but that new YANG models
specific to S-CUSP will need to be defined. The definitions of the
parameters are out of scope for this document.
UP CP 3.4 BNG CUPS Procedure Overview
| |
| Configure Control Interface |
|<-----------via NETCONF-----------|
| |
| Configure Service Interface |
|<-----------via NETCONF-----------|
| |
| Configure Access Interfaces |
|<-----------via NETCONF-----------|
| |
| Configure QOS Template |
|<-----------via NETCONF-----------|
| |
Once the parameters are configured, a UP can start to establish S- The following numbered sequences (Figure 3) gives a high level view
CUSP session(s) with the specified CP(s) through the S-CUSP Session of the main BNG CUPS procedures.
Establishment as defined Section 3.2 of this document.
INTERNET-DRAFT BNG Simple CUSP RG UP CP AAA
| | | |
| |Establish S-CUSP Channel| |
| 1|<---------------------->| |
| | | |
| | Report Board | |
| | interface | |
| | information | |
| 2|------to CP via Ci----->| |
| | | |
| | Update BAS function | |
| 3| request / response | |
| |<-----on UP via Ci----->| |
| | | |
| | Update network routing | |
| | request / response | |
| 4|<------- via Ci-------->| |
| | | |
| Online Req | | |
5.1|-------------->| | |
| | Relay the Online Req | |
| 5.2|-----to CP via Si------>| Authentication|
3.2 S-CUSP Session Establishment INTERNET-DRAFT Simple BNG CUSP
UP CP | | | Req/Rep |
| | | | 5.3|<------------->|
| TCP Session Establishment | | | Send the Online Rep | |
|<------------------------------->| | 5.4|<----to UP via Si-------| |
| | | Online Rep | | |
| | 5.5|<--------------| | |
| HELLO (version, capability) | | | Create subscriber | |
|-------------------------------->| | | session on UP | |
| | | 5.6|<--------via Ci-------->| |
| | | | | CoA Request |
| HELLO (version, capability) | | | 6.1|<--------------|
|<--------------------------------| | | Update session on UP | |
| | | 6.2|<--------via Ci-------->| |
| | | CoA Response |
| | 6.3|-------------->|
| | | |
| Offline Req | | |
7.1|-------------->| | |
| | Relay the Offline Req | |
| 7.2|------to CP via Si----->| |
| | | |
| | Send the Offline Rep | |
| 7.3|<-----to UP via Si------| |
| Offline Rep | | |
7.4|<--------------| | |
| | Delete session on UP | |
| 7.5|<--------via Ci-------->| |
| | | |
| | Event report | |
| 8|---------via Ci-------->| |
| | | |
| | Data Synchronization | |
| 9|<--------via Ci-------->| |
| | | |
| | CGN Address Allocation | |
| 10|<--------via Ci-------->| |
| | | |
Figure 3: BNG CUPS Procedures Overview
1. S-CUSP session establishment: This is the first step of BNG CUPS
procedures. Once the Control Interface parameters are configured
on a UP. It will start to setup S-CUSP sessions with the
specified CPs. The detailed definition of S-CUSP session
establishment can be found in Section 4.1.1.
2. Board and interface report: Once the S-CUSP session is
established between the UP and a CP, the UP will report status
information on the boards and subscriber side interfaces of this
UP to the CP. A board can also be called a Line/Service Process
INTERNET-DRAFT Simple BNG CUSP
Unit (LPU/SPU) card. The subscriber side interfaces refer to the
interfaces that connect the Acess Network nodes (e.g., OLT:
Optical Line Terminal, DSLAM: Digital Subscriber Line Access
Multiplexer, etc.). The CP can use this information to enable the
Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, etc.)
on the specified interfaces. See Sections 4.2.1 and 7.10 for more
details on Resource reporting.
3. BAS (Broadband Access Service) function enable: To enable the BAS
function on the specified interfaces of a UP.
4. Subscriber network route advertisement: The CP will allocate one
or more IP address blocks to a UP. Each address block contains a
series of IP addresses. Those IP addresses will be allocated to
subscribers who are dialing up from the UP. To enable other nodes
in the network to learn how to reach the subscribers, the CP
needs to notify the UP to advertise to the network the routes
that can reach those IP addresses.
5. 5.1-5.6 is a complete call flow of a subscriber dial-up process.
When a UP receives a dial-up request, it will relay the request
packet to a CP through the Service Interface. The CP will parse
the request. If everything is OK, it will send an authentication
request to the AAA server to authenticate the subscriber. Once
the subscriber passes the authentication, the AAA server will
return a positive response to the CP. Then the CP will send the
dial-up response packet to the UP and the UP will forward the
response packet to the subscriber (RG). At the same time, the CP
will create a subscriber session on the UP, which enables the
subscriber to access the network. For different access types,
the process may be a bit different. But the high-level process is
similar. For each access type, the detail process can be found in
Section 5.
6. 6.1-6.3 is the sequence when updating an existing subscriber
session. The AAA server initiates a Change of Authorization (CoA)
and sends the CoA to the CP. The CP will then update the session
according to the CoA. See Section 4.3.2 for more detail on CP
messages updating UP tables.
7. 7.1-7.5 is the sequence for deleting an existing subscriber
session. When a UP receives an offline request, it will relay the
request to a CP through the Service Interface. The CP will send
back a response to the UP through the Service Interface. The UP
will then forward the offline response to the subscriber. Then
the CP will delete the session on the UP through the Control
Interface.
INTERNET-DRAFT Simple BNG CUSP
8. Event reports include the following two parts (more detail can be
found in Section 4.3.4) Both are reported using the Event
message.
8.1 Subscriber Traffic Statistics Report
8.2 Subscriber Detection Result Report
9. Data synchronization: See Sections 4.2.5 for more detail on CP
and UP Synchronization.
10. CGN address allocation: See Sections 4.2.4 for more detail on CGN
Address Allocation.
INTERNET-DRAFT Simple BNG CUSP
4. S-CUSP Protocol Overview
4.1 Control Channel Related Procedures
4.1.1 S-CUSP Session Establishment
A UP is associated with a CP and is controlled by that CP. In the
case of a hot-standby or cold-standby, a UP is associated with two
CPs, one called the Master CP and the other called the Standby CP.
The association between a UP and its CPs is implemented by dynamic
configuration.
Once a UP knows its CPs, the UP starts to establish S-CUSP sessions
with those CPs as shown in Figure 4.
UP CP
| |
| TCP Session Establishment |
|<------------------------------->|
| |
| HELLO (version, capability) |
|-------------------------------->|
| |
| HELLO (version, capability) |
|<--------------------------------|
| |
Figure 4: S-CUSP Session Establishment
The S-CUSP session establishment consists of two successive steps: The S-CUSP session establishment consists of two successive steps:
1) Establishment of a TCP [RFC793] connection (3-way handshake) 1. Establishment of a TCP [RFC793] connection (3-way handshake)
between the CP and the UP using port tbd1. between the CP and the UP using a configured port from the
dynamic port range (49152-65535).
2) Establishment of a S-CUSP session over the TCP connection. 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 S-CUSP session during which the version negotiation is performed. the S-CUSP session during which the version and Keepalive timers are
The version information is carried within Hello messages (see Section negotiated.
6.2). If the S-CUSP session establishment phase fails because the CP
or UP disagree on the version parameters or one of the CP or UP does
not answer after the expiration of the establishment timer. When the
S-CUSP session establishment fails, the TCP connection is promptly
closed.
3.3 Overview of S-CUSP Procedures The version information (Hello TLV, see Section 7.4) is carried
within Hello messages (see Section 6.2.1). A CP can support multiple
versions, but a UP can only support one version. So, the version
negotiation is based on whether a version can be support by both the
CP and the UP. For a CP or UP, if a Hello message is received that
The five sequences below give a high level view of the S-CUSP message INTERNET-DRAFT Simple BNG CUSP
sequences. These sequences are covered in more detail below as
indicated.
UP CP does not indicate a version supported by both, a subsequent Hello
message with an Error Information TLV will be sent to the peer to
notify the peer of the "Version-Mismatch" error and the session
establishment phase fails.
1. Keepalive negotiation is performed by carrying a Keepalive TLV in the
| UP reports the Statistic INFO | Hello message. The Keepalive TLV includes a Keepalive timer and Dead
|-----to CP via S-CUSP---------------->| Timer field. The CP and UP have to agree on the Keepalive Timer and
| | Dead Timer. Otherwise, a subsequent Hello message with an Error
| UP reports the Event INFO | Information TLV will be sent to its peer and the session
|-----to CP via S-CUSP---------------->| establishment phase fails.
| |
| UP reports Resource INFO |
INTERNET-DRAFT BNG Simple CUSP The S-CUSP session establishment phase fails if the CP or UP disagree
on the version and keepalive parameters or if one of the CP or UP
does not answer after the expiration of the Establishment timer.
When the S-CUSP session establishment fails, the TCP connection is
promptly closed. Successive retries are permitted but an
implementation SHOULD make use of an exponential back-off session
establishment retry procedure.
|-----to CP via S-CUSP---------------->| The S-CUSP session timer values that need to be configured are
| | summarized in the table below.
1. See Sections 3.4 and 4.1.3 for more details on Resource reporting. Timer Range in Default
See Section 4.1.4 for more details on Event reporting. Traffic Name seconds Value
statistics are also reported using the Event message. ------------- ------- -------
Establishment 1-32767 45
Keepalive 0-255 30
DeadTimer 1-32767 4 * Keepalive
2. 4.1.2 Keep Alive
| UP relays User Dial-up Request |
|-----to CP via Si-------------------->|
| |
| CP sends User Dial-up Response |
|<----to UPs via Si--------------------|
| |
2. This interaction is via the Service Interface and corresponds to Once an S-CUSP session has been established, a UP or CP may want to
the initial interaction in the message sequence charged in the know that its S-CUSP peer is still available for use.
sub-sections of Section 3.5.
3. Each end of a S-CUSP session runs a Keepalive timer. It restarts the
| CP sends User INFO | timer every time it sends a message on the session. When the timer
|<----to UP via S-CUSP-----------------| expires, it sends a Keepalive message.
| |
| CP sends User Policy INFO |
|<----to UP via S-CUSP-----------------|
| |
| CP sends Route INFO |
|<----to UP via S-CUSP-----------------|
| |
| CP sends Tunnel INFO |
|<----to UP via S-CUSP-----------------|
| |
3. See Section 4.1.2 for more detail on CP messages updating UP The ends of the S-CUSP session also run DeadTimers, and they restart
tables. the timers whenever a message is received on the session. If one end
of the session receives no message after the DeadTimer expires, it
declares the session dead. The session will be closed.
4. The minimum value of the Keepalive timer is 1 second, and it is
| CGN Address Allocation via S-CUSP | specified in units of 1 second. The RECOMMENDED default value is 30
|<------------------------------------>| seconds. The timer may be disabled by setting it to zero.
| |
4. See Sections 3.8 and 4.1.8 for more detail on CGN Address INTERNET-DRAFT Simple BNG CUSP
Allocation.
5. The recommended default for the DeadTimer is 4 times the value of the
| Data Synchronization via S-CUSP | Keepalive timer used by the remote peer. This implies there is
|<------------------------------------>| essentially no risk of TCP congestion due to excessive Keepalive
| | messages.
INTERNET-DRAFT BNG Simple CUSP The Keepalive timer and DeadTimer are initially negotiated through
the Keepalive TLV carried in the Hello Message.
5. See Sections 3.7 and 4.1.1 for more detail on CP and UP 4.2 Node Related Procedures
Synchronization.
3.4 Network Resource Report 4.2.1 UP Resource Report
Once an S-CUSP session is established between a CP and an UP. The UP Once an S-CUSP session has been established between a CP and an UP.
will begin to report the status/attributes of its slots, interfaces, The UP reports the information of the Boards and access side
and sub-interfaces. interfaces on this UP to the CP as shown in Figure 5. Report messages
are unacknowledged and are assumed to be delivered because the
session runs over TCP.
UP CP The CP can use that information to activate/enable the Broadband
| | Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the
| Slot attributes report | specified interfaces.
| via S-CUSP |
|-------------------------------->|
| |
| Port attributes report |
| via S-CUSP |
|-------------------------------->|
| |
| Sub-interface attributes report |
| via S-CUSP |
|-------------------------------->|
| |
Details of the Resource Report Messages can be found in Sections In addition, the UP resource report may trigger a UP warm-standby
4.2.3 and 7. process. In the case of warm-standby, a failure on an UP may trigger
the CP to start a warm-standby process, by moving the on-line
subscriber sessions to a standby UP and then direct the affected
subscribers to access the Internet through the standby UP.
3.5 BNG Access Procedures UP CP
| |
| Report Board Status |
|------to CP via Ci----->|
| |
| Report Interface Status|
|------to CP via Ci----->|
| |
The subsection below give an overview of various "dial up" Figure 5: UP Board and Interface Report
interactions over the Service Interface followed by the setting of
various informatiion in the UP by the CP using S-CUSP over the
Control Interface.
INTERNET-DRAFT BNG Simple CUSP Board status information is carried in the Board Status TLV (Section
7.10.2) and Interface status information is carried in Interface
Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are
carried in the Report Message (Section 6.4).
3.5.1 IPoE Access INTERNET-DRAFT Simple BNG CUSP
UP CP 4.2.2 Update BAS Function on Access Interface
| |
| DHCP Negotiation Messages |
|<-----------via Si-------------------->|
| |
| CP sends USER_BASEC_INFO |
|<---to UPs via S-CUSP------------------|
| |
| CP sends USER_POLICY_INFO |
|<---to UP via S-CUSP-------------------|
| |
| CP sends USER_IPV4/6_INFO |
|<---to UPs via S-CUSP------------------|
| |
| CP sends ROUTEV4/6 INFO |
|<---to UPs via S-CUSP------------------|
| |
| UP reports USER_DETECT_RESULT_INFO |
|----to CP via S-CUSP------------------>|
| |
| UP reports USER_TRAFFIC_INFO |
|----to CP via S-CUSP------------------>|
| |
INTERNET-DRAFT BNG Simple CUSP Once the CP collects the interface status of a UP, it will
activate/de-activate/modify the BAS functions on specified interfaces
through the Update_Request and Update_Response message (Section 6.2)
exchanges carrying the BAS Function TLV (Section 7.7).
3.5.2 PPPoE Access UP CP
| |
| Update BAS function |
| Request |
|<-----on UP via Ci-------|
| |
| Update BAS function |
| Response |
|------on UP via Ci------>|
| |
UP CP Figure 6: Update BAS Function
| |
| 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----------------->|
| |
INTERNET-DRAFT BNG Simple CUSP 4.2.3 Update Network Routing
3.5.3 L2TP LAC Access The CP will allocate one or more address blocks to a UP. Each address
block contains a series of IP addresses. Those IP addresses will be
allocated to subscribers who are dialing up to the UP. To enable the
other nodes in the network to learn how to reach the subscribers, the
CP needs to install the routes on the UP and notify the UP to
advertise the routes to the network.
UP CP LNS UP CP
| | | | |
| PPPoE Negotiation Messages | | | Subscriber network route|
|<-----------via Si------------------>| | | update request |
| | | |<------- via Ci----------|
| LCP Negotiation Messages | | | |
|<-----------via Si------------------>| | | Subscriber network route|
| | | | update response |
| User Authentication Messages | | |-------- via Ci--------->|
|<-----------via Si------------------>| | | |
| | |
| LAC Tunnel Negotiation Messages | |
| -----------via Si------------------>| |
| /\ | |
| || forward | |
| \/ | |
| ------------------ LAC Tunnel Negotiation ---------->|
| | |
| LAC Session Negotiation Messages | |
|<-----------via Si------------------>| |
| /\ | |
| || forward | |
| \/ | |
| ------------------ LAC Session Negotiation --------->|
| | |
| CP sends USER_BASIC_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends LAC_TUNNEL_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends LAC_USER_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| | |
| UP reports USER_TRAFFIC_INFO | |
|-----to CP via S-CUSP--------------->| |
| | |
3.5.4 L2TP LNS Access Figure 7: Update Network Routing
INTERNET-DRAFT BNG Simple CUSP
|UP CP| LAC| The subscriber network routing update request and response are
| LNS Tunnel Negotiation Messages | | achieved through the Update Request and Response Message exchanges by
|<-----------via Si------------------>| | carrying the IPv4/IPv6 Routing Information TLVs (Section 7.8).
| /\ | |
| || forward | |
| \/ | |
| ------------------ LNS Tunnel Negotiation --------->|
| | |
| LNS Session Negotiation Messages | |
|<-----------via Si------------------>| |
| /\ | |
| || forward | |
| \/ | |
| ------------------ LNS Session Negotiation -------->|
| | |
| LCP Negotiation Messages | |
|<-----------via Si------------------>| |
| | |
| User Authentication Messages | |
|<-----------via Si------------------>| |
| | |
| IPCP Negotiation Messages | |
|<-----------via Si------------------>| |
| | |
| CP sends LNS_TUNNEL_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends USER_BASEC_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends USER_IPV4/6_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends ROUTEV4/6 INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends USER_PPP_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends LNS_USER_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| CP sends USER_POLICY_INFO | |
|<----to UP via S-CUSP----------------| |
| | |
| UP reports USER_DETECT_RESULT_INFO | |
|-----to CP via S-CUSP--------------->| |
| | |
| UP reports USER_TRAFFIC_INFO | |
|-----to CP via S-CUSP--------------->| |
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
3.5.5 L2TP LTS Access 4.2.4 CGN Public IP Address Allocation
UP CP LAC/LNS The following sequences describe the CGN address management related
| | | procedures. Three independent procedures are defined, one each for
| LAC/LTS Tunnel Negotiation Messages | | CGN address allocation request/response, CGN address renewal
|<-----------via Si------------------>| | request/response, and CGN address release request/response.
| /\ | |
| || 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 CGN address allocation/renew/release procedures are designed for the
INTERNET-DRAFT BNG Simple CUSP case where the CGN function is running on the UP. The UP has to map
the subscriber private IP addresses to a public IP addresses, and
such mapping is performed by the UP locally when a subscriber dials-
up. That means the UP has to ask for public IPv4 address blocks for
CGN subscribers from the CP.
UP CP AAA In addition, when a public IP address is allocated to a UP, there
| | | will be a lease time (e.g., one day). Before the lease time expires,
| Configure QOS template | | the UP can ask for renewal of the IP address lease from the CP. It is
|<-----via NETCONF--------------------| | achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack
| | | messages.
| 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 If the public IP address will not be used anymore, the UP SHOULD
Service (QoS) needs to be set dynamically, the CP initiate a NETCONF release the address by sending an Addr_Release_Req message to the CP.
session to configure the requested User's QoS template. Then the
user dials up via the Si, the CP sends the USER_BASIC_INFO message,
USER_IPV4_INFO message, and USER_ROUTEV4_INFO messages to the UP, the
UPs report the user detection results and user's traffic status.
Once the above process has been accomplished, the CP sends the If the CP wishes to withdraw addresses that it has previously leased
USER_QOS_AUTH_INFO message to the UPs; this message contains a to a UP, it uses the same procedures as above. The "Oper" code in
variety of objects that specify the set of constrains and attributes the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the
for the user's required QoS. (The format of these QoS attributes request is an update or withdraw.
should be parallel to the QoS configuration templates.)
3.7 CP and UP Synchronization The relevant messages are defined in Section 6.5.
Under some circumstances it is necessary to synchrnoize state between INTERNET-DRAFT Simple BNG CUSP
UP CP
| |
| CGN Address Allocation |
| Request |
1.1|-------- via Ci--------->|
| CGN Address Allocation |
| Response |
1.2|<------- via Ci----------|
| |
| CGN Address Renew |
| Request |
2.1|-------- via Ci--------->|
| CGN Address Renew |
| Response |
2.2|<------- via Ci----------|
| |
| CGN Address Release |
| Request |
3.1|-------- via Ci--------->|
| CGN Address Release |
| Response |
3.3|<------- via Ci----------|
| |
Figure 8: CGN Public IP Address Allocation
4.2.5 Data Synchronization between the CP and UP
For a CU separated BNG, the UP will continue to function using the
state that has been installed in it even if the CP fails or the
session between the UP and CP fails.
Under some circumstances it is necessary to synchronize state between
the CP and UP, for example if a CP fails and the UP is switched to a the CP and UP, for example if a CP fails and the UP is switched to a
different CP. There may be multiple Resource INFO messages between different CP.
the Synchronization Begin and Synchronization End.
UP CP Synchronization includes two directions. One direction is from UP to
| | CP; in that case, the synchronization information is mainly about the
| CP sends Synchronization Request | board/interface status of the UP. The other direction is from CP to
|<-----to UP via S-CUSP---------------| UP; in that case, the subscriber sessions, subscriber network routes,
| | L2TP tunnels, etc. will be synchronized to the UP.
| UP sends Synchronization Begin |
|------to CP via S-CUSP-------------->|
| |
| UP reports Resource INFO |
|------to CP via S-CUSP-------------->|
INTERNET-DRAFT BNG Simple CUSP The synchronization is triggered by a Sync_Request message, to which
the receiver will (1) reply with a Sync_Begin message to notify the
requester that synchronization will begin, and (2) then start the
synchronization using the Sync_Data message. When synchronization
finished, a Sync_End message will be sent.
| | INTERNET-DRAFT Simple BNG CUSP
| UP sends Synchronization End |
|------to CP via S-CUSP-------------->|
| |
| UP sends NAT Address Renew Req. | The following figure shows the process of data synchronization
|------to CP via S-CUSP-------------->| between a UP and a CP.
| |
| CP sends NAT Address Renew Res. |
|<-----to UP via S-CUSP---------------|
| |
| UP sends Synchronization Request | UP CP
|------to CP via S-CUSP-------------->| | |
| | | Synchronization Request |
| CP sends Synchronization Begin | |<------- via Ci----------|
|<-----to UP via S-CUSP---------------| | |
| | | Synchronization Begin |
| CP sends User/Route/Tunnel. INFO | |-------- via Ci--------->|
|<-----to UP via S-CUSP---------------| | |
| | | Board/Interface Report |
| CP sends Synchronization End | |-------- via Ci--------->|
|<-----to UP via S-CUSP---------------| | |
| | | Synchronization End |
|-------- via Ci--------->|
| |
1) Synchronization from UP to CP
3.8 CGN Address Allocation UP CP
| |
| Synchronization Request |
|-------- via Ci--------->|
| |
| Synchronization Begin |
|<-------- via Ci---------|
| |
| Synchronizes |
|Subscriber Session States|
| Network Route Entries |
|<------- via Ci----------|
| |
| Synchronization End |
|<-------- via Ci---------|
| |
2) Synchronization from CP to UP
UP CP Figure 9: Data Synchronization
| |
| UP sends Address Allocation Req. |
|------to CP via S-CUSP-------------->|
| |
| CP sends Address Allocation Res. |
|<-----to UP via S-CUSP---------------|
| |
See Section 4.1.6 4.3 Subscriber Session Related Procedures
INTERNET-DRAFT BNG Simple CUSP A subscriber session consists of a set of forwarding states,
policies, and security rules that are applied to the subscriber. It
is used for forwarding subscriber traffic in a UP. To initialize a
session on a UP, a set of hardware resource have to be allocated
(e.g., NP, TCAM etc.) to a session.
4. S-CUSP Message Formats Subscriber session related procedures include subscriber session
This section specifies the format of the common S-CUSP message INTERNET-DRAFT Simple BNG CUSP
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, create, update, delete, and statistics report. The following sub-
and the format of some basic data fields. sections give a high level view of the procedures.
4.3.1 Create Subscriber Session
The below sequence describes the DHCP IPv4 dial-up process, it is an
example that shows how a subscriber session is created. (An example
for IPv6 appears in Section 5.1.2.)
RG UP CP AAA
| | | |
| Online Request| | |
1|-------------->| | |
| |Relay the Online Request| |
| 2|-----to CP via Si------>| Authentication|
| | | Req/Rep |
| | 3|<------------->|
| | Create subscriber | |
| | session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create subscriber | |
| | session Response | |
| 5|---------via Ci-------->| |
| | | |
| | | Accounting |
| | 6|<------------->|
| | | |
| | Send Online Response | |
| 7|<----to UP via Si-------| |
| | | |
|Online Response| | |
12|<--------------| | |
| | | |
Figure 10: Subscriber Session Create
The request starts from an Online Request message (step 1) from the
RG (for example, a DHCP Discovery packet). When the UP receives the
Online Request from the RG, it will tunnel the Online Request to the
CP through the Service Interface (Step 2). The Service Interface is
implemented by a tunneling technology.
When the CP receives the Online Request from the UP, it will send an
authentication request to the AAA server to authenticate and
authorize the subscriber (step 3). When a positive reply is received
from the AAA sever, the CP starts to create a subscriber session for
the request. Relevant resources (e.g., IP address, bandwidth, etc.)
INTERNET-DRAFT Simple BNG CUSP
will be allocated to the subscriber, policies and security rules will
be generated for the subscriber Then the CP sends a session create
request to the UP through the Control Interface (Ci) (step 4), and a
response is expected from the UP to confirm the creation (step 5).
Finally, the CP will notify the AAA server to start accounting (step
6). At the same time, an Online Response message (for example, a
DHCP Ack packet) will be sent to the UP through the Si (step 7). And
the UP will forward the Online Response to the RG (step 8).
This completes the subscriber online process.
4.3.2 Update Subscriber Session
The following numbered sequence shows the process of subscriber
session update.
UP CP AAA
| | COA Request |
| 1|<--------------|
| Session update Request | |
2|<--------via Ci---------| |
| | |
| Session update Response| |
3|---------via Ci-------->| |
| | COA Response |
| 4|-------------->|
| | |
Figure 11: Subscriber Session Update
When a subscriber session has been created on a UP, there may be
requirements to update the session with new parameters (e.g.,
Bandwidth, QoS, policies, etc.).
This procedure is triggered by a Change of Authorization (COA)
request message sent by the AAA server. The CP will update the
session on the UP according to the new parameters through the Control
Interface.
INTERNET-DRAFT Simple BNG CUSP
4.3.3 Delete Subscriber Session
The below call flow shows generally how S-CUPS deals with a
subscriber offline request.
RG UP CP
| | |
|Offline Request | |
1|--------------->| |
| | Relay the Offline |
| | Request |
| 2|------to CP via Si----->|
| | |
| | Send the Offline |
| | Response |
| 3|<-----to UP via Si------|
|Offline Response| |
4|<---------------| |
| | Session delete |
| | Request |
| |<--------via Ci---------|
| | Session delete |
| | Response |
| |---------via Ci-------->|
| | |
Figure 12: Subscriber Session Delete
Similar to the session creation process, when a UP receives an
offline request from a RG, it will tunnel the request to a CP through
the Si.
When the CP receives the offline request, it will withdraw/release
the resources (e.g., IP address, bandwidth) that have been allocated
to the subscriber. Then, it sends a reply to the UP through the
Service Interface and the UP will forward the reply to the RG. At
the same time, it will delete all the status of the session on the UP
through the Ci.
4.3.4 Subscriber Session Events Report
UP CP
| |
| Statistic/Detect report|
|---------via Ci-------->|
| |
Figure 13: Events Report
INTERNET-DRAFT Simple BNG CUSP
When a session is created on an UP, the UP will periodically report
statistics information and detect results of the session to the CP.
INTERNET-DRAFT Simple BNG CUSP
5. S-CUSP Call Flows
The subsections below give an overview of various "dial-up"
interactions over the Service Interface followed by an overview of
the setting of various information in the UP by the CP using S-CUSP
over the Control Interface.
S-CUSP messages are described in this document using Routing Backus
Naur Form (RBNF) as defined in [RFC5511].
5.1 IPoE
5.1.1 DHCPv4 Access
The following sequence shows detailed procedures for DHCPv4 access.
RG UP CP AAA
| | | |
| DHCP Discovery| | |
1|-------------->| | |
| |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | | |
| | Send the DHCP Offer | |
| 4|<----to UP vis Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request| |
| 7|-----to CP via Si------>| |
| | | |
| | Create subscriber | |
| | session Request | |
| 8|<--------via Ci---------| |
| | Create subscriber | |
| | session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | | |
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| | | |
INTERNET-DRAFT Simple BNG CUSP
| DHCP ACK | | |
12|<--------------| | |
| | | |
Figure 14: DHCPv4 Access
Step 8 and 9 are implemented by the S-CUSP protocol.
When a subscriber is authenticated and authorized by the AAA server,
the CP will create a subscriber session on the UP. This is achieved
by sending an Update_Request message to the UP.
The format of the Update_Request message is shown as follows using
RBNF:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message, the format of the
Update_Response message is as follows:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
5.1.2 DHCPv6 Access
The following sequence shows detailed procedures for DHCPv6 access.
RG UP CP AAA
| | | |
| Solicit | | |
1|-------------->| | |
| | Relay the Solicit | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | | |
| | Send the Advertise | |
| 4|<----to UP vis Si-------| |
| Advertise | | |
5|<--------------| | |
| | | |
| Request | | |
6|-------------->| | |
INTERNET-DRAFT Simple BNG CUSP
| | Relay the Request | |
| 7|-----to CP via Si------>| |
| | | |
| | | |
| | Create subscriber | |
| | session Request | |
| 8|<--------via Ci-------->| |
| | | |
| | Create subscriber | |
| | session Response | |
| 9|---------via Ci-------->| |
| | | |
| | | Accounting |
| | 10|<------------->|
| | | |
| | Send Reply | |
| 11|<----to UP via Si-------| |
| | | |
| Reply | | |
12|<--------------| | |
| | | |
Figure 15: DHCPv6 Access
Steps 1-7 are a standard DHCP IPv6 access process. The subscriber
creation is triggered by a DHCP IPv6 request message. When this
message is received, it means that the subscriber has passed the AAA
authentication and authorization. Then the CP will create a
subscriber session on the UP. This is achieved by sending an
Update_Request message to the UP (Step 8).
The format of the Update_Request message is as follows:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message (Step 9). The
format of the Update_Response message is as follows:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
5.1.3 IPv6 SLAAC Access
The following flow shows the IPv6 SLAAC access process.
RG UP CP AAA
| | | |
| RS | | |
1|-------------->| | |
| | Relay the Router | |
| | Solicit (RS) | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | | |
| | Create subscriber | |
| | session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create subscriber | |
| | session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send Router Advertise | |
| | (RA) | |
| 6|<----to UP vis Si-------| |
| RA | | |
7|<--------------| | |
| | | |
| NS | | |
8|-------------->| | |
| | Relay the Neighbor | |
| | Solicit (NS) | |
| 9|-----to CP via Si------>| |
| | | |
| | | Accounting |
| | 10|<------------->|
| | | |
| | Send a Neighbor | |
| | Advertise (NA) | |
| 11|<----to UP via Si-------| |
| | | |
| NA | | |
12|<--------------| | |
| | | |
Figure 16: IPv6 SLAAC Access
It starts with a Router Solicit (RS) request from an RG that is
tunneled to the CP by the UP. After the AAA authentication and
authorization, the CP will create a subscriber session on the UP.
INTERNET-DRAFT Simple BNG CUSP
This is achieved by sending an Update_Request message to the UP (step
4).
The format of the Update_Request message is as follows:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message (step 5), the
format of the Update_Response message is as follows:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.1.4 DHCPv6 + SLAAC Access
The following call flow shows the DHCP IPv6 and SLAAC access process.
RG UP CP AAA
| | | |
| RS | | |
1|-------------->| | |
| | Relay the Router | |
| | Solicit (RA) | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | | |
| | Create subscriber | |
| | session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create subscriber | |
| | session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send Router Advertise | |
| | (RA) | |
| 6|<----to UP vis Si-------| |
| RA | | |
7|<--------------| | |
| | | |
|DHCPv6 Solicit | | |
8|-------------->| | |
| | Relay DHCPv6 Solicit | |
INTERNET-DRAFT Simple BNG CUSP
| 9|-----to CP via Si------>| |
| | | |
| | Update subscriber | |
| | session Request | |
| 10|<--------via Ci---------| |
| | | |
| | Update subscriber | |
| | session Response | |
| 11|---------via Ci-------->| |
| | | |
| | | Accounting |
| | 12|<------------->|
| | | |
| | Send DHCPv6 Reply | |
| 13|<----to UP via Si-------| |
| | | |
| DHCPv6 Reply | | |
14|<--------------| | |
| | | |
Figure 17: DHCPv6 + SLAAC Access
When a subscriber passes AAA authentication, the CP will create a
subscriber session on the UP. This is achieved by sending an
Update_Request message to the UP (step 4).
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message (step 5). The
format of the Update_Response is as follows:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
After receiving a DHCPv6 Solicit, the CP will update the subscriber
session by sending an Update_Request message with new parameters to
the UP (Step 10).
The format of the Update_Request message is as follows:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
INTERNET-DRAFT Simple BNG CUSP
The UP will reply with an Update_Response message (step 11). The
format of the Update_Response is as follows:
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.1.5 DHCP Dual Stack Access
The following sequence is a combination of DHCP IPv4 and DHCP IPv6
access processes.
RG UP CP AAA
| | | |
| DHCP Discovery| | |
1|-------------->| | |
| |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA |
| | | Req/Resp |
| | 3|<------------->|
| | | |
| | Send the DHCP Offer | |
| 4|<----to UP vis Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request| |
| 7|-----to CP via Si------>| |
| | | |
| | Create subscriber | |
| | session Request | |
| 8|<--------via Ci-------->| |
| | Create subscriber | |
| | session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| | | |
| DHCP ACK | | |
12|<--------------| | |
| RS | | |
13|-------------->| | |
| | Relay the Router | |
| | Solicit (RA) | |
| 14|-----to CP via Si------>| AAA |
| | | Req/Rep |
INTERNET-DRAFT Simple BNG CUSP
| | 15|<------------->|
| | | |
| | Create subscriber | |
| | session Request | |
| 16|<--------via Ci---------| |
| | Create subscriber | |
| | session Response | |
| 17|---------via Ci-------->| |
| | | |
| | Send Router Advertise | |
| | (RA) | |
| 18|<----to UP vis Si-------| |
| RA | | |
19|<--------------| | |
| | | |
|DHCPv6 Solicit | | |
20|-------------->| | |
| | Relay DHCPv6 Solicit | |
| 21|-----to CP via Si------>| |
| | | |
| | Update subscriber | |
| | session Request | |
| 22|<--------via Ci---------| |
| | Update subscriber | |
| | session Response | |
| 23|---------via Ci-------->| |
| | | Accounting |
| | 24|<------------->|
| | Send DHCPv6 Reply | |
| 25|<----to UP via Si-------| |
| DHCPv6 Reply | | |
26|<--------------| | |
| | | |
Figure 18: DHCP Dual Stack Access
The DHCP dual stack access includes three sets of Update_Request /
Update_Response exchanges to create/update DHCPv4/v6 subscriber
session.
1. Create DHCPv4 session (step 8 and 9)
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
2. Create DHCPv6 session (step 16 and 17)
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
3. Update DHCPv6 session (step 22 and 23)
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.1.6 L2 Static Subscriber Access
L2 static subscriber access processes are as follows:
RG UP CP AAA
| | | |
| | Static Subscriber | |
| | Detection Req. | |
| 1|<-----to UP via Ci------| |
| | Static Subscriber | |
| | Detection Rep. | |
| 2|------to UP via Ci----->| |
| ARP/ND(REQ) | | |
3.1|<--------------| | |
| ARP/ND(ACK) | | |
3.2|-------------->| | |
| | Relay the ARP/ND | |
| 3.3|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3.4|<------------->|
| | Create subscriber | |
| | session Request | |
INTERNET-DRAFT Simple BNG CUSP
| 3.5|<--------via Ci---------| |
| | Create subscriber | |
| | session Response | |
| 3.6|---------via Ci-------->| |
| | | |
| ARP/ND(REQ) | | |
4.1|-------------->| | |
| | Relay the ARP/ND | |
| 4.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 4.3|<------------->|
| | Create subscriber | |
| | session Request | |
| 4.4|<--------via Ci---------| |
| | Create subscriber | |
| | session Response | |
| 4.5|---------via Ci-------->| |
| ARP/ND(ACK) | | |
4.6|<--------------| | |
| | | |
| IP Traffic | | |
5.1|-------------->| | |
| | Relay the IP Traffic | |
| 5.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 5.3|<------------->|
| | Create subscriber | |
| | session Request | |
| 5.4|<--------via Ci-------->| |
| | Create subscriber | |
| | session Response | |
| 5.5|---------via Ci-------->| |
| | | |
| ARP/ND(REQ) | | |
5.6|<--------------| | |
| ARP/ND(ACK) | | |
5.7|-------------->| | |
| | | |
Figure 19: L2 Static Subscriber Access
For L2 static subscriber access, the process starts with a CP
installing a static subscriber detection list on an UP. The list
determines which subscribers will be detected. This is implemented
by exchanging Update_Request and Update_Response messages between CP
and UP. The format of the messages are as follows:
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header>
<IPv4 Static Subscriber Detect TLVs>
<IPv6 Static Subscriber Detect TLVs>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
For L2 Static subscriber access, there are three ways to trigger the
access process:
1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP
address, the access interface, and VLAN of the RG. The UP will
actively trigger the access flow by sending an ARP/ND packet to
the RG. If the RG is online, it will reply with an ARP/ND to the
UP. The UP will tunnel the ARP/ND to the CP through the Si. The
CP then triggers the authentication process. If the
authentication result is positive. The CP will create a
corresponding subscriber session on the UP.
2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as
option 1 (triggered by UP). The difference is that the RG will
actively send the ARP/ND to trigger the process.
3. Triggered by RG IP traffic (5.1-5.7): This is for the case where
the RG has the ARP/ND information, but the subscriber session on
the UP is lost (e.g., due to failure on the UP, or the UP
restarted). That means the RG may keep sending IP packets to the
UP. The packets will trigger the UP to start a new access
process.
From a subscriber session point of view, the procedures and the
message formats for the above three cases are the same, as follows:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.2 PPPoE
5.2.1 IPv4 PPPoE Access
The following figure shows the IPv4 PPPoE access call flow.
RG UP CP AAA
| | | |
| PPPoE Disc | PPPoE Disc | |
1|<------------->|<---------via Si------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create subscriber | |
| | session Request | |
| 5|<--------via Ci---------| |
| | | |
| | Create subscriber | |
| | session Response | |
| 6|---------via Ci-------->| |
| | | |
| | | Accounting |
| | 7|<------------->|
| | | |
Figure 20: IPv4 PPPoE Access
From the above sequence, step 1-4 are the standard PPPoE call flow.
The UP is responsible for redirecting the PPPoE control packets to
the CP or RG. The PPPoE control packets are transmitted between the
CP and UP through the Si.
After the PPPoE call flow, if the subscriber passed the AAA
authentication and authorization, the CP will create a corresponding
session on the UP through the Ci. The formats of the messages are as
follows:
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
5.2.2 IPv6 PPPoE Access
The following figure describes the IPv6 PPPoE access call flow.
RG UP CP AAA
| | | |
| PPPoE Disc | PPPoE Disc | |
1|<------------->|<--------via Si-------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IP6CP | PPP IP6CP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create subscriber | |
| | session Request | |
| 5|<--------via Ci---------| |
| | | |
| | Create subscriber | |
| | session Response | |
| 6|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
7|<------------->|<---------via Si------->| |
| | | |
| | Update subscriber | |
| | session Request | |
| 8|<--------via Ci---------| |
| | | |
| | Update subscriber | |
| | session Response | |
| 9|---------via Ci-------->| |
| | | |
INTERNET-DRAFT Simple BNG CUSP
| | | Accounting |
| | 10|<------------->|
| | | |
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
7'|<------------->|<---------via Si------->| |
| | | |
| | Update subscriber | |
| | session Request | |
| 8'|<---------via Ci--------| |
| | | |
| | Update subscriber | |
| | session Response | |
| 9'|---------via Ci-------->| |
| | | |
| | | Accounting |
| | 10'|<------------->|
| | | |
Figure 21: IPv6 PPPoE Access
From the above sequence, steps 1-4 are the standard PPPoE call flow.
The UP is responsible for redirecting the PPPoE control packets to
the CP or RG. The PPPoE control packets are transmitted between the
CP and UP through the Si.
After the PPPoE call flow, if the subscriber passed the AAA
authentication and authorization, the CP will create a corresponding
session on the UP through the Ci. The formats of the messages are as
follows:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Then, the RG will initialize a ND/DHCPv6 negotiation process with the
CP (see step 7 and 7'), after that, it will trigger an update (8-9,
8'-9') to the subscriber session. The formats of the update messages
are as follows:
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.2.3 PPPoE Dual Stack Access
The following figure shows a combination of IPv4 and IPv6 PPPoE
access call flow.
RG UP CP AAA
| | | |
|PPPoE Discovery| PPPoE Discovery | |
1|<------------->|<---------via Si------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create v4 subscriber | |
| | session Request | |
| 5|<--------via Ci---------| |
| | Create v4 subscriber | |
| | session Response | |
| 6|---------via Ci-------->| |
| | | Accounting |
| | 7|<------------->|
| PPP IP6CP | PPP IP6CP | |
4'|<------------->|<---------via Si------->| |
| | | |
| | Create V6 subscriber | |
| | session Request | |
| 5'|<--------via Ci---------| |
| | Create v6 subscriber | |
| | session Response | |
| 6'|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
INTERNET-DRAFT Simple BNG CUSP
8|<------------->|<---------via Si------->| |
| | | |
| | Update v6 subscriber | |
| | session Request | |
| 9|<---------via Ci--------| |
| | Update v6 subscriber | |
| | session Response | |
| 10|---------via Ci-------->| |
| | | Accounting |
| | 7'|<------------->|
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
8'|<------------->|<---------via Si------->| |
| | | |
| | Update v6 subscriber | |
| | session Request | |
| 9'|<--------via Ci---------| |
| | | |
| | Update v6 subscriber | |
| | session Response | |
| 10'|---------via Ci-------->| |
| | | |
| | | Accounting |
| | 7"|<------------->|
| | | |
Figure 22: PPPoE Dual Stack Access
PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE
access. The process is as above. The formats of the messages are as
follows:
1. Create an IPv4 PPPoE subscriber session (5-6)
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
2. Create an IPv6 PPPoE subscriber session (5'-6')
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
INTERNET-DRAFT Simple BNG CUSP
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10')
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.3 WLAN Access
The following figure shows the WLAN access call flow.
RG UP CP AAA WEB Server
| | | | |
| DHCP | | | |
| Discovery | | | |
1|------------>| | | |
| | DHCP | | |
| | Discovery | | |
| 2|-----via Si---->| AAA | |
| | DHCP Offer |<-------->| |
| 3|<----via Si-----| | |
| DHCP Offer | | | |
4|<------------| | | |
| DHCP | | | |
| Request | | | |
5|------------>| | | |
| | DHCP Request | | |
| 6|-----via Si---->| | |
| | | | |
| | Create session | | |
| | Request | | |
| 7|<----via Ci-----| | |
| | Create session | | |
| | Response | | |
| 8|----via Ci----->| | |
| | | | |
INTERNET-DRAFT Simple BNG CUSP
| | DHCP ACK | | |
| 9|<----via Si-----| | |
| | | | |
| DHCP ACK | | | |
10|<------------| | | |
| | | | |
| Subscriber | | | |
| HTTP Traffic| | | |
11|------------>|--> | | |
| | | WEB URL | | |
| Traffic | | Redirect | | |
| Redirection | | | | |
12|<------------|<-+ | | |
| | | |
| |
13|-----------------Redirect to Web server------------->|
| |
14|<----------------Push HTTP log-in page---------------|
| |
15|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 16|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 17|<-------->| |
| | | | |
| | Update session | | |
| | Request | | |
| 18|<----via Ci-----| | |
| | | | |
| | Update session | | |
| | Response | | |
| 19|-----via Ci---->| | |
| | | | |
Figure 23: WLAN Access
WLAN access starts with the DHCP dial-up process (steps 1-6), after
that the CP will create a subscriber session on the UP (steps 7-8).
The formats of the session creation messages are as follows:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
After step 10, the RG will be allocated an IP address and its first
HTTP packet will be redirected to a WEB server for subscriber
authentication (steps 11-17). After the WEB authentication, if the
result is positive, the CP will update the subscriber session by
using the following message exchanges:
IPv4 Case: <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case: <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.4 L2TP
5.4.1 L2TP LAC Access
RG UP(LAC) CP(LAC) AAA LNS
| | | | |
| PPPoE | PPPoE | | |
INTERNET-DRAFT Simple BNG CUSP
| Discovery | Discovery | | |
1|<---------->|<---via Si--->| | |
| | | | |
| PPP LCP | PPP LCP | | |
2|<---------->|<---via Si--->| | |
| | | AAA | |
|PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| |
3|<---------->|<---via Si--->|<------>| |
| | | | |
| PPP IPCP | PPP IPCP | | |
4|<---------->|<---via Si--->| | |
| | | | |
| | L2TP tunnel | | |
| | negotiation | | |
| | SCCRQ/ | | |
| | SCCRP/ | | |
| | SCCCN | | |
| 5|<---via Si--->| | |
| | /\ |
| | || forward |
| | \/ |
| |<-----------via routing---------->|
| | |
| | L2TP session | | |
| | negotiation | | |
| | ICRQ/ | | |
| | ICRP/ | | |
| | ICCN | | |
| 6|<---via Si--->| | |
| | /\ |
| | || forward |
| | \/ |
| |<-----------via routing---------->|
| | |
| | Create | | |
| | subscriber | | |
| | session | | |
| | Request | | |
| 7|<---via Ci----| | |
| | | | |
| | Create | | |
| | subscriber | | |
| | session | | |
| | Response | | |
| 8|----via Ci--->| | |
| | | | |
| |
| PAP/CHAP (Triggered by LNS) |
9|<-----------------via routing?---------------->|
| |
INTERNET-DRAFT Simple BNG CUSP
Figure 24: L2TP-LAC Access
Steps 1-4 are a standard PPPoE access process. After that the LAC-CP
starts to negotiate an L2TP session and tunnel with the LNS. After
the negotiation, the CP will create an L2TP LAC subscriber session on
the UP through the following messages:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<L2TP-LAC Subscriber TLV>
<L2TP-LAC Tunnel TLV>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.4.2 L2TP LNS IPv4 Access
RG LAC UP(LNS) AAA CP(LNS)
| | | | |
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | |
| | L2TP tunnel | L2TP tunnel |
| | negotiation | negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP session | L2TP session |
| | negotiation | negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create |
| | | subscriber |
| | | session |
| | | Request |
INTERNET-DRAFT Simple BNG CUSP
| | 6|<-----via Ci-------|
| | | Create |
| | | subscriber |
| | | session |
| | | Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| | | |
| |
| PPP IPCP |
10|<--------------------------------------------->|
| |
| | | Update |
| | | subscriber |
| | | session |
| | | Request |
| | 11|<-----via Ci-------|
| | | Update |
| | | subscriber |
| | | session |
| | | Response |
| | 12|------via Ci------>|
| | | |
Figure 25: IPv4 L2TP-LNS Access
In this case, the BNG is running as an LNS and separated into LNS-CP
and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When
the L2TP session and tunnel negotiations are finished, the LNS-CP
will create an L2TP LNS subscriber session on the LNS-UP. The format
of messages are as follows:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
INTERNET-DRAFT Simple BNG CUSP
After that, the LNS-CP will trigger an AAA authentication. If the
authentication result is positive, a PPP IPCP process will follow,
then the CP will update the session with the following message
exchanges:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
5.4.3 L2TP LNS IPv6 Access
RG LAC UP(LNS) AAA CP(LNS)
| | | | |
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | |
| | L2TP tunnel | L2TP tunnel |
| | negotiation | negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP session | L2TP session |
| | negotiation | negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create |
INTERNET-DRAFT Simple BNG CUSP
| | | subscriber |
| | | session |
| | | Request |
| | 6|<-----via Ci-------|
| | | Create |
| | | subscriber |
| | | session |
| | | Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| | | | |
| |
| PPP IP6CP |
10|<--------------------------------------------->|
| |
| | | Update |
| | | subscriber |
| | | session |
| | | Request |
| | 11|<-----via Ci-------|
| | | Update |
| | | subscriber |
| | | session |
| | | Response |
| | 12|------via Ci------>|
| | | |
| | |
| ND negotiation | ND negotiation |
13|<------------------------->|<-----via Si------>|
| | |
| | | Update |
| | | subscriber |
| | | session |
| | | Request |
| | 14|<-----via Ci-------|
| | | Update |
| | | subscriber |
| | | session |
| | | Response |
| | 15|------via Ci------>|
| | | |
Figure 26: L2TP-LNS IPv6 Access
INTERNET-DRAFT Simple BNG CUSP
Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5
finish the normal L2TP dial-up process. When the L2TP session and
tunnel negotiations are finished, the LNS-CP will create an L2TP LNS
subscriber session on the LNS-UP. The format of the messages is as
follows:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
After that, the LNS-CP will trigger a AAA authentication. If the
authentication result is positive, a PPP IP6CP process will follow,
then the CP will update the session with the following message
exchanges:
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Then, an ND negotiation will be triggered by the RG. After the ND
negotiation, the CP will update the session with the following
message exchanges:
<Update_Request Message> ::= <Common Header>
<L2TP-LAC Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
5.5 CGN (Carrier Grade NAT)
RG UP CP AAA
| | | |
| | Public Address Block | |
| | Allocation Request | |
| 1|<--------via Ci-------->| |
| | Public Address Block | |
| | Allocation Reply | |
| 2|---------via Ci-------->| |
| | | |
| Subscriber | | |
| access request| Subscriber | |
3|-------------->| access request | |
| 4|----------via Si------->| |
| | | AAA |
| | Subscriber | Req/Rep |
| Subscriber | access reply 5|<------------->|
| access reply 6|<---------via Si--------| |
7|<--------------| | |
| | | |
| | Create subscriber | |
| | session Request | |
| 8|<--------via Ci---------| |
| | | |
| | Create subscriber | |
| | session Response | |
| | (with NAT information) | |
| 9|---------via Ci-------->| |
| | | |
| | | Accounting |
| | | with source |
| | | information |
| | 10|<------------->|
| | | Public IP + |
| | | Port range |
| | | to Private IP|
| | | mapping |
| | | |
Figure 27: CGN Access
The first steps allocate one or more CGN address blocks to the UP
(steps 1-2). This is achieved by the following message exchanges
between CP and UP.
INTERNET-DRAFT Simple BNG CUSP
<Addr_Allocation_Req Message> ::= <Common Header>
<Request Address Allocation TLV>
<Addr_Allocation_Ack Message> ::= <Common Header>
<Address Assignment Response TLV>
Steps 3-9 show the general dial-up process in the case of CGN mode.
The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in
above sections.
If a subscriber is a CGN subscriber, once the subscriber session is
created/updated, the UP will report the NAT information to the CP.
This is achieved by carrying the "Subscriber CGN Port Range TLV" in
the Update_Response message.
5.6 L3 Leased Line Access
5.6.1 Web Authentication
RG UP CP AAA WEB Server
| | | | |
| User | | | |
| traffic | | | |
1|------------>| | | |
| | User | | |
| | traffic | | |
| 2|-----via Si---->| AAA | |
| | | Req/Rep | |
| | 3|<-------->| |
| | Create session | | |
| | Request | | |
| 4|<----via Ci-----| | |
| | | | |
| | Create session | | |
| | Response | | |
| 5|----via Ci----->| | |
| HTTP | | | |
| traffic | | | |
6|------------>| | | |
| | | | |
| Redirect to | | | |
| Web URL | | | |
7|<------------| | | |
| | | | |
| |
8|-----------------Redirected to Web server----------->|
INTERNET-DRAFT Simple BNG CUSP
| |
9|<----------------Push HTTP Log-in page---------------|
| |
10|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 11|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 12|<-------->| |
| | | | |
| | | | |
| | Update session | | |
| | Request | | |
| 13|<----via Ci-----| | |
| | | | |
| | Update session | | |
| | Response | | |
| 14|----via Ci----->| | |
| | | | |
Figure 28: Web Authentication based L3 Leased Line Access
In this case, IP traffic from the RG will trigger the CP to
authenticate the RG by checking the source IP and the exchanges with
the AAA server. Once the RG passed the authentication, the CP will
create a corresponding subscriber session on the UP through the
following message exchanges:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
Then, the HTTP traffic from the RG will be redirected to a WEB server
to finish the WEB authentication. Once the WEB authentication is
passed, the CP will trigger another AAA authentication. After the
AAA authentication, the CP will update the session with the following
message exchanges:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.6.2 User Traffic Trigger
RG UP CP AAA
| | | |
| | L3 access | |
| | control list | |
| 1|<----via Ci-----| |
| User | | |
| traffic | | |
2|------------>| | |
| | User | |
| | traffic | |
| 3|-----via Si---->| |
| | | AAA |
| | | Req/Rep |
| | 4|<-------->|
| | | |
| | Create session | |
| | Request | |
| 5|<----via Ci-----| |
| | Create session | |
INTERNET-DRAFT Simple BNG CUSP
| | Response | |
| 6|----via Ci----->| |
| | | |
Figure 29: User Traffic Triggered L3 Leased Line Access
In this user traffic triggered case, the CP must install an access
control list on the UP, which is used by the UP to determine whether
an RG is legal or not. If the traffic is from a legal RG, it will be
redirected to the CP though the Si. The CP will trigger a AAA
interchange with the AAA server. After that, the CP will create a
corresponding subscriber session on the UP with the following message
exchanges:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
5.7 Multicast Access
RG UP CP AAA
| | | |
| User access | User access | AAA |
| request | request | Req/Rep |
1|<----------->|<----via Si---->|<-------->|
| | User | |
| | | |
| | | |
| | Create session | |
| | Request | |
| 2|<----via Ci---->| |
INTERNET-DRAFT Simple BNG CUSP
| | | |
| | Create session | |
| | Response | |
| 3|----via Ci----->| |
| | | |
| Multicast | | |
| negotiation | | |
4|<----------->| | |
| | | |
Figure 30: Multicast Access
Multicast access starts with an user access request from the RG. The
request will be redirected to the CP by the Si. A follow-up AAA
interchange between the CP and the AAA server will be triggered.
After the authentication, the CP will create a multicast subscriber
session on the UP through the following messages:
IPv4 Case:
<Update_Request Message> ::= <Common Header>
<Multicast Group Information TLV>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
<Update_Request Message> ::= <Common Header>
<Multicast Group Information TLV>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
6. S-CUSP Message Formats
An S-CUSP message consists of a common header followed by a variable- An S-CUSP message consists of a common header followed by a variable-
length body consisting entirely of TLVs. Receiving an S-CUSP message length body consisting entirely of TLVs. Receiving an S-CUSP message
with a missing mandatory TLV MUST trigger an Error message (see with an unknown message type or missing mandatory TLV MUST trigger an
Section 5.6). Conversely, if a TLV is optional, the TLV may or may Error message (see Section 6.7) or a response message with an Error
not be present. Information TLV (see Section 7.6).
Conversely, if a TLV is optional, the TLV may or may not be present.
Optional TLVs are indicated in the message formats shown in this
document by being enclosed in square brackets.
This section specifies the format of the common S-CUSP message header
and lists the defined messages.
Network byte order is used for all multi-byte fields. Network byte order is used for all multi-byte fields.
4.1 Common Message Header 6.1 Common Message Header
Common header: S-CUSP Common Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Resv | Message-Type | Message-Length | | Ver | Resv | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Transaction-ID | | Reserved | Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S-CUSP Message Common Header Figure 6.1: S-CUSP Message Common Header
Ver (4 bits): The major version of the protocol. This document o Ver (4 bits): The major version of the protocol. This document
specifies version 1. Different major versions of the specifies version 1. Different major versions of the protocol
protocol may have significantly different message may have significantly different message structure and format
structure and format except that the Ver field will except that the Ver field will always be in the same place at
always be in the same place at the beginning of each the beginning of each message. A successful S-CUSP session
message. A successful S-CUSP session depends on the CP depends on the CP and the UP both using the same major version
and UP both using the same major version of the of the protocol.
protocol.
Resv (4 bits): Reserved. MUST be sent as zero and ignored on o Resv (4 bits): Reserved. MUST be sent as zero and ignored on
receipt. receipt.
Message-Type (8 bits): The set of message types specified in this o Message-Type (8 bits): The set of message types specified in
document is listed in Section 12.2.1. this document is listed in Section 9.1.
Message-Length (16 bits): Total length of the CUSP message o Message-Length (16 bits): Total length of the S-CUSP message
including the common header, expressed in number of including the common header, expressed in number of bytes as an
bytes as an unsigned integer. unsigned integer.
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
Transaction ID (16 bits): This field is used to identify o Transaction ID (16 bits): This field is used to identify
requests. It is echoed back in any corresponding ACK / requests. It is echoed back in any corresponding ACK / response
response / Error message. / Error message. It is RECOMMENDED that a monotonically
increasing value be used in successive message and that value
wrap back to zero after 0xFFFF. The contents of this field is
an opaque value that the receiver MUST NOT use for any purpose
except to echo back in a corresponding response and,
optionally, for logging.
4.1.1 Control Messages 6.2 Control Messages
Control messages are listed below. This document defines the following control messages:
Type Name Notes and TLVs that can be carried Type Name Notes and TLVs that can be carried
---- ---- ------------------------------------ ---- ---- ------------------------------------
1 Hello Capability negotiation. 1 Hello Hello TLV, Keep-Alive TLV.
2 Keepalive Keepalive. 2 Keepalive A common header with the Keepalive message
3 Synch_Request Synchronization request. type.
4 Sync_Begin Synchronization starts. 3 Sync_Request Synchronization request.
5 Sync_Data Synchronization data: TLVs specified in 4 Sync_Begin Synchronization starts.
5 Sync_Data Synchronization data: TLVs specified in
Section 5. Section 5.
6 Sync_End End synchronization. 6 Sync_End End synchronization.
7 Update_Request TLVs specified in Sections 7.6-7.9.
8 Update_Response TLVs specified in Sections 7.6-7.9.
4.1.2 Table Messages 6.2.1 Hello Message
Table messages are listed below. Hello message is used for S-CUSP session establishment and version
negotiation. The detail of S-CUSP session establishment and version
negotiation can be found in Section 4.1.1.
Type Name Notes and TLVs that can be carried The format of Hello message is as follows:
---- ---- ------------------------------------
7 Update_Request TLVs specified in Section 5.
8 Update_Response TLVs specified in Section 5.
4.1.3 Resource Reporting Message <Hello Message> ::= <Common Header>
<Hello TLV>
<Keepalive TLV>
[<Error Information TLV>]
The Resource Reporting message is as follows: The return code and negotiation result will be carried in the Error
Information TLV. They are listed as follows:
Type Name Notes and TLVs that can be carried 0: Success, version negotiation success.
---- ---- ------------------------------------
9 Report Interface-Info, Board-Info.
4.1.4 Event Reporting Message 1: Failure, malformed message received.
The Event Reporting message is as follows: INTERNET-DRAFT Simple BNG CUSP
Type Name Notes and TLVs that can be carried 2: One or more of the TLVs was not understood.
---- ---- ------------------------------------
10 Event Traffic-Info, Detect-Info.
INTERNET-DRAFT BNG Simple CUSP 1001: The version negotiation fails. The S-CUSP session
establishment phase fails.
4.1.5 Vendor Message 1002: The keepalive negotiation fails. The S-CUSP session
establishment phase fails.
The Vendor message is as follows: 1003: The establishment timer expires. session establishment
phase fails.
Type Name Notes and TLVs that can be carried 6.2.2 Keepalive Message
---- ---- ------------------------------------
11 Vendor Vendor-Defined, any other TLV(s) as
implemented by the vendor.
4.1.6 Resource Allocation Messages The Keepalive message is periodically sent by each end of an S-CUSP
session. It is used to detect whether the peer end is still alive.
The Keepalive procedures are defined Section 4.1.2.
The Resource Allocation messages are listed below. The format of the Keepalive message is as follows:
Type Name Notes and TLVs that can be carried <Keepalive Message> ::= <Common Header>
---- ---- ------------------------------------
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 6.2.3 Sync_Request Message
CUSP messages consist of the common header specified in Section 4.1 The Sync_Request message is used to request synchronization from an
S-CUSP peer. Both CP and UP can request their peer to synchronize
data.
The format of the Sync_Request message is as follows:
<Sync_Request Message> ::= <Common Header>
A Sync_Request message may result in a Sync_Begin message from its
peer. The Sync_Begin message is defined in Section 6.2.4.
6.2.4 Sync_Begin Message
The Sync_Begin message is a reply to a Sync_Request message. It is
used to notify the synchronization requester whether the
synchronization can be started.
The format of Sync_Begin message is as follows:
<Sync_Begin Message> ::= <Common Header>
<Error Information TLV>
INTERNET-DRAFT Simple BNG CUSP
The return codes are carried in the Error Information TLV. The codes
are listed below:
0: Success, be ready to synchronize.
1: Failure, malformed message received.
2: One or more of the TLVs was not understood.
2001: Synch-NoReady. The data to be synchronized is not ready.
2002: Synch-Unsupport. The data synchronization is not supported.
6.2.5 Sync_Data Message
The Sync_Data message is used to send data being synchronized between
the CP and UP. The Sync_Data message has the same function and
format as the Update_Request message. The difference is that there
is no ACK for a Sync_Data message. An error caused by the Sync_Data
message will result in a Sync_End message.
There are two scenarios:
Synchronization from UP to CP: Synchronize the resource data to
CP.
<Sync_Data Message> ::= <Common Header>
[<Resource Reporting TLVs>]
Synchronization from CP to UP: Synchronize all subscriber sessions
to UP. As for which TLVs should be carried, it depends on the
specific session data to be synchronized. This is equivalent to
create the specific session. Refer to Section 5 to see more
details.
<Sync_Data Message> ::= <Common Header>
[<User Routing TLVs>]
[<User Information TLVs>]
[<L2TP Subscriber TLVs>]
[<Subscriber CGN Port Range TLV>]
[<Subscriber Policy TLV>]
6.2.6 Sync_End Message
The Sync_End message is used to indicate the end of a synchronization
process. The format of a Sync_End message is as follows:
INTERNET-DRAFT Simple BNG CUSP
<Sync_End Message> ::= <Common Header>
<Error Information TLV>
The return/error codes are listed as follows:
0: Success, synchronization finished.
1: Failure, malformed message received.
2: One or more of the TLVs was not understood.
6.2.7 Update_Request Message
The Update_Request message is a multi-task message, it can be used to
create, update, and delete subscriber sessions on a UP.
For session operations, the specific operation is controlled by the
"Oper" field of the carried TLVs. As defined in Section 7.1, the
"Oper" can be set to either "update" or "delete" when a TLV is
carried in an Update_Request message.
When the "Oper" set to update, it means to create or update a
subscriber session, if the "Oper" set to delete, it indicates to
delete a corresponding session on an UP.
The format of Update_Request message is as follows:
<Update_Request Message> ::= <Common Header>
[<User Routing TLVs>]
[<User Information TLVs>]
[<L2TP Subscriber TLVs>]
[<Subscriber CGN Port Range TLV>]
[<Subscriber Policy TLV>]
Each Update_Request message will result in an Update_Response message
that is defined in Section 6.2.8.
6.2.8 Update_Response Message
The Update_Response message is a response to an Update_Request
message. It is used to confirm the update request (or reject it in
the case of an error). The format of an Update_Response message is
as follows:
INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header>
[<Subscriber CGN Port Range TLV>]
<Error Information TLV>
The return/error codes are carried in the Error Information TLV.
They are listed as follows:
0: Success.
1: Failure, malformed message received.
2: One or more of the TLVs was not understood.
3001(Pool-Mismatch): The corresponding address pool cannot be
found.
3002 (Pool-Full): The address pool is fully allocated and no
address segment is available.
3003 (Subnet-Mismatch): The address pool subnet cannot be found.
3004 (Subnet-Conflict): Subnets in the address pool have been
classified into other clients.
4001 (Update-Fail-No-Res): The forwarding table fails to be
delivered because the forwarding resources are insufficient.
4002 (QoS-Update-Success): The QoS policy takes effect.
4003 (QoS-Update-Sq-Fail): Failed to process the queue in the QoS
policy.
4004 (QoS-Update-CAR-Fail): Processing of the CAR in the QoS
policy fails.
4005 (Statistic-Fail-No-Res): Statistics processing failed due to
insufficient statistics resources.
6.3 Event Message
The Event message is used to report subscriber session traffic
statistics and detection information. The format of Event message is
as follows:
<Event Message> ::= <Common Header>
[<User Traffic Statistics Report TLV>]
[<User Detection Result Report TLV>]
INTERNET-DRAFT Simple BNG CUSP
6.4 Report Message
The Report message is used to report board and interface status on a
UP. The format of Report message is as follows:
<Report Message> ::= <Common Header>
[<Board Status TLVs>]
[<Interface Status TLVs>]
6.5 CGN Messages
This document defines the following resource allocation messages:
Type Message Name TLV that is carried
---- ------------------- ------------------------
200 Addr_Allocation_Req Address Allocation Request
201 Addr_Allocation_Ack Address Allocation Response
202 Addr_Renew_Req Address Renewal Request
203 Addr_Renew_Ack Address Renewal Response
204 Addr_Release_Req Address Release Request
205 Addr_Release_Ack Address Release Response
6.5.1 Addr_Allocation_Req Message
The Addr_Allocation_Req message is used to request CGN address
allocation. The format of Addr_Allocation_Req message is as follows:
<Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV>
6.5.2 Addr_Allocation_Ack Message
The Addr_Allocation_Ack message is a response to an
Addr_Allocation_Req message. The format of Addr_Allocation_Ack
message is as follows:
<Addr_Allocation_Ack Message> ::= <Common Header>
<Address Allocation Response TLV>
INTERNET-DRAFT Simple BNG CUSP
6.5.3 Addr_Renew_Req Message
The Addr_Renew_Req message is used to request address renewal. The
format of Addr_Renew_Req message is as follows:
<Addr_Renew_Req Message> ::= <Common Header>
<Address Renewal Request TLV>
6.5.4 Addr_Renew_Ack Message
The Addr_Renew_Ack message is a response to an Addr_Renew_Req
message. The format of Addr_Renew_Req message is as follows:
<Addr_Renew_Ack Message> ::= <Common Header>
<Address Renewal Response TLV>
6.5.5 Addr_Release_Req Message
The Addr_Release_Req message is used to request address release. The
format of Addr_Release_Req message is as follows:
<Addr_Release_Req Message> ::= <Common Header>
<Address Release Request TLV>
6.5.6 Addr_Release_Ack Message
The Addr_Release_Ack message is a response to an Addr_Release_Req
message. The format of Addr_Release_Ack message is as follows:
<Addr_Release_Ack Message> ::= <Common Header>
<Address Release Response TLV>
6.6 Vendor Message
The Vendor message is, in conjunction with the vendor TLV and vendor
sub-TLV, can be used by vendors to extend the S-CUSP protocol. It's
message type is 11. If the receiver does not recognize the message,
an Error message will be returned to the sender.
INTERNET-DRAFT Simple BNG CUSP
The format of the Vendor message is as follows:
<Vendor Message> ::= <Common Header>
<Vendor TLV>
[<any other TLVs as specified by the vendor>]
6.7 Error Message
The Error message is defined to return some critical error
information to the sender. If a receiver does not know the message
type of a received message, it MUST return an Error message to the
sender.
The format of the Error message is as below:
<Error Message> ::= <Common Header>
<Error Information TLV>
INTERNET-DRAFT Simple BNG CUSP
7. S-CUSP TLVs and Sub-TLVs
This section specifies the following:
o the format of the TLVs that appear in S-CUSP messages,
o the format of the sub-TLVs that appear within the values of some
TLVs, and
o the format of some basic data fields that appear within TLVs or
sub-TLVs.
See Section 9 for a list of all defined TLVs and sub-TLVs.
7.1 Common TLV Header
S-CUSP messages consist of the common header specified in Section 6.1
followed by TLVs formatted as specified in this section. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper | TLV-Type | TLV-Length | | Oper | TLV-Type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Oper (4 bits): For Message-Types that indicate an operation on a Figure 32: Common TLV Header
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 o Oper (4 bits): For Message-Types that indicate an operation on a
format of the Value part, are determined by the TLV- data set, the Oper field is interpreted as Update, Delete, or
Type of the TLV. See Section 12.2.2. Reserved as specified in Section 9.3. For all other Message-Types,
the Oper field MUST be sent as zero and ignored on receipt.
INTERNET-DRAFT BNG Simple CUSP o TLV-Type (12 bits): The Type of a TLV, that is the meaning and
format of the Value part, are determined by the TLV-Type of the
TLV. See Section 9.2.
TLV-Length (2 bytes): The length of the Value portion of the TLV o TLV-Length (2 bytes): The length of the Value portion of the TLV
in bytes as an unsigned integer. in bytes as an unsigned integer.
Value (variable length): This is the value portion of the TLV o Value (variable length): This is the value portion of the TLV
whose size is given by TLV-Length. whose size is given by TLV-Length. The value portion consists of
fields, frequently using one of the basic data field types (see
Section 7.2) and sub-TLVs (see Section 7.3).
4.3 Basic Data Fields INTERNET-DRAFT Simple BNG CUSP
7.2 Basic Data Fields
This section specifies the binary format of several standard basic This section specifies the binary format of several standard basic
data fields that are used within other data structures in this data fields that are used within other data structures in this
specification. specification.
STRING o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section
0 to 255 octets. Will be encoded as a sub-TLV (see Section 7.3) to provide the length. The use of this data type in S-CUSP is
4.4) to provide the length. to provide convenient labels for use by network operators in
configuring and debugging their networks and interpreting S-CUSP
messages. These labels will not normally be seen by subscribers.
They are normally interpreted as ASCII [RFC20].
MAC-Addr o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042].
6 octets. Ethernet MAC Address.
IPv4 Address o IPv4-Address: 8 octets. 4 octets of the IPv4 address value
8 octets. 4 octets of the IPv4 address value followed by a followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX.
4 octet address mask in the format XXX.XXX.XXX.XXX.
IPv6 Address o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4
20 octets. 16 octets of IPv6 address followed by a 4 octet octet integer n in the range of 0 to 128 which gives the address
integer n in the range of 0 to 128 which gives the address mask as the one's complement of 2**(128-n) - 1.
mask as the one's complement of 2**(128-n) - 1.
VLAN ID o VLAN ID: 2 octets. As follows [802.1Q]:
2 octets. As follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRI |D| VLAN-ID | | PRI |D| VLAN-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PRI: Priority. Default value 7. PRI: Priority. Default value 7.
D: Drop Eligibility Indicator (DEI). Default value 0. D: Drop Eligibility Indicator (DEI). Default value 0.
VLAN-ID: Unsigned integer in the range 1-4094. VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are
not valid VLAN IDs [802.1Q].)
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
4.4 Sub-TLV Format and Specific Sub-TLVs 7.3 Sub-TLV Format and Sub-TLVs
In some cases, the Value portion of a TLV, as specified above, can In some cases, the Value portion of a TLV, as specified above, can
contain one or more Sub-TLVs formatted as follows: contain one or more Sub-TLVs formatted as follows:
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Type (2 bytes): The Type of a Sub-TLV, that is the meaning and Figure 33: Sub-TLV Header
format of the Value part, are determined by the Type
of the TLV. Sub-TLV Types numbers have the same
meaning regardless of the TLV Type of the TLV within
which the Sub-TVL occurs. See Section 12.2.4.
Length (2 bytes): The length of the Value portion of the TLV in o Type (2 bytes): The Type of a Sub-TLV, that is the meaning and
bytes as an unsigned integer. format of the Value part, are determined by the Type of the
TLV. Sub-TLV Types numbers have the same meaning regardless of
the TLV Type of the TLV within which the sub-TLV occurs. See
Section 9.4.
Value (variable length): This is the value portion of the TLV o Length (2 bytes): The length of the Value portion of the sub-
whose size is given by Length. TLV in bytes as an unsigned integer.
The sub-TLVs currently specified are specified in the following o Value (variable length): This is the value portion of the sub-
subsections. TLV whose size is given by Length.
4.4.1 VRF-Name The sub-TLVs currently specified are defined in the following
subsections.
The name of the VRF (Virtual Routing and Forwarding instance) that 7.3.1 Name sub-TLVs
the BNG user accesses. Optional.
Sub-TLV Type: 1, VRF Name This document defines the following name sub-TLVs that are used to
Length: 1-255 octets. carry the name of the corresponding object. The length of each of
Value: STRING. these sub-TLV is variable from 1 to 255 octets. The value is of type
STRING padded with zeros octets to 4-octet alignment.
4.4.2 Ingress-QoS-Profile Type Sub-TLV Name Meaning
----- -------------------- -------------------
1 VRF-Name The name of a VRF
2 Ingress-QoS-Profile The name of an ingress QoS profile
3 Egress-QoS-Profile The name of an egress QoS profile
4 User-ACL-Policy The name of an ACL policy
5 Multicast-ProfileV4 The name of an IPv4 multicast profile
6 Multicast-ProfileV6 The name of an IPv6 multicast profile
7 NAT-Instance The name of a NAT instance
8 Pool-Name The name of an address pool
Indicates the upstream QoS Profile Name. Optional. INTERNET-DRAFT Simple BNG CUSP
Sub-TLV Type: 2, Ingress QoS Profile Name 7.3.2 Ingress-CAR sub-TLV
Length: 1-255 octets.
Value: STRING.
INTERNET-DRAFT BNG Simple CUSP The Ingress-CAR sub-TLV indicates the authorized upstream Committed
Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR
sub-TLV is 9 and the sub-TLV length is 16. The format is as shown in
Figure 34.
4.4.3 Egress-QoS-Profile 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Indicates the downstream QoS Profile Name. Optional. Figure 34: Ingress-CAR sub-TLV
Sub-TLV Type: 3, Egress QoS Profile Name Where:
Length: 1-255 octets.
Value: STRING.
4.4.4 User-ACL-Policy CIR (4 bytes): Guaranteed rate in bits/second.
Indicates the name of the ACL policy group to which the user belongs. PIR (4 bytes): Burst rate in bits/second.
Optional.
Sub-TLV Type: 4, User ACL Policy Name CBS (4 bytes): The token bucket in bytes.
Length: 1-255 octets.
Value: STRING.
4.4.5 Multicast-Profile-v4 PBS (4 bytes): Burst token bucket in bytes.
Name of the IPv4 multicast program list a user can order. Optional. These fields are unsigned integers. More details about CIR, PIR, CBS,
and PBS can be found in [RFC2698].
Sub-TLV Type: 5, Multicast Profile of IPv4. 7.3.3 Egress-CAR sub-TLV
Length: 1-255 octets.
Value: STRING.
4.4.6 Multicast-Profile-v6 The Egress-CAR sub-TLV indicates the authorized downstream Committed
Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub-
TLV is 10 and its sub-TLV length is 16 octets. The format of the
value part is as defined below.
Name of the IPv6 multicast program list a user can order. Optional. INTERNET-DRAFT Simple BNG CUSP
Sub-TLV Type: 6, Multicast Profile of IPv6. 0 1 2 3
Length: 1-255 octets. 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
Value: STRING. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.7 Ingress-CAR Figure 35: Egress-CAR sub-TLV
Indicates the authorized upstream Committed Access Rate (CAR) Where:
parameters. Optional.
Sub-TLV Type: 7, Ingress CAR. CIR (4 bytes): Guaranteed rate in bits/second.
Length: 16 Octets.
Value: The following four fields in the order given:
INTERNET-DRAFT BNG Simple CUSP PIR (4 bytes): Burst rate in bits/second.
Name Type Description CBS (4 bytes): The token bucket in bytes.
------ ------- ---------------------------------
CIR 4 bytes Guaranteed rate in bits/second.
PIR 4 bytes Burst rate in bits/second.
CBS 4 bytes The token bucket in bytes.
PBS 4 bytes Burst token bucket in bytes.
4.4.8 Egress-CAR PBS (4 bytes): Burst token bucket in bytes.
Indicates the authorized downstream Committed Access Rate (CAR) These fields are unsigned integers. More details about CIR, PIR, CBS,
parameters. Optional. and PBS can be found in [RFC2698].
Sub-TLV Type: 8, Egress CAR. 7.3.4 If-Desc sub-TLV
Length: 16 Octets.
Value: The following four fields in the order given:
Name Type Description The If-Desc sub-TLV is defined to designate an interface. It is an
------ ------- --------------------------------- optional sub-TLV that may be carried in those TLVs that have an "if-
CIR 4 bytes Guaranteed rate in bits/second. index" or "out-if-index" field. The If-Desc sub-TLV is used as a
PIR 4 bytes Burst rate in bits/second. local unique identifier within a BNG.
CBS 4 bytes The token bucket in bytes.
PBS 4 bytes Burst token bucket in bytes.
4.4.9 NAT-Instance The sub-TLV type is 11 and the sub-TLV length is 12 octets. The
format depends on the If-Type. The format of the value part is as
follows:
Name of the Network Address Translation (NAT) Instance to which the INTERNET-DRAFT Simple BNG CUSP
user belongs. Optional.
Sub-TLV Type: 9, NAT Instance Name. 0 1 2 3
Length: 1-255 octets. 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
Value: STRING. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (1-5)| Chassis | Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Slot | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc sub-TLV (Physical Port)
4.4.10 Pool-Name 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (6-7) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logic-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc sub-TLV (Virtual Port)
Indicates the name of the address pool to which the public network Figure 36: If-Desc sub-TLV Formats
segment belongs. Optional.
Sub-TLV Type: 10, IP Address Pool Name. Where:
Length: 1-255 octets.
Value: STRING.
INTERNET-DRAFT BNG Simple CUSP If-Type: 8 bits in length, indicates the type of an interface.
Following types are defined in this document:
4.4.11 If-Desc 0: Reserved
1: Fast Ethernet (FE)
2: GE
3: 10GE
4: 100GE
5: Eth-Trunk
6: Tunnel
7: VE
8-255: Reserved.
Description of an interface. Mandatory. Chassis (8 bits): Identifies the chassis that the interface
belongs to.
Sub-TLV Type: 11, Interface Description Slot (16 bits): Identifies the slot that the interface belongs to.
Length: 12
Value: Several fields structured as follows:
0 1 2 3 Sub-slot (16 bits): Identifies the sub-slot the interface belongs
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 to.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type 4 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chassis | 1 byte
+-+-+-+-+-+-+-+-+
| Slot | 1 byte
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Information | 2 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number 4 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Type: Interface Type: Port Number (16 bits): An identifier of a physical port/interface
0 = Reserved, 1 = FE, 2 = GE, 3 = 10GE, 4 = 100GE, 5: Eth- (e.g., If-Type: 1-5). It is locally significant within the
Trunk, 6: Tunnel, 7: VE slot/sub-slot.
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
INTERNET-DRAFT BNG Simple CUSP INTERNET-DRAFT Simple BNG CUSP
5. Basic TLVs Sub-port Number (32 bits): An identifier of the sub-port. Locally
significant within its "parent" port (physical or virtual).
This section describes basic TLVs. Logic-ID (32 bits): An identifier of a virtual interface (e.g.,
If-Type: 6-7)
5.1 Interface Information TLV 7.3.5 IPv6 Address List sub-TLV
The Interface Information TLV can be used by a CP to control the The IPv6 Address List sub-TLV is used to convey one or more IPv6
access mode, authentication methods, and other related functions of addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV
an interface. type is 12, the sub-TLV length is variable.
The format of the Interface Information TLV value part is as below: The format of IPv6 Addresses sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1: Interface Information TLV Figure 37: IPv6 Address List sub-TLV
Function: Service information about the user access interface Where:
on the BNG.
TLV Type: 1
TLV Length: variable
TLV fields: IP Address (IPv6-Address): Each IP Address is an IP-Address type,
If-Index: 4 bytes in length, a unique identifier of an interface carries an IPv6 address.
of a BNG.
Access-Mode: 1 byte in length, indicates the access mode of the
interface; this document defines following values:
0: Layer 2 subscriber;
1: Layer 3 subscriber;
2: Layer 2 leased line;
3: Layer 3 leased line;
4-255: Reserved.
Auth-Method4: 1 byte in length, for IPv4 scenario, indicates the 7.3.6 Vendor sub-TLV
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;
INTERNET-DRAFT BNG Simple CUSP The Vendor sub-TLV is intended to be used inside the value portion of
the Vendor TLV (Section 7.13). It provides a Sub-Type that
effectively extends the sub-TLV type in the sub-TLV header and
provides for versioning of vendor sub-TLVs.
0x2: DOT1X authentication; The value part of the Vendor sub-TLV is formatted as follows:
0x4: Web authentication;
0x8: Web fast authentication;
0x10: Binding authentication.
Auth-Method6: 1 byte in length, for IPv6 scenario, indicates the INTERNET-DRAFT Simple BNG CUSP
authentication on this interface; this field is defined
as a bitmap, this document defines following values
(other bits are reserved and MUST be sent as zero and
ignored on receipt):
0x1: PPPoE authentication;
0x2: DOT1X authentication;
0x4: Web authentication;
0x8: Web fast authentication;
0x10: Binding authentication;
The flags field is defined as below: 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ value (other as specified by vendor) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: Vendor sub-TLV
Where:
The sub-TLV type: 13.
The sub-TLV length: variable.
Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865].
Sub-Type (2 bytes): Used by the Vendor to distinguish multiple
different sub-TLVs.
Sub-Type-Version (2 bytes): Used by the Vendor to distinguish
different versions of a Vendor Defined sub-TLV sub-Type.
value: as specified by the vendor.
Since Vendor code will be handling the sub-TLV after the Vendor ID
field is recognized, the remainder of the sub-TLV can be organized
however the vendor wants. But it desirable for a vendor to be able to
define multiple different vendor sub-TLVs and to keep track of
different versions of its vendor defined sub-TLVs. Thus, it is
RECOMMENDED that the vendor assign a Sub-Type value for each of that
vendor's sub-TLVs that is different from other Sub-Type values that
vendor has used. Also, when modifying a vendor defined sub-TLV in a
way potentially incompatible with a previous definition, the vendor
SHOULD increase the value it is using in the Sub-Type-Version field.
INTERNET-DRAFT Simple BNG CUSP
7.4 The Hello TLV
The Hello TLV is defined to be carried in the Hello message for
version and capabilities negotiation. It indicates the S-CUSP sub-
version and capabilities supported. The format of Hello TLV is as
follows:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |Y|X|P|I|N|A|S|F| | VerSupported |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.2: Interface Flags Figure 39: Hello TLV
Where: Where:
F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a The TLV type is 100.
subscriber go to online.
1: enabled, 0: disabled.
S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a The TLV length is 12 octets.
subscriber go to online.
1: enabled, 0: disabled.
A (ARP Trigger) bit: Indicates whether ARP packets can trigger a The value field consists of three parts:
subscriber go to online.
1: enabled, 0: disabled.
N (ND Trigger) bit: Indicates whether ND packets can trigger a VerSupported: 32 bits in length. This is a bit map of the Sub-
subscriber go to online. Versions of the S-CUSP protocol that the sender supports. This
1: enabled, 0: disabled. document specifies Sub-Version zero of Major Version 1, that
is, Version 1.0. The VerSupported field MUST be non-zero. The
VerSupported bits are numbered from 0 as the most significant
bit. Bit 0 indicates support of Sub-Version zero, bit 1
indicates support of Sub-Version one, etc.
I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable traffic Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS
detection. 0: Disable traffic detection. [RFC2865].
P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable traffic Capabilities: 32 bits in length. Flags that indicate the
detection. 0: Disable traffic detection. support of particular capabilities by the sender of the Hello.
No Capabilities are defined in this document and so
implementations will set this field to zero. The Capabilities
field of the Hello TLV MUST be checked before any other TLVs in
the Hello because capabilities defined in the future might
extend existing TLVs or permit new TLVs.
INTERNET-DRAFT BNG Simple CUSP After the exchange of Hello messages, the CP and UP each perform a
logical AND of the Sub-Version supported by the CP and the UP and
separately perform a logical AND of the Capabilities bits fields for
the CP and the UP.
X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy and can INTERNET-DRAFT Simple BNG CUSP
process ARP requests across different Port+VLANs.
0: The ARP proxy is not enabled on the interface, and
only the ARP requests of the same Port+VLAN are
processed.
Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and can If the result of the AND of the Sub-Versions supported is zero, then
process ND requests across different Port+VLANs. no session can be established and the connection is torn down. If the
0: The ND proxy is not enabled on the interface, and only result of the AND of the Sub-Versions supported is non-zero, then the
the ND requests of the same Port+VLAN are processed. session uses the highest Sub-Version supported by both the CP and UP.
MBZ: Reserved bits that MUST be sent as zero and ignored on receipt. For example, if one side supports Sub-Versions 1, 3, 4, and 5
(VerSupported = 0x5C000000) and the other side supports 2, 3, and 4
(VerSupported = 0x38000000) then 3 and 4 are the Sub-Versions in
common and 4 is the highest Sub-Version supported by both sides. So
Sub-Version 4 is used for the session that has been negotiated.
5.2 Basic User Information TLVs The result of the logical AND of the Capabilities bits will show what
additional capabilities both sides support. If this result is zero,
there are no such capabilities so none can be used during the
session. If this result is non-zero, it shows the additional
capabilities that can be used during the session. The CP and the UP
MUST NOT use a capability unless both advertise support.
The Basic User Information TLVs are defined for a CP to carry the 7.5 The Keep Alive TLV
basic information about a user to an UP.
5.2.1 Basic User Information TLV The Keep Alive TLV is defined to be carried in the Hello message. It
provides timing information for the keep alive feature. The format
of Hello TLV is as follows:
The format of the Basic User Information TLV value part is as below: 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive | DeadTimer | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: Keep Alive TLV
Where:
The TLV type: 102.
The value of length: 4 octets.
Keepalive (8 bits): Indicates the maximum period of time (in
seconds) between two consecutive S-CUSP messages sent by the
sender of the message containing this TLV as an unsigned integer.
The minimum value for the Keepalive is 1 second. When set to 0,
once the session is established, no further Keepalive messages are
sent to the remote peer. A RECOMMENDED value for the Keepalive
frequency is 30 seconds.
DeadTimer (8 bits in length): Specifies the amount of time as an
unsigned integer number of seconds after the expiration of which
INTERNET-DRAFT Simple BNG CUSP
the S-CUSP peer can declare the session with the sender of the
Hello message to be down if no S-CUSP message has been received.
The DeadTimer SHOULD be set to 0 and MUST be ignored if the
Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4
times the value of the Keepalive.
The Reserved bits MUST be sent as zero and ignored on receipt.
7.6 The Error Information TLV
The Error Information TLV is a common TLV that can be used in many
Response (e.g., Update_Response message) and ACK messages (e.g.,
Addr_Allocation_Ack message, etc.). It is used to convey the
information about an error in the received S-CUSP message. The
format of the Error Information TLV is as follows:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | Message-Type | Reserved | TLV-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC |
Figure 41: Error Information TLV
Where:
The TLV type: 101.
The value of length: 8 octets.
Message-Type(1 byte): This parameter is the message type of the
message containing an error.
Reserved (1 byte): MUST be sent as zero and ignored on receipt.
TLV-Type (2 bytes): Indicates which TLV caused the error.
Error Code: 4 bytes in length. Indicate the specific Error Code
(see Section 9.5).
7.7 BAS Function TLV
The BAS Function TLV is used by a CP to control the access mode,
authentication methods, and other related functions of an interface
INTERNET-DRAFT Simple BNG CUSP
on a UP.
The format of the BAS Function TLV value part is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | Oper ID | Reserved | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Type |Sub-access Type| Account Type | Address Family| | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect Times | Detect Interval | | sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
Figure 42: BAS Function TLV
Where:
The TLV type: 1.
The value of length: variable.
If-Index: 4 bytes in length, a unique identifier of an interface
of a BNG.
Access-Mode: 1 byte in length, indicates the access mode of the
interface. This document defines following values:
0: Layer 2 subscriber;
1: Layer 3 subscriber;
2: Layer 2 leased line;
3: Layer 3 leased line;
4-255: Reserved.
Auth-Method4: 1 byte in length, for IPv4 scenario, it indicates
the authentication on this interface; this field is defined as a
bitmap, this document defines following values (other bits are
reserved and MUST be sent as zero and ignored on receipt):
0x1: PPPoE authentication;
0x2: DOT1X authentication;
0x4: Web authentication;
0x8: Web fast authentication;
0x10: Binding authentication.
Auth-Method6: 1 byte in length, for IPv6 scenario, it indicates
the authentication on this interface; this field is defined as a
bitmap, this document defines following values (other bits are
INTERNET-DRAFT Simple BNG CUSP
reserved and MUST be sent as zero and ignored on receipt):
0x1: PPPoE authentication;
0x2: DOT1X authentication;
0x4: Web authentication;
0x8: Web fast authentication;
0x10: Binding authentication;
sub-TLVs:
The IF-Desc sub-TLV can be carried.
If-Desc sub-TLV: carries the interface information.
The flags field is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ | MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.3: Basic User Information TLV Figure 43: Interface Flags
INTERNET-DRAFT BNG Simple CUSP Where:
Function: Basic information about a BNG user. F (IPv4 Trigger) bit: Indicates whether IPv4 packets can
TLV Type: 2 trigger a subscriber to go online. 1: enabled, 0: disabled.
TLV Length: variable in length;
TLV Fields: S (IPv6 Trigger) bit: Indicates whether IPv6 packets can
Name Length Description trigger a subscriber to go online. 1: enabled, 0: disabled.
-------------- ------ ----------------------
User-ID 4 bytes User ID.
User-Mac MAC-Addr User MAC Address.
Oper-ID 1 byte Indicates the ID of an operation performed
by a user. This field is carried in the
response from the UP.
Session-ID 4 bytes Session ID of a PPPoE user. Zero for non-
PPPoE user.
Access-Type 1 byte See Section 5.2.1.1.
Sub-Access-Type 1 byte Indicates whether PPP termination or PPP
relay is used. 0: N/A 1: PPP2 on the LAC
side: Termination, PPP on the LNS side
Account-Type 1 byte IPv4/IPv6 charging: 0 separate charging:
Collects statistics on IPv4 and IPv6 traffic
of terminals independently. 1: Statistics
and charging Collects statistics on IPv4 and
IPv6 traffic of terminals.
User-IP-Type 1 byte 1:IPv4 stack and 2:IPv6 stack 3: dual stack
C-VID VLAN-ID Indicates the inner VLAN ID. The value 0
indicates that the VLAN ID is invalid. The
default value of PRI is 7, the value of DEI
is 0, and the value of VID is 1~4094. The
PRI value can also be obtained by parsing
terminal packets.
P-VID VLAN-ID Outer VLAN ID. The value 0 indicates that
the VLAN ID is invalid. The format is the
same as that the C-VID.
Detect-Times 2 bytes Number of detection timeout times. The value
0 indicates that no detection is performed.
Detect-Interval 2 bytes Detection interval in seconds.
If-Index 4 bytes Interface index.
The Reserved field MUST be sent as zero and ignored on receipt. A (ARP Trigger) bit: Indicates whether ARP packets can trigger
a subscriber to go online. 1: enabled, 0: disabled.
INTERNET-DRAFT BNG Simple CUSP N (ND Trigger) bit: Indicates whether ND packets can trigger a
subscriber to go online. 1: enabled, 0: disabled.
5.2.1.1 Access Types Table I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable
traffic detection. 0: Disable traffic detection.
Value Meaning P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable
----- --------- traffic detection. 0: Disable traffic detection.
1 PPP access (PPP)
2 PPP over Ethernet over ATM access (PPPoEoA)
3 PPP over ATM access (PPPoA)
4 PPP over Ethernet access (PPPoE)
5 PPPoE over VLAN access (PPPoEoVLAN)
6 PPP over LNS access (PPPoLNS)
7 IP over Ethernet DHCP access (IPoE_DHCP)
8 IP over Ethernet EAP authentication access (IPoE_EAP)
9 IP over Ethernet Layer 3 access (IPoE_L3)
10 IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC)
11 Layer 2 Leased Line access (L2_Leased_Line)
12 Layer 2 VPN Leased Line access (L2VPN_Leased_Line)
13 Layer 3 Leased Line access (L3_Leased_Line)
14 Layer 2 Leased line Sub-User access
(L2_Leased_Line_SUB_USER)
15 L2TP LAC tunnel access (L2TP_LAC)
16 L2TP LNS tunnel access (L2TP_LNS)
5.2.2 User PPP Information TLV X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy
and can process ARP requests across different Port+VLANs. 0:
The ARP proxy is not enabled on the interface, and only the ARP
requests of the same Port+VLAN are processed.
The User PPP Information TLV is defined to carry PPP information of a INTERNET-DRAFT Simple BNG CUSP
User, from a CP to an UP.
Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and
can process ND requests across different Port+VLANs. 0: The ND
proxy is not enabled on the interface, and only the ND requests
of the same Port+VLAN are processed.
MBZ: Reserved bits that MUST be sent as zero and ignored on
receipt.
7.8 Routing TLVs
Normally, after an S-CUSP session is established between a UP and a
CP, the CP will allocate one or more blocks of IP addresses to the
UP. Those IP addresses will be allocated to subscribers who will
dial-up to the UP. In order to make sure that other nodes within the
network learn how to reach those IP addresses, the CP needs to
install one or more routes that can reach those IP addresses on the
UP and notify the UP to advertise the routes to the network.
The Routing TLVs are used by a CP to notify a UP of the network
routing. They can be carried in the Update_Request message and
Sync_Data message.
7.8.1 IPv4 Routing TLV
The IPv4 Routing TLV is used to carry IPv4 network routing related
information.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as below: The format of the TLV value part is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSS | Reserved |M| | Dest-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | Reserved | | Next-Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Number | | Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Magic Number | | Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.4: User PPP Information TLV Figure 44: IPv4 Routing TLV
Function: PPP [RFC1661] information for a BNG user. Where:
TLV Type: 3
TLV Length: 20 bytes in length
INTERNET-DRAFT BNG Simple CUSP The TLV Type: 7
TLV Fields: The TLV Length: Variable
Name Type Description
-------------- ------ ----------------------
User-ID 4 bytes User ID.
MSS-Value 2 bytes Indicates the MSS value.
MSS-Enable 1 bit Indicates whether the MSS is enabled. 0: The
function is disabled. 1: Enable
MRU 2 bytes PPPoE local MRU.
Magic-Number 4 bytes Local magic number in PPP negotiation
packets.
Peer-Magic-Number 4 bytes Remote peer magic number.
The Reserved fields MUST be sent as zero and ignored on receipt. User-ID: 4 bytes in length. Carries the user identifier. This
field is filled with all Fs when a non-user route is delivered to
the UP.
5.3 User IPv4 Information TLV Dest-Address (IPv4-Address type): Identifies the destination
address.
The User IPv4 Information TLV is defined to carry IPv4 related Next-Hop: (IPv4-Address type): Identifies the next hop address.
information for a BNG user.
The format of the TLV value part is as below: Out-If-Index (4 bytes): Indicates the interface index.
Cost (4 bytes): The cost value of the route.
Tag (4 bytes): The tag value of the route.
Route-Type (2 bytes): Indicates the route type. The options are
as follows:
INTERNET-DRAFT Simple BNG CUSP
0: User host route
1: Radius authorization FrameRoute
2: Network segment route
3: Gateway route
4: Radius authorized IP route
5: L2TP LNS side user route
Advertise-Flag: 1 bit. Indicates whether the route should be
advertised by the UP. Following flags are defined:
0: Not advertised,
1: advertised.
sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried.
VRF-Name sub-TLV: indicates which VRF the route belongs to.
If-Desc sub-TLV: carries the interface information.
The Reserved field MUST be sent as zero and ignored on receipt.
7.8.2 IPv6 Routing TLV
The IPv6 Routing TLV is used to carry IPv6 network routing
information.
The format of this TLV is as follows:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User IPv4 Address | ~ IPv6 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway IPv4 Address | ~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P| | Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs ~ | Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.5: User IPv4 Information TLV Figure 45: IPv6 Routing TLV
Function: IPv4 information for a BNG user. Where:
TLV Type: 4
TLV Length: variable
TLV fields: INTERNET-DRAFT Simple BNG CUSP
Name Type Description
-------------- ------ ----------------------
User-ID 4 bytes User ID.
User-IPv4 IPv4 User IPv4 address.
Gateway-IPv4 IPv4 User gateway.
Portal Force 1 bit (P) Push advertisement switch, 0: off, 1:
INTERNET-DRAFT BNG Simple CUSP The TLV Type: 7
on. The TLV Length: Variable
Web-Force 1 bit (W) IP4 Web push flag. 0: off, 1: on.
Echo-Enable 1 bit (E) Compatible with PPP/ARP and the UP
returns ARP Req or PPP Echo. 0: off, 1: on.
IPv4-URPF 1 bit (U) Unicast Reverse Path Forwarding (URPF)
flag of a user. 0: off, 1: on.
MTU 2 bytes MTU value. The default value is 1500.
VRF-Name Sub-TLV VRF name.
The Reserved field MUST be sent as zero and ignored on receipt. User-ID: 4 bytes in length. Carries the user identifier. This
field is filled with all Fs when a non-user route is delivered to
the UP.
5.4 User IPv6 Information IPv6 Dest-Address (IPv6-Address type): Identifies the destination
address.
The User IPv6 Information TLV is defined to carry IPv6 related IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop
information of a BNG user. address.
The format of the TLV value part is as below: Out-If-Index (4 bytes): Indicates the interface index.
Cost (4 bytes): The cost value of the route.
Tag (4 bytes): The tag value of the route.
Route-Type: (2 bytes): Indicates the route type. The options are
as follows:
0: User host route
1: Radius authorization FrameRoute
2: Network segment route
3: Gateway route
4: Radius authorized IP route
5: L2TP LNS side user route
Advertise-Flag: 1 bit. Indicates whether the route should be
advertised by the UP. Following flags are defined:
0: Not advertised,
1: advertised.
sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried.
VRF-Name sub-TLV: Indicates the VRF to which the subscriber
belongs.
If-Desc sub TLV: carries the interface information.
The Reserved field MUST be sent as zero and ignored on receipt.
7.9 Subscriber TLVs
The Subscriber TLVs are defined for a CP to send the basic
information about a user to a UP.
INTERNET-DRAFT Simple BNG CUSP
7.9.1 Basic Subscriber TLV
The Basic Subscriber TLV is used to carry the basic common
information for all kinds of access subscribers. It is carried in an
Update_Request message.
The format of the Basic Subscriber TLV value part is as follows:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User PD-Address ~ | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway ND-Address ~ | User MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User IANA Address | | User MAC | Oper ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID | | Access Type |Sub-access Type| Account Type | Address Family|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID (cont.) | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P| | Detect Times | Detect Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (VRF Name sub-TLV) ~ | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.6: User IPv6 Information TLV Figure 46: Basic Subscriber TLV
Function: IPv6 information for a BNG user. Where:
TLV Type: 5
TLV Length: variable
INTERNET-DRAFT BNG Simple CUSP The TLV Type: 2.
TLV fields: The TLV Length: variable in length.
Name Type Description
-------------- ------ ----------------------
User-ID 4 bytes User ID.
PD-Address IPv6 Prefix Delegation (PD) address.
ND-Address IPv6 Neighbor Discovery (ND) address.
IANA-Address IPv6 IANA address.
Interface-ID 8 bytes IPv6 interface ID.
Portal Force 1 bit (P) Push advertisement switch, 0: off, 1:
on.
Web-Force 1 bit (W) IP6 Web push flag. 0: off, 1: on.
Echo-Enable 1 bit (E) Compatible with PPP/ARP and the UP
returns ARP Req or PPP Echo. 0: off, 1: on.
IPv6-URPF 1 bit (U) User Reverse Path Forwarding (URPF) flag
of a user. 0: off, 1: on.
MTU 2 bytes MTU value. The default value is 1500.
VRF-Name Sub-TLV VRF name.
The Reserved field MUST be sent as zero and ignored on receipt. User-ID (4 bytes): The identifier of a subscriber.
5.5 User QoS Policy Information TLV Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero
means non-PPPoE subscriber.
User-Mac (MAC-Addr type): The MAC Address of a subscriber.
Oper-ID (1 byte): Indicates the ID of an operation performed by a
user. This field is carried in the response from the UP.
Reserved (1 byte): MUST be sent as zero and ignored on receipt.
INTERNET-DRAFT Simple BNG CUSP
Access-Type (1 byte):
1: PPP access (PPP [RFC1661])
2: PPP over Ethernet over ATM access (PPPoEoA)
3: PPP over ATM access (PPPoA [RFC3336])
4: PPP over Ethernet access (PPPoE [RFC2516])
5: PPPoE over VLAN access (PPPoEoVLAN [RFC2516])
6: PPP over LNS access (PPPoLNS)
7: IP over Ethernet DHCP access (IPoE_DHCP)
8: IP over Ethernet EAP authentication access (IPoE_EAP)
9: IP over Ethernet Layer 3 access (IPoE_L3)
10: IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC)
11: Layer 2 Leased Line access (L2_Leased_Line)
12: Layer 2 VPN Leased Line access (L2VPN_Leased_Line)
13: Layer 3 Leased Line access (L3_Leased_Line)
14: Layer 2 Leased line Sub-User access
(L2_Leased_Line_SUB_USER)
15: L2TP LAC tunnel access (L2TP_LAC)
16: L2TP LNS tunnel access (L2TP_LNS)
Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP
relay is used.
0: Reserved
1: PPP Relay (for LAC)
2: PPP termination (for LNS)
Account-Type(1 byte):
0: Collects statistics on IPv4 and IPv6 traffic of terminals
independently.
1: Collects statistics on IPv4 and IPv6 traffic of terminals.
Address Family (1 byte)
1: IPv4
2: IPv6
3: dual stack
C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0
indicates that the VLAN ID is invalid. The default value of PRI
is 7, the value of DEI is 0, and the value of VID is 1~4094. The
PRI value can also be obtained by parsing terminal packets.
P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0
indicates that the VLAN ID is invalid. The format is the same as
that for C-VID.
Detect-Times (2 bytes): Number of detection timeout times. The
value 0 indicates that no detection is performed.
Detect-Interval (2 bytes): Detection interval in seconds.
INTERNET-DRAFT Simple BNG CUSP
If-Index (4 bytes): Interface index.
Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried.
VRF-Name sub-TLV: Indicates the VRF to which the subscriber
belongs.
If-Desc sub-TLV: carries the interface information.
The Reserved field MUST be sent as zero and ignored on receipt.
7.9.2 PPP Subscriber TLV
The PPP Subscriber TLV is defined to carry PPP information of a User
from a CP to a UP. It will be carried in an Update_Request message
when PPPoE or L2TP access is used.
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-Priority | E-Priority | Reserved | | MSS | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs ~ | MRU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Magic Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.7: User QoS Policy Information TLV Figure 47: PPP Subscriber TLV
Function: BNG user authorization information. Where:
TLV Type: 6
TLV length: variable in length
TLV Fields: The TLV type: 3.
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 The TLV length: 12 octets.
Ingress-CAR Sub-TLV Upstream CAR. User-ID (4 bytes): The identifier of a subscriber.
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. MSS-Value (2 bytes): Indicates the MSS value (in bytes).
5.6 Routing Table TLVs MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled.
0: Disabled.
1: Enabled.
5.6.1 IPv4 Routing Information TLV MRU (2 bytes): PPPoE local MRU (in bytes).
The format of the TLV value part is as below: INTERNET-DRAFT Simple BNG CUSP
Magic-Number (4 bytes): Local magic number in PPP negotiation
packets.
Peer-Magic-Number (4 bytes): Remote peer magic number.
The Reserved fields MUST be sent as zero and ignored on receipt.
7.9.3 IPv4 Subscriber TLV
The IPv4 Subscriber TLV is defined to carry IPv4 related information
for a BNG user. It will be carried in an Update_Request message when
IPv4 IPoE, or PPPoE access is used.
The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest-Address | | User IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | | Gateway IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A| | MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs ~ ~ VRF-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.8: IPv4 Routing Information TLV Figure 48: IPv4 Subscriber TLV
Function: IPv4 routing information. Where:
TLV Type: 7
TLV Length: Variable length
INTERNET-DRAFT BNG Simple CUSP The TLV type: 4.
TLV Fields: The TLV length: variable.
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. User-ID (4 bytes): The identifier of a subscriber.
5.6.2 IPv6 Routing Information TLV User-IPv4 (IPv4-Address): The IPv4 address of the subscriber.
Gateway-IPv4 (IPv4-Address): The gateway address of the
subscriber.
Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on.
Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on.
INTERNET-DRAFT Simple BNG CUSP
Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off,
1: on.
IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF)
flag. 0: off, 1: on.
MTU 2 bytes MTU value. The default value is 1500.
VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.
The Reserved field MUST be sent as zero and ignored on receipt.
7.9.4 IPv6 Subscriber TLV
The IPv6 Subscriber TLV is defined to carry IPv6 related information
for a BNG user. It will be carried in an Update_Request message when
IPv6 IPoE, or PPPoE access is used.
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Dest-Address ~ ~ User PD-Address (IPv6 Address List sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~ ~ Gateway ND-Address (IPv6 Address List sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index | | User IANA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost | | IPv6 Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | | IPv6 Interface ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A| | MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name sub-TLVs ~ ~ VRF Name sub-TLV (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INTERNET-DRAFT BNG Simple CUSP Figure 49: IPv6 Subscriber TLV
Figure 5.9: IPv6 Routing Information TLV Where:
Function: IPv4 routing information. The TLV type: 5.
TLV Type: 8
TLV Length: Variable
TLV Fields: The TLV length: variable.
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. INTERNET-DRAFT Simple BNG CUSP
5.7 Static User Information TLVs User-ID (4 bytes): The identifier of a subscriber.
INTERNET-DRAFT BNG Simple CUSP
5.7.1 Static IPv4 User Information TLV User PD-Addresses (IPv6 Address List): Carries a list of Prefix
Delegation (PD) addresses of the subscriber.
User ND-Addresses (IPv6 Address List): Carries a list of Neighbor
Discovery (ND) addresses of the subscriber.
User IANA-Address (IPv6-Address): The IANA address of the
subscriber.
IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface.
Portal Force 1 bit (P): Push advertisement, 0: off, 1: on.
Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on.
Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off;
1: on.
IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0:
off; 1: on.
MTU (2 bytes): The MTU value. The default value is 1500.
VRF-Name Sub-TLV: Indicates the VRF to which the subscriber
belongs.
The Reserved field MUST be sent as zero and ignored on receipt.
7.9.5 IPv4 Static Subscriber Detect TLV
The IPv4 Static Subscriber Detect TLV is defined to carry IPv4
related information for a static access subscriber. It will be
carried in an Update_Request message when IPv4 static access on a UP
needs to be enabled.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Address | | User Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Address | | Gateway Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Reserved | | User MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name sub-TLVs ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.10: Static IPv4 User Information TLV Figure 50: IPv4 Static Subscriber TLV
Function: User information which is used proactively to detect Where:
and go on line.
TLV Type: 9
TLV Length: variable
TLV Fields: The TLV type: 6.
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. The TLV length: variable.
INTERNET-DRAFT BNG Simple CUSP If-Index (4 bytes): The interface index of the interface from
which the subscriber will dial-up.
5.7.2 Static IPv6 User Information TLV C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0
indicates that the VLAN ID is invalid. A valid value is 1~4094.
P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0
indicates that the VLAN ID is invalid. The format is the same as
that of the C-VID. A valid value is 1~4094. For a single-layer
VLAN, set this parameter to PeVid.
User Address (IPv4-Addr): The user's IPv4 address.
Gateway Address (IPv4-Addr): The gateway's IPv4 Address.
User-MAC (MAC-Addr type): The MAC address of the subscriber.
Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried.
VRF-Name sub-TLV: Indicates the VEF to which the subscriber
belongs.
If-Desc sub-TLV: Carries the interface information.
INTERNET-DRAFT Simple BNG CUSP
The Reserved field MUST be sent as zero and ignored on receipt.
7.9.6 IPv6 Static Subscriber Detect TLV
The IPv6 Static Subscriber Detect TLV is defined to carry IPv6
related information for a static access subscriber. It will be
carried in an Update_Request message when needed to enable IPv6
static subscriber detection on a UP.
The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Address ~ ~ User Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway Address ~ ~ Gateway Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Reserved | | User MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.11: Static IPv6 User Information TLV Figure 51: IPv6 Static Subscriber Detect TLV
Function: User information which is used proactively to detect Where:
and go on line.
TLV Type: 10
TLV Length: variable
TLV Fields: The TLV type: 6.
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. The TLV length: variable.
INTERNET-DRAFT BNG Simple CUSP If-Index (4 bytes): The interface index of the interface from
which the subscriber will dial-up.
5.8 L2TP User Information TLVs C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0
indicates that the VLAN ID is invalid. A valid value is 1~4094.
5.8.1 L2TP-LAC User Information TLV P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0
indicates that the VLAN ID is invalid. The format is the same as
that the of C-VID. A valid value is 1~4094. For a single-layer
VLAN, set this parameter to PeVid.
INTERNET-DRAFT Simple BNG CUSP
User Address (IPv6-Address type): The subscriber's IPv6 address.
Gateway Address (IPv6-Address type): The gateway's IPv6 Address.
User-MAC (MAC-Addr type): The MAC address of the subscriber.
sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried
VRF-Name Sub-TLV: Indicates the VRF to which the subscriber
belongs.
If-Desc sub-TLV: Carries the interface information.
The Reserved field MUST be sent as zero and ignored on receipt.
7.9.7 L2TP-LAC Subscriber TLV
The L2TP-LAC Subscriber TLV is defined to carry the related
information for a L2TP LAC access subscriber. It will be carried in
an Update_Request message when L2TP LAC access is used.
The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Local Session ID | | Local Tunn