| RFC 8772 | Simple BNG CUSP | May 2020 |
| Hu, et al. | Informational | [Page] |
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 and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP). China Mobile, Huawei Technologies, and ZTE have developed a simple CUPS control channel protocol to support such 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.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of 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 obtained at https://www.rfc-editor.org/info/rfc8772.¶
Copyright (c) 2020 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 (https://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.¶
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. To provide centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, the CU-separated (CP/UP-separated) BNG framework is described in a technical report [TR-384] from the Broadband Forum (BBF). The CU-separated service CP, which is responsible for user access authentication and setting forwarding entries in UPs, can be virtualized and centralized. The routing control and forwarding plane, i.e., the BNG UP (local), can be distributed across the infrastructure. Other structures can also be supported, such as 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 Protocol (S-CUSP) for communications over the BNG control channel between a BNG CP and a set of 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 BBF is working to produce [WT-459], which will describe an architecture and requirements for a CP and 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.¶
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].¶
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.¶
This section specifies terms used in this document.¶
The rapid development of new services, such as 4K TV, Internet of Things (IoT), etc., and increasing numbers of home broadband service users present some new challenges for BNGs such as:¶
The framework for a cloud-based BNG with 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 CP. The traditional router's CP and forwarding plane are both preserved on BNG devices in the form of a UP.¶
The functions in a traditional BNG can be divided into two parts: (1) the user access management function and (2) the routing function. The user access management function can be deployed as a centralized module or device, called the BNG Control Plane (BNG-CP). The routing function, which includes routing control and the forwarding engine, can be deployed in the form of the BNG User Plane (BNG-UP).¶
Figure 1 shows the architecture of a CU-separated BNG:¶
+------------------------------------------------------------------+ | Neighboring policy and resource management systems | | | | +-------------+ +-----------+ +---------+ +----------+ | | | AAA Server | |DHCP Server| | EMS | | MANO | | | +-------------+ +-----------+ +---------+ +----------+ | +------------------------------------------------------------------+ +------------------------------------------------------------------+ | CU-separated BNG system | | +--------------------------------------------------------------+ | | | +----------+ +----------+ +------++------++-----------+ | | | | | Address | |Subscriber| | AAA ||Access|| UP | | | | | |management| |management| | || mgt ||management | | | | | +----------+ +----------+ +------++------++-----------+ | | | | CP | | | +--------------------------------------------------------------+ | | | | | | | | +---------------------------+ +--------------------------+ | | | +------------------+ | | +------------------+ | | | | | Routing control | | | | Routing control | | | | | +------------------+ | ... | +------------------+ | | | | +------------------+ | | +------------------+ | | | | |Forwarding engine | | | |Forwarding engine | | | | | +------------------+ UP | | +------------------+ UP| | | +---------------------------+ +--------------------------+ | +------------------------------------------------------------------+
As shown in Figure 1, the BNG-CP could be virtualized and centralized, which provides benefits such as centralized session management, flexible address allocation, high scalability for subscriber management capacity, cost-efficient redundancy, etc. The functional components inside the BNG-CP can be implemented as Virtual Network Functions (VNFs) and hosted in an NFVI.¶
The UP management module in the BNG-CP centrally manages the distributed BNG-UPs (e.g., load balancing), as well as the setup, deletion, and maintenance of channels between CPs and UPs. Other modules in the 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 UP SHOULD support both physical and virtual network functions. For example, network functions related to BNG-UP L3 forwarding can be disaggregated and distributed across the physical infrastructure, and the other CP management functions in the CU-separated BNG can be moved into the NFVI for virtualization [TR-384].¶
The details of the CU-separated BNG's function components are as follows:¶
The CP is responsible for the following:¶
The UP is responsible for the following:¶
The three interfaces defined below support the communication between the CP and UP. These are referred to as the Service Interface (Si), Control Interface (Ci), and Management Interface (Mi) as shown in Figure 2.¶
+-----------------------------------+
| |
| BNG-CP |
| |
+--+--------------+--------------+--+
| | |
1. Service | 2. Control | 3. Management|
Interface | Interface | Interface |
(Si) | (Ci) | (Mi) |
| | |
| ___|___ |
| ___( )___ |
_|______( )______|_
( )
( Network/Internet )
(________ ________)
| (___ ___) |
| (_______) |
| | |
| | |
+--+--------------+--------------+--+
| |
| BNG-UP |
| |
+-----------------------------------+
For a traditional BNG (without CU separation), the user dial-up signals are terminated and processed by the 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 Si is used to establish tunnels between the CP and UP. The tunnels are responsible for relaying the PPPoE-, IPoE-, and L2TP-related control packets that are received from a Residential Gateway (RG) over those tunnels. An appropriate tunnel type is Virtual eXtensible Local Area Network (VXLAN) [RFC7348].¶
The detailed definition of Si is out of scope for this document.¶
The CP uses the Ci to deliver subscriber session states, network routing entries, etc., to the UP (see Section 6.2.7). The UP uses this interface to report subscriber service statistics, subscriber detection results, etc., to the CP (see Sections 6.3 and 6.4). A carrying protocol for this interface is specified in this document.¶
The Network Configuration Protocol (NETCONF) [RFC6241] is the protocol used on the Mi between a CP and UP. It is used to configure the parameters of the Ci, Si, access interfaces, and QoS/ACL Templates. It is expected that implementations will make use of existing YANG models where possible but that new YANG models specific to S-CUSP will need to be defined. The definitions of the parameters that can be configured are out of scope for this document.¶
The following numbered sequences (Figure 3) give a high-level view of the main BNG CUPS procedures.¶
RG UP CP AAA | |Establish S-CUSP Channel| | | 1|<---------------------->| | | | | | | | Report board interface | | | | information | | | 2|------to CP via Ci----->| | | | | | | | Update BAS function | | | 3| request/response | | | |<-----on UP via Ci----->| | | | | | | | Update network routing | | | | request/response | | | 4|<------- via Ci-------->| | | Online Req | | | 5.1|-------------->| | | | | Relay the Online Req | | | 5.2|-----to CP via Si------>| Authentication| | | | Req/Rep | | | 5.3|<------------->| | | Send the Online Rep | | | 5.4|<----to UP via Si-------| | | | | | | | Create subscriber | | | | session on UP | | | 5.5|<--------via Ci-------->| | | Online Rep | | | 5.6|<--------------| | | | | | CoA Request | | | 6.1|<--------------| | | Update session on UP | | | 6.2|<--------via Ci-------->| | | | | CoA Response | | 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 | | | 9|<--------via Ci-------->| | | | | | | | CGN address allocation | | | 10|<--------via Ci-------->| | | | | |
Event reports include the following two parts (more detail can be found in Section 4.3.4). Both are reported using the Event message:¶
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: the master CP and standby CP. The association between a UP and its CPs is implemented by dynamic configuration.¶
Once a UP knows its CPs, the UP starts to establish S-CUSP sessions with those CPs, as shown in Figure 4.¶
UP CP
| TCP Session Establishment |
|<------------------------------->|
| |
| Hello (version, capability) |
|-------------------------------->|
| |
| Hello (version, capability) |
|<--------------------------------|
| |
The S-CUSP session establishment consists of two successive steps:¶
Once the TCP connection is established, the CP and the UP initialize the S-CUSP session, during which the version and Keepalive timers are negotiated.¶
The version information (Hello TLV, see Section 7.4) is carried within Hello messages (see Section 6.2.1). A CP can support multiple versions, but a UP can only support one version; thus the version negotiation is based on whether a version can be supported by both the CP and the UP. If a CP or UP receives a Hello message that does not indicate a version supported by both, it responds with a Hello message containing an Error Information TLV to notify the peer of the Version-Mismatch error, and the session establishment phase fails.¶
Keepalive negotiation is performed by carrying a Keepalive TLV in the Hello message. The Keepalive TLV includes a Keepalive timer and DeadTimer field. The CP and UP have to agree on the Keepalive Timer and DeadTimer. Otherwise, a subsequent Hello message with an Error Information TLV will be sent to its peer, and the session establishment phase fails.¶
The S-CUSP session establishment phase fails if the CP or UP disagree on the version and keepalive parameters or if one of the CP or UP does not answer after the expiration of the Establishment timer. When the S-CUSP session establishment fails, the TCP connection is promptly closed. Successive retries are permitted, but an implementation SHOULD make use of an exponential backoff session establishment retry procedure.¶
The S-CUSP session timer values that need to be configured are summarized in Table 1.¶
| Timer Name | Range in Seconds | Default Value |
|---|---|---|
| Establishment Timer | 1-32767 | 45 |
| Keepalive Timer | 0-255 | 30 |
| DeadTimer | 1-32767 | 4 * Keepalive |
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, unless, as explained below, that value is the special value zero.¶
Each end of an S-CUSP session also runs a DeadTimer and restarts that DeadTimer whenever a message is received on the session. If the DeadTimer expires at an end of the session, that end declares the session dead and the session will be closed, unless their DeadTimer is set to the special value zero, in which case the session will not time out.¶
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.¶
Once an S-CUSP session has been established between a CP and a UP, the UP reports the state information of the 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 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 online subscriber sessions to a standby UP and then 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----->|
| |
Board status information is carried in the Board Status TLV (Section 7.10.2), and 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 (Section 6.4).¶
Once the CP collects the interface status of a UP, it will activate/deactivate/modify the BAS functions on specified interfaces through the Update_Request and Update_Response message exchanges (Section 6.2), carrying the BAS Function TLV (Section 7.7).¶
UP CP
| Update BAS Function |
| Request |
|<-----on UP via Ci-------|
| |
| Update BAS Function |
| Response |
|------on UP via Ci------>|
| |
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--------->|
| |
The Update_Request and Update_Response message exchanges, carrying the IPv4/IPv6 Routing TLVs (Section 7.8), update the subscriber's network routing information.¶
The following sequences (Figure 8) describe the procedures related to CGN address management. Three independent procedures are defined: one each for CGN address allocation request/response, CGN address renewal request/response, and CGN address release request/response.¶
CGN address allocation/renew/release procedures are designed for the case where the CGN function is running on the UP. The UP has to map the subscriber private IP addresses to public IP addresses, and such mapping is performed by the UP locally when a subscriber dials up. That means the UP has to ask for public IPv4 address blocks for CGN subscribers from the CP.¶
In addition, when a public IP address is allocated to a UP, there will be a lease time (e.g., one day). Before the lease time expires, the UP can ask for renewal of the IP address lease from the CP. It is achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack messages.¶
If the public IP address will not be used anymore, the UP SHOULD release the address by sending an Addr_Release_Req message to the CP.¶
If the CP wishes to withdraw addresses that it has previously leased to a UP, it uses the same procedures as above. The Oper code (see Section 7.1) in the IPv4/IPv6 Routing TLV (see Section 7.8) determines whether the request is an update or withdraw.¶
The relevant messages are defined in Section 6.5.¶
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----------|
| |
For a CU-separated BNG, the UP will continue to function using the state that has been installed in it even if the CP fails or the session between the UP and CP fails.¶
Under some circumstances, it is necessary to synchronize state between the CP and UP, for example, if a CP fails and the UP is switched to a different CP.¶
Synchronization includes two directions. One direction is from UP to CP; in that case, the synchronization information is mainly about the board/interface status of the UP. The other direction is from CP to UP; in that case, the subscriber sessions, subscriber network routes, L2TP tunnels, etc., will be synchronized to the UP.¶
The synchronization is triggered by a Sync_Request message, to which the receiver will (1) reply with a Sync_Begin message to notify the requester that synchronization will begin and (2) then start the synchronization using the Sync_Data message. When synchronization finishes, a Sync_End message will be sent.¶
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
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 collection of hardware resources (e.g., NP, TCAM, etc.) has to be allocated to a session on a UP as part of its initiation.¶
Procedures related to subscriber sessions include subscriber session creation, update, deletion, and statistics reporting. The following subsections give a high-level view of the procedures.¶
The 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 | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | Accounting |
| | 6|<------------->|
| | Send Online Response | |
| 7|<----to UP via Si-------| |
| | | |
|Online Response| | |
8|<--------------| | |
| | | |
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 Si (step 2). A tunneling technology implements the 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 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 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). The UP will then forward the Online Response to the RG (step 8).¶
That completes the subscriber activation process.¶
The following numbered sequence (Figure 11) shows the process of updating the subscriber session.¶
UP CP AAA
| | CoA Request |
| 1|<--------------|
| Session Update Request | |
2|<--------via Ci---------| |
| | |
| Session Update Response| |
3|---------via Ci-------->| |
| | CoA Response |
| 4|-------------->|
| | |
When a subscriber session has been created on a UP, there may be requirements to update the session with new parameters (e.g., bandwidth, QoS, policies, etc.).¶
This procedure is triggered by a Change of Authorization (CoA) request message sent by the AAA server. The CP will update the session on the UP according to the new parameters through the Ci.¶
The call flow below shows how S-CUSP deals with a subscriber Offline Request.¶
RG UP CP
|Offline Request | |
1|--------------->| |
| | Relay the Offline |
| | Request |
| 2|------to CP via Si----->|
| | |
| | Send the Offline |
| | Response |
| 3|<-----to UP via Si------|
|Offline Response| |
4|<---------------| |
| | Session Delete |
| | Request |
| |<--------via Ci---------|
| | Session Delete |
| | Response |
| |---------via Ci-------->|
| | |
Similar to the session creation process, when a UP receives an Offline Request from an RG, it will tunnel the request to a CP through the Si.¶
When the CP receives the Offline Request, it will withdraw/release the resources (e.g., IP address, bandwidth) that have been allocated to the subscriber. It then sends a reply to the UP through the 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.¶
UP CP
| Statistic/Detect Report|
|---------via Ci-------->|
| |
When a session is created on a UP, the UP will periodically report statistics information and subscriber detection results of the session to the CP.¶
The subsections below give an overview of various "dial-up" interactions over the Si followed by an overview of the setting of information in the UP by the CP using S-CUSP over the Ci.¶
S-CUSP messages are described in this document using Routing Backus Naur Form (RBNF) as defined in [RFC5511].¶
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 via Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request | |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| | | |
| DHCP ACK | | |
12|<--------------| | |
| | | |
S-CUSP 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 format of the Update_Response message is as follows:¶
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
¶
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 via Si-------| |
| Advertise | | |
5|<--------------| | |
| | | |
| Request | | |
6|-------------->| | |
| | Relay the Request | |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci-------->| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send Reply | |
| 11|<----to UP via Si-------| |
| Reply | | |
12|<--------------| | |
| | | |
Steps 1-7 are a standard DHCP IPv6 access process. The subscriber creation is triggered by a DHCP IPv6 request message. When this message is received, it means that the subscriber has passed the AAA authentication and authorization. Then the CP will create a subscriber session on the UP. This is achieved by sending an Update_Request message to the UP (step 8).¶
The format of the Update_Request message is as follows:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
¶
The UP will reply with an Update_Response message (step 9). The format of the Update_Response message is as follows:¶
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
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 | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send Router Advertise | |
| | (RA) | |
| 6|<----to UP 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|<--------------| | |
| | | |
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.¶
This is achieved by sending an Update_Request message to the UP (step 4).¶
The format of the Update_Request message is as follows:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
¶
The UP will reply with an Update_Response message (step 5). The format of the Update_Response message is as follows:¶
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
The following call flow (Figure 17) shows the DHCP IPv6 and SLAAC access process.¶
RG UP CP AAA
| RS | | |
1|-------------->| | |
| | Relay the RS | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send RA | |
| 6|<----to UP via Si-------| |
| RA | | |
7|<--------------| | |
| | | |
|DHCPv6 Solicit | | |
8|-------------->| | |
| | Relay DHCPv6 Solicit | |
| 9|-----to CP via Si------>| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 10|<--------via Ci---------| |
| | | |
| | Update Subscriber | |
| | Session Response | |
| 11|---------via Ci-------->| |
| | | Accounting |
| | 12|<------------->|
| | Send DHCPv6 Reply | |
| 13|<----to UP via Si-------| |
| | | |
| DHCPv6 Reply | | |
14|<--------------| | |
| | | |
When a subscriber passes AAA authentication, the CP will create a subscriber session on the UP. This is achieved by sending an Update_Request message to the UP (step 4).¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
¶
The UP will reply with an Update_Response message (step 5). The format of the Update_Response is as follows:¶
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
After receiving a DHCPv6 Solicit, the CP will update the subscriber session by sending an Update_Request message with new parameters to the UP (step 10).¶
The format of the Update_Request message is as follows:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
¶
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>
¶
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 via Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request| |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci-------->| |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| DHCP ACK | | |
12|<--------------| | |
| RS | | |
13|-------------->| | |
| | Relay the RS | |
| 14|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 15|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 16|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 17|---------via Ci-------->| |
| | | |
| | Send the RA | |
| 18|<----to UP via Si-------| |
| RA | | |
19|<--------------| | |
|DHCPv6 Solicit | | |
20|-------------->| | |
| | Relay DHCPv6 Solicit | |
| 21|-----to CP via Si------>| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 22|<--------via Ci---------| |
| | Update Subscriber | |
| | Session Response | |
| 23|---------via Ci-------->| |
| | | Accounting |
| | 24|<------------->|
| | Send DHCPv6 Reply | |
| 25|<----to UP via Si-------| |
| DHCPv6 Reply | | |
26|<--------------| | |
| | | |
The DHCP dual-stack access includes three sets of Update_Request/Update_Response exchanges to create/update a DHCPv4/v6 subscriber session.¶
Create a DHCPv4 session (steps 8 and 9):¶
<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>]
¶
Create a DHCPv6 session (steps 16 and 17):¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
Update DHCPv6 session (steps 22 and 23):¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
L2 static subscriber access processes are as follows:¶
RG UP CP AAA
| | Static Subscriber | |
| | Detection Req. | |
| 1|<-----to UP via Ci------| |
| | Static Subscriber | |
| | Detection Rep. | |
| 2|------to UP via Ci----->| |
| ARP/ND(REQ) | | |
3.1|<--------------| | |
| ARP/ND(ACK) | | |
3.2|-------------->| | |
| | Relay the ARP/ND | |
| 3.3|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3.4|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 3.5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 3.6|---------via Ci-------->| |
| ARP/ND(REQ) | | |
4.1|-------------->| | |
| | Relay the ARP/ND | |
| 4.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 4.3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4.4|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 4.5|---------via Ci-------->| |
| ARP/ND(ACK) | | |
4.6|<--------------| | |
| IP Traffic | | |
5.1|-------------->| | |
| | Relay the IP Traffic | |
| 5.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 5.3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 5.4|<--------via Ci-------->| |
| | Create Subscriber | |
| | Session Response | |
| 5.5|---------via Ci-------->| |
| ARP/ND(REQ) | | |
5.6|<--------------| | |
| ARP/ND(ACK) | | |
5.7|-------------->| | |
| | | |
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 formats of the messages are as follows:¶
<Update_Request Message> ::= <Common Header>
<IPv4 Static Subscriber Detect TLVs>
<IPv6 Static Subscriber Detect TLVs>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
For L2 static subscriber access, there are three ways to trigger the access process:¶
From a subscriber session point of view, the procedures and the message formats for the three cases above are the same, as follows.¶
IPv4 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
¶
IPv6 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
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 | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | Accounting |
| | 7|<------------->|
| | | |
In 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>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
¶
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 | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
7|<------------->|<---------via Si------->| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | Update Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
7'|<------------->|<---------via Si------->| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 8'|<---------via Ci--------| |
| | Update Subscriber | |
| | Session Response | |
| 9'|---------via Ci-------->| |
| | | Accounting |
| | 10'|<------------->|
| | | |
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 steps 7 and 7'); after that, it will trigger an update (steps 8-9 and 8'-9') to the subscriber session. The formats of the update 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>
¶
Figure 22 shows a combination of IPv4 and IPv6 PPPoE access call 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 | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create v4 Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | Accounting |
| | 7|<------------->|
| PPP IP6CP | PPP IP6CP | |
4'|<------------->|<---------via Si------->| |
| | | |
| | Create V6 Subscriber | |
| | Session Request | |
| 5'|<--------via Ci---------| |
| | Create v6 Subscriber | |
| | Session Response | |
| 6'|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
8|<------------->|<---------via Si------->| |
| | | |
| | Update v6 Subscriber | |
| | Session Request | |
| 9|<---------via Ci--------| |
| | Update v6 Subscriber | |
| | Session Response | |
| 10|---------via Ci-------->| |
| | | Accounting |
| | 7'|<------------->|
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
8'|<------------->|<---------via Si------->| |
| | | |
| | Update v6 Subscriber | |
| | Session Request | |
| 9'|<--------via Ci---------| |
| | Update v6 Subscriber | |
| | Session Response | |
| 10'|---------via Ci-------->| |
| | | Accounting |
| | 7"|<------------->|
| | | |
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:¶
Create an IPv4 PPPoE subscriber session (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>]
¶
Create an IPv6 PPPoE subscriber session (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>
¶
Update the IPv6 PPPoE subscriber session (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>
¶
Figure 23 shows the WLAN access call flow.¶
RG UP CP AAA Web Server
| DHCP | | | |
| Discovery | | | |
1|------------>| | | |
| | DHCP Discovery | | |
| 2|-----via Si---->| AAA | |
| | DHCP Offer |<-------->| |
| 3|<----via Si-----| | |
| DHCP Offer | | | |
4|<------------| | | |
| DHCP Request| | | |
5|------------>| | | |
| | DHCP Request | | |
| 6|-----via Si---->| | |
| | | | |
| | Create Session | | |
| | Request | | |
| 7|<----via Ci-----| | |
| | Create Session | | |
| | Response | | |
| 8|----via Ci----->| | |
| | | | |
| | DHCP ACK | | |
| 9|<----via Si-----| | |
| DHCP ACK | | | |
10|<------------| | | |
| | | | |
| Subscriber | | | |
| HTTP Traffic| | | |
11|------------>|--> | | |
| | | Web URL | | |
| Traffic | | Redirect | | |
| Redirection | | | | |
12|<------------|<-+ | | |
| |
13|-----------------Redirect to Web Server------------->|
| |
14|<----------------Push HTTP Log-in Page---------------|
| |
15|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 16|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 17|<-------->| |
| | | | |
| | Update Session | | |
| | Request | | |
| 18|<----via Ci-----| | |
| | Update Session | | |
| | Response | | |
| 19|-----via Ci---->| | |
| | | | |
WLAN access starts with the DHCP dial-up process (steps 1-6). After that, the CP will create a subscriber session on the UP (steps 7-8). The formats of the session creation messages are as follows:¶
IPv4 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
¶
IPv6 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
After step 10, the RG will be allocated an IP address, and its first HTTP packet will be redirected to a web server for subscriber authentication (steps 11-17). After the web authentication, if the result is positive, the CP will update the subscriber session by using the following message exchanges:¶
IPv4 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
¶
IPv6 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
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 | | |
| | Negotiation | | |
| | SCCRQ/ | | |
| | SCCRP/ | | |
| | SCCCN | | |
| 5|<---via Si--->| | |
| | /\ |
| | || Forward |
| | \/ |
| |<-----------via Routing---------->|
| | |
| | L2TP Session | | |
| | Negotiation | | |
| | ICRQ/ | | |
| | ICRP/ | | |
| | ICCN | | |
| 6|<---via Si--->| | |
| | /\ |
| | || Forward |
| | \/ |
| |<-----------via Routing---------->|
| | |
| | Create | | |
| | Subscriber | | |
| | Session Req | | |
| 7|<---via Ci----| | |
| | Create | | |
| | Subscriber | | |
| | Session Rep | | |
| 8|----via Ci--->| | |
| | | | |
| |
| PAP/CHAP (Triggered by LNS) |
9|<-----------------via Routing----------------->|
| |
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>
¶
RG LAC UP(LNS) AAA CP(LNS)
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | L2TP Tunnel | L2TP Tunnel |
| | Negotiation | Negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP Session | L2TP Session |
| | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create Subscriber |
| | | Session Request |
| | 6|<-----via Ci-------|
| | | Create Subscriber |
| | | Session Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| | | |
| |
| PPP IPCP |
10|<--------------------------------------------->|
| |
| | | Update Subscriber |
| | | Session Request |
| | 11|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 12|------via Ci------>|
| | | |
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:¶
<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 a AAA authentication. If the authentication result is positive, a PPP 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>]
¶
RG LAC UP(LNS) AAA CP(LNS)
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | L2TP Tunnel | L2TP Tunnel |
| | Negotiation | Negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP Session | L2TP Session |
| | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create Subscriber |
| | | Session Request |
| | 6|<-----via Ci-------|
| | | Create Subscriber |
| | | Session Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| | | | |
| |
| PPP IP6CP |
10|<--------------------------------------------->|
| |
| | | Update Subscriber |
| | | Session Request |
| | 11|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 12|------via Ci------>|
| | |
| ND Negotiation | ND Negotiation |
13|<------------------------->|<-----via Si------>|
| | |
| | | Update Subscriber |
| | | Session Request |
| | 14|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 15|------via Ci------>|
| | | |
Steps 1-12 are the same as L2TP LNS IPv4 access. Steps 1-5 finish the normal L2TP dial-up process. When the L2TP session and tunnel negotiations are finished, the LNS-CP will create an L2TP LNS subscriber session on the LNS-UP. The format of the messages is as follows:¶
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
After that, the LNS-CP will trigger a AAA authentication. If the authentication result is positive, a PPP IP6CP process will follow, 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 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>
¶
RG UP CP AAA
| | Public Address Block | |
| | Allocation Request | |
| 1|<--------via Ci-------->| |
| | Public Address Block | |
| | Allocation Reply | |
| 2|---------via Ci-------->| |
| Subscriber | | |
| Access Request| Subscriber | |
3|-------------->| Access Request | |
| 4|----------via Si------->| |
| | | AAA |
| | Subscriber | Req/Rep |
| Subscriber | Access Reply 5|<------------->|
| Access Reply 6|<---------via Si--------| |
7|<--------------| | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| | (with NAT information) | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | | with source |
| | | information |
| | 10|<------------->|
| | | Public IP + |
| | | Port Range |
| | | to Private IP|
| | | Mapping |
| | | |
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:¶
<Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV>
<Addr_Allocation_Ack Message> ::= <Common Header>
<Address 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 CGN Port Range TLV in the Update_Response message.¶
RG UP CP AAA Web Server
| User traffic| | | |
1|------------>| | | |
| | User traffic | | |
| 2|-----via Si---->| AAA | |
| | | Req/Rep | |
| | 3|<-------->| |
| | Create Session | | |
| | Request | | |
| 4|<----via Ci-----| | |
| | Create Session | | |
| | Response | | |
| 5|----via Ci----->| | |
| | | | |
| HTTP traffic| | | |
6|------------>| | | |
| | | | |
| Redirect to | | | |
| Web URL | | | |
7|<------------| | | |
| | | | |
| |
8|-----------------Redirected to Web Server----------->|
| |
9|<----------------Push HTTP Log-in Page---------------|
| |
10|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 11|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 12|<-------->| |
| | | | |
| | Update Session | | |
| | Request | | |
| 13|<----via Ci-----| | |
| | Update Session | | |
| | Response | | |
| 14|----via Ci----->| | |
| | | | |
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>
<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 server to finish the web authentication. Once the web authentication is passed, the CP will trigger another AAA authentication. After the AAA authentication, the CP will update the session with the following message exchanges:¶
IPv4 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
¶
IPv6 Case:¶
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
¶
RG UP CP AAA
| | L3 access | |
| | control list | |
| 1|<----via Ci-----| |
| User | | |
| traffic | | |
2|------------>| | |
| | User traffic | |
| 3|-----via Si---->| |
| | | AAA |
| | | Req/Rep |
| | 4|<-------->|
| | | |
| | Create Session | |
| | Request | |
| 5|<----via Ci-----| |
| | Create Session | |
| | Response | |
| 6|----via Ci----->| |
| | | |
In this case, the CP must install on the UP an access control list, which is used by the UP to determine whether or not an RG is 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>
¶
RG UP CP AAA
| User Access | User Access | AAA |
| Request | Request | Req/Rep |
1|<----------->|<----via Si---->|<-------->|
| | | |
| | Create Session | |
| | Request | |
| 2|<----via Ci---->| |
| | | |
| | Create Session | |
| | Response | |
| 3|----via Ci----->| |
| | | |
| Multicast | | |
| negotiation | | |
4|<----------->| | |
| | | |
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, there will be a Multicast-ProfileV4 sub-TLV present in the Subscriber Policy TLV:¶
<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, there will be a Multicast-ProfileV6 sub-TLV present in the Subscriber Policy TLV:¶
<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>
¶
An S-CUSP message consists of a common header followed by a variable-length body consisting entirely of TLVs. Receiving an S-CUSP message with an unknown message type or missing mandatory TLV MUST trigger an Error message (see Section 6.7) or a Response message with an Error Information TLV (see Section 7.6).¶
Conversely, if a TLV is optional, the TLV may or may not be present. Optional TLVs are indicated in the message formats shown in this document by being enclosed in square brackets.¶
This section specifies the format of the common S-CUSP message header and lists the defined messages.¶
Network byte order is used for all multi-byte fields.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines the following control messages:¶
| Type | Name | Notes and TLVs that can be carried |
|---|---|---|
| 1 | Hello | Hello TLV, Keepalive TLV |
| 2 | Keepalive | A common header with the Keepalive message type |
| 3 | Sync_Request | Synchronization request |
| 4 | Sync_Begin | Synchronization starts |
| 5 | Sync_Data | Synchronization data: TLVs specified in Section 7 |
| 6 | Sync_End | End synchronization |
| 7 | Update_Request | TLVs specified in Sections 7.6-7.9 |
| 8 | Update_Response | TLVs specified in Sections 7.6-7.9 |
The Hello message is used for S-CUSP session establishment and version negotiation. The 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>]
¶
The return code and negotiation result will be carried in the Error Information TLV. They are listed as follows:¶
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>¶
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.¶
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:¶
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>
[<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>
[<IPv4 Routing TLV>]
[<IPv6 Routing TLV>]
[<Subscriber TLVs>]
¶
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:¶
The Update_Request message is a 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 field of the carried TLVs. As defined in Section 7.1, the Oper field can be set to either Update or Delete when a TLV is carried in an Update_Request message.¶
When the Oper field is set to Update, it means to create or update a subscriber session. If the 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>
[<IPv4 Routing TLV>]
[<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, which is defined in Section 6.2.8.¶
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:¶
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>
[<Subscriber Traffic Statistics Report TLV>]
[<Subscriber Detection Result Report TLV>]
¶
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>]
¶
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 |
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>
¶
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>
¶
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>
¶
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>
¶
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>
¶
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>
¶
The Vendor message, in conjunction with the Vendor TLV and Vendor sub-TLV, can be used by vendors to extend S-CUSP. The 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>]
¶
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>
¶
This section specifies the following:¶
See Section 8 for a list of all defined TLVs and sub-TLVs.¶
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section specifies the binary format of several standard basic data fields that are used within other data structures in this specification.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
In some cases, the Value portion of a TLV, as specified in Section 7.1, can contain one or more sub-TLVs formatted as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
The sub-TLVs currently specified are defined in the following subsections.¶
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 zero octets to 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 |
| 9 | NAT-Instance | The name of a NAT instance |
| 10 | Pool-Name | The name of an address pool |
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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
These fields are unsigned integers. More details about CIR, PIR, CBS, and PBS can be found in [RFC2698].¶
The Egress-CAR sub-TLV indicates the authorized downstream Committed Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub-TLV is 8. Its sub-TLV length is 16 octets. The format of the value part is as defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
These fields are unsigned integers. More details about CIR, PIR, CBS, and PBS can be found in [RFC2698].¶
The If-Desc sub-TLV is defined to designate an interface. It is an optional sub-TLV that may be carried in those TLVs that have an If-Index or Out-If-Index field. The If-Desc sub-TLV is used as a 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 (Section 8.6). The format of the 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-Type (1-5)| Chassis | Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Slot | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc Sub-TLV (Physical Port)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (6-7) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logic-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc Sub-TLV (Virtual Port)
Where:¶
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 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The Vendor sub-TLV is intended to be used inside the Value portion of the Vendor TLV (Section 7.13). It provides a Sub-Type that effectively extends the sub-TLV type in the sub-TLV header and provides for versioning of Vendor sub-TLVs.¶
The value part of the Vendor sub-TLV is formatted as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (other as specified by vendor) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Since vendor code will be handling the sub-TLV after the Vendor-ID field is recognized, the remainder of the sub-TLV can be organized however the vendor wants. But it desirable for a vendor to be able to define multiple different Vendor sub-TLVs and to keep track of different versions of its vendor-defined sub-TLVs. Thus, it is RECOMMENDED that the vendor assign a Sub-Type value for each of that vendor's sub-TLVs that is different from other Sub-Type values that vendor has used. Also, when modifying a vendor-defined sub-TLV in a way potentially incompatible with a previous definition, the vendor SHOULD increase the value it is using in the Sub-Type-Version field.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
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 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, and the connection is torn down. If the result of the AND of the Sub-Versions supported is 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, and 4 is the highest Sub-Version supported by both sides. So Sub-Version 4 is used for the session that has been negotiated.¶
The result of the logical AND of the Capabilities bits will show what additional capabilities both sides support. If this result is zero, there are no such capabilities, so none can be used during the session. If this result is 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.¶
The Keepalive TLV is carried in the Hello message. It provides timing information for this feature. The format of 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The Error Information TLV is a common TLV that can be used in many responses (e.g., Update_Response message) and ACK messages (e.g., Addr_Allocation_Ack 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
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.¶
The format of the BAS Function TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Mode | Auth-Method4 | Auth-Method6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The IF-Desc sub-TLV can be carried.¶
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Indicates whether IPv4 packets can trigger a subscriber to go online.¶
Indicates whether IPv6 packets can trigger a subscriber to go online.¶
Indicates whether ARP packets can trigger a subscriber to go online.¶
Indicates whether ND packets can trigger a subscriber to go online.¶
Used for UP detection.¶
Used for UP detection.¶
Indicates whether ARP proxy is enabled on the interface.¶
Indicates whether ND proxy is enabled on the interface.¶
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 dial-up (as defined in Section 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.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
1 bit shown as "A" in the figure above (Figure 44). Indicates whether the UP should advertise the route. The following flag values are defined:¶
The VRF-Name and/or If-Desc sub-TLVs can be carried.¶
The IPv6 Routing TLV is used to carry IPv6 network routing information.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
1 bit shown as "A" in the figure above (Figure 45). Indicates whether the UP should advertise the route. The following flags are defined:¶
The If-Desc and VRF-Name sub-TLVs can be carried.¶
The Subscriber TLVs are defined for a CP to send the basic information about a user to a UP.¶
The Basic Subscriber TLV is used to carry the common information for all kinds of access subscribers. It is carried in an Update_Request message.¶
The format of the Basic Subscriber TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Oper-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Type |Sub-Access-Type| Account-Type | Address Family|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect-Times | Detect-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Indicates whether PPP termination or PPP relay is used.¶
Indicates whether traffic statistics are collected independently.¶
The type of IP address.¶
The VRF-Name sub-TLV and If-Desc sub-TLV can be carried.¶
The PPP Subscriber TLV is defined to carry PPP information of a user from a CP to a UP. It will be carried in an Update_Request message when PPPoE or L2TP access is used.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSS-Value | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Indicates whether the MSS is enabled.¶
The IPv4 Subscriber TLV is defined to carry IPv4-related information for a BNG user. It will be carried in an Update_Request message when IPv4 IPoE or PPPoE access is used.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway-IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Push advertisement.¶
Push IPv4 Web.¶
UP returns ARP Req or PPP Echo.¶
User Unicast Reverse Path Forwarding (URPF) flag.¶
The IPv6 Subscriber TLV is defined to carry IPv6-related information for a BNG user. It will be carried in an Update_Request message when IPv6 IPoE or PPPoE access is used.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User PD-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway ND-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Link-Local-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name Sub-TLV (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Push advertisement.¶
Push IPv6 Web.¶
The UP returns ARP Req or PPP Echo.¶
User Reverse Path Forwarding (URPF) flag.¶
The IPv4 Static Subscriber Detect TLV is defined to carry IPv4-related information for a static access subscriber. It will be carried in an Update_Request message when IPv4 static access on a UP needs to be enabled.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The VRF-Name and If-Desc sub-TLVs may be carried.¶
The IPv6 Static Subscriber Detect TLV is defined to carry IPv6-related information for a static access subscriber. It will be carried in an Update_Request message when needed to enable IPv6 static subscriber detection on a UP.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
VRF-Name and If-Desc sub-TLVs may be carried¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The L2TP-LNS Subscriber TLV is defined to carry the related information for a L2TP LNS access subscriber. It will be carried in an Update_Request message when L2TP LNS access is used.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The L2TP-LAC Tunnel TLV is defined to carry information related to the L2TP LAC tunnel. It will be carried in the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The L2TP-LNS Tunnel TLV is defined to carry information related to the L2TP LNS tunnel. It will be carried in the Update_Request message when L2TP LNS access is used.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
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.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Operation code.¶
Operation Result.¶
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.¶
The format of the TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-Priority | E-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The sub-TLVs that are present can occur in any order.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT-Port-Start | NAT-Port-End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The TLVs in this section are for reporting interface and board-level information from the UP to the CP.¶
The Interface Status TLV is used to carry the status information of an interface on a UP. It is carried in a Report message.¶
The format of the value part of this TLV is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC-Address (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC-Address (lower part) | Phy-State | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Physical status of the interface.¶
The Board Status TLV is used to carry the status information of a board on an UP. It is carried in a Report message.¶
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 | Sub-Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The type of board used.¶
Indicates whether there are issues with the board.¶
The Address Allocation Request TLV is used to request address allocation from the CP. 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.¶
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The Address Allocation Response TLV is used to return the address allocation 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Indicates success or an error.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Indicates success or an error:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The Address Release Response TLV is used to return the address release result. It is carried in the Addr_Release_Ack 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Traffic type. It can be one of the following options:¶
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. The result can be used by the CP to determine how to deal with the subscriber session (e.g., delete the session if detection failed).¶
The format of this TLV value part is as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect-Type | Detect-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
The Vendor 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.¶
The value part of the Vendor TLV is formatted as follows:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Since vendor code will be handling the TLV after the Vendor-ID field is recognized, the remainder of the TLV 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.¶
This section 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.¶
| Type | Name | Section of This Document |
|---|---|---|
| 0 | Reserved | |
| 1 | Hello | 6.2.1 |
| 2 | Keepalive | 6.2.2 |
| 3 | Sync_Request | 6.2.3 |
| 4 | Sync_Begin | 6.2.4 |
| 5 | Sync_Data | 6.2.5 |
| 6 | Sync_End | 6.2.6 |
| 7 | Update_Request | 6.2.7 |
| 8 | Update_Response | 6.2.8 |
| 9 | Report | 6.4 |
| 10 | Event | 6.3 |
| 11 | Vendor | 6.6 |
| 12 | Error | 6.7 |
| 13-199 | Unassigned | |
| 200 | Addr_Allocation_Req | 6.5.1 |
| 201 | Addr_Allocation_Ack | 6.5.2 |
| 202 | Addr_Renew_Req | 6.5.3 |
| 203 | Addr_Renew_Ack | 6.5.4 |
| 204 | Addr_Release_Req | 6.5.5 |
| 205 | Addr_Release_Ack | 6.5.6 |
| 206-254 | Unassigned | |
| 255 | Reserved |
| Type | Name | Usage Description |
|---|---|---|
| 0 | Reserved | - |
| 1 | BAS Function | Carries the BNG access functions to be enabled or disabled on specified interfaces. |
| 2 | Basic Subscriber | Carries the basic information about a BNG subscriber. |
| 3 | PPP Subscriber | Carries the PPP information about a BNG subscriber. |
| 4 | IPv4 Subscriber | Carries the IPv4 address of a BNG subscriber. |
| 5 | IPv6 Subscriber | Carries the IPv6 address of a BNG subscriber. |
| 6 | Subscriber Policy | Carries the policy information applied to a BNG subscriber. |
| 7 | IPv4 Routing | Carries the IPv4 network routing information. |
| 8 | IPv6 Routing | Carries the IPv6 network routing information. |
| 9 | IPv4 Static Subscriber Detect | Carries the IPv4 static subscriber detect information. |
| 10 | IPv6 Static Subscriber Detect | Carries the IPv6 static subscriber detect information. |
| 11 | L2TP-LAC Subscriber | Carries the L2TP LAC subscriber information. |
| 12 | L2TP-LNS Subscriber | Carries the L2TP LNS subscriber information. |
| 13 | L2TP-LAC Tunnel | Carries the L2TP LAC tunnel subscriber information. |
| 14 | L2TP-LNS Tunnel | Carries the L2TP LNS tunnel subscriber information. |
| 15 | Subscriber CGN Port Range | Carries the public IPv4 address and related port range of a BNG subscriber. |
| 16-99 | Unassigned | - |
| 100 | Hello | Used for version and Keepalive timers negotiation. |
| 101 | Error Information | Carried in the Ack of the control message. Carries the processing result, success, or error. |
| 102 | Keepalive | Carried in the Hello message for Keepalive timers negotiation. |
| 103-199 | Unassigned | - |
| 200 | Interface Status | Interfaces status reported by the UP including physical interfaces, sub-interfaces, trunk interfaces, and tunnel interfaces. |
| 201 | Board Status | Board information reported by the UP including the board type and in-position status. |
| 202-299 | Unassigned | - |
| 300 | Subscriber Traffic Statistics | User traffic statistics. |
| 301 | Subscriber Detection Result | User detection information. |
| 302 | Update Response | The processing result of a subscriber session update. |
| 303-299 | Unassigned | - |
| 400 | Address Allocation Request | Request address allocation. |
| 401 | Address Allocation Response | Address allocation response. |
| 402 | Address Renewal Request | Request for address lease renewal. |
| 403 | Address Renewal Response | Response to a request for extending an IP address lease. |
| 404 | Address Release Request | Request to release the address. |
| 405 | Address Release Response | Ack of a message releasing an IP address. |
| 406-1023 | Unassigned | - |
| 1024 | Vendor | As implemented by the vendor. |
| 1039-4095 | Unassigned | - |
TLV operation codes appear in the Oper field in the header of some TLVs. See Section 7.1.¶
| Code | Operation |
|---|---|
| 0 | Reserved |
| 1 | Update |
| 2 | Delete |
| 3-15 | Unassigned |
See Section 7.3.¶
| Type | Name | Section of This Document |
|---|---|---|
| 0 | Reserved | |
| 1 | VRF Name | 7.3.1 |
| 2 | Ingress-QoS-Profile | 7.3.1 |
| 3 | Egress-QoS-Profile | 7.3.1 |
| 4 | User-ACL-Policy | 7.3.1 |
| 5 | Multicast-ProfileV4 | 7.3.1 |
| 6 | Multicast-ProfileV6 | 7.3.1 |
| 7 | Ingress-CAR | 7.3.2 |
| 8 | Egress-CAR | 7.3.3 |
| 9 | NAT-Instance | 7.3.1 |
| 10 | Pool-Name | 7.3.1 |
| 11 | If-Desc | 7.3.4 |
| 12 | IPv6-Address List | 7.3.5 |
| 13 | Vendor | 7.3.6 |
| 12-64534 | Unassigned | |
| 65535 | Reserved |
| Value | Name | Remarks |
|---|---|---|
| 0 | Success | Success |
| 1 | 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 basic error codes. |
| 1000 | Reserved | |
| 1001 | Version-Mismatch | The version negotiation fails. Terminate. The subsequent service processes corresponding to the UP are suspended. |
| 1002 | Keepalive Error | The keepalive negotiation fails. |
| 1003 | Timer Expires | The establishment timer expired. |
| 1004-1999 | Unassigned | Unassigned error codes for version negotiation. |
| 2000 | Reserved | |
| 2001 | Synch-NoReady | The data to be smoothed is not ready. |
| 2002 | Synch-Unsupport | The request for smooth data is not supported. |
| 2003-2999 | Unassigned | Unassigned data synchronization error codes. |
| 3000 | Reserved | |
| 3001 | Pool-Mismatch | The corresponding address pool cannot be found. |
| 3002 | Pool-Full | The address pool is fully allocated, and no address segment is available. |
| 3003 | Subnet-Mismatch | The address pool subnet cannot be found. |
| 3004 | Subnet-Conflict | Subnets in the address pool have been classified into other clients. |
| 3005-3999 | Unassigned | Unassigned error codes for address allocation. |
| 4000 | Reserved | |
| 4001 | Update-Fail-No-Res | The forwarding table fails to be delivered because the forwarding resources are insufficient. |
| 4002 | QoS-Update-Success | The QoS policy takes effect. |
| 4003 | QoS-Update-Sq-Fail | Failed to process the queue in the QoS policy. |
| 4004 | QoS-Update-CAR-Fail | Processing of the CAR in the QoS policy fails. |
| 4005 | Statistic-Fail-No-Res | Statistics processing failed due to insufficient statistics resources. |
| 4006-4999 | Unassigned | Unassigned forwarding table delivery error codes. |
| 5000-4294967295 | Reserved |
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 |
| 1 | Fast Ethernet (FE) |
| 2 | GE |
| 3 | 10GE |
| 4 | 100GE |
| 5 | Eth-Trunk |
| 6 | Tunnel |
| 7 | VE |
| 8-254 | Unassigned |
| 255 | Reserved |
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 |
| 255 | Reserved |
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:¶
| Bit | Meaning |
|---|---|
| 0x01 | PPPoE authentication |
| 0x02 | DOT1X authentication |
| 0x04 | Web authentication |
| 0x08 | Web fast authentication |
| 0x10 | Binding authentication |
| 0x20 | Reserved |
| 0x40 | Reserved |
| 0x80 | Reserved |
| Bit | Meaning |
|---|---|
| 0x01 | PPPoE authentication |
| 0x02 | DOT1X authentication |
| 0x04 | Web authentication |
| 0x08 | Web fast authentication |
| 0x10 | Binding authentication |
| 0x20 | Reserved |
| 0x40 | Reserved |
| 0x80 | Reserved |
Values of the Route-Type field in the IPv4 and IPv6 Routing TLVs (see 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 |
| 65535 | Reserved |
Values of the Access-Type field in the Basic Subscriber TLV (see Section 7.9.1) defined in this document are as follows:¶
| Value | Meaning |
|---|---|
| 0 | 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 |
| 255 | Reserved |
This document has no IANA actions.¶
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 the decision of the network operator. See [RFC6241] for Mi/NETCONF security. Security on the Si is dependent on the tunneling protocol used, which is out of scope for this document. Security for the Ci, over which S-CUSP flows, is further discussed below.¶
S-CUSP messages do not provide security. Thus, if these messages are exchanged in an environment where security is a concern, that security MUST be provided by another protocol such as TLS 1.3 [RFC8446] or IPsec. TLS 1.3 is the mandatory-to-implement protocol for interoperability. The use of a particular security protocol on the Ci is determined by configuration. Such security protocols need not always be used, and lesser security precautions might be appropriate because, in some cases, the communication between the CP and UP is in a benign environment.¶
The helpful comments and suggestions from the following individuals are hereby acknowledged:¶