< draft-chz-simple-cu-separation-bng-protocol-01.txt   draft-chz-simple-cu-separation-bng-protocol-02.txt >
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Intended status: Informational China Mobile Intended status: Informational China Mobile
D. Eastlake D. Eastlake
Futurewei Technologies Futurewei Technologies
M. Chen M. Chen
Huawei Technologies Huawei Technologies
F. Qin F. Qin
Z. Li Z. Li
China Mobile China Mobile
T. Chua T. Chua
Singapore Telecommunications Singapore Telecommunications
Expires: December 13, 2019 June 14, 2019 Expires: December 22, 2019 June 23, 2019
The China Mobile, Huawei, and ZTE BNG The China Mobile, Huawei, and ZTE BNG
Simple Control and User Plane Separation Protocol (S-CUSP) Simple Control and User Plane Separation Protocol (S-CUSP)
draft-chz-simple-cu-separation-bng-protocol-01 draft-chz-simple-cu-separation-bng-protocol-02
Abstract Abstract
To support Control Plane (CP) and User Plane (UP) Separation (CUPS) To support Control Plane (CP) and User Plane (UP) Separation (CUPS)
for fixed network Broadband Network Gateway (BNG) service providers, for fixed network Broadband Network Gateway (BNG) service providers,
China Mobile, Huawei Technologies, and ZTE have developed a simple China Mobile, Huawei Technologies, and ZTE have developed a simple
CUPS control channel Protocol (S-CUSP). CUPS control channel Protocol (S-CUSP).
This document is not an IETF standard and does not have IETF This document is not an IETF standard and does not have IETF
consensus. It is presented here to make the S-CUSP specification consensus. It is presented here to make the S-CUSP specification
skipping to change at page 3, line 30 skipping to change at page 3, line 30
3.3.2. Control Interface...............................14 3.3.2. Control Interface...............................14
3.3.3. Management Interface............................14 3.3.3. Management Interface............................14
3.4. BNG CUPS Procedure Overview.......................14 3.4. BNG CUPS Procedure Overview.......................14
4. S-CUSP Protocol Overview..............................18 4. S-CUSP Protocol Overview..............................18
4.1. Control Channel Related Procedures................18 4.1. Control Channel Related Procedures................18
4.1.1. S-CUSP Session Establishment....................18 4.1.1. S-CUSP Session Establishment....................18
4.1.2. Keep Alive......................................19 4.1.2. Keep Alive......................................19
4.2. Node Related Procedures...........................20 4.2. Node Related Procedures...........................20
4.2.1. UP Resource Report..............................20 4.2.1. UP Resource Report..............................20
4.2.2. Enable BAS Function on Access Interface.........20 4.2.2. Update BAS Function on Access Interface.........21
4.2.3. Update Subscriber Network Routing...............21 4.2.3. Update Network Routing..........................21
4.2.4. CGN Public IP Address Allocation................21 4.2.4. CGN Public IP Address Allocation................22
4.2.5. Data Synchronization between the CP and UP......23 4.2.5. Data Synchronization between the CP and UP......23
4.3. Subscriber Session Related Procedures.............24 4.3. Subscriber Session Related Procedures.............24
4.3.1. Create Subscriber Session.......................25 4.3.1. Create Subscriber Session.......................25
4.3.2. Update Subscriber Session.......................26 4.3.2. Update Subscriber Session.......................26
4.3.3. Delete Subscriber Session.......................26 4.3.3. Delete Subscriber Session.......................27
4.3.4. Subscriber Session Events Report................27 4.3.4. Subscriber Session Events Report................27
5. S-CUSP Call Flows.....................................28 5. S-CUSP Call Flows.....................................29
5.1. IPoE..............................................28 5.1. IPoE..............................................29
5.1.1. DHCPv4 Access...................................28 5.1.1. DHCPv4 Access...................................29
5.1.2. DHCPv6 Access...................................29 5.1.2. DHCPv6 Access...................................30
5.1.3. IPv6 SLAAC Access...............................31 5.1.3. IPv6 SLAAC Access...............................32
5.1.4. DHCPv6 + SLAAC Access...........................32 5.1.4. DHCPv6 + SLAAC Access...........................33
5.1.5. DHCP Dual Stack Access..........................34 5.1.5. DHCP Dual Stack Access..........................35
5.1.6. L2 Static Subscriber Access.....................36 5.1.6. L2 Static Subscriber Access.....................37
5.2. PPPoE.............................................39 5.2. PPPoE.............................................40
5.2.1. IPv4 PPPoE Access...............................39 5.2.1. IPv4 PPPoE Access...............................40
5.2.2. IPv6 PPPoE Access...............................40 5.2.2. IPv6 PPPoE Access...............................41
5.2.3. PPPoE Dual Stack Access.........................42 5.2.3. PPPoE Dual Stack Access.........................43
5.3. WLAN Access.......................................44 5.3. WLAN Access.......................................45
5.4. L2TP..............................................46 5.4. L2TP..............................................47
5.4.1. L2TP LAC Access.................................46 5.4.1. L2TP LAC Access.................................47
5.4.2. L2TP LNS IPv4 Access............................48 5.4.2. L2TP LNS IPv4 Access............................49
5.4.3. L2TP LNS IPv6 Access............................50 5.4.3. L2TP LNS IPv6 Access............................51
5.5. CGN (Carrier Grade NAT)...........................52 5.5. CGN (Carrier Grade NAT)...........................54
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
Table of Contents (continued) Table of Contents (continued)
5.6. L3 Leased Line Access.............................54 5.6. L3 Leased Line Access.............................55
5.6.1. Web Authentication..............................54 5.6.1. Web Authentication..............................55
5.6.2. User Traffic Trigger............................56 5.6.2. User Traffic Trigger............................57
5.7. Multicast Access..................................57 5.7. Multicast Access..................................58
6. S-CUSP Message Formats................................59 6. S-CUSP Message Formats................................60
6.1. Common Message Header.............................59 6.1. Common Message Header.............................60
6.2. Control Messages..................................60 6.2. Control Messages..................................61
6.2.1. Hello Message...................................60 6.2.1. Hello Message...................................61
6.2.2. Keepalive Message...............................61 6.2.2. Keepalive Message...............................62
6.2.3. Sync_Request Message............................61 6.2.3. Sync_Request Message............................62
6.2.4. Sync_Begin Message..............................61 6.2.4. Sync_Begin Message..............................62
6.2.5. Sync_Data Message...............................62 6.2.5. Sync_Data Message...............................63
6.2.6. Sync_End Message................................62 6.2.6. Sync_End Message................................63
6.2.7. Update_Request Message..........................63 6.2.7. Update_Request Message..........................64
6.2.8. Update_Response Message.........................63 6.2.8. Update_Response Message.........................64
6.3. Event Message.....................................64 6.3. Event Message.....................................65
6.4. Report Message....................................65 6.4. Report Message....................................66
6.5. CGN Messages......................................65 6.5. CGN Messages......................................66
6.5.1. Addr_Allocation_Req Message.....................65 6.5.1. Addr_Allocation_Req Message.....................66
6.5.2. Addr_Allocation_Ack Message.....................65 6.5.2. Addr_Allocation_Ack Message.....................66
6.5.3. Addr_Renew_Req Message..........................66 6.5.3. Addr_Renew_Req Message..........................67
6.5.4. Addr_Renew_Ack Message..........................66 6.5.4. Addr_Renew_Ack Message..........................67
6.5.5. Addr_Release_Req Message........................66 6.5.5. Addr_Release_Req Message........................67
6.5.6. Addr_Release_Ack Message........................66 6.5.6. Addr_Release_Ack Message........................67
6.6. Vendor Message....................................66 6.6. Vendor Message....................................67
6.7 Error Message.......................................67 6.7 Error Message.......................................68
7. S-CUSP TLVs and Sub-TLVs..............................68 7. S-CUSP TLVs and Sub-TLVs..............................69
7.1. Common TLV Header.................................68 7.1. Common TLV Header.................................69
7.2. Basic Data Fields.................................69 7.2. Basic Data Fields.................................70
7.3. Sub-TLV Format and Sub-TLVs.......................70 7.3. Sub-TLV Format and Sub-TLVs.......................71
7.3.1. Name sub-TLVs...................................70 7.3.1. Name sub-TLVs...................................71
7.3.2. Ingress-CAR sub-TLV.............................71 7.3.2. Ingress-CAR sub-TLV.............................72
7.3.3. Egress-CAR sub-TLV..............................71 7.3.3. Egress-CAR sub-TLV..............................72
7.3.4. If-Desc sub-TLV.................................72 7.3.4. If-Desc sub-TLV.................................73
7.3.5. IPv6 Address List sub-TLV.......................74 7.3.5. IPv6 Address List sub-TLV.......................75
7.3.6. Vendor sub-TLV..................................74 7.3.6. Vendor sub-TLV..................................75
7.4. The Hello TLV.....................................76 7.4. The Hello TLV.....................................77
7.5. The Keep Alive TLV................................77 7.5. The Keep Alive TLV................................78
7.6. The Error Information TLV.........................78 7.6. The Error Information TLV.........................79
7.7. BAS Function Enabler TLV..........................78 7.7. BAS Function TLV..................................79
7.8. Routing TLVs......................................81 7.8. Routing TLVs......................................82
7.8.1. IPv4 Routing TLV................................81 7.8.1. IPv4 Routing TLV................................82
7.8.2. IPv6 Routing TLV................................82 7.8.2. IPv6 Routing TLV................................84
7.9. Subscriber TLVs...................................84 7.9. Subscriber TLVs...................................85
7.9.1. Basic Subscriber TLV............................84 7.9.1. Basic Subscriber TLV............................86
7.9.2. PPP Subscriber TLV..............................87 7.9.2. PPP Subscriber TLV..............................88
7.9.3. IPv4 Subscriber TLV.............................88 7.9.3. IPv4 Subscriber TLV.............................89
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
Table of Contents (continued) Table of Contents (continued)
7.9.4. IPv6 Subscriber TLV.............................89 7.9.4. IPv6 Subscriber TLV.............................90
7.9.5. IPv4 Static Subscriber Detect TLV...............90 7.9.5. IPv4 Static Subscriber Detect TLV...............91
7.9.6. IPv6 Static Subscriber Detect TLV...............91 7.9.6. IPv6 Static Subscriber Detect TLV...............93
7.9.7. L2TP-LAC Subscriber TLV.........................93 7.9.7. L2TP-LAC Subscriber TLV.........................94
7.9.8. L2TP-LNS Subscriber TLV.........................93 7.9.8. L2TP-LNS Subscriber TLV.........................95
7.9.9. L2TP-LAC Tunnel TLV.............................94 7.9.9. L2TP-LAC Tunnel TLV.............................95
7.9.10. L2TP-LNS Tunnel TLV............................95 7.9.10. L2TP-LNS Tunnel TLV............................96
7.9.11. Update Response TLV............................96 7.9.11. Update Response TLV............................97
7.9.12. Subscriber Policy TLV..........................97 7.9.12. Subscriber Policy TLV..........................98
7.9.13. Subscriber CGN Port Range TLV..................99 7.9.13. Subscriber CGN Port Range TLV.................100
7.10. Device Status TLVs...............................99 7.10. Device Status TLVs..............................100
7.10.1. Interface Status TLV..........................100 7.10.1. Interface Status TLV..........................101
7.10.2. Board Status TLV..............................100 7.10.2. Board Status TLV..............................101
7.11. CGN TLVs........................................101 7.11. CGN TLVs........................................102
7.11.1. Address Allocation Request TLV................101 7.11.1. Address Allocation Request TLV................102
7.11.2. Address Allocation Response TLV...............102 7.11.2. Address Allocation Response TLV...............103
7.11.3. Address Renewal Request TLV...................103 7.11.3. Address Renewal Request TLV...................104
7.11.4. The Address Renewal Response TLV..............104 7.11.4. The Address Renewal Response TLV..............105
7.11.5. Address Release Request TLV...................105 7.11.5. Address Release Request TLV...................106
7.11.6. The Address Release Response TLV..............105 7.11.6. The Address Release Response TLV..............106
7.12. Event TLVs......................................106 7.12. Event TLVs......................................107
7.12.1. Subscriber Traffic Statistics TLV..............106 7.12.1. Subscriber Traffic Statistics TLV..............108
7.12.2. Subscriber Detection Result TLV...............108 7.12.2. Subscriber Detection Result TLV...............109
7.13. Vendor TLV......................................109 7.13. Vendor TLV......................................110
8. Implementation Status................................111 8. Implementation Status................................112
8.1. Implementations..................................111 8.1. Implementations..................................112
8.1.1. Huawei Technologies............................111 8.1.1. Huawei Technologies............................112
8.1.2. ZTE............................................112 8.1.2. ZTE............................................113
8.1.3. H3C............................................112 8.1.3. H3C............................................113
8.2. Hackathon........................................112 8.2. Hackathon........................................113
8.3. EANTC Testing....................................113 8.3. EANTC Testing....................................114
9. Summary of Major S-CUSP Codepoints...................114 9. Summary of Major S-CUSP Codepoints...................115
9.1. Message Types....................................114 9.1. Message Types....................................115
9.2. TLV Types........................................114 9.2. TLV Types........................................115
9.3. TLV Operation Codes..............................116 9.3. TLV Operation Codes..............................117
9.4. Sub-TLV Types....................................116 9.4. Sub-TLV Types....................................118
9.5. Error Codes......................................117 9.5. Error Codes......................................118
10. IANA Considerations.................................119 10. IANA Considerations.................................120
11. Security Considerations.............................120 11. Security Considerations.............................121
Contributors.............................................121 Contributors.............................................122
Normative References.....................................122
Informative References...................................122 Normative References.....................................123
Authors' Addresses.......................................124 Informative References...................................124
Authors' Addresses.......................................126
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
1. Introduction 1. Introduction
A fixed network Broadband Network Gateway (BNG) is an Ethernet- A fixed network Broadband Network Gateway (BNG) is an Ethernet-
centric IP edge router, and the aggregation point for user traffic. centric IP edge router, and the aggregation point for user traffic.
To provide centralized session management, flexible address To provide centralized session management, flexible address
allocation, high scalability for subscriber management capacity, and allocation, high scalability for subscriber management capacity, and
cost-efficient redundancy, the Control/User (CU) separated BNG cost-efficient redundancy, the Control/User (CU) separated BNG
skipping to change at page 7, line 52 skipping to change at page 8, line 5
CBS: Committed Burst Size. CBS: Committed Burst Size.
CGN: Carrier Grade NAT. CGN: Carrier Grade NAT.
Ci: Control Interface. Ci: Control Interface.
CIR: Committed Information Rate. CIR: Committed Information Rate.
CoA: Change of Authorization. CoA: Change of Authorization.
CP: Control Plane.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
CP: Control Plane.
CP is a user control management component which supports the CP is a user control management component which supports the
management of the UP's resources such as the user entry and management of the UP's resources such as the user entry and
forwarding policy. forwarding policy.
CPE: Customer Premises Equipment. CPE: Customer Premises Equipment.
CU: Control-plane / User-plane. CU: Control-plane / User-plane.
CUSP: Control and User plane Separation Protocol. CUSP: Control and User plane Separation Protocol.
DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the
priority and before the VLAN ID. (This bit was formerly the CFI priority and before the VLAN ID. (This bit was formerly the CFI
(Canonical Format Indicator).) [802.1Q] (Canonical Format Indicator).) [802.1Q]
DHCP: Dynamic Host Configuration Protocol [RFC2131]. DHCP: Dynamic Host Configuration Protocol [RFC2131].
dial-up: This refers to the initial connection messages when a new dial-up: This refers to the initial connection messages when a new
user appears. The name is left over from when users literally user appears. The name is left over from when users literally
dialed up on a modem equipped phone line but herein is applied to dialed up on a modem equipped phone line but herein is applied to
other initial connection techniques. Initial connection is other initial connection techniques. Initial connection is
frequently indicated by the receipt of packets over PPPoE or frequently indicated by the receipt of packets over PPPoE
IPoE. [RFC2516] or IPoE.
EMS: Element Management System. EMS: Element Management System.
IPoE: IP over Ethernet. IPoE: IP over Ethernet.
L2TP: Layer 2 Tunneling Protocol [RFC2661]. L2TP: Layer 2 Tunneling Protocol [RFC2661].
LAC: L2TP Access Concentrator. LAC: L2TP Access Concentrator.
LNS: L2TP Network Server. LNS: L2TP Network Server.
skipping to change at page 8, line 56 skipping to change at page 9, line 5
MSS: Maximum Segment Size. MSS: Maximum Segment Size.
MRU: Maximum Receive Unit. MRU: Maximum Receive Unit.
NAT: Network Address Translation [RFC3022]. NAT: Network Address Translation [RFC3022].
ND: Neighbor Discovery. ND: Neighbor Discovery.
NFV: Network Function Virtualization. NFV: Network Function Virtualization.
NFVI: NFV Infrastructure
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
NFVI: NFV Infrastructure
PBS: Peak Burst Size. PBS: Peak Burst Size.
PD: Prefix Delegation. PD: Prefix Delegation.
PIR: Peak Information Rate. PIR: Peak Information Rate.
PPP: Point to Point Protocol [RFC1661]. PPP: Point to Point Protocol [RFC1661].
PPPoE: PPP over Ethernet. PPPoE: PPP over Ethernet [RFC2516].
RBNF: Routing Backus-Naur Form [RFC5511]. RBNF: Routing Backus-Naur Form [RFC5511].
RG: Residential Gateway. RG: Residential Gateway.
S-CUSP: Simple Control and User Plane Separation Protocol. S-CUSP: Simple Control and User Plane Separation Protocol.
Si: Service Interface. Si: Service Interface.
TLV: Type, Length, Value. See Sections 7.1 and 7.3. TLV: Type, Length, Value. See Sections 7.1 and 7.3.
skipping to change at page 10, line 51 skipping to change at page 11, line 5
3.2. BNG CUPS Architecture Overview 3.2. BNG CUPS Architecture Overview
The functions in a traditional BNG can be divided into two parts: one The functions in a traditional BNG can be divided into two parts: one
is the user access management function, the other is the router is the user access management function, the other is the router
function. The user management function can be centralized and function. The user management function can be centralized and
deployed as a concentrated module or device, called the BNG Control deployed as a concentrated module or device, called the BNG Control
Plane (BNG-CP). The other functions, such as the router function and Plane (BNG-CP). The other functions, such as the router function and
forwarding engine, can be deployed in the form of the BNG User Plane forwarding engine, can be deployed in the form of the BNG User Plane
(BNG-UP). (BNG-UP).
The following figure shows the architecture of CU separated BNG:
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
The following figure shows the architecture of CU separated BNG:
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Neighboring policy and resource management systems | | Neighboring policy and resource management systems |
| | | |
| +-------------+ +-----------+ +---------+ +----------+ | | +-------------+ +-----------+ +---------+ +----------+ |
| |AAA Server| |DHCP Server| | EMS | | MANO | | | |AAA Server| |DHCP Server| | EMS | | MANO | |
| +-------------+ +-----------+ +---------+ +----------+ | | +-------------+ +-----------+ +---------+ +----------+ |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| CU-separated BNG system | | CU-separated BNG system |
skipping to change at page 11, line 55 skipping to change at page 12, line 4
Network Function Virtualization Infrastructure (NFVI). Network Function Virtualization Infrastructure (NFVI).
The User Plane Management module in the BNG Control Plane centrally The User Plane Management module in the BNG Control Plane centrally
manages the distributed BNG User Planes (e.g. load balancing), as manages the distributed BNG User Planes (e.g. load balancing), as
well as the setup, deletion, and maintenance of channels between well as the setup, deletion, and maintenance of channels between
Control Planes and User Planes. Other modules in the BNG control Control Planes and User Planes. Other modules in the BNG control
plane, such as address management, AAA, etc., are responsible for the plane, such as address management, AAA, etc., are responsible for the
connection with outside subsystems in order to fulfill those connection with outside subsystems in order to fulfill those
services. Note that the User Plane SHOULD support both physical and services. Note that the User Plane SHOULD support both physical and
virtual network functions. For example, BNG user plane L3 forwarding virtual network functions. For example, BNG user plane L3 forwarding
related network functions can be disaggregated and distributed across
the physical infrastructure. And the other control plane and
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
related network functions can be disaggregated and distributed across
the physical infrastructure. And the other control plane and
management plane functions in the CU Separation BNG can be moved into management plane functions in the CU Separation BNG can be moved into
the NFVI for virtualization [TR-384]. the NFVI for virtualization [TR-384].
The details of CU separated BNG's function components are as The details of CU separated BNG's function components are as
following: following:
The Control Plane is responsible for the following: The Control Plane is responsible for the following:
1. Address management: unified address pool management and CGN 1. Address management: unified address pool management and CGN
subscriber address traceability management. subscriber address traceability management.
skipping to change at page 14, line 41 skipping to change at page 14, line 41
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| |Establish S-CUSP Channel| | | |Establish S-CUSP Channel| |
| 1|<---------------------->| | | 1|<---------------------->| |
| | | | | | | |
| | Report Board | | | | Report Board | |
| | interface | | | | interface | |
| | information | | | | information | |
| 2|------to CP via Ci----->| | | 2|------to CP via Ci----->| |
| | | | | | | |
| | Enable BAS function | | | | Update BAS function | |
| 3|<-----on UP via Ci------| | | 3| request / response | |
| |<-----on UP via Ci----->| |
| | | | | | | |
| | Notify UP to advertise | | | | Update network routing | |
| | subscriber network | | | | request / response | |
| | routing | | | 4|<------- via Ci-------->| |
| 4|<------- via Ci---------| |
| | | | | | | |
| Dial-up Req | | | | Online Req | | |
5.1|-------------->| | | 5.1|-------------->| | |
| | Relay the Dial-up Req | | | | Relay the Online Req | |
| 5.2|-----to CP via Si------>| Authentication| | 5.2|-----to CP via Si------>| Authentication|
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
| | | Req/Rep | | | | Req/Rep |
| | 5.3|<------------->| | | 5.3|<------------->|
| | Send the Dial-up Rep | | | | Send the Online Rep | |
| 5.4|<----to UP via Si-------| | | 5.4|<----to UP via Si-------| |
| Dial-up Rep | | | | Online Rep | | |
5.5|<--------------| | | 5.5|<--------------| | |
| | Create subscriber | | | | Create subscriber | |
| | session on UP | | | | session on UP | |
| 5.6|<--------via Ci-------->| | | 5.6|<--------via Ci-------->| |
| | | CoA Request | | | | CoA Request |
| | 6.1|<--------------| | | 6.1|<--------------|
| | Update session on UP | | | | Update session on UP | |
| 6.2|<--------via Ci-------->| | | 6.2|<--------via Ci-------->| |
| | | CoA Response | | | | CoA Response |
| | 6.3|-------------->| | | 6.3|-------------->|
skipping to change at page 15, line 56 skipping to change at page 16, line 4
1. S-CUSP session establishment: This is the first step of BNG CUPS 1. S-CUSP session establishment: This is the first step of BNG CUPS
procedures. Once the Control Interface parameters are configured procedures. Once the Control Interface parameters are configured
on a UP. It will start to setup S-CUSP sessions with the on a UP. It will start to setup S-CUSP sessions with the
specified CPs. The detailed definition of S-CUSP session specified CPs. The detailed definition of S-CUSP session
establishment can be found in Section 4.1.1. establishment can be found in Section 4.1.1.
2. Board and interface report: Once the S-CUSP session is 2. Board and interface report: Once the S-CUSP session is
established between the UP and a CP, the UP will report status established between the UP and a CP, the UP will report status
information on the boards and subscriber side interfaces of this information on the boards and subscriber side interfaces of this
UP to the CP. A board can also be called a Line/Service Process UP to the CP. A board can also be called a Line/Service Process
Unit (LPU/SPU) card. The subscriber side interfaces refer to the
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
Unit (LPU/SPU) card. The subscriber side interfaces refer to the
interfaces that connect the Acess Network nodes (e.g., OLT: interfaces that connect the Acess Network nodes (e.g., OLT:
Optical Line Terminal, DSLAM: Digital Subscriber Line Access Optical Line Terminal, DSLAM: Digital Subscriber Line Access
Multiplexer, etc.). The CP can use this information to enable the Multiplexer, etc.). The CP can use this information to enable the
Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, etc.) Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, etc.)
on the specified interfaces. See Sections 4.2.1 and 7.10 for more on the specified interfaces. See Sections 4.2.1 and 7.10 for more
details on Resource reporting. details on Resource reporting.
3. BAS (Broadband Access Service) function enable: To enable the BAS 3. BAS (Broadband Access Service) function enable: To enable the BAS
function on the specified interfaces of a UP. function on the specified interfaces of a UP.
skipping to change at page 16, line 54 skipping to change at page 17, line 5
messages updating UP tables. messages updating UP tables.
7. 7.1-7.5 is the sequence for deleting an existing subscriber 7. 7.1-7.5 is the sequence for deleting an existing subscriber
session. When a UP receives an offline request, it will relay the session. When a UP receives an offline request, it will relay the
request to a CP through the Service Interface. The CP will send request to a CP through the Service Interface. The CP will send
back a response to the UP through the Service Interface. The UP back a response to the UP through the Service Interface. The UP
will then forward the offline response to the subscriber. Then will then forward the offline response to the subscriber. Then
the CP will delete the session on the UP through the Control the CP will delete the session on the UP through the Control
Interface. Interface.
INTERNET-DRAFT Simple BNG CUSP
8. Event reports include the following two parts (more detail can be 8. Event reports include the following two parts (more detail can be
found in Section 4.3.4) Both are reported using the Event found in Section 4.3.4) Both are reported using the Event
message. message.
INTERNET-DRAFT Simple BNG CUSP
8.1. Subscriber Traffic Statistics Report 8.1. Subscriber Traffic Statistics Report
8.2. Subscriber Detection Result Report 8.2. Subscriber Detection Result Report
9. Data synchronization: See Sections 4.2.5 for more detail on CP and 9. Data synchronization: See Sections 4.2.5 for more detail on CP
UP Synchronization. and UP Synchronization.
10. CGN address allocation: See Sections 4.2.4 for more detail on CGN 10. CGN address allocation: See Sections 4.2.4 for more detail on CGN
Address Allocation. Address Allocation.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
4. S-CUSP Protocol Overview 4. S-CUSP Protocol Overview
4.1. Control Channel Related Procedures 4.1. Control Channel Related Procedures
4.1.1. S-CUSP Session Establishment 4.1.1. S-CUSP Session Establishment
A UP is associated with a CP and is controlled by that CP. In the A UP is associated with a CP and is controlled by that CP. In the
case of a hot-standby or warm-standby, a UP is associated with two case of a hot-standby or cold-standby, a UP is associated with two
CPs, one called the Master CP and the other called the Standby CP. CPs, one called the Master CP and the other called the Standby CP.
The association between a UP and its CPs is implemented by dynamic The association between a UP and its CPs is implemented by dynamic
configuration. configuration.
Once a UP knows its CPs, the UP starts to establish S-CUSP sessions Once a UP knows its CPs, the UP starts to establish S-CUSP sessions
with those CPs as shown in Figure 4. with those CPs as shown in Figure 4.
UP CP UP CP
| | | |
| TCP Session Establishment | | TCP Session Establishment |
|<------------------------------->| |<------------------------------->|
| | | |
| HELLO (version, capability) | | HELLO (version, capability) |
|-------------------------------->| |-------------------------------->|
| | | |
| HELLO (version, capability) | | HELLO (version, capability) |
|<--------------------------------| |<--------------------------------|
| | | |
Figure 4: S-CUSP Session Establishment Figure 4: S-CUSP Session Establishment
The S-CUSP session establishment consists of two successive steps: The S-CUSP session establishment consists of two successive steps:
1. Establishment of a TCP [RFC793] connection (3-way handshake) 1. Establishment of a TCP [RFC793] connection (3-way handshake)
between the CP and the UP using port tbd1. between the CP and the UP using a configured port from the
dynamic port range (49152-65535).
2. Establishment of a S-CUSP session over the TCP connection. 2. Establishment of a S-CUSP session over the TCP connection.
Once the TCP connection is established, the CP and the UP initialize Once the TCP connection is established, the CP and the UP initialize
the S-CUSP session during which the version and Keepalive timers are the S-CUSP session during which the version and Keepalive timers are
negotiated. negotiated.
The version information (Hello TLV, see section 7.4) is carried The version information (Hello TLV, see Section 7.4) is carried
within Hello messages (see Section 6.2.1). A CP can support multiple within Hello messages (see Section 6.2.1). A CP can support multiple
versions, but a UP can only support one version. So, the version versions, but a UP can only support one version. So, the version
negotiation is based on whether a version can be support by both the negotiation is based on whether a version can be support by both the
CP and the UP. For a CP or UP, if a Hello message is received that CP and the UP. For a CP or UP, if a Hello message is received that
does not indicate a version supported by both, a subsequent Hello
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
does not indicate a version supported by both, a subsequent Hello
message with an Error Information TLV will be sent to the peer to message with an Error Information TLV will be sent to the peer to
notify the peer of the "Version-Mismatch" error and the session notify the peer of the "Version-Mismatch" error and the session
establishment phase fails. establishment phase fails.
Keepalive negotiation is performed by carrying a Keepalive TLV in the Keepalive negotiation is performed by carrying a Keepalive TLV in the
Hello message. The Keepalive TLV includes a Keepalive timer and Dead Hello message. The Keepalive TLV includes a Keepalive timer and Dead
Timer field. The CP and UP have to agree on the Keepalive Timer and Timer field. The CP and UP have to agree on the Keepalive Timer and
Dead Timer. Otherwise, a subsequent Hello message with an Error Dead Timer. Otherwise, a subsequent Hello message with an Error
Information TLV will be sent to its peer and the session Information TLV will be sent to its peer and the session
establishment phase fails. establishment phase fails.
The S-CUSP session establishment phase fails if the CP or UP disagree 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 on the version and keepalive parameters or if one of the CP or UP
does not answer after the expiration of the establishment timer. does not answer after the expiration of the Establishment timer.
When the S-CUSP session establishment fails, the TCP connection is When the S-CUSP session establishment fails, the TCP connection is
promptly closed. Successive retries are permitted but an promptly closed. Successive retries are permitted but an
implementation SHOULD make use of an exponential back-off session implementation SHOULD make use of an exponential back-off session
establishment retry procedure. establishment retry procedure.
The S-CUSP session timer values that need to be configured are
summarized in the table below.
Timer Range in Default
Name seconds Value
------------- ------- -------
Establishment 1-32767 45
Keepalive 0-255 30
DeadTimer 1-32767 4 * Keepalive
4.1.2. Keep Alive 4.1.2. Keep Alive
Once an S-CUSP session has been established, a UP or CP may want to Once an S-CUSP session has been established, a UP or CP may want to
know that its S-CUSP peer is still available for use. know that its S-CUSP peer is still available for use.
Each end of a S-CUSP session runs a Keepalive timer. It restarts the Each end of a S-CUSP session runs a Keepalive timer. It restarts the
timer every time it sends a message on the session. When the timer timer every time it sends a message on the session. When the timer
expires, it sends a Keepalive message. expires, it sends a Keepalive message.
The ends of the S-CUSP session also run DeadTimers, and they restart The ends of the S-CUSP session also run DeadTimers, and they restart
the timers whenever a message is received on the session. If one end the timers whenever a message is received on the session. If one end
of the session receives no message after the DeadTimer expires, it of the session receives no message after the DeadTimer expires, it
declares the session dead. The session will be closed. declares the session dead. The session will be closed.
The minimum value of the Keepalive timer is 1 second, and it is 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 specified in units of 1 second. The RECOMMENDED default value is 30
seconds. The timer may be disabled by setting it to zero. seconds. The timer may be disabled by setting it to zero.
INTERNET-DRAFT Simple BNG CUSP
The recommended default for the DeadTimer is 4 times the value of the The recommended default for the DeadTimer is 4 times the value of the
Keepalive timer used by the remote peer. This implies there is Keepalive timer used by the remote peer. This implies there is
essentially no risk of TCP congestion due to excessive Keepalive essentially no risk of TCP congestion due to excessive Keepalive
messages. messages.
The Keepalive timer and DeadTimer are initially negotiated through The Keepalive timer and DeadTimer are initially negotiated through
the Keepalive TLV carried in the Hello Message. the Keepalive TLV carried in the Hello Message.
INTERNET-DRAFT Simple BNG CUSP
4.2. Node Related Procedures 4.2. Node Related Procedures
4.2.1. UP Resource Report 4.2.1. UP Resource Report
Once an S-CUSP session has been established between a CP and an UP. Once an S-CUSP session has been established between a CP and an UP.
The UP reports the information of the Boards and access side The UP reports the information of the Boards and access side
interfaces on this UP to the CP as shown in Figure 5. Report messages interfaces on this UP to the CP as shown in Figure 5. Report messages
are unacknowledged and are assumed to be delivered because the are unacknowledged and are assumed to be delivered because the
session runs over TCP. session runs over TCP.
skipping to change at page 20, line 43 skipping to change at page 21, line 5
|------to CP via Ci----->| |------to CP via Ci----->|
| | | |
Figure 5: UP Board and Interface Report Figure 5: UP Board and Interface Report
Board status information is carried in the Board Status TLV (Section Board status information is carried in the Board Status TLV (Section
7.10.2) and Interface status information is carried in Interface 7.10.2) and Interface status information is carried in Interface
Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are
carried in the Report Message (Section 6.4). carried in the Report Message (Section 6.4).
4.2.2. Enable BAS Function on Access Interface INTERNET-DRAFT Simple BNG CUSP
Once the CP collects the interface status of a UP, it will 4.2.2. Update BAS Function on Access Interface
activate/enable the BAS functions on specified interfaces through the
Update_Request and Update_Response message (Section 6.2) exchanges
carrying the BAS Function Enabler TLV (Section 7.7).
INTERNET-DRAFT Simple BNG CUSP Once the CP collects the interface status of a UP, it will
activate/de-activate/modify the BAS functions on specified interfaces
through the Update_Request and Update_Response message (Section 6.2)
exchanges carrying the BAS Function TLV (Section 7.7).
UP CP UP CP
| | | |
| Enable BAS function | | Update BAS function |
| Request | | Request |
|<-----on UP via Ci-------| |<-----on UP via Ci-------|
| | | |
| Enable BAS function | | Update BAS function |
| Response | | Response |
|------on UP via Ci------>| |------on UP via Ci------>|
| | | |
Figure 6: Enable BAS Function Figure 6: Update BAS Function
4.2.3. Update Subscriber Network Routing 4.2.3. Update Network Routing
The CP will allocate one or more address blocks to a UP. Each address 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 block contains a series of IP addresses. Those IP addresses will be
allocated to subscribers who are dialing up to the UP. To enable the allocated to subscribers who are dialing up to the UP. To enable the
other nodes in the network to learn how to reach the subscribers, the 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 CP needs to install the routes on the UP and notify the UP to
advertise the routes to the network. advertise the routes to the network.
UP CP UP CP
| | | |
| Subscriber network route| | Subscriber network route|
| update request | | update request |
|<------- via Ci----------| |<------- via Ci----------|
| | | |
| Subscriber network route| | Subscriber network route|
| update response | | update response |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | |
Figure 7: Update Subscriber Network Routing Figure 7: Update Network Routing
The subscriber network routing update request and response are The subscriber network routing update request and response are
achieved through the Update Request and Response Message exchanges by achieved through the Update Request and Response Message exchanges by
carrying the IPv4/IPv6 Routing Information TLVs (Section 7.8). carrying the IPv4/IPv6 Routing Information TLVs (Section 7.8).
INTERNET-DRAFT Simple BNG CUSP
4.2.4. CGN Public IP Address Allocation 4.2.4. CGN Public IP Address Allocation
The following sequences describe the CGN address management related The following sequences describe the CGN address management related
procedures. Three independent procedures are defined, one each for procedures. Three independent procedures are defined, one each for
CGN address allocation request/response, CGN address renewal CGN address allocation request/response, CGN address renewal
request/response, and CGN address release request/response. request/response, and CGN address release request/response.
INTERNET-DRAFT Simple BNG CUSP
CGN address allocation/renew/release procedures are designed for the 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 case where the CGN function is running on the UP. The UP has to map
the subscriber private IP addresses to a public IP addresses, and the subscriber private IP addresses to a public IP addresses, and
such mapping is performed by the UP locally when a subscriber dials- 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 up. That means the UP has to ask for public IPv4 address blocks for
CGN subscribers from the CP. CGN subscribers from the CP.
In addition, when a public IP address is allocated to a UP, there 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, 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 the UP can ask for renewal of the IP address lease from the CP. It is
skipping to change at page 22, line 30 skipping to change at page 23, line 5
If the public IP address will not be used anymore, the UP SHOULD 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. 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 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 in to a UP, it uses the same procedures as above. The "Oper" code in
the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the
request is an update or withdraw. request is an update or withdraw.
The relevant messages are defined in Section 6.5. The relevant messages are defined in Section 6.5.
UP CP INTERNET-DRAFT Simple BNG CUSP
| |
| CGN Address Allocation |
| Request |
1.1|-------- via Ci--------->|
| CGN Address Allocation |
| Response |
1.2|<------- via Ci----------|
| |
| CGN Address Renew |
| Request |
2.1|-------- via Ci--------->|
| CGN Address Renew |
| Response |
2.2|<------- via Ci----------|
| |
| CGN Address Release |
| Request |
3.1|-------- via Ci--------->|
| CGN Address Release |
| Response |
3.3|<------- via Ci----------|
| |
Figure 8: CGN Public IP Address Allocation 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----------|
| |
INTERNET-DRAFT Simple BNG CUSP Figure 8: CGN Public IP Address Allocation
4.2.5. Data Synchronization between the CP and UP 4.2.5. Data Synchronization between the CP and UP
For a CU separated BNG, the UP will continue to function using the 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 state that has been installed in it even if the CP fails or the
session between the UP and CP fails. session between the UP and CP fails.
Under some circumstances it is necessary to synchronize state between Under some circumstances it is necessary to synchronize state between
the CP and UP, for example if a CP fails and the UP is switched to a the CP and UP, for example if a CP fails and the UP is switched to a
different CP. different CP.
skipping to change at page 23, line 29 skipping to change at page 24, line 5
board/interface status of the UP. The other direction is from CP to board/interface status of the UP. The other direction is from CP to
UP; in that case, the subscriber sessions, subscriber network routes, UP; in that case, the subscriber sessions, subscriber network routes,
L2TP tunnels, etc. will be synchronized to the UP. L2TP tunnels, etc. will be synchronized to the UP.
The synchronization is triggered by a Sync_Request message, to which The synchronization is triggered by a Sync_Request message, to which
the receiver will (1) reply with a Sync_Begin message to notify the the receiver will (1) reply with a Sync_Begin message to notify the
requester that synchronization will begin, and (2) then start the requester that synchronization will begin, and (2) then start the
synchronization using the Sync_Data message. When synchronization synchronization using the Sync_Data message. When synchronization
finished, a Sync_End message will be sent. finished, a Sync_End message will be sent.
INTERNET-DRAFT Simple BNG CUSP
The following figure shows the process of data synchronization The following figure shows the process of data synchronization
between a UP and a CP. between a UP and a CP.
INTERNET-DRAFT Simple BNG CUSP UP CP
| |
UP CP | Synchronization Request |
| | |<------- via Ci----------|
| Synchronization Request | | |
|<------- via Ci----------| | Synchronization Begin |
| | |-------- via Ci--------->|
| Synchronization Begin | | |
|-------- via Ci--------->| | Board/Interface Report |
| | |-------- via Ci--------->|
| Board/Interface Report | | |
|-------- via Ci--------->| | Synchronization End |
| | |-------- via Ci--------->|
| Synchronization End | | |
|-------- via Ci--------->| 1) Synchronization from UP to CP
| |
1) Synchronization from UP to CP
UP CP UP CP
| | | |
| Synchronization Request | | Synchronization Request |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | |
| Synchronization Begin | | Synchronization Begin |
|<-------- via Ci---------| |<-------- via Ci---------|
| | | |
| Synchronizes | | Synchronizes |
|Subscriber Session States| |Subscriber Session States|
| Network Route Entries | | Network Route Entries |
|<------- via Ci----------| |<------- via Ci----------|
| | | |
| Synchronization End | | Synchronization End |
|<-------- via Ci---------| |<-------- via Ci---------|
| | | |
2) Synchronization from CP to UP 2) Synchronization from CP to UP
Figure 9: Data Synchronization Figure 9: Data Synchronization
4.3. Subscriber Session Related Procedures 4.3. Subscriber Session Related Procedures
A subscriber session consists of a set of forwarding states, A subscriber session consists of a set of forwarding states,
policies, and security rules that are applied to the subscriber. It policies, and security rules that are applied to the subscriber. It
is used for forwarding subscriber traffic in a UP. To initialize a is used for forwarding subscriber traffic in a UP. To initialize a
session on a UP, a set of hardware resource have to be allocated session on a UP, a set of hardware resource have to be allocated
(e.g., NP, TCAM etc.) to a session. (e.g., NP, TCAM etc.) to a session.
Subscriber session related procedures include subscriber session Subscriber session related procedures include subscriber session
create, update, delete, and statistics report. The following sub-
sections give a high level view of the procedures.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
create, update, delete, and statistics report. The following sub-
sections give a high level view of the procedures.
4.3.1. Create Subscriber Session 4.3.1. Create Subscriber Session
The below sequence describes the DHCP IPv4 dial-up process, it is an The below sequence describes the DHCP IPv4 dial-up process, it is an
example that shows how a subscriber session is created. (An example example that shows how a subscriber session is created. (An example
for IPv6 appears in Section 5.1.2.) for IPv6 appears in Section 5.1.2.)
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| Online Request| | | | Online Request| | |
1|-------------->| | | 1|-------------->| | |
skipping to change at page 25, line 52 skipping to change at page 26, line 4
RG (for example, a DHCP Discovery packet). When the UP receives 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 Online Request from the RG, it will tunnel the Online Request to the
CP through the Service Interface (Step 2). The Service Interface is CP through the Service Interface (Step 2). The Service Interface is
implemented by a tunneling technology. implemented by a tunneling technology.
When the CP receives the Online Request from the UP, it will send an When the CP receives the Online Request from the UP, it will send an
authentication request to the AAA server to authenticate and authentication request to the AAA server to authenticate and
authorize the subscriber (step 3). When a positive reply is received authorize the subscriber (step 3). When a positive reply is received
from the AAA sever, the CP starts to create a subscriber session for from the AAA sever, the CP starts to create a subscriber session for
the request. Relevant resources (e.g., IP address, bandwidth, etc.) the request. Relevant resources (e.g., IP address, bandwidth, etc.)
INTERNET-DRAFT Simple BNG CUSP
will be allocated to the subscriber, policies and security rules will will be allocated to the subscriber, policies and security rules will
be generated for the subscriber Then the CP sends a session create be generated for the subscriber Then the CP sends a session create
request to the UP through the Control Interface (Ci) (step 4), and a request to the UP through the Control Interface (Ci) (step 4), and a
response is expected from the UP to confirm the creation (step 5). response is expected from the UP to confirm the creation (step 5).
INTERNET-DRAFT Simple BNG CUSP
Finally, the CP will notify the AAA server to start accounting (step Finally, the CP will notify the AAA server to start accounting (step
6). At the same time, an Online Response message (for example, a 6). At the same time, an Online Response message (for example, a
DHCP Ack packet) will be sent to the UP through the Si (step 7). And DHCP Ack packet) will be sent to the UP through the Si (step 7). And
the UP will forward the Online Response to the RG (step 8). the UP will forward the Online Response to the RG (step 8).
This completes the subscriber online process. This completes the subscriber online process.
4.3.2. Update Subscriber Session 4.3.2. Update Subscriber Session
The following numbered sequence shows the process of subscriber The following numbered sequence shows the process of subscriber
session update. session update.
UP CP AAA UP CP AAA
| | COA Request | | | COA Request |
| 1|<--------------| | 1|<--------------|
| Session update Request | | | Session update Request | |
2|<--------via Ci---------| | 2|<--------via Ci---------| |
| | | | | |
| Session update Response| | | Session update Response| |
3|---------via Ci-------->| | 3|---------via Ci-------->| |
| | COA Response | | | COA Response |
| 4|-------------->| | 4|-------------->|
| | | | | |
Figure 11: Subscriber Session Update Figure 11: Subscriber Session Update
When a subscriber session has been created on a UP, there may be When a subscriber session has been created on a UP, there may be
requirements to update the session with new parameters (e.g., requirements to update the session with new parameters (e.g.,
Bandwidth, QoS, policies, etc.). Bandwidth, QoS, policies, etc.).
This procedure is triggered by a Change of Authorization (COA) This procedure is triggered by a Change of Authorization (COA)
request message sent by the AAA server. The CP will update the request message sent by the AAA server. The CP will update the
session on the UP according to the new parameters through the Control session on the UP according to the new parameters through the Control
Interface. Interface.
INTERNET-DRAFT Simple BNG CUSP
4.3.3. Delete Subscriber Session 4.3.3. Delete Subscriber Session
The below call flow shows generally how S-CUPS deals with a The below call flow shows generally how S-CUPS deals with a
subscriber offline request. subscriber offline request.
RG UP CP RG UP CP
| | | | | |
|Offline Request | | |Offline Request | |
1|--------------->| | 1|--------------->| |
| | Relay the Offline | | | Relay the Offline |
| | Request | | | Request |
| 2|------to CP via Si----->|
INTERNET-DRAFT Simple BNG CUSP | | |
| | Send the Offline |
| 2|------to CP via Si----->| | | Response |
| | | | 3|<-----to UP via Si------|
| | Send the Offline | |Offline Response| |
| | Response | 4|<---------------| |
| 3|<-----to UP via Si------| | | Session delete |
|Offline Response| | | | Request |
4|<---------------| | | |<--------via Ci---------|
| | Session delete | | | Session delete |
| | Request | | | Response |
| |<--------via Ci---------| | |---------via Ci-------->|
| | Session delete | | | |
| | Response |
| |---------via Ci-------->|
| | |
Figure 12: Subscriber Session Delete Figure 12: Subscriber Session Delete
Similar to the session creation process, when a UP receives an Similar to the session creation process, when a UP receives an
offline request from a RG, it will tunnel the request to a CP through offline request from a RG, it will tunnel the request to a CP through
the Si. the Si.
When the CP receives the offline request, it will withdraw/release When the CP receives the offline request, it will withdraw/release
the resources (e.g., IP address, bandwidth) that have been allocated the resources (e.g., IP address, bandwidth) that have been allocated
to the subscriber. Then, it sends a reply to the UP through the to the subscriber. Then, it sends a reply to the UP through the
Service Interface and the UP will forward the reply to the RG. At Service Interface and the UP will forward the reply to the RG. At
the same time, it will delete all the status of the session on the UP the same time, it will delete all the status of the session on the UP
through the Ci. through the Ci.
4.3.4. Subscriber Session Events Report 4.3.4. Subscriber Session Events Report
UP CP UP CP
| | | |
| Statistic/Detect report| | Statistic/Detect report|
|---------via Ci-------->| |---------via Ci-------->|
| | | |
Figure 13: Events Report Figure 13: Events Report
INTERNET-DRAFT Simple BNG CUSP
When a session is created on an UP, the UP will periodically report When a session is created on an UP, the UP will periodically report
statistics information and detect results of the session to the CP. statistics information and detect results of the session to the CP.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
5. S-CUSP Call Flows 5. S-CUSP Call Flows
The subsections below give an overview of various "dial-up" The subsections below give an overview of various "dial-up"
interactions over the Service Interface followed by an overview of interactions over the Service Interface followed by an overview of
the setting of various information in the UP by the CP using S-CUSP the setting of various information in the UP by the CP using S-CUSP
skipping to change at page 34, line 23 skipping to change at page 35, line 23
5.1.5. DHCP Dual Stack Access 5.1.5. DHCP Dual Stack Access
The following sequence is a combination of DHCP IPv4 and DHCP IPv6 The following sequence is a combination of DHCP IPv4 and DHCP IPv6
access processes. access processes.
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| DHCP Discovery| | | | DHCP Discovery| | |
1|-------------->| | | 1|-------------->| | |
| |Relay the DHCP Discovery| | | |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| | | 2|-----to CP via Si------>| AAA |
| | | Accounting | | | | Req/Resp |
| | 3|<------------->| | | 3|<------------->|
| | | | | | | |
| | Send the DHCP Offer | | | | Send the DHCP Offer | |
| 4|<----to UP vis Si-------| | | 4|<----to UP vis Si-------| |
| DHCP Offer | | | | DHCP Offer | | |
5|<--------------| | | 5|<--------------| | |
| DHCP Request | | | | DHCP Request | | |
6|-------------->| | | 6|-------------->| | |
| | Relay the DHCP Request| | | | Relay the DHCP Request| |
| 7|-----to CP via Si------>| | | 7|-----to CP via Si------>| |
skipping to change at page 35, line 43 skipping to change at page 36, line 43
| | | Accounting | | | | Accounting |
| | 24|<------------->| | | 24|<------------->|
| | Send DHCPv6 Reply | | | | Send DHCPv6 Reply | |
| 25|<----to UP via Si-------| | | 25|<----to UP via Si-------| |
| DHCPv6 Reply | | | | DHCPv6 Reply | | |
26|<--------------| | | 26|<--------------| | |
| | | | | | | |
Figure 18: DHCP Dual Stack Access Figure 18: DHCP Dual Stack Access
The DHCP dual stack access includes three sets of Update_Request/ The DHCP dual stack access includes three sets of Update_Request /
Update_Response exchanges to create/update DHCPv4/v6 subscriber Update_Response exchanges to create/update DHCPv4/v6 subscriber
session. session.
1. Create DHCPv4 session (step 8 and 9) 1. Create DHCPv4 session (step 8 and 9)
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
2. Create DHCPv6 session (step 16 and 17) 2. Create DHCPv6 session (step 16 and 17)
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
skipping to change at page 36, line 29 skipping to change at page 37, line 31
3. Update DHCPv6 session (step 22 and 23) 3. Update DHCPv6 session (step 22 and 23)
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
5.1.6. L2 Static Subscriber Access 5.1.6. L2 Static Subscriber Access
L2 static subscriber access processes are as follows: L2 static subscriber access processes are as follows:
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| | Static Subscriber | | | | Static Subscriber | |
| | Detection Req. | | | | Detection Req. | |
| 1|<-----to UP via Ci------| | | 1|<-----to UP via Ci------| |
| | Static Subscriber | | | | Static Subscriber | |
| | Detection Rep. | | | | Detection Rep. | |
| 2|<-----to UP via Ci----->| | | 2|------to UP via Ci----->| |
| ARP/ND(REQ) | | | | ARP/ND(REQ) | | |
3.1|<--------------| | | 3.1|<--------------| | |
| ARP/ND(ACK) | | | | ARP/ND(ACK) | | |
3.2|-------------->| | | 3.2|-------------->| | |
| | Relay the ARP/ND | | | | Relay the ARP/ND | |
| 3.3|-----to CP via Si------>| AAA | | 3.3|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3.4|<------------->| | | 3.4|<------------->|
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 3.5|<--------via Ci-------->| |
| | Create subscriber | |
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
| 3.5|<--------via Ci---------| |
| | Create subscriber | |
| | session Response | | | | session Response | |
| 3.6|---------via Ci-------->| | | 3.6|---------via Ci-------->| |
| | | | | | | |
| ARP/ND(REQ) | | | | ARP/ND(REQ) | | |
4.1|-------------->| | | 4.1|-------------->| | |
| | Relay the ARP/ND | | | | Relay the ARP/ND | |
| 4.2|-----to CP via Si------>| AAA | | 4.2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 4.3|<------------->| | | 4.3|<------------->|
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 4.4|<--------via Ci-------->| | | 4.4|<--------via Ci---------| |
| | Create subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
| 4.5|---------via Ci-------->| | | 4.5|---------via Ci-------->| |
| ARP/ND(ACK) | | | | ARP/ND(ACK) | | |
4.6|<--------------| | | 4.6|<--------------| | |
| | | | | | | |
| IP Traffic | | | | IP Traffic | | |
5.1|-------------->| | | 5.1|-------------->| | |
| | Relay the IP Traffic | | | | Relay the IP Traffic | |
| 5.2|-----to CP via Si------>| AAA | | 5.2|-----to CP via Si------>| AAA |
skipping to change at page 37, line 52 skipping to change at page 39, line 5
| | | | | | | |
Figure 19: L2 Static Subscriber Access Figure 19: L2 Static Subscriber Access
For L2 static subscriber access, the process starts with a CP For L2 static subscriber access, the process starts with a CP
installing a static subscriber detection list on an UP. The list installing a static subscriber detection list on an UP. The list
determines which subscribers will be detected. This is implemented determines which subscribers will be detected. This is implemented
by exchanging Update_Request and Update_Response messages between CP by exchanging Update_Request and Update_Response messages between CP
and UP. The format of the messages are as follows: and UP. The format of the messages are as follows:
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<IPv4 Static Subscriber Detect TLVs> <IPv4 Static Subscriber Detect TLVs>
<IPv6 Static Subscriber Detect TLVs> <IPv6 Static Subscriber Detect TLVs>
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
INTERNET-DRAFT Simple BNG CUSP
<Update Response TLV> <Update Response TLV>
For L2 Static subscriber access, there are three ways to trigger the For L2 Static subscriber access, there are three ways to trigger the
access process: access process:
1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP 1. Triggered by UP (3.1-3.6): This assumes that the UP knows the IP
address, the access interface, and VLAN of the RG. The UP will address, the access interface, and VLAN of the RG. The UP will
actively trigger the access flow by sending an ARP/ND packet to actively trigger the access flow by sending an ARP/ND packet to
the RG. If the RG is online, it will reply with an ARP/ND to the the RG. If the RG is online, it will reply with an ARP/ND to the
UP. The UP will tunnel the ARP/ND to the CP through the Si. The UP. The UP will tunnel the ARP/ND to the CP through the Si. The
skipping to change at page 38, line 53 skipping to change at page 40, line 5
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
IPv6 Case: IPv6 Case:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
5.2. PPPoE 5.2. PPPoE
5.2.1. IPv4 PPPoE Access 5.2.1. IPv4 PPPoE Access
The following figure shows the IPv4 PPPoE access call flow. The following figure shows the IPv4 PPPoE access call flow.
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| PPPoE Disc | PPPoE Disc | | | PPPoE Disc | PPPoE Disc | |
1|<------------->|<---------via Si------->| | 1|<------------->|<---------via Si------->| |
skipping to change at page 39, line 29 skipping to change at page 40, line 32
2|<------------->|<---------via Si------->| | 2|<------------->|<---------via Si------->| |
| | | AAA | | | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->| 3|<------------->|<---------via Si------->|<------------->|
| | | | | | | |
| PPP IPCP | PPP IPCP | | | PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| | 4|<------------->|<---------via Si------->| |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 5|<--------via Ci-------->| | | 5|<--------via Ci---------| |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
| 6|---------via Ci-------->| | | 6|---------via Ci-------->| |
| | | | | | | |
| | | Accounting | | | | Accounting |
| | 7|<------------->| | | 7|<------------->|
| | | | | | | |
Figure 20: IPv4 PPPoE Access Figure 20: IPv4 PPPoE Access
skipping to change at page 39, line 51 skipping to change at page 41, line 5
From the above sequence, step 1-4 are the standard PPPoE call flow. From the above sequence, step 1-4 are the standard PPPoE call flow.
The UP is responsible for redirecting the PPPoE control packets to The UP is responsible for redirecting the PPPoE control packets to
the CP or RG. The PPPoE control packets are transmitted between the the CP or RG. The PPPoE control packets are transmitted between the
CP and UP through the Si. CP and UP through the Si.
After the PPPoE call flow, if the subscriber passed the AAA After the PPPoE call flow, if the subscriber passed the AAA
authentication and authorization, the CP will create a corresponding authentication and authorization, the CP will create a corresponding
session on the UP through the Ci. The formats of the messages are as session on the UP through the Ci. The formats of the messages are as
follows: follows:
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
INTERNET-DRAFT Simple BNG CUSP
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
5.2.2. IPv6 PPPoE Access 5.2.2. IPv6 PPPoE Access
The following figure describes the IPv6 PPPoE access call flow. The following figure describes the IPv6 PPPoE access call flow.
skipping to change at page 40, line 51 skipping to change at page 42, line 4
7|<------------->|<---------via Si------->| | 7|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update subscriber | | | | Update subscriber | |
| | session Request | | | | session Request | |
| 8|<--------via Ci---------| | | 8|<--------via Ci---------| |
| | | | | | | |
| | Update subscriber | | | | Update subscriber | |
| | session Response | | | | session Response | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | | | | | |
INTERNET-DRAFT Simple BNG CUSP
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | | | | | | |
| DHCPv6 | DHCPv6 | | | DHCPv6 | DHCPv6 | |
INTERNET-DRAFT Simple BNG CUSP
| Negotiation | Negotiation | | | Negotiation | Negotiation | |
7'|<------------->|<---------via Si------->| | 7'|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update subscriber | | | | Update subscriber | |
| | session Request | | | | session Request | |
| 8'|---------via Ci-------->| | | 8'|<---------via Ci--------| |
| | | | | | | |
| | Update subscriber | | | | Update subscriber | |
| | session Response | | | | session Response | |
| 9'|---------via Ci-------->| | | 9'|---------via Ci-------->| |
| | | | | | | |
| | | Accounting | | | | Accounting |
| | 10'|<------------->| | | 10'|<------------->|
| | | | | | | |
Figure 21: IPv6 PPPoE Access Figure 21: IPv6 PPPoE Access
skipping to change at page 41, line 49 skipping to change at page 43, line 5
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
Then, the RG will initialize a ND/DHCPv6 negotiation process with the Then, the RG will initialize a ND/DHCPv6 negotiation process with the
CP (see step 7 and 7'), after that, it will trigger an update (8-9, CP (see step 7 and 7'), after that, it will trigger an update (8-9,
8'-9') to the subscriber session. The formats of the update messages 8'-9') to the subscriber session. The formats of the update messages
are as follows: are as follows:
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
INTERNET-DRAFT Simple BNG CUSP
<Update Response TLV> <Update Response TLV>
5.2.3. PPPoE Dual Stack Access 5.2.3. PPPoE Dual Stack Access
The following figure shows a combination of IPv4 and IPv6 PPPoE The following figure shows a combination of IPv4 and IPv6 PPPoE
access call flow. access call flow.
RG UP CP AAA RG UP CP AAA
| | | | | | | |
|PPPoE Discovery| PPPoE Discovery | | |PPPoE Discovery| PPPoE Discovery | |
skipping to change at page 42, line 47 skipping to change at page 44, line 4
4'|<------------->|<---------via Si------->| | 4'|<------------->|<---------via Si------->| |
| | | | | | | |
| | Create V6 subscriber | | | | Create V6 subscriber | |
| | session Request | | | | session Request | |
| 5'|<--------via Ci---------| | | 5'|<--------via Ci---------| |
| | Create v6 subscriber | | | | Create v6 subscriber | |
| | session Response | | | | session Response | |
| 6'|---------via Ci-------->| | | 6'|---------via Ci-------->| |
| | | | | | | |
| ND Negotiation| ND Negotiation | | | ND Negotiation| ND Negotiation | |
INTERNET-DRAFT Simple BNG CUSP
8|<------------->|<---------via Si------->| | 8|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update v6 subscriber | | | | Update v6 subscriber | |
| | session Request | | | | session Request | |
| 9|---------via Ci-------->| | | 9|<---------via Ci--------| |
| | Update v6 subscriber | | | | Update v6 subscriber | |
| | session Response | | | | session Response | |
| 10|---------via Ci-------->| | | 10|---------via Ci-------->| |
INTERNET-DRAFT Simple BNG CUSP
| | | Accounting | | | | Accounting |
| | 7'|<------------->| | | 7'|<------------->|
| DHCPv6 | DHCPv6 | | | DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | | | Negotiation | Negotiation | |
8'|<------------->|<---------via Si------->| | 8'|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update v6 subscriber | | | | Update v6 subscriber | |
| | session Request | | | | session Request | |
| 9'|<--------via Ci---------| | | 9'|<--------via Ci---------| |
| | | | | | | |
skipping to change at page 43, line 49 skipping to change at page 45, line 4
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
2. Create an IPv6 PPPoE subscriber session (5'-6') 2. Create an IPv6 PPPoE subscriber session (5'-6')
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
INTERNET-DRAFT Simple BNG CUSP
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10') 3. Update the IPv6 PPPoE subscriber session (9-10, 9'-10')
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
skipping to change at page 44, line 46 skipping to change at page 46, line 4
| | DHCP Request | | | | | DHCP Request | | |
| 6|-----via Si---->| | | | 6|-----via Si---->| | |
| | | | | | | | | |
| | Create session | | | | | Create session | | |
| | Request | | | | | Request | | |
| 7|<----via Ci-----| | | | 7|<----via Ci-----| | |
| | Create session | | | | | Create session | | |
| | Response | | | | | Response | | |
| 8|----via Ci----->| | | | 8|----via Ci----->| | |
| | | | | | | | | |
INTERNET-DRAFT Simple BNG CUSP
| | DHCP ACK | | | | | DHCP ACK | | |
| 9|<----via Si-----| | | | 9|<----via Si-----| | |
| | | | | | | | | |
| DHCP ACK | | | | | DHCP ACK | | | |
10|<------------| | | | 10|<------------| | | |
| | | | | | | | | |
| Subscriber | | | | | Subscriber | | | |
| HTTP Traffic| | | | | HTTP Traffic| | | |
11|------------>|--> | | | 11|------------>|--> | | |
INTERNET-DRAFT Simple BNG CUSP
| | | WEB URL | | | | | | WEB URL | | |
| Traffic | | Redirect | | | | Traffic | | Redirect | | |
| Redirection | | | | | | Redirection | | | | |
12|<------------|<-+ | | | 12|<------------|<-+ | | |
| | | | | | | |
| | | |
13|-----------------Redirect to Web server------------->| 13|-----------------Redirect to Web server------------->|
| | | |
14|<----------------Push HTTP log-in page---------------| 14|<----------------Push HTTP log-in page---------------|
| | | |
skipping to change at page 45, line 48 skipping to change at page 47, line 5
that the CP will create a subscriber session on the UP (steps 7-8). that the CP will create a subscriber session on the UP (steps 7-8).
The formats of the session creation messages are as follows: The formats of the session creation messages are as follows:
IPv4 Case: IPv4 Case:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
IPv6 Case: IPv6 Case:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
INTERNET-DRAFT Simple BNG CUSP
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
After step 10, the RG will be allocated an IP address and its first 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 HTTP packet will be redirected to a WEB server for subscriber
authentication (steps 11-17). After the WEB authentication, if the authentication (steps 11-17). After the WEB authentication, if the
result is positive, the CP will update the subscriber session by result is positive, the CP will update the subscriber session by
using the following message exchanges: using the following message exchanges:
skipping to change at page 46, line 44 skipping to change at page 48, line 4
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
5.4. L2TP 5.4. L2TP
5.4.1. L2TP LAC Access 5.4.1. L2TP LAC Access
RG UP(LAC) CP(LAC) AAA LNS RG UP(LAC) CP(LAC) AAA LNS
| | | | | | | | | |
| PPPoE | PPPoE | | | | PPPoE | PPPoE | | |
INTERNET-DRAFT Simple BNG CUSP
| Discovery | Discovery | | | | Discovery | Discovery | | |
1|<---------->|<---via Si--->| | | 1|<---------->|<---via Si--->| | |
| | | | | | | | | |
| PPP LCP | PPP LCP | | | | PPP LCP | PPP LCP | | |
2|<---------->|<---via Si--->| | | 2|<---------->|<---via Si--->| | |
| | | AAA | | | | | AAA | |
|PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| | |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| |
3|<---------->|<---via Si--->|<------>| | 3|<---------->|<---via Si--->|<------>| |
| | | | | | | | | |
INTERNET-DRAFT Simple BNG CUSP
| PPP IPCP | PPP IPCP | | | | PPP IPCP | PPP IPCP | | |
4|<---------->|<---via Si--->| | | 4|<---------->|<---via Si--->| | |
| | | | | | | | | |
| | L2TP tunnel | | | | | L2TP tunnel | | |
| | negotiation | | | | | negotiation | | |
| | SCCRQ/ | | | | | SCCRQ/ | | |
| | SCCRP/ | | | | | SCCRP/ | | |
| | SCCCN | | | | | SCCCN | | |
| 5|<---via Si--->| | | | 5|<---via Si--->| | |
| | /\ | | | /\ |
skipping to change at page 47, line 49 skipping to change at page 49, line 5
| | subscriber | | | | | subscriber | | |
| | session | | | | | session | | |
| | Response | | | | | Response | | |
| 8|----via Ci--->| | | | 8|----via Ci--->| | |
| | | | | | | | | |
| | | |
| PAP/CHAP (Triggered by LNS) | | PAP/CHAP (Triggered by LNS) |
9|<-----------------via routing?---------------->| 9|<-----------------via routing?---------------->|
| | | |
INTERNET-DRAFT Simple BNG CUSP
Figure 24: L2TP-LAC Access Figure 24: L2TP-LAC Access
Steps 1-4 are a standard PPPoE access process. After that the LAC-CP 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 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 negotiation, the CP will create an L2TP LAC subscriber session on
the UP through the following messages: the UP through the following messages:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
INTERNET-DRAFT Simple BNG CUSP
<Basic Subscriber TLV> <Basic Subscriber TLV>
<L2TP-LAC Subscriber TLV> <L2TP-LAC Subscriber TLV>
<L2TP-LAC Tunnel TLV> <L2TP-LAC Tunnel TLV>
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
5.4.2. L2TP LNS IPv4 Access 5.4.2. L2TP LNS IPv4 Access
RG LAC UP(LNS) AAA CP(LNS) RG LAC UP(LNS) AAA CP(LNS)
skipping to change at page 48, line 47 skipping to change at page 50, line 4
| | negotiation | negotiation | | | negotiation | negotiation |
| | ICRQ/ | ICRQ/ | | | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ | | | ICRP/ | ICRP/ |
| | ICCN | ICCN | | | ICCN | ICCN |
| 5|<------------>|<------via Si----->| | 5|<------------>|<------via Si----->|
| | | | | | | |
| | | Create | | | | Create |
| | | subscriber | | | | subscriber |
| | | session | | | | session |
| | | Request | | | | Request |
INTERNET-DRAFT Simple BNG CUSP
| | 6|<-----via Ci-------| | | 6|<-----via Ci-------|
| | | Create | | | | Create |
| | | subscriber | | | | subscriber |
| | | session | | | | session |
| | | Response | | | | Response |
| | 7|------via Ci------>| | | 7|------via Ci------>|
| | | |
| PAP/CHAP (Triggered by LNS) | | PAP/CHAP (Triggered by LNS) |
INTERNET-DRAFT Simple BNG CUSP
8|<--------------------------------------------->| 8|<--------------------------------------------->|
| | | |
| | | | AAA | | | | | AAA |
| | | | Req/Rep | | | | | Req/Rep |
| | | 9|<-------->| | | | 9|<-------->|
| | | | | | | |
| | | |
| PPP IPCP | | PPP IPCP |
10|<--------------------------------------------->| 10|<--------------------------------------------->|
| | | |
skipping to change at page 49, line 50 skipping to change at page 51, line 5
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
INTERNET-DRAFT Simple BNG CUSP
After that, the LNS-CP will trigger an AAA authentication. If the After that, the LNS-CP will trigger an AAA authentication. If the
authentication result is positive, a PPP IPCP process will follow, authentication result is positive, a PPP IPCP process will follow,
then the CP will update the session with the following message then the CP will update the session with the following message
exchanges: exchanges:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV> <L2TP-LNS Subscriber TLV>
INTERNET-DRAFT Simple BNG CUSP
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
skipping to change at page 50, line 48 skipping to change at page 52, line 4
| 4|<------------>|<------via Si----->| | 4|<------------>|<------via Si----->|
| | | | | | | |
| | L2TP session | L2TP session | | | L2TP session | L2TP session |
| | negotiation | negotiation | | | negotiation | negotiation |
| | ICRQ/ | ICRQ/ | | | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ | | | ICRP/ | ICRP/ |
| | ICCN | ICCN | | | ICCN | ICCN |
| 5|<------------>|<------via Si----->| | 5|<------------>|<------via Si----->|
| | | | | | | |
| | | Create | | | | Create |
INTERNET-DRAFT Simple BNG CUSP
| | | subscriber | | | | subscriber |
| | | session | | | | session |
| | | Request | | | | Request |
| | 6|<-----via Ci-------| | | 6|<-----via Ci-------|
| | | Create | | | | Create |
| | | subscriber | | | | subscriber |
| | | session | | | | session |
INTERNET-DRAFT Simple BNG CUSP
| | | Response | | | | Response |
| | 7|------via Ci------>| | | 7|------via Ci------>|
| | | |
| PAP/CHAP (Triggered by LNS) | | PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->| 8|<--------------------------------------------->|
| | | |
| | | | AAA | | | | | AAA |
| | | | Req/Rep | | | | | Req/Rep |
| | | 9|<-------->| | | | 9|<-------->|
| | | | | | | | | |
skipping to change at page 51, line 50 skipping to change at page 53, line 5
| | 14|<-----via Ci-------| | | 14|<-----via Ci-------|
| | | Update | | | | Update |
| | | subscriber | | | | subscriber |
| | | session | | | | session |
| | | Response | | | | Response |
| | 15|------via Ci------>| | | 15|------via Ci------>|
| | | | | | | |
Figure 26: L2TP-LNS IPv6 Access Figure 26: L2TP-LNS IPv6 Access
INTERNET-DRAFT Simple BNG CUSP
Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5 Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5
finish the normal L2TP dial-up process. When the L2TP session and finish the normal L2TP dial-up process. When the L2TP session and
tunnel negotiations are finished, the LNS-CP will create an L2TP LNS 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 subscriber session on the LNS-UP. The format of the messages is as
follows: follows:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
INTERNET-DRAFT Simple BNG CUSP
<L2TP-LNS Subscriber TLV> <L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
skipping to change at page 52, line 51 skipping to change at page 54, line 5
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
5.5. CGN (Carrier Grade NAT) 5.5. CGN (Carrier Grade NAT)
RG UP CP AAA RG UP CP AAA
| | | | | | | |
INTERNET-DRAFT Simple BNG CUSP
| | Public Address Block | | | | Public Address Block | |
| | Allocation Request | | | | Allocation Request | |
| 1|<--------via Ci-------->| | | 1|<--------via Ci-------->| |
| | Public Address Block | | | | Public Address Block | |
| | Allocation Reply | | | | Allocation Reply | |
| 2|---------via Ci-------->| | | 2|---------via Ci-------->| |
| | | | | | | |
| Subscriber | | | | Subscriber | | |
| access request| Subscriber | | | access request| Subscriber | |
3|-------------->| access request | | 3|-------------->| access request | |
| 4|----------via Si------->| | | 4|----------via Si------->| |
| | | AAA | | | | AAA |
| | Subscriber | Req/Rep | | | Subscriber | Req/Rep |
| Subscriber | access reply 5|<------------->| | Subscriber | access reply 5|<------------->|
| access reply 6|<---------via Si--------| | | access reply 6|<---------via Si--------| |
7|<--------------| | | 7|<--------------| | |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 8|<--------via Ci-------->| | | 8|<--------via Ci---------| |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
| | (with NAT information) | | | | (with NAT information) | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | | | | | |
| | | Accounting | | | | Accounting |
| | | with source | | | | with source |
| | | information | | | | information |
| | 10|<------------->| | | 10|<------------->|
skipping to change at page 53, line 49 skipping to change at page 55, line 5
| | | to Private IP| | | | to Private IP|
| | | mapping | | | | mapping |
| | | | | | | |
Figure 27: CGN Access Figure 27: CGN Access
The first steps allocate one or more CGN address blocks to the UP The first steps allocate one or more CGN address blocks to the UP
(steps 1-2). This is achieved by the following message exchanges (steps 1-2). This is achieved by the following message exchanges
between CP and UP. between CP and UP.
INTERNET-DRAFT Simple BNG CUSP
<Addr_Allocation_Req Message> ::= <Common Header> <Addr_Allocation_Req Message> ::= <Common Header>
<Request Address Allocation TLV> <Request Address Allocation TLV>
<Addr_Allocation_Ack Message> ::= <Common Header> <Addr_Allocation_Ack Message> ::= <Common Header>
<Address Assignment Response TLV> <Address Assignment Response TLV>
Steps 3-9 show the general dial-up process in the case of CGN mode. 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 The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in
INTERNET-DRAFT Simple BNG CUSP
above sections. above sections.
If a subscriber is a CGN subscriber, once the subscriber session is If a subscriber is a CGN subscriber, once the subscriber session is
created/updated, the UP will report the NAT information to the CP. created/updated, the UP will report the NAT information to the CP.
This is achieved by carrying the "Subscriber CGN Port Range TLV" in This is achieved by carrying the "Subscriber CGN Port Range TLV" in
the Update_Response message. the Update_Response message.
5.6. L3 Leased Line Access 5.6. L3 Leased Line Access
5.6.1. Web Authentication 5.6.1. Web Authentication
skipping to change at page 54, line 45 skipping to change at page 56, line 4
| HTTP | | | | | HTTP | | | |
| traffic | | | | | traffic | | | |
6|------------>| | | | 6|------------>| | | |
| | | | | | | | | |
| Redirect to | | | | | Redirect to | | | |
| Web URL | | | | | Web URL | | | |
7|<------------| | | | 7|<------------| | | |
| | | | | | | | | |
| | | |
8|-----------------Redirected to Web server----------->| 8|-----------------Redirected to Web server----------->|
INTERNET-DRAFT Simple BNG CUSP
| | | |
9|<----------------Push HTTP Log-in page---------------| 9|<----------------Push HTTP Log-in page---------------|
| | | |
10|-----------------User Authentication---------------->| 10|-----------------User Authentication---------------->|
| | | |
| | | Portal Interchange | | | | Portal Interchange |
| | 11|<-------------------->| | | 11|<-------------------->|
| | | | | | | |
INTERNET-DRAFT Simple BNG CUSP
| | | AAA | | | | | AAA | |
| | | Req/Rep | | | | | Req/Rep | |
| | 12|<-------->| | | | 12|<-------->| |
| | | | | | | | | |
| | | | | | | | | |
| | Update session | | | | | Update session | | |
| | Request | | | | | Request | | |
| 13|<----via Ci-----| | | | 13|<----via Ci-----| | |
| | | | | | | | | |
| | Update session | | | | | Update session | | |
skipping to change at page 55, line 48 skipping to change at page 56, line 56
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
IPv6 Case: IPv6 Case:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
Then, the HTTP traffic from the RG will be redirected to a WEB server Then, the HTTP traffic from the RG will be redirected to a WEB server
to finish the WEB authentication. Once the WEB authentication is to finish the WEB authentication. Once the WEB authentication is
passed, the CP will trigger another AAA authentication. After the passed, the CP will trigger another AAA authentication. After the
AAA authentication, the CP will update the session with the following AAA authentication, the CP will update the session with the following
message exchanges: message exchanges:
IPv4 Case: IPv4 Case:
INTERNET-DRAFT Simple BNG CUSP
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
skipping to change at page 56, line 48 skipping to change at page 58, line 4
| | traffic | | | | traffic | |
| 3|-----via Si---->| | | 3|-----via Si---->| |
| | | AAA | | | | AAA |
| | | Req/Rep | | | | Req/Rep |
| | 4|<-------->| | | 4|<-------->|
| | | | | | | |
| | Create session | | | | Create session | |
| | Request | | | | Request | |
| 5|<----via Ci-----| | | 5|<----via Ci-----| |
| | Create session | | | | Create session | |
INTERNET-DRAFT Simple BNG CUSP
| | Response | | | | Response | |
| 6|----via Ci----->| | | 6|----via Ci----->| |
| | | | | | | |
Figure 29: User Traffic Triggered L3 Leased Line Access Figure 29: User Traffic Triggered L3 Leased Line Access
In this user traffic triggered case, the CP must install an access In this user traffic triggered case, the CP must install an access
INTERNET-DRAFT Simple BNG CUSP
control list on the UP, which is used by the UP to determine whether control list on the UP, which is used by the UP to determine whether
an RG is legal or not. If the traffic is from a legal RG, it will be an RG is legal or not. If the traffic is from a legal RG, it will be
redirected to the CP though the Si. The CP will trigger a AAA 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 interchange with the AAA server. After that, the CP will create a
corresponding subscriber session on the UP with the following message corresponding subscriber session on the UP with the following message
exchanges: exchanges:
IPv4 Case: IPv4 Case:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
skipping to change at page 57, line 37 skipping to change at page 58, line 44
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
5.7. Multicast Access 5.7. Multicast Access
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| User access | User access | AAA | | User access | User access | AAA |
| request | request | Req/Rep | | request | request | Req/Rep |
1|<----------->|<----via Si---->|<-------->| 1|<----------->|<----via Si---->|<-------->|
| | User | | | | User | |
| | | | | | | |
| | | | | | | |
| | Create session | | | | Create session | |
| | Request | | | | Request | |
| 2|<----via Ci---->| | | 2|<----via Ci---->| |
| | | |
| | Create session | |
| | Response | |
| 3|----via Ci----->| |
| | | |
| Multicast | | |
| negotiation | | |
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
4|<----------->| | | | | | |
| | | | | | Create session | |
| | Response | |
| 3|----via Ci----->| |
| | | |
| Multicast | | |
| negotiation | | |
4|<----------->| | |
| | | |
Figure 30: Multicast Access Figure 30: Multicast Access
Multicast access starts with an user access request from the RG. The Multicast access starts with an user access request from the RG. The
request will be redirected to the CP by the Si. A follow-up AAA 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. interchange between the CP and the AAA server will be triggered.
After the authentication, the CP will create a multicast subscriber After the authentication, the CP will create a multicast subscriber
session on the UP through the following messages: session on the UP through the following messages:
IPv4 Case: IPv4 Case:
skipping to change at page 63, line 51 skipping to change at page 65, line 5
Each Update_Request message will result in an Update_Response message Each Update_Request message will result in an Update_Response message
that is defined in Section 6.2.8. that is defined in Section 6.2.8.
6.2.8. Update_Response Message 6.2.8. Update_Response Message
The Update_Response message is a response to an Update_Request The Update_Response message is a response to an Update_Request
message. It is used to confirm the update request (or reject it in 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 the case of an error). The format of an Update_Response message is
as follows: as follows:
<Update_Response Message> ::= <Common Header>
[<Subscriber CGN Port Range TLV>]
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
<Update_Response Message> ::= <Common Header>
[<Subscriber CGN Port Range TLV>]
<Error Information TLV> <Error Information TLV>
The return/error codes are carried in the Error Information TLV. The return/error codes are carried in the Error Information TLV.
They are listed as follows: They are listed as follows:
0: Success. 0: Success.
1: Failure, malformed message received. 1: Failure, malformed message received.
2: One or more of the TLVs was not understood. 2: One or more of the TLVs was not understood.
skipping to change at page 65, line 20 skipping to change at page 66, line 20
UP. The format of Report message is as follows: UP. The format of Report message is as follows:
<Report Message> ::= <Common Header> <Report Message> ::= <Common Header>
[<Board Status TLVs>] [<Board Status TLVs>]
[<Interface Status TLVs>] [<Interface Status TLVs>]
6.5. CGN Messages 6.5. CGN Messages
This document defines the following resource allocation messages: This document defines the following resource allocation messages:
Type Name TLV that is carried Type Message Name TLV that is carried
---- ------------------- ------------------------ ---- ------------------- ------------------------
200 Addr_Allocation_Req Address Allocation Request 200 Addr_Allocation_Req Address Allocation Request
201 Addr_Allocation_Ack Address Allocation Response 201 Addr_Allocation_Ack Address Allocation Response
202 Addr_Renew_Req Address Renewal Request 202 Addr_Renew_Req Address Renewal Request
203 Addr_Renew_Ack Address Renewal Response 203 Addr_Renew_Ack Address Renewal Response
204 Addr_Release_Req Address Release Request 204 Addr_Release_Req Address Release Request
205 Addr_Release_Ack Address Release Response 205 Addr_Release_Ack Address Release Response
6.5.1. Addr_Allocation_Req Message 6.5.1. Addr_Allocation_Req Message
skipping to change at page 66, line 37 skipping to change at page 67, line 37
<Addr_Release_Req Message> ::= <Common Header> <Addr_Release_Req Message> ::= <Common Header>
<Address Release Request TLV> <Address Release Request TLV>
6.5.6. Addr_Release_Ack Message 6.5.6. Addr_Release_Ack Message
The Addr_Release_Ack message is a response to an Addr_Release_Req The Addr_Release_Ack message is a response to an Addr_Release_Req
message. The format of Addr_Release_Ack message is as follows: message. The format of Addr_Release_Ack message is as follows:
<Addr_Release_Ack Message> ::= <Common Header> <Addr_Release_Ack Message> ::= <Common Header>
<Address Renewal Response TLV> <Address Release Response TLV>
6.6. Vendor Message 6.6. Vendor Message
The Vendor message is, in conjunction with the vendor TLV and vendor The Vendor message is, in conjunction with the vendor TLV and vendor
sub-TLV, can be used by vendors to extend the S-CUSP protocol. It's sub-TLV, can be used by vendors to extend the S-CUSP protocol. It's
message type is 11. If the receiver does not recognize the message, message type is 11. If the receiver does not recognize the message,
an Error message will be returned to the sender. an Error message will be returned to the sender.
INTERNET-DRAFT Simple BNG CUSP
The format of the Vendor message is as follows: The format of the Vendor message is as follows:
<Vendor Message> ::= <Common Header> <Vendor Message> ::= <Common Header>
INTERNET-DRAFT Simple BNG CUSP
<Vendor TLV> <Vendor TLV>
[<any other TLVs as specified by the vendor>] [<any other TLVs as specified by the vendor>]
6.7 Error Message 6.7 Error Message
The Error message is defined to return some critical error The Error message is defined to return some critical error
information to the sender. If a receiver does not know the message information to the sender. If a receiver does not know the message
type of a received message, it MUST return an Error message to the type of a received message, it MUST return an Error message to the
sender. sender.
skipping to change at page 69, line 17 skipping to change at page 70, line 17
7.2. Basic Data Fields 7.2. Basic Data Fields
This section specifies the binary format of several standard basic This section specifies the binary format of several standard basic
data fields that are used within other data structures in this data fields that are used within other data structures in this
specification. specification.
o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section
7.3) to provide the length. The use of this data type in S-CUSP is 7.3) to provide the length. The use of this data type in S-CUSP is
to provide convenient labels for use by network operators in to provide convenient labels for use by network operators in
configuring and debugging their networks and interpreting S-CUSP configuring and debugging their networks and interpreting S-CUSP
messages. These labels should not be seen by subscribers. They are messages. These labels will not normally be seen by subscribers.
normally interpreted as ASCII [RFC20]. They are normally interpreted as ASCII [RFC20].
o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042]. o MAC-Addr: 6 octets. Ethernet MAC Address [RFC7042].
o IPv4-Address: 8 octets. 4 octets of the IPv4 address value o IPv4-Address: 8 octets. 4 octets of the IPv4 address value
followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX. followed by a 4 octet address mask in the format XXX.XXX.XXX.XXX.
o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4 o IPv6-Address: 20 octets. 16 octets of IPv6 address followed by a 4
octet integer n in the range of 0 to 128 which gives the address octet integer n in the range of 0 to 128 which gives the address
mask as the one's complement of 2**(128-n) - 1. mask as the one's complement of 2**(128-n) - 1.
skipping to change at page 70, line 25 skipping to change at page 71, line 25
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 33: Sub-TLV Header Figure 33: Sub-TLV Header
o Type (2 bytes): The Type of a Sub-TLV, that is the meaning and o Type (2 bytes): The Type of a Sub-TLV, that is the meaning and
format of the Value part, are determined by the Type of the format of the Value part, are determined by the Type of the
TLV. Sub-TLV Types numbers have the same meaning regardless of TLV. Sub-TLV Types numbers have the same meaning regardless of
the TLV Type of the TLV within which the sub-TVL occurs. See the TLV Type of the TLV within which the sub-TLV occurs. See
Section 9.4. Section 9.4.
o Length (2 bytes): The length of the Value portion of the sub- o Length (2 bytes): The length of the Value portion of the sub-
TLV in bytes as an unsigned integer. TLV in bytes as an unsigned integer.
o Value (variable length): This is the value portion of the sub- o Value (variable length): This is the value portion of the sub-
TLV whose size is given by Length. TLV whose size is given by Length.
The sub-TLVs currently specified are defined in the following The sub-TLVs currently specified are defined in the following
subsections. subsections.
skipping to change at page 78, line 49 skipping to change at page 79, line 49
Message-Type(1 byte): This parameter is the message type of the Message-Type(1 byte): This parameter is the message type of the
message containing an error. message containing an error.
Reserved (1 byte): MUST be sent as zero and ignored on receipt. Reserved (1 byte): MUST be sent as zero and ignored on receipt.
TLV-Type (2 bytes): Indicates which TLV caused the error. TLV-Type (2 bytes): Indicates which TLV caused the error.
Error Code: 4 bytes in length. Indicate the specific Error Code Error Code: 4 bytes in length. Indicate the specific Error Code
(see Section 9.5). (see Section 9.5).
7.7. BAS Function Enabler TLV 7.7. BAS Function TLV
The BAS Function Enabler TLV is used by a CP to control the access The BAS Function TLV is used by a CP to control the access mode,
mode, authentication methods, and other related functions of an authentication methods, and other related functions of an interface
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
interface on a UP. on a UP.
The format of the BAS Function Enabler TLV value part is as follows: The format of the BAS Function TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (optional) | | sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: BAS Function Enabler TLV Figure 42: BAS Function TLV
Where: Where:
The TLV type: 1. The TLV type: 1.
The value of length: variable. The value of length: variable.
If-Index: 4 bytes in length, a unique identifier of an interface If-Index: 4 bytes in length, a unique identifier of an interface
of a BNG. of a BNG.
skipping to change at page 80, line 15 skipping to change at page 81, line 15
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
reserved and MUST be sent as zero and ignored on receipt): reserved and MUST be sent as zero and ignored on receipt):
0x1: PPPoE authentication; 0x1: PPPoE authentication;
0x2: DOT1X authentication; 0x2: DOT1X authentication;
0x4: Web authentication; 0x4: Web authentication;
0x8: Web fast authentication; 0x8: Web fast authentication;
0x10: Binding authentication; 0x10: Binding authentication;
sub-TLVs: The IF-Desc sub-TLV can be carried. sub-TLVs:
The IF-Desc sub-TLV can be carried.
If-Desc sub-TLV: carries the interface information. If-Desc sub-TLV: carries the interface information.
The flags field is defined as follows: The flags field is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |Y|X|P|I|N|A|S|F| | MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 80, line 53 skipping to change at page 82, line 5
traffic detection. 0: Disable traffic detection. traffic detection. 0: Disable traffic detection.
P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable
traffic detection. 0: Disable traffic detection. traffic detection. 0: Disable traffic detection.
X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy
and can process ARP requests across different Port+VLANs. 0: and can process ARP requests across different Port+VLANs. 0:
The ARP proxy is not enabled on the interface, and only the ARP The ARP proxy is not enabled on the interface, and only the ARP
requests of the same Port+VLAN are processed. requests of the same Port+VLAN are processed.
INTERNET-DRAFT Simple BNG CUSP
Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and
can process ND requests across different Port+VLANs. 0: The ND can process ND requests across different Port+VLANs. 0: The ND
proxy is not enabled on the interface, and only the ND requests proxy is not enabled on the interface, and only the ND requests
of the same Port+VLAN are processed. of the same Port+VLAN are processed.
INTERNET-DRAFT Simple BNG CUSP
MBZ: Reserved bits that MUST be sent as zero and ignored on MBZ: Reserved bits that MUST be sent as zero and ignored on
receipt. receipt.
7.8. Routing TLVs 7.8. Routing TLVs
Normally, after an S-CUSP session is established between a UP and a Normally, after an S-CUSP session is established between a UP and a
CP, the CP will allocate one or more blocks of IP addresses to the 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 UP. Those IP addresses will be allocated to subscribers who will
dial-up to the UP. In order to make sure that other nodes within the dial-up to the UP. In order to make sure that other nodes within the
network learn how to reach those IP addresses, the CP needs to network learn how to reach those IP addresses, the CP needs to
skipping to change at page 81, line 29 skipping to change at page 83, line 5
The Routing TLVs are used by a CP to notify a UP of the network The Routing TLVs are used by a CP to notify a UP of the network
routing. They can be carried in the Update_Request message and routing. They can be carried in the Update_Request message and
Sync_Data message. Sync_Data message.
7.8.1. IPv4 Routing TLV 7.8.1. IPv4 Routing TLV
The IPv4 Routing TLV is used to carry IPv4 network routing related The IPv4 Routing TLV is used to carry IPv4 network routing related
information. information.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as below: The format of the TLV value part is as below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest-Address | | Dest-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop | | Next-Hop |
skipping to change at page 82, line 5 skipping to change at page 83, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A| | Route Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 44: IPv4 Routing TLV Figure 44: IPv4 Routing TLV
INTERNET-DRAFT Simple BNG CUSP
Where: Where:
The TLV Type: 7 The TLV Type: 7
The TLV Length: Variable The TLV Length: Variable
User-ID: 4 bytes in length. Carries the user identifier. This User-ID: 4 bytes in length. Carries the user identifier. This
field is filled with all Fs when a non-user route is delivered to field is filled with all Fs when a non-user route is delivered to
the UP. the UP.
skipping to change at page 82, line 31 skipping to change at page 84, line 5
Out-If-Index (4 bytes): Indicates the interface index. Out-If-Index (4 bytes): Indicates the interface index.
Cost (4 bytes): The cost value of the route. Cost (4 bytes): The cost value of the route.
Tag (4 bytes): The tag value of the route. Tag (4 bytes): The tag value of the route.
Route-Type (2 bytes): Indicates the route type. The options are Route-Type (2 bytes): Indicates the route type. The options are
as follows: as follows:
INTERNET-DRAFT Simple BNG CUSP
0: User host route 0: User host route
1: Radius authorization FrameRoute 1: Radius authorization FrameRoute
2: Network segment route 2: Network segment route
3: Gateway route 3: Gateway route
4: Radius authorized IP route 4: Radius authorized IP route
5: L2TP LNS side user route 5: L2TP LNS side user route
Advertise-Flag: 1 bit. Indicates whether the route should be Advertise-Flag: 1 bit. Indicates whether the route should be
advertised by the UP. Following flags are defined: advertised by the UP. Following flags are defined:
0: Not advertised, 0: Not advertised,
skipping to change at page 83, line 5 skipping to change at page 84, line 32
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.8.2. IPv6 Routing TLV 7.8.2. IPv6 Routing TLV
The IPv6 Routing TLV is used to carry IPv6 network routing The IPv6 Routing TLV is used to carry IPv6 network routing
information. information.
The format of this TLV is as follows: The format of this TLV is as follows:
INTERNET-DRAFT Simple BNG CUSP
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Dest-Address ~ ~ IPv6 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~ ~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index | | Out-If-Index |
skipping to change at page 83, line 31 skipping to change at page 85, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A| | Route Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 45: IPv6 Routing TLV Figure 45: IPv6 Routing TLV
Where: Where:
INTERNET-DRAFT Simple BNG CUSP
The TLV Type: 7 The TLV Type: 7
The TLV Length: Variable The TLV Length: Variable
User-ID: 4 bytes in length. Carries the user identifier. This User-ID: 4 bytes in length. Carries the user identifier. This
field is filled with all Fs when a non-user route is delivered to field is filled with all Fs when a non-user route is delivered to
the UP. the UP.
IPv6 Dest-Address (IPv6-Address type): Identifies the destination IPv6 Dest-Address (IPv6-Address type): Identifies the destination
address. address.
skipping to change at page 84, line 5 skipping to change at page 85, line 30
Out-If-Index (4 bytes): Indicates the interface index. Out-If-Index (4 bytes): Indicates the interface index.
Cost (4 bytes): The cost value of the route. Cost (4 bytes): The cost value of the route.
Tag (4 bytes): The tag value of the route. Tag (4 bytes): The tag value of the route.
Route-Type: (2 bytes): Indicates the route type. The options are Route-Type: (2 bytes): Indicates the route type. The options are
as follows: as follows:
INTERNET-DRAFT Simple BNG CUSP
0: User host route 0: User host route
1: Radius authorization FrameRoute 1: Radius authorization FrameRoute
2: Network segment route 2: Network segment route
3: Gateway route 3: Gateway route
4: Radius authorized IP route 4: Radius authorized IP route
5: L2TP LNS side user route 5: L2TP LNS side user route
Advertise-Flag: 1 bit. Indicates whether the route should be Advertise-Flag: 1 bit. Indicates whether the route should be
advertised by the UP. Following flags are defined: advertised by the UP. Following flags are defined:
0: Not advertised, 0: Not advertised,
skipping to change at page 84, line 31 skipping to change at page 86, line 5
belongs. belongs.
If-Desc sub TLV: carries the interface information. If-Desc sub TLV: carries the interface information.
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.9. Subscriber TLVs 7.9. Subscriber TLVs
The Subscriber TLVs are defined for a CP to send the basic The Subscriber TLVs are defined for a CP to send the basic
information about a user to a UP. information about a user to a UP.
INTERNET-DRAFT Simple BNG CUSP
7.9.1. Basic Subscriber TLV 7.9.1. Basic Subscriber TLV
The Basic Subscriber TLV is used to carry the basic common The Basic Subscriber TLV is used to carry the basic common
information for all kinds of access subscribers. It is carried in an information for all kinds of access subscribers. It is carried in an
Update_Request message. Update_Request message.
INTERNET-DRAFT Simple BNG CUSP
The format of the Basic Subscriber TLV value part is as follows: The format of the Basic Subscriber TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User MAC |
skipping to change at page 85, line 51 skipping to change at page 87, line 5
Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero
means non-PPPoE subscriber. means non-PPPoE subscriber.
User-Mac (MAC-Addr type): The MAC Address of a subscriber. User-Mac (MAC-Addr type): The MAC Address of a subscriber.
Oper-ID (1 byte): Indicates the ID of an operation performed by a Oper-ID (1 byte): Indicates the ID of an operation performed by a
user. This field is carried in the response from the UP. user. This field is carried in the response from the UP.
Reserved (1 byte): MUST be sent as zero and ignored on receipt. Reserved (1 byte): MUST be sent as zero and ignored on receipt.
INTERNET-DRAFT Simple BNG CUSP
Access-Type (1 byte): Access-Type (1 byte):
1: PPP access (PPP) 1: PPP access (PPP [RFC1661])
2: PPP over Ethernet over ATM access (PPPoEoA) 2: PPP over Ethernet over ATM access (PPPoEoA)
3: PPP over ATM access (PPPoA) 3: PPP over ATM access (PPPoA [RFC3336])
4: PPP over Ethernet access (PPPoE) 4: PPP over Ethernet access (PPPoE [RFC2516])
5: PPPoE over VLAN access (PPPoEoVLAN [RFC2516])
INTERNET-DRAFT Simple BNG CUSP
5: PPPoE over VLAN access (PPPoEoVLAN)
6: PPP over LNS access (PPPoLNS) 6: PPP over LNS access (PPPoLNS)
7: IP over Ethernet DHCP access (IPoE_DHCP) 7: IP over Ethernet DHCP access (IPoE_DHCP)
8: IP over Ethernet EAP authentication access (IPoE_EAP) 8: IP over Ethernet EAP authentication access (IPoE_EAP)
9: IP over Ethernet Layer 3 access (IPoE_L3) 9: IP over Ethernet Layer 3 access (IPoE_L3)
10: IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) 10: IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC)
11: Layer 2 Leased Line access (L2_Leased_Line) 11: Layer 2 Leased Line access (L2_Leased_Line)
12: Layer 2 VPN Leased Line access (L2VPN_Leased_Line) 12: Layer 2 VPN Leased Line access (L2VPN_Leased_Line)
13: Layer 3 Leased Line access (L3_Leased_Line) 13: Layer 3 Leased Line access (L3_Leased_Line)
14: Layer 2 Leased line Sub-User access 14: Layer 2 Leased line Sub-User access
(L2_Leased_Line_SUB_USER) (L2_Leased_Line_SUB_USER)
skipping to change at page 86, line 51 skipping to change at page 88, line 5
P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0
indicates that the VLAN ID is invalid. The format is the same as indicates that the VLAN ID is invalid. The format is the same as
that for C-VID. that for C-VID.
Detect-Times (2 bytes): Number of detection timeout times. The Detect-Times (2 bytes): Number of detection timeout times. The
value 0 indicates that no detection is performed. value 0 indicates that no detection is performed.
Detect-Interval (2 bytes): Detection interval in seconds. Detect-Interval (2 bytes): Detection interval in seconds.
INTERNET-DRAFT Simple BNG CUSP
If-Index (4 bytes): Interface index. If-Index (4 bytes): Interface index.
Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried. Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried.
VRF-Name sub-TLV: Indicates the VRF to which the subscriber VRF-Name sub-TLV: Indicates the VRF to which the subscriber
belongs. belongs.
If-Desc sub-TLV: carries the interface information. If-Desc sub-TLV: carries the interface information.
INTERNET-DRAFT Simple BNG CUSP
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.9.2. PPP Subscriber TLV 7.9.2. PPP Subscriber TLV
The PPP Subscriber TLV is defined to carry PPP information of a User 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 from a CP to a UP. It will be carried in an Update_Request message
when PPPoE or L2TP access is used. when PPPoE or L2TP access is used.
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
skipping to change at page 87, line 49 skipping to change at page 89, line 5
User-ID (4 bytes): The identifier of a subscriber. User-ID (4 bytes): The identifier of a subscriber.
MSS-Value (2 bytes): Indicates the MSS value (in bytes). MSS-Value (2 bytes): Indicates the MSS value (in bytes).
MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled. MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled.
0: Disabled. 0: Disabled.
1: Enabled. 1: Enabled.
MRU (2 bytes): PPPoE local MRU (in bytes). MRU (2 bytes): PPPoE local MRU (in bytes).
INTERNET-DRAFT Simple BNG CUSP
Magic-Number (4 bytes): Local magic number in PPP negotiation Magic-Number (4 bytes): Local magic number in PPP negotiation
packets. packets.
Peer-Magic-Number (4 bytes): Remote peer magic number. Peer-Magic-Number (4 bytes): Remote peer magic number.
The Reserved fields MUST be sent as zero and ignored on receipt. The Reserved fields MUST be sent as zero and ignored on receipt.
INTERNET-DRAFT Simple BNG CUSP
7.9.3. IPv4 Subscriber TLV 7.9.3. IPv4 Subscriber TLV
The IPv4 Subscriber TLV is defined to carry IPv4 related information 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 for a BNG user. It will be carried in an Update_Request message when
IPv4 IPoE, or PPPoE access is used. IPv4 IPoE, or PPPoE access is used.
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 88, line 48 skipping to change at page 90, line 5
User-IPv4 (IPv4-Address): The IPv4 address of the subscriber. User-IPv4 (IPv4-Address): The IPv4 address of the subscriber.
Gateway-IPv4 (IPv4-Address): The gateway address of the Gateway-IPv4 (IPv4-Address): The gateway address of the
subscriber. subscriber.
Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on. Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on.
Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on. Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on.
INTERNET-DRAFT Simple BNG CUSP
Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off, Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off,
1: on. 1: on.
IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF)
flag. 0: off, 1: on. flag. 0: off, 1: on.
MTU 2 bytes MTU value. The default value is 1500. MTU 2 bytes MTU value. The default value is 1500.
VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.
INTERNET-DRAFT Simple BNG CUSP
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.9.4. IPv6 Subscriber TLV 7.9.4. IPv6 Subscriber TLV
The IPv6 Subscriber TLV is defined to carry IPv6 related information 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 for a BNG user. It will be carried in an Update_Request message when
IPv6 IPoE, or PPPoE access is used. IPv6 IPoE, or PPPoE access is used.
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
skipping to change at page 89, line 37 skipping to change at page 90, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID | | IPv6 Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID (cont.) | | IPv6 Interface ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P| | MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name sub-TLV (optional) ~ ~ VRF Name sub-TLV (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 749: IPv6 Subscriber TLV Figure 49: IPv6 Subscriber TLV
Where: Where:
The TLV type: 5. The TLV type: 5.
The TLV length: variable. The TLV length: variable.
INTERNET-DRAFT Simple BNG CUSP
User-ID (4 bytes): The identifier of a subscriber. User-ID (4 bytes): The identifier of a subscriber.
User PD-Addresses (IPv6 Address List): Carries a list of Prefix User PD-Addresses (IPv6 Address List): Carries a list of Prefix
Delegation (PD) addresses of the subscriber. Delegation (PD) addresses of the subscriber.
User ND-Addresses (IPv6 Address List): Carries a list of Neighbor User ND-Addresses (IPv6 Address List): Carries a list of Neighbor
Discovery (ND) addresses of the subscriber. Discovery (ND) addresses of the subscriber.
User IANA-Address (IPv6-Address): The IANA address of the User IANA-Address (IPv6-Address): The IANA address of the
subscriber. subscriber.
INTERNET-DRAFT Simple BNG CUSP
IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface. IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface.
Portal Force 1 bit (P): Push advertisement, 0: off, 1: on. Portal Force 1 bit (P): Push advertisement, 0: off, 1: on.
Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on. Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on.
Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off; Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off;
1: on. 1: on.
IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0: IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0:
skipping to change at page 90, line 33 skipping to change at page 92, line 5
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.9.5. IPv4 Static Subscriber Detect TLV 7.9.5. IPv4 Static Subscriber Detect TLV
The IPv4 Static Subscriber Detect TLV is defined to carry IPv4 The IPv4 Static Subscriber Detect TLV is defined to carry IPv4
related information for a static access subscriber. It will be related information for a static access subscriber. It will be
carried in an Update_Request message when IPv4 static access on a UP carried in an Update_Request message when IPv4 static access on a UP
needs to be enabled. needs to be enabled.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Address | | User Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Address | | Gateway Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Reserved | | User MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 750: IPv4 Static Subscriber TLV Figure 50: IPv4 Static Subscriber TLV
INTERNET-DRAFT Simple BNG CUSP
Where: Where:
The TLV type: 6. The TLV type: 6.
The TLV length: variable. The TLV length: variable.
If-Index (4 bytes): The interface index of the interface from If-Index (4 bytes): The interface index of the interface from
which the subscriber will dial-up. which the subscriber will dial-up.
skipping to change at page 91, line 35 skipping to change at page 93, line 5
Gateway Address (IPv4-Addr): The gateway's IPv4 Address. Gateway Address (IPv4-Addr): The gateway's IPv4 Address.
User-MAC (MAC-Addr type): The MAC address of the subscriber. User-MAC (MAC-Addr type): The MAC address of the subscriber.
Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried. Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried.
VRF-Name sub-TLV: Indicates the VEF to which the subscriber VRF-Name sub-TLV: Indicates the VEF to which the subscriber
belongs. belongs.
If-Desc sub-TLV: Carries the interface information. If-Desc sub-TLV: Carries the interface information.
INTERNET-DRAFT Simple BNG CUSP
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.9.6. IPv6 Static Subscriber Detect TLV 7.9.6. IPv6 Static Subscriber Detect TLV
The IPv6 Static Subscriber Detect TLV is defined to carry IPv6 The IPv6 Static Subscriber Detect TLV is defined to carry IPv6
related information for a static access subscriber. It will be related information for a static access subscriber. It will be
carried in an Update_Request message when needed to enable IPv6 carried in an Update_Request message when needed to enable IPv6
static subscriber detection on a UP. static subscriber detection on a UP.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Address ~ ~ User Address ~
skipping to change at page 92, line 46 skipping to change at page 94, line 5
which the subscriber will dial-up. which the subscriber will dial-up.
C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0
indicates that the VLAN ID is invalid. A valid value is 1~4094. indicates that the VLAN ID is invalid. A valid value is 1~4094.
P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0
indicates that the VLAN ID is invalid. The format is the same as indicates that the VLAN ID is invalid. The format is the same as
that the of C-VID. A valid value is 1~4094. For a single-layer that the of C-VID. A valid value is 1~4094. For a single-layer
VLAN, set this parameter to PeVid. VLAN, set this parameter to PeVid.
INTERNET-DRAFT Simple BNG CUSP
User Address (IPv6-Address type): The subscriber's IPv6 address. User Address (IPv6-Address type): The subscriber's IPv6 address.
Gateway Address (IPv6-Address type): The gateway's IPv6 Address. Gateway Address (IPv6-Address type): The gateway's IPv6 Address.
User-MAC (MAC-Addr type): The MAC address of the subscriber. User-MAC (MAC-Addr type): The MAC address of the subscriber.
sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried
VRF-Name Sub-TLV: Indicates the VRF to which the subscriber VRF-Name Sub-TLV: Indicates the VRF to which the subscriber
belongs. belongs.
If-Desc sub-TLV: Carries the interface information. If-Desc sub-TLV: Carries the interface information.
INTERNET-DRAFT Simple BNG CUSP
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.9.7. L2TP-LAC Subscriber TLV 7.9.7. L2TP-LAC Subscriber TLV
The L2TP-LAC Subscriber TLV is defined to carry the related The L2TP-LAC Subscriber TLV is defined to carry the related
information for a L2TP LAC access subscriber. It will be carried in information for a L2TP LAC access subscriber. It will be carried in
an Update_Request message when L2TP LAC access is used. an Update_Request message when L2TP LAC access is used.
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
skipping to change at page 93, line 44 skipping to change at page 95, line 5
User-ID (4 bytes): The identifier of a user/subscriber. User-ID (4 bytes): The identifier of a user/subscriber.
Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
Local-Session-ID (2 bytes): The local session ID with the L2TP Local-Session-ID (2 bytes): The local session ID with the L2TP
tunnel. tunnel.
Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel. Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel.
INTERNET-DRAFT Simple BNG CUSP
Remote-Session-ID (2 bytes): The remote session ID of the L2TP Remote-Session-ID (2 bytes): The remote session ID of the L2TP
tunnel. tunnel.
7.9.8. L2TP-LNS Subscriber TLV 7.9.8. L2TP-LNS Subscriber TLV
The L2TP-LNS Subscriber TLV is defined to carry the related The L2TP-LNS Subscriber TLV is defined to carry the related
information for a L2TP LNS access subscriber. It will be carried in information for a L2TP LNS access subscriber. It will be carried in
an Update_Request message when L2TP LNS access is used. an Update_Request message when L2TP LNS access is used.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Local Session ID | | Local Tunnel ID | Local Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Tunnel ID | Remote Session ID | | Remote Tunnel ID | Remote Session ID |
skipping to change at page 94, line 45 skipping to change at page 96, line 5
Remote-Session-ID (2 bytes): The remote session ID of the L2TP Remote-Session-ID (2 bytes): The remote session ID of the L2TP
tunnel. tunnel.
7.9.9. L2TP-LAC Tunnel TLV 7.9.9. L2TP-LAC Tunnel TLV
The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel
related information. It will be carried in the Update_Request related information. It will be carried in the Update_Request
message when L2TP LAC access is used. message when L2TP LAC access is used.
The format of the TLV value part is as follows:
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Remote Tunnel ID | | Local Tunnel ID | Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Source Address ~ ~ Tunnel Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Destination Address ~ ~ Tunnel Destination Address ~
skipping to change at page 95, line 52 skipping to change at page 97, line 5
VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel
belongs. belongs.
7.9.10. L2TP-LNS Tunnel TLV 7.9.10. L2TP-LNS Tunnel TLV
The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel
related information. It will be carried in the Update_Request related information. It will be carried in the Update_Request
message when L2TP LNS access is used. message when L2TP LNS access is used.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
INTERNET-DRAFT Simple BNG CUSP
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Remote Tunnel ID | | Local Tunnel ID | Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Source Address ~ ~ Tunnel Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Destination Address ~ ~ Tunnel Destination Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 97, line 7 skipping to change at page 98, line 7
belongs. belongs.
7.9.11. Update Response TLV 7.9.11. Update Response TLV
The Update Response TLV is used to return the operation result of an 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 update request. It is carried in the Update_Response message as a
response to the Update_Request message. response to the Update_Request message.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
The format of Session Update Response TLV is as follows: The format of Update Response TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID | | User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-Trans-ID | Oper-Code | Oper-Result | Reserved | | User-Trans-ID | Oper-Code | Oper-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code | | Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 56: Session Update Response TLV Figure 56: Update Response TLV
Where: Where:
The TLV type: 302. The TLV type: 302.
The TLV length: 12. The TLV length: 12.
User-ID (4 bytes): A unique identifier of an user/subscriber. User-ID (4 bytes): A unique identifier of an user/subscriber.
User-Trans-ID (1 byte): In the case of dual-stack access or when User-Trans-ID (1 byte): In the case of dual-stack access or when
skipping to change at page 100, line 54 skipping to change at page 102, line 5
sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried. sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried.
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.10.2. Board Status TLV 7.10.2. Board Status TLV
The Board Status TLV is used to carry the status information of a The Board Status TLV is used to carry the status information of a
board on an UP. It is carried in a Report message. board on an UP. It is carried in a Report message.
The format of Board Status TLV is as follows:
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
The format of Board Status TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board-Type | Board-State | Reserved | Chassis | | Board-Type | Board-State | Reserved | Chassis |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot | Reserved | | Slot | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 60: Interface Resource TLV Figure 60: Interface Resource TLV
skipping to change at page 101, line 48 skipping to change at page 103, line 5
7.11. CGN TLVs 7.11. CGN TLVs
7.11.1. Address Allocation Request TLV 7.11.1. Address Allocation Request TLV
The Address Allocation Request TLV is used to request address The Address Allocation Request TLV is used to request address
allocation from CP. An address Pool-Name sub-TLV is carried to allocation from CP. An address Pool-Name sub-TLV is carried to
indicate from which address pool to allocate addresses. The Address indicate from which address pool to allocate addresses. The Address
Allocation Request TLV is carried in the Addr_Allocation_Req message. Allocation Request TLV is carried in the Addr_Allocation_Req message.
The format of the value part of this TLV is as follows:
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
The format of the value part of this TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~ ~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 61: Address Allocation Request TLV Figure 61: Address Allocation Request TLV
Where: Where:
skipping to change at page 102, line 54 skipping to change at page 104, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 62: Address Assignment Response TLV Figure 62: Address Assignment Response TLV
Where: Where:
The TLV type: 401. The TLV type: 401.
The TLV length: variable. The TLV length: variable.
Lease Time (4 bytes): Duration of address lease in seconds.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
Lease Time (4 bytes): Duration of address lease in seconds.
IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4 IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4
address. address.
Error-Code (4 bytes): Indicates success or an error. Error-Code (4 bytes): Indicates success or an error.
0: Success. 0: Success.
1: Failure. 1: Failure.
3001 (Pool-Mismatch): The corresponding address pool cannot be 3001 (Pool-Mismatch): The corresponding address pool cannot be
skipping to change at page 103, line 53 skipping to change at page 105, line 4
Where: Where:
The TLV type: 402. The TLV type: 402.
The TLV length: variable. The TLV length: variable.
IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed. IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed.
Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which
Address pool to renew the address.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
Address pool to renew the address.
7.11.4. The Address Renewal Response TLV 7.11.4. The Address Renewal Response TLV
The Address Renewal Response TLV is used to return the address The Address Renewal Response TLV is used to return the address
renewal result. It is carried in the Addr_Renew_Ack message. renewal result. It is carried in the Addr_Renew_Ack message.
The format of this TLV value is as follows: The format of this TLV value is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 104, line 54 skipping to change at page 106, line 5
3002 (Pool-Full): The address pool is fully allocated and no 3002 (Pool-Full): The address pool is fully allocated and no
address segment is available. address segment is available.
3003 (Subnet-Mismatch): The address pool subnet cannot be 3003 (Subnet-Mismatch): The address pool subnet cannot be
found. found.
3004 (Subnet-Conflict): Subnets in the address pool have been 3004 (Subnet-Conflict): Subnets in the address pool have been
assigned to other clients. assigned to other clients.
INTERNET-DRAFT Simple BNG CUSP
Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which
Address pool to renew the address. Address pool to renew the address.
INTERNET-DRAFT Simple BNG CUSP
7.11.5. Address Release Request TLV 7.11.5. Address Release Request TLV
The Address Release Request TLV is used to release an IPv4 address. The Address Release Request TLV is used to release an IPv4 address.
It is carried in the Addr_Release_Req message. It is carried in the Addr_Release_Req message.
The value part of this TLV is formatted as follows: The value part of this TLV is formatted as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 105, line 43 skipping to change at page 107, line 5
released. released.
Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which
Address pool to release the address. Address pool to release the address.
7.11.6. The Address Release Response TLV 7.11.6. The Address Release Response TLV
The Address Release Response TLV is used to return the address The Address Release Response TLV is used to return the address
release result. It is carried in the Addr_Release_Ack message. release result. It is carried in the Addr_Release_Ack message.
The format of this TLV is as follows:
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
The format of this TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address and Mask | | IPv4 Address and Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address and Mask continued | | IPv4 Address and Mask continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code | | Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~ ~ Pool-Name sub-TLV ~
skipping to change at page 106, line 47 skipping to change at page 108, line 4
3003 (Subnet-Mismatch): The address cannot be found. 3003 (Subnet-Mismatch): The address cannot be found.
3004 (Subnet-Conflict): The address has been allocated to 3004 (Subnet-Conflict): The address has been allocated to
another subscriber. another subscriber.
Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which
address pool to release the address. address pool to release the address.
7.12. Event TLVs 7.12. Event TLVs
INTERNET-DRAFT Simple BNG CUSP
7.12.1. Subscriber Traffic Statistics TLV 7.12.1. Subscriber Traffic Statistics TLV
The Subscriber Traffic Statistics TLV is used to return the traffic The Subscriber Traffic Statistics TLV is used to return the traffic
statistics of a user/subscriber. The format of this TLV is as statistics of a user/subscriber. The format of this TLV is as
follows: follows:
INTERNET-DRAFT Simple BNG CUSP
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID | | User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Type | | Statistics Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (upper part) | | Ingress Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (lower part) | | Ingress Packets (lower part) |
skipping to change at page 107, line 51 skipping to change at page 109, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (upper part) | | Egress Loss Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (lower part) | | Egress Loss Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 67: Subscriber Traffic Statistics TLV Figure 67: Subscriber Traffic Statistics TLV
Where: Where:
INTERNET-DRAFT Simple BNG CUSP
The TLV type: 300. The TLV type: 300.
The TLV length: 72 octets. The TLV length: 72 octets.
User-ID (4 bytes): The user/subscriber identifier. User-ID (4 bytes): The user/subscriber identifier.
INTERNET-DRAFT Simple BNG CUSP
Statistics-Type (4 bytes): Traffic type. It can be one of the Statistics-Type (4 bytes): Traffic type. It can be one of the
following options: following options:
0: IPv4 traffic. 0: IPv4 traffic.
1: IPv6 traffic. 1: IPv6 traffic.
2: Dual stack traffic. 2: Dual stack traffic.
Ingress Packets (8 bytes): The number of the packets in upstream Ingress Packets (8 bytes): The number of the packets in upstream
direction. direction.
skipping to change at page 108, line 44 skipping to change at page 110, line 5
packets. packets.
7.12.2. Subscriber Detection Result TLV 7.12.2. Subscriber Detection Result TLV
The Subscriber Detection Result TLV is used to return the detection The Subscriber Detection Result TLV is used to return the detection
result of a subscriber. Subscriber detection is a function to detect result of a subscriber. Subscriber detection is a function to detect
whether a subscriber is online or not. The result can be used by the whether a subscriber is online or not. The result can be used by the
CP to determine how to deal with the subscriber session. (e.g., CP to determine how to deal with the subscriber session. (e.g.,
delete the session if detection failed). delete the session if detection failed).
INTERNET-DRAFT Simple BNG CUSP
The format of this TLV value part is as follows: The format of this TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID | | User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect Type | Detect Result | Reserved | | Detect Type | Detect Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 68: Subscriber Detection Result TLV Figure 68: Subscriber Detection Result TLV
INTERNET-DRAFT Simple BNG CUSP
Where: Where:
The TLV type: 301. The TLV type: 301.
The TLV length: 8 octets. The TLV length: 8 octets.
User-ID (4 bytes): A user/subscriber identifier. User-ID (4 bytes): A user/subscriber identifier.
Detect-Type (1 byte): Detect-Type (1 byte):
skipping to change at page 109, line 39 skipping to change at page 111, line 5
The Reserved field MUST be sent as zero and ignored on receipt. The Reserved field MUST be sent as zero and ignored on receipt.
7.13. Vendor TLV 7.13. Vendor TLV
The Vendor ID TLV occurs as the first TLV in the Vendor message The Vendor ID TLV occurs as the first TLV in the Vendor message
(Section 6.6). It provides a Sub-Type that effectively extends the (Section 6.6). It provides a Sub-Type that effectively extends the
message type in the message header, provides for versioning of vendor message type in the message header, provides for versioning of vendor
TLVs, and can accommodate sub-TLVs. TLVs, and can accommodate sub-TLVs.
INTERNET-DRAFT Simple BNG CUSP
The value part of the Vendor TLV is formatted as follows: The value part of the Vendor TLV is formatted as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version | | Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 69: Vendor TLV Figure 69: Vendor TLV
Where: Where:
INTERNET-DRAFT Simple BNG CUSP
The TLV type: 1024. The TLV type: 1024.
The TLV length: variable. The TLV length: variable.
Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS [RFC2865]. Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS [RFC2865].
Sub-Type (2 bytes): Used by the Vendor to distinguish multiple Sub-Type (2 bytes): Used by the Vendor to distinguish multiple
different vendor messages. different vendor messages.
Sub-Type-Version (2 bytes): Used by the Vendor to distinguish Sub-Type-Version (2 bytes): Used by the Vendor to distinguish
skipping to change at page 114, line 46 skipping to change at page 115, line 46
204 Addr_Release_Req 6.5.5. 204 Addr_Release_Req 6.5.5.
205 Addr_Release_Ack 6.5.6. 205 Addr_Release_Ack 6.5.6.
206-254 - Unassigned 206-254 - Unassigned
255 - Reserved 255 - Reserved
9.2. TLV Types 9.2. TLV Types
Type Name Usage Description Type Name Usage Description
------ ------------ -------------------------- ------ ------------ --------------------------
0 reserved - 0 reserved -
1 BAS Function Enabler Carries the BNG access 1 BAS Function Carries the BNG access
functions to be enabled or functions to be enabled or
disabled on specified disabled on specified
interfaces. interfaces.
2 Basic Subscriber Carries the basic information 2 Basic Subscriber Carries the basic information
about a BNG subscriber. about a BNG subscriber.
3 PPP Subscriber Carries the PPP information 3 PPP Subscriber Carries the PPP information
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
about a BNG subscriber. about a BNG subscriber.
skipping to change at page 115, line 55 skipping to change at page 116, line 55
the UP including physical the UP including physical
interfaces, sub-interfaces, interfaces, sub-interfaces,
trunk interfaces, and tunnel trunk interfaces, and tunnel
interfaces. interfaces.
201 Board Status Board information reported by 201 Board Status Board information reported by
the UP including the board the UP including the board
type and in-position status. type and in-position status.
202-299 unassigned - 202-299 unassigned -
300 Subscriber Traffic Statistics User traffic statistics. 300 Subscriber Traffic Statistics User traffic statistics.
301 Subscriber Detection Results User detection information. 301 Subscriber Detection Results User detection information.
302 Session Update Response The processing result of a 302 Update Response The processing result of a
subscriber session update. subscriber session update.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
303-299 unassigned - 303-299 unassigned -
400 Address Allocation Request Request address allocation. 400 Address Allocation Request Request address allocation.
401 Address Allocation Response Address allocation response. 401 Address Allocation Response Address allocation response.
402 Address Renewal Request Request for address lease 402 Address Renewal Request Request for address lease
renewal. renewal.
403 Address Renewal Response Response to a request for 403 Address Renewal Response Response to a request for
skipping to change at page 116, line 34 skipping to change at page 118, line 5
TLV operation codes appear in the Oper field in the header of some TLV operation codes appear in the Oper field in the header of some
TLVs. See Section 7.1. TLVs. See Section 7.1.
Code Operation Code Operation
---- ---------- ---- ----------
0 - reserved 0 - reserved
1 Update 1 Update
2 Delete 2 Delete
3-15 - unassigned 3-15 - unassigned
INTERNET-DRAFT Simple BNG CUSP
9.4. Sub-TLV Types 9.4. Sub-TLV Types
See Section 7.3. See Section 7.3.
INTERNET-DRAFT Simple BNG CUSP Type Name Section of this document
---- ------------------ ------------------------
Type Name Reference
---- ------------------ ---------------.................
0 - reserved 0 - reserved
1 VRF Name 7.3.1. 1 VRF Name 7.3.1.
2 Ingress-QoS-Profile 7.3.1. 2 Ingress-QoS-Profile 7.3.1.
3 Egress-QoS-Profile 7.3.1. 3 Egress-QoS-Profile 7.3.1.
4 User-ACL-Policy 7.3.1. 4 User-ACL-Policy 7.3.1.
5 Multicast-ProfileV4 7.3.1. 5 Multicast-ProfileV4 7.3.1.
6 Multicast-ProfileV6 7.3.1. 6 Multicast-ProfileV6 7.3.1.
7 Ingress-CAR 7.3.2. 7 Ingress-CAR 7.3.2.
8 Egress-CAR 7.3.3. 8 Egress-CAR 7.3.3.
9 NAT-Instance 7.3.1. 9 NAT-Instance 7.3.1.
skipping to change at page 117, line 51 skipping to change at page 119, line 4
1002 Keepalive Error The keepalive negotiation fails. 1002 Keepalive Error The keepalive negotiation fails.
1003 Timer Expires The establishment timer expired. 1003 Timer Expires The establishment timer expired.
1004-1999 - unassigned Unassigned error codes for version 1004-1999 - unassigned Unassigned error codes for version
negotiation. negotiation.
2000 - reserved 2000 - reserved
2001 Synch-NoReady The data to be smoothed is not ready. 2001 Synch-NoReady The data to be smoothed is not ready.
2002 Synch-Unsupport The request for smooth data is not 2002 Synch-Unsupport The request for smooth data is not
supported. supported.
2003-2999 - unassigned Unassigned data synchronization error 2003-2999 - unassigned Unassigned data synchronization error
codes. codes.
INTERNET-DRAFT Simple BNG CUSP
3000 - reserved 3000 - reserved
3001 Pool-Mismatch The corresponding address pool cannot be 3001 Pool-Mismatch The corresponding address pool cannot be
found. found.
3002 Pool-Full The address pool is fully allocated and no 3002 Pool-Full The address pool is fully allocated and no
INTERNET-DRAFT Simple BNG CUSP
address segment is available. address segment is available.
3003 Subnet-Mismatch The address pool subnet cannot be found. 3003 Subnet-Mismatch The address pool subnet cannot be found.
3004 Subnet-Conflict Subnets in the address pool have been 3004 Subnet-Conflict Subnets in the address pool have been
classified into other clients. classified into other clients.
3005-3999 - unassigned Unassigned error codes for address 3005-3999 - unassigned Unassigned error codes for address
allocation. allocation.
4000 - reserved 4000 - reserved
4001 Update-Fail-No-Res The forwarding table fails to be 4001 Update-Fail-No-Res The forwarding table fails to be
delivered because the forwarding resources delivered because the forwarding resources
are insufficient. are insufficient.
skipping to change at page 119, line 9 skipping to change at page 120, line 9
4005 Statistic-Fail-No-Res Statistics processing failed due to 4005 Statistic-Fail-No-Res Statistics processing failed due to
insufficient statistics resources. insufficient statistics resources.
4006-4999 - unassigned forwarding table delivery error codes. 4006-4999 - unassigned forwarding table delivery error codes.
5000-4294967295 - reserved 5000-4294967295 - reserved
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign a service name and port for BNG S-CUSP as This document requires no IANA actions.
follows:
Service Port Transport
Name Number Protocol Description Reference
------- ------ --------- ------------- ---------------
s-cusp tbd1 TCP Control-plane and [this document]
User-plane
Separation Protocol
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
11. Security Considerations 11. Security Considerations
The Service, Control, and Management Interfaces between the CP and UP The Service, Control, and Management Interfaces between the CP and UP
might be across the general Internet or other hostile environment. 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 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 Thus, appropriate protections MUST be implemented to provide
integrity, authenticity, and secrecy of traffic over those integrity, authenticity, and secrecy of traffic over those
interfaces. Whether such protection is used is an operator decision. interfaces. Whether such protection is used is a network operator
decision. See [RFC6241] for Management Interface / NETCONF security.
Security on the Service Interface is dependent on the tunneling
protocol used which is out of scope for this document. Security for
the Control Interface, over which the S-CUSP protocol flows, is
further discussed below.
The S-CUSP messages do not provide security. Thus, if these messages S-CUSP messages do not provide security. Thus, if these messages are
are exchanged in an environment where security is a concern, that exchanged in an environment where security is a concern, that
security MUST be provided by another protocol such as TLS 1.3 security MUST be provided by another protocol such as TLS 1.3
[RFC8446] or IPSEC. However, such security protocols need not always [RFC8446] or IPSEC. TLS 1.3 is the mandatory to implement protocol
be used and lesser security precautions might be appropriate because, for interoperability. However, such security protocols need not
in some cases, the communication between the CP and UP is in a more always be used and lesser security precautions might be appropriate
benign environment. because, in some cases, the communication between the CP and UP is in
a benign environment.
INTERNET-DRAFT Simple BNG CUSP INTERNET-DRAFT Simple BNG CUSP
Contributors Contributors
Zhouyi Yu Zhouyi Yu
Huawei Technologies Huawei Technologies
Email: yuzhouyi@huawei.com Email: yuzhouyi@huawei.com
skipping to change at page 122, line 41 skipping to change at page 124, line 5
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>. 2017, <https://www.rfc-editor.org/info/rfc8174>.
INTERNET-DRAFT Simple BNG CUSP
Informative References Informative References
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area
networks / Bridges and Bridged Networks", IEEE Std networks / Bridges and Bridged Networks", IEEE Std
802.1Q-2014, 3 November 2013. 802.1Q-2014, 3 November 2013.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>. <https://www.rfc-editor.org/info/rfc1661>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
DOI 10.17487/RFC2131, March 1997, <https://www.rfc- DOI 10.17487/RFC2131, March 1997, <https://www.rfc-
editor.org/info/rfc2131>. editor.org/info/rfc2131>.
INTERNET-DRAFT Simple BNG CUSP [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February
1999, <https://www.rfc-editor.org/info/rfc2516>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
<https://www.rfc-editor.org/info/rfc2698>. <https://www.rfc-editor.org/info/rfc2698>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, DOI Address Translator (Traditional NAT)", RFC 3022, DOI
10.17487/RFC3022, January 2001, <https://www.rfc- 10.17487/RFC3022, January 2001, <https://www.rfc-
editor.org/info/rfc3022> editor.org/info/rfc3022>
[RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over
Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC
3336, DOI 10.17487/RFC3336, December 2002,
<https://www.rfc-editor.org/info/rfc3336>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used
to Form Encoding Rules in Various Routing Protocol to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>. 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>. October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
INTERNET-DRAFT Simple BNG CUSP
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, RFC Code: The Implementation Status Section", BCP 205, RFC
7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc- 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-
editor.org/info/rfc7942>. editor.org/info/rfc7942>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[TR-384] Broadband Forum, "Cloud Central Office Reference [TR-384] Broadband Forum, "Cloud Central Office Reference
 End of changes. 212 change blocks. 
476 lines changed or deleted 499 lines changed or added

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