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