< draft-chz-simple-cu-separation-bng-protocol-00.txt   draft-chz-simple-cu-separation-bng-protocol-01.txt >
Network Working Group S. Hu INTERNET-DRAFT S. Hu
Internet-Draft China Mobile Intended status: Informational China Mobile
Intended status: Informational D. Eastlake D. Eastlake
Expires: December 5, 2019 M. Chen Futurewei Technologies
M. Chen
Huawei Technologies Huawei Technologies
F. Qin F. Qin
Z. Li Z. Li
China Mobile China Mobile
T. Chua T. Chua
Singapore Telecommunications Limited Singapore Telecommunications
D. Huang Expires: December 13, 2019 June 14, 2019
ZTE
June 03, 2019
The China Mobile, Huawei, and ZTE BNG Simple Control and User Plane The China Mobile, Huawei, and ZTE BNG
Separation Protocol (S-CUSP) Simple Control and User Plane Separation Protocol (S-CUSP)
draft-chz-simple-cu-separation-bng-protocol-00 draft-chz-simple-cu-separation-bng-protocol-01
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). This document is intended to CUPS control channel Protocol (S-CUSP).
make the S-CUSP specification conveniently available to the Internet
community. This document is not an IETF standard and does not have IETF
consensus. It is presented here to make the S-CUSP specification
conveniently available to the Internet community to enable diagnosis
and interoperability.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF), its areas, and its working groups. Note that
working documents as Internet-Drafts. The list of current Internet- other groups may also distribute working documents as Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2019. INTERNET-DRAFT Simple BNG CUSP
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the The list of current Internet-Drafts can be accessed at
document authors. All rights reserved. http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is subject to BCP 78 and the IETF Trust's Legal INTERNET-DRAFT Simple BNG CUSP
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction...........................................6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. BNG CUPS Overview . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology............................................7
3.1. BNG CUPS Motivation . . . . . . . . . . . . . . . . . . . 8 2.1. Implementation Requirement Keywords................7
3.2. BNG CUPS Architecture Overview . . . . . . . . . . . . . 8 2.2. Terms..............................................7
3.3. BNG CUPS Interfaces . . . . . . . . . . . . . . . . . . . 10
3.3.1. Service Interface . . . . . . . . . . . . . . . . . . 11 3. BNG CUPS Overview.....................................10
3.3.2. Management Interface . . . . . . . . . . . . . . . . 11 3.1. BNG CUPS Motivation...............................10
3.3.3. Control Interface . . . . . . . . . . . . . . . . . . 11 3.2. BNG CUPS Architecture Overview....................10
3.4. BNG CUPS Procedure Overview . . . . . . . . . . . . . . . 12 3.3. BNG CUPS Interfaces...............................12
4. S-CUSP Protocol Overview . . . . . . . . . . . . . . . . . . 14 3.3.1. Service Interface...............................13
4.1. Control Channel Related Procedures . . . . . . . . . . . 14 3.3.2. Control Interface...............................14
4.1.1. S-CUSP Session Establishment . . . . . . . . . . . . 14 3.3.3. Management Interface............................14
4.1.2. Keep Alive . . . . . . . . . . . . . . . . . . . . . 16 3.4. BNG CUPS Procedure Overview.......................14
4.2. Node Related Procedures . . . . . . . . . . . . . . . . . 16
4.2.1. UP Board and Interface Status Report . . . . . . . . 16 4. S-CUSP Protocol Overview..............................18
4.2.2. Enable BAS Function on Access Interface . . . . . . . 17 4.1. Control Channel Related Procedures................18
4.2.3. Advertise Subscriber Network Routing . . . . . . . . 17 4.1.1. S-CUSP Session Establishment....................18
4.2.4. CGN Public IP Address Allocation . . . . . . . . . . 18 4.1.2. Keep Alive......................................19
4.2.5. Data Synchronization Between CP and UP . . . . . . . 19 4.2. Node Related Procedures...........................20
4.3. Subscriber Session Related Procedures . . . . . . . . . . 20 4.2.1. UP Resource Report..............................20
4.3.1. Create Subscriber Session . . . . . . . . . . . . . . 21 4.2.2. Enable BAS Function on Access Interface.........20
4.3.2. Update Subscriber Session . . . . . . . . . . . . . . 22 4.2.3. Update Subscriber Network Routing...............21
4.3.3. Delete Subscriber Session . . . . . . . . . . . . . . 23 4.2.4. CGN Public IP Address Allocation................21
4.3.4. Subscriber Session Events Report . . . . . . . . . . 23 4.2.5. Data Synchronization between the CP and UP......23
5. S-CUSP Call Flows . . . . . . . . . . . . . . . . . . . . . . 24 4.3. Subscriber Session Related Procedures.............24
5.1. IPoE . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.1. Create Subscriber Session.......................25
5.1.1. DHCPv4 Access . . . . . . . . . . . . . . . . . . . . 24 4.3.2. Update Subscriber Session.......................26
5.1.2. DHCPv6 Access . . . . . . . . . . . . . . . . . . . . 26 4.3.3. Delete Subscriber Session.......................26
5.1.3. IPv6 SLAAC Access . . . . . . . . . . . . . . . . . . 28 4.3.4. Subscriber Session Events Report................27
5.1.4. DHCPv6 + SLAAC Access . . . . . . . . . . . . . . . . 30
5.1.5. DHCP Dual Stack Access . . . . . . . . . . . . . . . 32 5. S-CUSP Call Flows.....................................28
5.1.6. L2 Static Subscriber Access . . . . . . . . . . . . . 35 5.1. IPoE..............................................28
5.2. PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1. DHCPv4 Access...................................28
5.2.1. IPv4 PPPoE Access . . . . . . . . . . . . . . . . . . 37 5.1.2. DHCPv6 Access...................................29
5.2.2. IPv6 PPPoE Access . . . . . . . . . . . . . . . . . . 39 5.1.3. IPv6 SLAAC Access...............................31
5.2.3. PPPoE Dual Stack Access . . . . . . . . . . . . . . . 41 5.1.4. DHCPv6 + SLAAC Access...........................32
5.3. WLAN Access . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.5. DHCP Dual Stack Access..........................34
5.4. L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.1.6. L2 Static Subscriber Access.....................36
5.4.1. L2TP LAC Access . . . . . . . . . . . . . . . . . . . 46 5.2. PPPoE.............................................39
5.4.2. L2TP LNS IPv4 Access . . . . . . . . . . . . . . . . 47 5.2.1. IPv4 PPPoE Access...............................39
5.4.3. L2TP LNS IPv6 Access . . . . . . . . . . . . . . . . 49 5.2.2. IPv6 PPPoE Access...............................40
5.5. CGN (Carrier Grade NAT) . . . . . . . . . . . . . . . . . 52 5.2.3. PPPoE Dual Stack Access.........................42
5.6. L3 Leased Line Access . . . . . . . . . . . . . . . . . . 54 5.3. WLAN Access.......................................44
5.6.1. Web Authentication . . . . . . . . . . . . . . . . . 54 5.4. L2TP..............................................46
5.6.2. User Traffic Trigger . . . . . . . . . . . . . . . . 57 5.4.1. L2TP LAC Access.................................46
5.7. Multicast Access . . . . . . . . . . . . . . . . . . . . 58 5.4.2. L2TP LNS IPv4 Access............................48
6. S-CUSP Message Formats . . . . . . . . . . . . . . . . . . . 60 5.4.3. L2TP LNS IPv6 Access............................50
6.1. Common Message Header . . . . . . . . . . . . . . . . . . 60 5.5. CGN (Carrier Grade NAT)...........................52
6.2. Control Messages . . . . . . . . . . . . . . . . . . . . 61
6.2.1. Hello Message . . . . . . . . . . . . . . . . . . . . 61 INTERNET-DRAFT Simple BNG CUSP
6.2.2. Keepalive Message . . . . . . . . . . . . . . . . . . 62
6.2.3. Synch_Request Message . . . . . . . . . . . . . . . . 62 Table of Contents (continued)
6.2.4. Sync_Begin Message . . . . . . . . . . . . . . . . . 62
6.2.5. Sync_Data Message . . . . . . . . . . . . . . . . . . 63 5.6. L3 Leased Line Access.............................54
6.2.6. Sync_End Message . . . . . . . . . . . . . . . . . . 64 5.6.1. Web Authentication..............................54
6.2.7. Update_Request Message . . . . . . . . . . . . . . . 64 5.6.2. User Traffic Trigger............................56
6.2.8. Update_Response Message . . . . . . . . . . . . . . . 64 5.7. Multicast Access..................................57
6.3. Event Message . . . . . . . . . . . . . . . . . . . . . . 65
6.4. Report Message . . . . . . . . . . . . . . . . . . . . . 66 6. S-CUSP Message Formats................................59
6.5. CGN Messages . . . . . . . . . . . . . . . . . . . . . . 66 6.1. Common Message Header.............................59
6.5.1. Addr_Allocation_Req Message . . . . . . . . . . . . . 66 6.2. Control Messages..................................60
6.5.2. Addr_Allocation_Ack Message . . . . . . . . . . . . . 66 6.2.1. Hello Message...................................60
6.5.3. Addr_Renew_Req Message . . . . . . . . . . . . . . . 66 6.2.2. Keepalive Message...............................61
6.5.4. Addr_Renew_Ack Message . . . . . . . . . . . . . . . 67 6.2.3. Sync_Request Message............................61
6.5.5. Addr_Release_Req Message . . . . . . . . . . . . . . 67 6.2.4. Sync_Begin Message..............................61
6.5.6. Addr_Release_Ack Message . . . . . . . . . . . . . . 67 6.2.5. Sync_Data Message...............................62
6.6. Vendor Message . . . . . . . . . . . . . . . . . . . . . 67 6.2.6. Sync_End Message................................62
7. S-CUSP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . 67 6.2.7. Update_Request Message..........................63
7.1. Common TLV Header . . . . . . . . . . . . . . . . . . . . 68 6.2.8. Update_Response Message.........................63
7.2. Basic Data Fields . . . . . . . . . . . . . . . . . . . . 68 6.3. Event Message.....................................64
7.3. Sub-TLV Format and Sub-TLVs . . . . . . . . . . . . . . . 69 6.4. Report Message....................................65
7.3.1. Name sub-TLVs . . . . . . . . . . . . . . . . . . . . 70 6.5. CGN Messages......................................65
7.3.2. Ingress-CAR sub-TLV . . . . . . . . . . . . . . . . . 70 6.5.1. Addr_Allocation_Req Message.....................65
7.3.3. Egress-CAR sub-TLV . . . . . . . . . . . . . . . . . 71 6.5.2. Addr_Allocation_Ack Message.....................65
7.3.4. If-Desc sub-TLV . . . . . . . . . . . . . . . . . . . 71 6.5.3. Addr_Renew_Req Message..........................66
7.3.5. IPv6 Address List sub-TLV . . . . . . . . . . . . . . 73 6.5.4. Addr_Renew_Ack Message..........................66
7.4. The Hello TLV . . . . . . . . . . . . . . . . . . . . . . 73 6.5.5. Addr_Release_Req Message........................66
7.5. The Keep Alive TLV . . . . . . . . . . . . . . . . . . . 75 6.5.6. Addr_Release_Ack Message........................66
7.6. The Error Information TLV . . . . . . . . . . . . . . . . 75 6.6. Vendor Message....................................66
7.7. BAS Function Enabler TLV . . . . . . . . . . . . . . . . 76 6.7 Error Message.......................................67
7.8. Routing TLVs . . . . . . . . . . . . . . . . . . . . . . 79
7.8.1. IPv4 Routing TLV . . . . . . . . . . . . . . . . . . 79 7. S-CUSP TLVs and Sub-TLVs..............................68
7.8.2. IPv6 Routing TLV . . . . . . . . . . . . . . . . . . 80 7.1. Common TLV Header.................................68
7.9. Subscriber TLVs . . . . . . . . . . . . . . . . . . . . . 82 7.2. Basic Data Fields.................................69
7.9.1. Basic Subscriber TLV . . . . . . . . . . . . . . . . 82 7.3. Sub-TLV Format and Sub-TLVs.......................70
7.9.2. PPP Subscriber TLV . . . . . . . . . . . . . . . . . 85 7.3.1. Name sub-TLVs...................................70
7.9.3. IPv4 Subscriber TLV . . . . . . . . . . . . . . . . . 86 7.3.2. Ingress-CAR sub-TLV.............................71
7.9.4. IPv6 Subscriber TLV . . . . . . . . . . . . . . . . . 87 7.3.3. Egress-CAR sub-TLV..............................71
7.9.5. IPv4 Static Subscriber TLV . . . . . . . . . . . . . 89 7.3.4. If-Desc sub-TLV.................................72
7.9.6. IPv6 Static Subscriber TLV . . . . . . . . . . . . . 90 7.3.5. IPv6 Address List sub-TLV.......................74
7.9.7. L2TP-LAC Subscriber TLV . . . . . . . . . . . . . . . 91 7.3.6. Vendor sub-TLV..................................74
7.9.8. L2TP-LNS Subscriber TLV . . . . . . . . . . . . . . . 92 7.4. The Hello TLV.....................................76
7.9.9. L2TP-LAC Tunnel TLV . . . . . . . . . . . . . . . . . 93 7.5. The Keep Alive TLV................................77
7.9.10. L2TP-LNS Tunnel TLV . . . . . . . . . . . . . . . . . 94 7.6. The Error Information TLV.........................78
7.9.11. Session Update Response TLV . . . . . . . . . . . . . 95 7.7. BAS Function Enabler TLV..........................78
7.9.12. Subscriber Policy TLV . . . . . . . . . . . . . . . . 95 7.8. Routing TLVs......................................81
7.9.13. Subscriber CGN Port Range TLV . . . . . . . . . . . . 97 7.8.1. IPv4 Routing TLV................................81
7.10. Device Status TLVs . . . . . . . . . . . . . . . . . . . 97 7.8.2. IPv6 Routing TLV................................82
7.10.1. Interface Status TLV . . . . . . . . . . . . . . . . 97 7.9. Subscriber TLVs...................................84
7.10.2. Board Status TLV . . . . . . . . . . . . . . . . . . 98 7.9.1. Basic Subscriber TLV............................84
7.11. CGN TLVs . . . . . . . . . . . . . . . . . . . . . . . . 99 7.9.2. PPP Subscriber TLV..............................87
7.11.1. Address Allocation Request TLV . . . . . . . . . . . 99 7.9.3. IPv4 Subscriber TLV.............................88
7.11.2. Address Allocation Response TLV . . . . . . . . . . 100
7.11.3. Address Renewal Request TLV . . . . . . . . . . . . 101 INTERNET-DRAFT Simple BNG CUSP
7.11.4. Address Renewal Response TLV . . . . . . . . . . . . 102
7.11.5. Address Release Request TLV . . . . . . . . . . . . 103 Table of Contents (continued)
7.11.6. Address Release Response TLV . . . . . . . . . . . . 103
7.12. Event TLVs . . . . . . . . . . . . . . . . . . . . . . . 104 7.9.4. IPv6 Subscriber TLV.............................89
7.12.1. Subscriber Traffic Statistics TLV . . . . . . . . . 104 7.9.5. IPv4 Static Subscriber Detect TLV...............90
7.12.2. Subscriber Detection Result TLV . . . . . . . . . . 106 7.9.6. IPv6 Static Subscriber Detect TLV...............91
7.13. Vendor TLV . . . . . . . . . . . . . . . . . . . . . . . 107 7.9.7. L2TP-LAC Subscriber TLV.........................93
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 108 7.9.8. L2TP-LNS Subscriber TLV.........................93
8.1. Implementations . . . . . . . . . . . . . . . . . . . . . 108 7.9.9. L2TP-LAC Tunnel TLV.............................94
8.1.1. Huawei Technologies . . . . . . . . . . . . . . . . . 109 7.9.10. L2TP-LNS Tunnel TLV............................95
8.1.2. ZTE . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.9.11. Update Response TLV............................96
8.1.3. H3C . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.9.12. Subscriber Policy TLV..........................97
8.2. Hackathon . . . . . . . . . . . . . . . . . . . . . . . . 109 7.9.13. Subscriber CGN Port Range TLV..................99
8.3. EANTC Testing . . . . . . . . . . . . . . . . . . . . . . 110 7.10. Device Status TLVs...............................99
9. Summary of Major S-CUSP Codepoints . . . . . . . . . . . . . 110 7.10.1. Interface Status TLV..........................100
9.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 110 7.10.2. Board Status TLV..............................100
9.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 111 7.11. CGN TLVs........................................101
9.3. TLV Operation Codes . . . . . . . . . . . . . . . . . . . 112 7.11.1. Address Allocation Request TLV................101
9.4. Sub-TLV Types . . . . . . . . . . . . . . . . . . . . . . 112 7.11.2. Address Allocation Response TLV...............102
9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 113 7.11.3. Address Renewal Request TLV...................103
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115 7.11.4. The Address Renewal Response TLV..............104
11. Security Considerations . . . . . . . . . . . . . . . . . . . 115 7.11.5. Address Release Request TLV...................105
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 115 7.11.6. The Address Release Response TLV..............105
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 116 7.12. Event TLVs......................................106
14. Informative References . . . . . . . . . . . . . . . . . . . 116 7.12.1. Subscriber Traffic Statistics TLV..............106
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 117 7.12.2. Subscriber Detection Result TLV...............108
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 7.13. Vendor TLV......................................109
8. Implementation Status................................111
8.1. Implementations..................................111
8.1.1. Huawei Technologies............................111
8.1.2. ZTE............................................112
8.1.3. H3C............................................112
8.2. Hackathon........................................112
8.3. EANTC Testing....................................113
9. Summary of Major S-CUSP Codepoints...................114
9.1. Message Types....................................114
9.2. TLV Types........................................114
9.3. TLV Operation Codes..............................116
9.4. Sub-TLV Types....................................116
9.5. Error Codes......................................117
10. IANA Considerations.................................119
11. Security Considerations.............................120
Contributors.............................................121
Normative References.....................................122
Informative References...................................122
Authors' Addresses.......................................124
INTERNET-DRAFT Simple BNG CUSP
1. Introduction 1. Introduction
A fixed network Broadband Network Gateway (BNG) is an Ethernet- A fixed network Broadband Network Gateway (BNG) is an Ethernet-
centric IP edge router, and the aggregation point for user traffic. centric IP edge router, and the aggregation point for user traffic.
To provide centralized session management, flexible address To provide centralized session management, flexible address
allocation, high scalability for subscriber management capacity, and allocation, high scalability for subscriber management capacity, and
cost-efficient redundancy, the Control/User (CU) separated BNG cost-efficient redundancy, the Control/User (CU) separated BNG
framework is described in [TR-384]. The CU separated service Control framework is described in [TR-384]. The CU separated service Control
Plane (CP), which is responsible for user access authentication and Plane (CP), which is responsible for user access authentication and
skipping to change at page 5, line 31 skipping to change at page 6, line 28
BNG user plane (local), can be distributed across the infrastructure. BNG user plane (local), can be distributed across the infrastructure.
Other structures can also be supported such as both CP and UP being Other structures can also be supported such as both CP and UP being
virtual or both being physical. virtual or both being physical.
This document specifies the Simple CU Separation BNG control channel This document specifies the Simple CU Separation BNG control channel
Protocol (S-CUSP) for communications between a BNG Control Plane (CP) Protocol (S-CUSP) for communications between a BNG Control Plane (CP)
and a set of User Planes (UPs). S-CUSP is designed to be flexible and a set of User Planes (UPs). S-CUSP is designed to be flexible
and extensible so as to easily allow for additional messages and data and extensible so as to easily allow for additional messages and data
items, should further requirements be expressed in the future. items, should further requirements be expressed in the future.
S-CUSP was designed by China Mobile, Huawei Technologies, and ZTE, This document is not an IETF standard and does not have IETF
has been implemented by Huawei Technologies, ZTE, and H3C, and has consensus. S-CUSP was designed by China Mobile, Huawei Technologies,
been deployed by China Mobile. and ZTE, it is presented here to make the S-CUSP specification
conveniently available to the Internet community to enable diagnosis
and interoperability.
INTERNET-DRAFT Simple BNG CUSP
2. Terminology 2. Terminology
This section specifies acronyms used in this document. This section specifies implementation requirement keywords and terms
used in this document. S-CUSP messages are described in this document
using Routing Backus-Naur Form (RBNF) as defined in [RFC5511].
2.1. Implementation Requirement Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Terms
This section specifies terms used in this document.
AAA: Authentication Authorization Accounting. AAA: Authentication Authorization Accounting.
ACK: Acknowledgement message. ACK: Acknowledgement message.
BAS: Broadband Access Server (BRAS, BNG).
BNG: Broadband Network Gateway. A broadband remote access server BNG: Broadband Network Gateway. A broadband remote access server
(BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic to (BRAS (BRoadband Access Server), B-RAS or BBRAS) routes traffic
and from broadband remote access devices such as digital subscriber to and from broadband remote access devices such as digital
line access multiplexers (DSLAM) on an Internet Service Provider's subscriber line access multiplexers (DSLAM) on an Internet
(ISP) network. BRAS can also be referred to as a Broadband Network Service Provider's (ISP) network. BRAS can also be referred to
Gateway (BNG). as a Broadband Network Gateway (BNG).
BRAS: BRoadband Access Server (BNG). BRAS: BRoadband Access Server (BNG).
BAS:Broadband ACCESS Service.
CAR: Committed Access Rate. CAR: Committed Access Rate.
CBS: Committed Burst Size. CBS: Committed Burst Size.
CGN: Carrier Grade NAT. CGN: Carrier Grade NAT.
Ci: Control Interface. Ci: Control Interface.
CIR: Committed Information Rate. CIR: Committed Information Rate.
CoA: Change of Authorization. CoA: Change of Authorization.
CP: Control Plane. CP: Control Plane.
CP is a user control management component which supports the INTERNET-DRAFT Simple BNG CUSP
management of the UP's resources such as the user entry and
forwarding policy. CP is a user control management component which supports the
management of the UP's resources such as the user entry and
forwarding policy.
CPE: Customer Premises Equipment. 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 dialed user appears. The name is left over from when users literally
up on a modem equipped phone line but herein is applied to other dialed up on a modem equipped phone line but herein is applied to
initial connection techniques. Initial connection is frequently other initial connection techniques. Initial connection is
indicated by the receipt of packets over PPPoE or IPoE. frequently indicated by the receipt of packets over PPPoE 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 7, line 23 skipping to change at page 9, line 5
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 NFVI: NFV Infrastructure
INTERNET-DRAFT Simple BNG CUSP
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.
RBNF: Routing Backus-Naur Form [RFC5511].
RG: Residential Gateway.
S-CUSP: Simple Control and User Plane Separation Protocol. S-CUSP: Simple Control and User Plane Separation Protocol.
Si: Service Interface. Si: Service Interface.
TLV: Type, Length, Value. See Section 4.2. TLV: Type, Length, Value. See Sections 7.1 and 7.3.
UP: User Plane. UP is a network edge and user policy implementation UP: User Plane. UP is a network edge and user policy implementation
component. The traditional router's Control Plane and Forwarding component. The traditional router's Control Plane and Forwarding
Plane are both preserved on BNG devices in the form of a user plane. Plane are both preserved on BNG devices in the form of a user
plane.
URPF: Unicast Reverse Path Forwarding. URPF: Unicast Reverse Path Forwarding.
User: Equivalent to "customer", "subscriber". User: Equivalent to "customer" or "subscriber".
VRF: Virtual Routing and Forwarding. VRF: Virtual Routing and Forwarding.
INTERNET-DRAFT Simple BNG CUSP
3. BNG CUPS Overview 3. BNG CUPS Overview
3.1. BNG CUPS Motivation 3.1. BNG CUPS Motivation
The rapid development of new services, such as 4K TV, IoT, etc., and The rapid development of new services, such as 4K TV, IoT, etc., and
increasing numbers of home broadband service users present some new increasing numbers of home broadband service users present some new
challenges for BNGs such as: challenges for BNGs such as:
Low resource utilization: The traditional BNG acts as both a Low resource utilization: The traditional BNG acts as both a gateway
gateway for user access authentication and accounting and an IP for user access authentication and accounting and an IP network's
network's Layer 3 edge. The mutually affecting nature of the Layer 3 edge. The mutually affecting nature of the tightly
tightly coupled control plane and forwarding plane makes it coupled control plane and forwarding plane makes it difficult to
difficult to achieve the maximum performance of either plane. achieve the maximum performance of either plane.
Complex management and maintenance: Due to the large numbers of Complex management and maintenance: Due to the large numbers of
traditional BNGs, configuring each device in a network is very traditional BNGs, configuring each device in a network is very
tedious when deploying global service policies. As the network tedious when deploying global service policies. As the network
expands and new services are introduced, this deployment mode will expands and new services are introduced, this deployment mode
cease to be feasible as it is unable to manage services will cease to be feasible as it is unable to manage services
effectively and rectify faults rapidly. effectively and rectify faults rapidly.
Slow service provisioning: The coupling of control plane and Slow service provisioning: The coupling of control plane and
forwarding plane, in addition to a distributed network control forwarding plane, in addition to a distributed network control
mechanism, means that any new technology has to rely heavily on mechanism, means that any new technology has to rely heavily on
the existing network devices. the existing network devices.
To address these challenges for fixed networks, the framework for a To address these challenges for fixed networks, the framework for a
cloud-based BNG with Control-Plane and User-Plane (CU) separation is cloud-based BNG with Control Plane and User Plane (CU) separation is
described in [TR-384]. The main idea of CU separation is to extract described in [TR-384]. The main idea of CU separation is to extract
and centralize the user management functions of multiple BNG devices, and centralize the user management functions of multiple BNG devices,
forming a unified and centralized Control Plane (CP). And the forming a unified and centralized Control Plane (CP). And the
traditional router's Control Plane and Forwarding Plane are both traditional router's Control Plane and Forwarding Plane are both
preserved on BNG devices in the form of a User Plane (UP). Note that preserved on BNG devices in the form of a User Plane (UP).
the CU separation concept has also been introduced in the 3GPP 5G
architecture [3GPP.23.501].
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. In a cloud-based BNG, we find that splitting these two function. The user management function can be centralized and
functions apart can make a difference. The user management function deployed as a concentrated module or device, called the BNG Control
can be centralized and deployed as a concentrated module or device, Plane (BNG-CP). The other functions, such as the router function and
called the BNG-CP (Control Plane). The other functions, such as the forwarding engine, can be deployed in the form of the BNG User Plane
router function and forwarding engine, can be deployed in the form of (BNG-UP).
the BNG User Plane. Thus, the Cloud-based BNG architecture is made
up of Control Plane and User Plane.
The following figure shows the architecture of CU separated BNG: The following figure shows the architecture of CU separated BNG:
INTERNET-DRAFT Simple BNG CUSP
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| 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 |
| +--------------------------------------------------------------+ | | +--------------------------------------------------------------+ |
| | +----------+ +----------+ +------++------++-----------+ | | | | +----------+ +----------+ +------++------++-----------+ | |
| | | Address | |Subscriber| | AAA ||PPPoE/|| UP | | | | | | Address | |Subscriber| | AAA ||Access|| UP | | |
| | |management| |management| | ||IPoE ||management | | | | | |management| |management| | || Mgt ||management | | |
| | +----------+ +----------+ +------++------++-----------+ | | | | +----------+ +----------+ +------++------++-----------+ | |
| | CP | | | | CP | |
| +--------------------------------------------------------------+ | | +--------------------------------------------------------------+ |
| | | |
| | | |
| | | |
| +---------------------------+ +--------------------------+ | | +---------------------------+ +--------------------------+ |
| | +------------------+ | | +------------------+ | | | | +------------------+ | | +------------------+ | |
| | | Routing control | | | | Routing control | | | | | | Routing control | | | | Routing control | | |
| | +------------------+ | ... | +------------------+ | | | | +------------------+ | ... | +------------------+ | |
| | +------------------+ | | +------------------+ | | | | +------------------+ | | +------------------+ | |
| | |Forwarding engine | | | |Forwarding engine | | | | | |Forwarding engine | | | |Forwarding engine | | |
| | +------------------+ UP | | +------------------+ UP| | | | +------------------+ UP | | +------------------+ UP| |
| +---------------------------+ +--------------------------+ | | +---------------------------+ +--------------------------+ |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Figure 3.1: Architecture of CU Separated BNG
As shown in Figure 3.1, the BNG Control Plane could be virtualized Figure 1: Architecture of CU Separated BNG
and centralized, which provides benefits such as centralized session
As shown in Figure 1, the BNG Control Plane could be virtualized and
centralized, which provides benefits such as centralized session
management, flexible address allocation, high scalability for management, flexible address allocation, high scalability for
subscriber management capacity, and cost-efficient redundancy, etc. subscriber management capacity, and cost-efficient redundancy, etc.
The functional components inside the BNG Service Control Plane can be The functional components inside the BNG Service Control Plane can be
implemented as Virtual Network Functions (VNFs) and hosted in a implemented as Virtual Network Functions (VNFs) and hosted in a
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 shouldsupport 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 related network functions can be disaggregated and distributed across
the physical infrastructure. And the other control plane and the physical infrastructure. And the other control plane and
INTERNET-DRAFT Simple BNG CUSP
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 should support: 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.
2. AAA: This component performs Authentication, Authorization and 2. AAA: This component performs Authentication, Authorization and
Accounting, together with RADIUS/DIAMETER. The BNG communicates Accounting, together with RADIUS/DIAMETER. The BNG communicates
with the AAA server to check whether the subscriber who sent an with the AAA server to check whether the subscriber who sent an
Access-Request has network access authority. Once the subscriber Access-Request has network access authority. Once the subscriber
goes online, this component together with the Service Control goes online, this component together with the Service Control
component implement accounting, data capacity limitation, and QoS component implement accounting, data capacity limitation, and QoS
enforcement policies. enforcement policies.
3. Subscriber management: user entry management and forwarding 3. Subscriber management: user entry management and forwarding
policy management. policy management.
4. PPPoE/IPoE: process user dial-up packets via PPPoE/IPoE. 4. Access management: process user dial-up packets, such as PPPoE,
DHCP, L2TP, etc.
5. UP management: management of UP interface status, and the setup, 5. UP management: management of UP interface status, and the setup,
deletion, and maintenance of channels between CP and UP. deletion, and maintenance of channels between CP and UP.
The User Plane should support: The User Plane is responsible for the following:
1. Control plane functions including routing, multicast, and MPLS. 1. Routing control functions: responsible for constructing routing
forwarding plane (e.g., routing, multicast, MPLS, etc.).
2. Forwarding plane functions including traffic forwarding, QoS and 2. Routing and Service Forwarding plane functions: responsible
traffic statistics collection. including traffic forwarding, QoS and traffic statistics
collection.
3. Subscriber detection, to detect whether an subscriber is still Subscriber detection: responsible for detecting whether a subscriber
online. is still online.
3.3. BNG CUPS Interfaces 3.3. BNG CUPS Interfaces
To support the communication between the Control Plane and User To support the communication between the Control Plane and User
Plane, three interfaces are defined. These are referred to as the Plane, three interfaces are assumed. These are referred to as the
Control Interface (Ci), Service Interface (Si) and Management Service Interface (Si), Control Interface (Ci), and Management
Interface (Mi) as shown in Figure 3.2. Interface (Mi) as shown in Figure 2.
+-----------------------------------+ INTERNET-DRAFT Simple BNG CUSP
| |
| BNG-CP |
| |
+--+--------------+--------------+--+
| | |
1. Service | 2. Control | 3. Management|
Interface | Interface | Interface |
(Si) | (Ci) | (Mi) |
| | |
+--+--------------+--------------+--+
| |
| BNG-UP |
| |
+-----------------------------------+
Figure 3.2: Interfaces Between the CP and UP of the BNG +-----------------------------------+
| |
| BNG-CP |
| |
+--+--------------+--------------+--+
| | |
1. Service | 2. Control | 3. Management|
Interface | Interface | Interface |
(Si) | (Ci) | (Mi) |
| | |
| ___|___ |
| ___( )___ |
_|______( )______|_
( )
( Network/Internet )
(________ ________)
| (___ ___) |
| (_______) |
| | |
| | |
+--+--------------+--------------+--+
| |
| BNG-UP |
| |
+-----------------------------------+
Figure 2: Interfaces Between the CP and UP of the BNG
3.3.1. Service Interface 3.3.1. Service Interface
For a traditional BNG (without CU separation), the user dial-up For a traditional BNG (without CU separation), the user dial-up
signals are terminated and processed by the control plane of a BNG. signals are terminated and processed by the control plane of a BNG.
When the CP and UP of a BNG are separated, there needs to be a way to When the CP and UP of a BNG are separated, there needs to be a way to
relay these signals between the CP and the UP. relay these signals between the CP and the UP.
The Service Interface (Si) is used to establish tunnels between the The Service Interface (Si) is used to establish tunnels between the
CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE,
and L2TP related control packets that are received from an RG over and L2TP related control packets that are received from a Residential
those tunnels. Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN
[RFC7348].
The detail definition of Si is out of the scope of this document. The detailed definition of Si is out of scope for this document.
3.3.2. Management Interface INTERNET-DRAFT Simple BNG CUSP
NETCONF [RFC6241] is the protocol used on the Management Interface 3.3.2. Control Interface
between a CP and UP. It is used to configure the parameters of the
Control Interface, Service Interface, the Access interfaces and QoS/
ACL Templates. The definitions of the parameters are out of the
scope of this document.
3.3.3. Control Interface The CP uses the Control Interface to deliver subscriber session
states, network routing entries, etc. to the UP (see Section 6.2.7)).
The UP uses this interface to report subscriber service statistics,
subscriber detection results, etc. to the CP (see Sections 6.3 and
6.4). A carrying protocol for this interface is specified in this
document.
The CP uses the Control Interface to deliver service entries, and the 3.3.3. Management Interface
UP uses this interface to report service events to the CP. A
carrying protocol for this interface is specified in this document. NETCONF [RFC6241] is the protocol used on the Management Interface
between a CP and UP. It is used to configure the parameters of the
Control Interface, Service Interface, the Access interfaces and
QoS/ACL Templates. It is expected that implementations will make use
of existing YANG models where possible, but that new YANG models
specific to S-CUSP will need to be defined. The definitions of the
parameters are out of scope for this document.
3.4. BNG CUPS Procedure Overview 3.4. BNG CUPS Procedure Overview
The following numbered sequences gives a high level view of the main The following numbered sequences (Figure 3) gives a high level view
BNG CUPS procedures. of the main BNG CUPS procedures.
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| |Establish S-CUSP Channel| | | |Establish S-CUSP Channel| |
| 1|<---------------------->| | | 1|<---------------------->| |
| | | | | | | |
| | Report Board/interface | | | | Report Board | |
| | status | | | | interface | |
| 2|------to CP via Ci----->| | | | information | |
| | | | | 2|------to CP via Ci----->| |
| | Enable BAS function | | | | | |
| 3|<-----on UP via Ci------| | | | Enable BAS function | |
| | | | | 3|<-----on UP via Ci------| |
| | Notify UP to advertise | | | | | |
| | subscriber network | | | | Notify UP to advertise | |
| | routing | | | | subscriber network | |
| 4|<------- via Ci---------| | | | routing | |
| | | | | 4|<------- via Ci---------| |
| Dial-up Req | | | | | | |
5.1|-------------->| | | | Dial-up Req | | |
| | Relay the Dial-up Req | | 5.1|-------------->| | |
| 5.2|-----to CP via Si------>| Authentication| | | Relay the Dial-up Req | |
| | | Req/Rep | | 5.2|-----to CP via Si------>| Authentication|
| | 5.3|<------------->|
| | Send the Dial-up Rep | |
| 5.4|<----to UP via Si-------| |
| Dial-up Rep | | |
5.5|<--------------| | |
| | Create subscriber | |
| | session on UP | |
| 5.6|<--------via Ci-------->| |
| | | CoA Request |
| | 6.1|<--------------|
| | Update session on UP | |
| 6.2|<--------via Ci-------->| |
| | | CoA Response |
| | 6.3|-------------->|
| | | |
| Offline Req | | |
7.1|-------------->| | |
| | Relay the Offline Req | |
| 7.2|------to CP via Si----->| |
| | | |
| | Send the Offline Rep | |
| 7.3|<-----to UP via Si------| |
| Offline Rep | | |
7.4|<--------------| | |
| | Delete session on UP | |
| 7.5|<--------via Ci-------->| |
| | | |
| | Event report | |
| 8|---------via Ci-------->| |
| | | |
| | Data Synchronization | |
| 9|<--------via Ci-------->| |
| | | |
| | CGN Address Allocation | |
| 10|<--------via Ci-------->| |
| | | |
Figure 3.3: BNG CUPS Overview Procedures INTERNET-DRAFT Simple BNG CUSP
1. S-CUSP session establishment: This is the first step of BNG CUPS | | | Req/Rep |
procedures. Once the Control Interface parameters are | | 5.3|<------------->|
configured on a UP. It will start to setup S-CUSP session(s) | | Send the Dial-up Rep | |
with the specified CP(s). The detailed definition of S-CUSP | 5.4|<----to UP via Si-------| |
session establishment can be found in Section 4.1.1. | Dial-up Rep | | |
5.5|<--------------| | |
| | Create subscriber | |
| | session on UP | |
| 5.6|<--------via Ci-------->| |
| | | CoA Request |
| | 6.1|<--------------|
| | Update session on UP | |
| 6.2|<--------via Ci-------->| |
| | | CoA Response |
| | 6.3|-------------->|
| | | |
| Offline Req | | |
7.1|-------------->| | |
| | Relay the Offline Req | |
| 7.2|------to CP via Si----->| |
| | | |
| | Send the Offline Rep | |
| 7.3|<-----to UP via Si------| |
| Offline Rep | | |
7.4|<--------------| | |
| | Delete session on UP | |
| 7.5|<--------via Ci-------->| |
| | | |
| | Event report | |
| 8|---------via Ci-------->| |
| | | |
| | Data Synchronization | |
| 9|<--------via Ci-------->| |
| | | |
| | CGN Address Allocation | |
| 10|<--------via Ci-------->| |
| | | |
2. Board and interface report: Once the S-CUSP session is Figure 3: BNG CUPS Procedures Overview
established between a UP and a CP, the UP will report the status 1. S-CUSP session establishment: This is the first step of BNG CUPS
information on the board(s) and access side interface(s) of this procedures. Once the Control Interface parameters are configured
UP to the CP. The CP can use this information to enable the on a UP. It will start to setup S-CUSP sessions with the
Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, specified CPs. The detailed definition of S-CUSP session
etc.) on the specified interface(s). See Sections 4.2.1 and establishment can be found in Section 4.1.1.
7.10 for more details on Resource reporting.
3. BAS (Broadband Access Service) function enable: To enable the 2. Board and interface report: Once the S-CUSP session is
BAS function on the specified interfaces(s) of a UP. established between the UP and a CP, the UP will report status
information on the boards and subscriber side interfaces of this
UP to the CP. A board can also be called a Line/Service Process
Unit (LPU/SPU) card. The subscriber side interfaces refer to the
4. Subscriber network route advertisement: The CP will allocate one INTERNET-DRAFT Simple BNG CUSP
or more address blocks to a UP. Each address block contains a
series of IP addresses. Those IP addresses will be allocated to
subscribers who are dialing up from the UP. To enable other
nodes in the network to learn how to reach the subscribers, the
CP needs to notify the UP to advertise the routes that can reach
those IP addresses to the network.
5. 5.1-5.6 is a general call flow of a subscriber dial-up process. interfaces that connect the Acess Network nodes (e.g., OLT:
When a UP receives a dial-up request, it will relay the request Optical Line Terminal, DSLAM: Digital Subscriber Line Access
packet to a CP through the Service Interface. The CP will parse Multiplexer, etc.). The CP can use this information to enable the
the request. If everything is OK, it will send an Broadband Access Service (BAS) function (e.g., IPoE, PPPoE, etc.)
authentication request to the AAA server to authenticate the on the specified interfaces. See Sections 4.2.1 and 7.10 for more
subscriber. Once the subscriber passes the authentication, the details on Resource reporting.
AAA server will return a positive response to the CP. Then the
CP will send the dial-up response packet to the UP and the UP
will forward the response packet to the subscriber (RG). At the
same time, the CP will create a subscriber session on the UP,
which enables the subscriber to access the network. For
different access types, the process may be a bit different. But
the high-level process is similar. For each access type, the
detail process can be found in Section 5.
6. 6.1-6.2 is the sequence when updating an existing session. The 3. BAS (Broadband Access Service) function enable: To enable the BAS
AAA server initiates a Change of Authorization (CoA) and sends function on the specified interfaces of a UP.
the CoA to the CP. The CP will then update the session
according to the CoA. See Section 4.3.2 for more detail on CP
messages updating UP tables.
7. 7.1-7.5 is the sequence for deleting an existing session. When 4. Subscriber network route advertisement: The CP will allocate one
a UP receives a offline request, it will relay the request to a or more IP address blocks to a UP. Each address block contains a
CP through the Service Interface. The CP will send back a series of IP addresses. Those IP addresses will be allocated to
response to the UP through the Service Interface. The UP will subscribers who are dialing up from the UP. To enable other nodes
forward the offline response to the subscriber. Then the CP in the network to learn how to reach the subscribers, the CP
will delete the session on the UP through the Control Interface. needs to notify the UP to advertise to the network the routes
that can reach those IP addresses.
8. Event reports include the following two parts (more detail can 5. 5.1-5.6 is a complete call flow of a subscriber dial-up process.
be found in Section 4.3.4). Both are reported using the Event When a UP receives a dial-up request, it will relay the request
message. packet to a CP through the Service Interface. The CP will parse
the request. If everything is OK, it will send an authentication
request to the AAA server to authenticate the subscriber. Once
the subscriber passes the authentication, the AAA server will
return a positive response to the CP. Then the CP will send the
dial-up response packet to the UP and the UP will forward the
response packet to the subscriber (RG). At the same time, the CP
will create a subscriber session on the UP, which enables the
subscriber to access the network. For different access types,
the process may be a bit different. But the high-level process is
similar. For each access type, the detail process can be found in
Section 5.
1. Subscriber Traffic Statistics Report 6. 6.1-6.3 is the sequence when updating an existing subscriber
session. The AAA server initiates a Change of Authorization (CoA)
and sends the CoA to the CP. The CP will then update the session
according to the CoA. See Section 4.3.2 for more detail on CP
messages updating UP tables.
2. Subscriber Detection Result Report 7. 7.1-7.5 is the sequence for deleting an existing subscriber
session. When a UP receives an offline request, it will relay the
request to a CP through the Service Interface. The CP will send
back a response to the UP through the Service Interface. The UP
will then forward the offline response to the subscriber. Then
the CP will delete the session on the UP through the Control
Interface.
9. Data synchronization: See Sections 4.2.5 for more detail on CP 8. Event reports include the following two parts (more detail can be
and UP Synchronization. found in Section 4.3.4) Both are reported using the Event
message.
10. CGN address allocation: See Sections 4.2.4 for more detail on INTERNET-DRAFT Simple BNG CUSP
CGN Address Allocation.
8.1. Subscriber Traffic Statistics Report
8.2. Subscriber Detection Result Report
9. Data synchronization: See Sections 4.2.5 for more detail on CP and
UP Synchronization.
10. CGN address allocation: See Sections 4.2.4 for more detail on CGN
Address Allocation.
INTERNET-DRAFT Simple BNG CUSP
4. S-CUSP Protocol Overview 4. 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 warm-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 CP(s) is implemented by The association between a UP and its CPs is implemented by dynamic
configuration. configuration.
Once a UP knows its CP(s), the UP starts to establish S-CUSP Once a UP knows its CPs, the UP starts to establish S-CUSP sessions
session(s) with those CP(s) as shown below. 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.1.1: 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 port tbd1.
2. Establishment of a S-CUSP session over the TCP connection. 2. Establishment of a S-CUSP session over the TCP connection.
Once the TCP connection is established, the CP and the UP initialize Once the TCP connection is established, the CP and the UP initialize
the S-CUSP session during which the version negotiation and Keepalive the S-CUSP session during which the version and Keepalive timers are
timers negotiation are performed. 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 received a Hello message that does CP and the UP. For a CP or UP, if a Hello message is received that
not have a supported version, the next Hello message with an Error does not indicate a version supported by both, a subsequent Hello
Information TLV will be sent to its peer to notify the "Version-
Mismatch" error . Then session establishment phase fails. INTERNET-DRAFT Simple BNG CUSP
message with an Error Information TLV will be sent to the peer to
notify the peer of the "Version-Mismatch" error and the session
establishment phase fails.
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 carries a Keepalive timer and Dead Hello message. The Keepalive TLV includes a Keepalive timer and Dead
Timer. Both 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 Hello message with an Error Information TLV Dead Timer. Otherwise, a subsequent Hello message with an Error
will be sent to its peer. Then session establishment phase fails. Information TLV will be sent to its peer and the session
establishment phase fails.
The S-CUSP session establishment phase fails if the CP or UP disagree The S-CUSP session establishment phase fails if the CP or UP disagree
on the version and Keepalive parameters or one of the CP or UP does on the version and keepalive parameters or if one of the CP or UP
not answer after the expiration of the establishment timer. When the does not answer after the expiration of the establishment timer.
S-CUSP session establishment fails, the TCP connection is promptly When the S-CUSP session establishment fails, the TCP connection is
closed. promptly closed. Successive retries are permitted but an
implementation SHOULD make use of an exponential back-off session
establishment retry procedure.
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 that they restart The ends of the S-CUSP session also run DeadTimers, and they restart
whenever a message is received on the session. If one end of the the timers whenever a message is received on the session. If one end
session receives no message after the DeadTimer expires, it declares of the session receives no message after the DeadTimer expires, it
the session dead. The session is 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.
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 Board and Interface Status Report 4.2.1. UP Resource Report
Once an S-CUSP session has been established between a CP and a UP. Once an S-CUSP session has been established between a CP and an UP.
The UP reports the information about the Board(s) and access side The UP reports the information of the Boards and access side
interface(s) on this UP to the CP. interfaces on this UP to the CP as shown in Figure 5. Report messages
are unacknowledged and are assumed to be delivered because the
session runs over TCP.
The CP can use that information to activate/enable the Broadband The CP can use that information to activate/enable the Broadband
Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the
specified interface(s). specified interfaces.
In addition, the UP resource report may trigger a UP warm-standby In addition, the UP resource report may trigger a UP warm-standby
procedure. In the case of warm-standby, a failure on a UP may process. In the case of warm-standby, a failure on an UP may trigger
trigger the CP to start the warm-standby procedure, by moving the on- the CP to start a warm-standby process, by moving the on-line
line subscriber sessions to a standby UP and then directing the subscriber sessions to a standby UP and then direct the affected
affected subscribers to access the Internet through the standby UP. subscribers to access the Internet through the standby UP.
UP CP UP CP
| | | |
| Report Board Status | | Report Board Status |
|------to CP via Ci----->| |------to CP via Ci----->|
| | | |
| Report Interface Status| | Report Interface Status|
|------to CP via Ci----->| |------to CP via Ci----->|
| | | |
Figure 4.2.1: UP Board and Interface Report Figure 5: UP Board and Interface Report
Board status information is carried in the Board Status Board status information is carried in the Board Status TLV (Section
TLV(Section 7.10.2), interface status information is carried in the 7.10.2) and Interface status information is carried in Interface
Interface Status TLV (Section 7.10.1). Both Board and Interface Status TLV (Section 7.10.1). Both Board and Interface Status TLVs are
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 4.2.2. Enable BAS Function on Access Interface
Once the CP collects the interface status of a UP, it will activate/ Once the CP collects the interface status of a UP, it will
enable the BAS functions on specified interfaces through the activate/enable the BAS functions on specified interfaces through the
Update_Request and Update_Response message (Section 6.2) exchanges Update_Request and Update_Response message (Section 6.2) exchanges
carrying the BAS Function Enabler TLV (Section 7.7). carrying the BAS Function Enabler TLV (Section 7.7).
INTERNET-DRAFT Simple BNG CUSP
UP CP UP CP
| | | |
| Enable BAS function | | Enable BAS function |
| Request | | Request |
|<-----on UP via Ci-------| |<-----on UP via Ci-------|
| | | |
| Enable BAS function | | Enable BAS function |
| Response | | Response |
|------on UP via Ci------>| |------on UP via Ci------>|
| | | |
Figure 4.2.2: Enable BAS Functions
4.2.3. Advertise Subscriber Network Routing Figure 6: Enable BAS Function
The CP will allocate one or more address blocks to a UP. Each 4.2.3. Update Subscriber Network Routing
address block contains a series of IP addresses. Those IP addresses
will be allocated to subscribers who are dialing up to the UP. To The CP will allocate one or more address blocks to a UP. Each address
enable other nodes in the network to learn how to reach the block contains a series of IP addresses. Those IP addresses will be
subscribers, the CP needs to install the routes on the UP and notify allocated to subscribers who are dialing up to the UP. To enable the
the UP to advertise the routes to the network. other nodes in the network to learn how to reach the subscribers, the
CP needs to install the routes on the UP and notify the UP to
advertise the routes to the network.
UP CP UP CP
| | | |
| Subscriber network route| | Subscriber network route|
| advertisement request | | update request |
|<------- via Ci----------| |<------- via Ci----------|
| | | |
| Subscriber network route| | Subscriber network route|
| advertisement response | | update response |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | |
Figure 4.2.3: Advertise Subscriber Network Routing Figure 7: Update Subscriber Network Routing
The subscriber network route advertisement request and response are The subscriber network routing update request and response are
achieved through the Update_Request and Update_Response Messages achieved through the Update Request and Response Message exchanges by
exchanges by carrying the IPv4/IPv6 Routing TLVs (Section 7.8). carrying the IPv4/IPv6 Routing Information TLVs (Section 7.8).
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. The relevant procedures. Three independent procedures are defined, one each for
messages are defined in Section 6.5. CGN address allocation request/response, CGN address renewal
request/response, and CGN address release request/response.
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 4.2.4: CGN Public IP Address Allocation CGN address allocation/renew/release procedures are designed for the
case where the CGN function is running on the UP. The UP has to map
the subscriber private IP addresses to a public IP addresses, and
such mapping is performed by the UP locally when a subscriber dials-
up. That means the UP has to ask for public IPv4 address blocks for
CGN subscribers from the CP.
4.2.5. Data Synchronization Between CP and UP In addition, when a public IP address is allocated to a UP, there
will be a lease time (e.g., one day). Before the lease time expires,
the UP can ask for renewal of the IP address lease from the CP. It is
achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack
messages.
If the public IP address will not be used anymore, the UP SHOULD
release the address by sending an Addr_Release_Req message to the CP.
If the CP wishes to withdraw addresses that it has previously leased
to a UP, it uses the same procedures as above. The "Oper" code in
the IPv4/IPv6 Routing TLV (see Section 7.1) determines whether the
request is an update or withdraw.
The relevant messages are defined in Section 6.5.
UP CP
| |
| CGN Address Allocation |
| Request |
1.1|-------- via Ci--------->|
| CGN Address Allocation |
| Response |
1.2|<------- via Ci----------|
| |
| CGN Address Renew |
| Request |
2.1|-------- via Ci--------->|
| CGN Address Renew |
| Response |
2.2|<------- via Ci----------|
| |
| CGN Address Release |
| Request |
3.1|-------- via Ci--------->|
| CGN Address Release |
| Response |
3.3|<------- via Ci----------|
| |
Figure 8: CGN Public IP Address Allocation
INTERNET-DRAFT Simple BNG CUSP
4.2.5. Data Synchronization between the CP and UP
For a CU separated BNG, the UP will continue to function using the
state that has been installed in it even if the CP fails or the
session between the UP and CP fails.
Under some circumstances it is necessary to synchronize state between 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.
Synchronization includes two directions. One direction is from UP to Synchronization includes two directions. One direction is from UP to
CP, the synchronization information is mainly about the board/ CP; in that case, the synchronization information is mainly about the
interface status of the UP. The other direction is from CP to UP, board/interface status of the UP. The other direction is from CP to
the subscriber sessions, subscriber network routes, L2TP tunnels, UP; in that case, the subscriber sessions, subscriber network routes,
etc. will be synchronized to the UP. L2TP tunnels, etc. will be synchronized to the UP.
The synchronization is triggered by a Synch_Request message, the The synchronization is triggered by a Sync_Request message, to which
receiver will reply with a Sync_Begin message to notify the requester the receiver will (1) reply with a Sync_Begin message to notify the
that synchronization will begin, then start the synchronization requester that synchronization will begin, and (2) then start the
through one or more Sync_Data messages. When synchronization synchronization using the Sync_Data message. When synchronization
finishes, a Sync_End message is sent. finished, a Sync_End message will be sent.
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.
UP CP INTERNET-DRAFT Simple BNG CUSP
| |
| Synchronization Request |
|<------- via Ci----------|
| |
| Synchronization Begin |
|-------- via Ci--------->|
| |
| Board/Interface Report |
|-------- via Ci--------->|
| |
| Synchronization End |
|-------- via Ci--------->|
| |
1) Synchronization from UP to CP
UP CP UP CP
| | | |
| Synchronization Request | | Synchronization Request |
|-------- via Ci--------->| |<------- via Ci----------|
| | | |
| Synchronization Begin | | Synchronization Begin |
|<-------- via Ci---------| |-------- via Ci--------->|
| | | |
| Synchronizes Sessions | | Board/Interface Report |
| /Routes/Tunnels... | |-------- via Ci--------->|
|<------- via Ci----------| | |
| | | Synchronization End |
| Synchronization End | |-------- via Ci--------->|
|<-------- via Ci---------| | |
| | 1) Synchronization from UP to CP
2) Synchronization from CP to UP
Figure 4.2.5: Data Synchronization UP CP
| |
| Synchronization Request |
|-------- via Ci--------->|
| |
| Synchronization Begin |
|<-------- via Ci---------|
| |
| Synchronizes |
|Subscriber Session States|
| Network Route Entries |
|<------- via Ci----------|
| |
| Synchronization End |
|<-------- via Ci---------|
| |
2) Synchronization from CP to UP
Figure 9: Data Synchronization
4.3. Subscriber Session Related Procedures 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 required to apply to the policies, and security rules that are applied to the subscriber. It
subscriber. It is used for forwarding subscriber traffic on a UP. is used for forwarding subscriber traffic in a UP. To initialize a
To initialize a session on a UP, a set of hardware resource have to session on a UP, a set of hardware resource have to be allocated
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- create, update, delete, and statistics report. The following sub-
sections give a high view about the procedures. sections give a high level view of the procedures.
INTERNET-DRAFT Simple BNG CUSP
4.3.1. Create Subscriber Session 4.3.1. Create Subscriber Session
The below sequence describes the DHCP IPv4 dial-up process, it gives The below sequence describes the DHCP IPv4 dial-up process, it is an
an example that shows how a subscriber session is created. example that shows how a subscriber session is created. (An example
for IPv6 appears in Section 5.1.2.)
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| DHCP Discovery| | | | Online Request| | |
1|-------------->| | | 1|-------------->| | |
| |Relay the DHCP Discovery| | | |Relay the Online Request| |
| 2|-----to CP via Si------>| Authentication| | 2|-----to CP via Si------>| Authentication|
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | | |
| | Send the DHCP Offer | |
| 4|<----to UP vis Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| | | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request| |
| 7|-----to CP via Si------>| |
| | | |
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 8|<--------via Ci-------->| | | 4|<--------via Ci---------| |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
| 9|---------via Ci-------->| | | 5|---------via Ci-------->| |
| | | | | | | |
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 6|<------------->|
| | | | | | | |
| | Send DHCP ACK | | | | Send Online Response | |
| 11|<----to UP via Si-------| | | 7|<----to UP via Si-------| |
| | | | | | | |
| DHCP ACK | | | |Online Response| | |
12|<--------------| | | 12|<--------------| | |
| | | | | | | |
Figure 4.3.1: Subscriber Session Create Figure 10: Subscriber Session Create
The request starts from a DHCP Discovery message from the RG. When The request starts from an Online Request message (step 1) from the
the UP receives the DHCP Discovery from the RG, it will tunnel the RG (for example, a DHCP Discovery packet). When the UP receives the
DHCP Discovery to the CP through the Service Interface. The Service Online Request from the RG, it will tunnel the Online Request to the
Interface is implemented by a tunnel technology. CP through the Service Interface (Step 2). The Service Interface is
implemented by a tunneling technology.
When the CP receives the DHCP Discovery 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. When a positive return from the AAA sever authorize the subscriber (step 3). When a positive reply is received
received, the CP will send a DHCP Offer message to the UP through the from the AAA sever, the CP starts to create a subscriber session for
Service Interface. The UP will then forward the DHCP Offer to the the request. Relevant resources (e.g., IP address, bandwidth, etc.)
RG. will be allocated to the subscriber, policies and security rules will
be generated for the subscriber Then the CP sends a session create
request to the UP through the Control Interface (Ci) (step 4), and a
response is expected from the UP to confirm the creation (step 5).
After received the DHCP Offer, the RG will send a DHCP Request to the INTERNET-DRAFT Simple BNG CUSP
UP. As when dealing with the DHCP Discovery message, the UP will
tunnel the DHCP Request to the CP. The CP starts to create a
subscriber session for the request. Relevant resource (e.g., IP
address, bandwidth, etc.) will be allocated to the subscriber and
policies and security rules will be generated for the subscriber.
Then the CP sends a session create request to the UP through the
Control Interface (Ci), and a response is expected from the UP to
confirm the creation.
Finally, the CP will notify the AAA server to start accounting. At Finally, the CP will notify the AAA server to start accounting (step
the same time, a DHCP ACK message will be sent to the UP through the 6). At the same time, an Online Response message (for example, a
Si. And the UP will forward the DHCP ACK to the RG. DHCP Ack packet) will be sent to the UP through the Si (step 7). And
the UP will forward the Online Response to the RG (step 8).
This completes the whole dial-up process. This completes the subscriber online process.
4.3.2. Update Subscriber Session 4.3.2. Update Subscriber Session
The following numbered sequence describes 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 4.3.2: 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.
4.3.3. Delete Subscriber Session 4.3.3. Delete Subscriber Session
The below call flow shows a general process for how BNG CUPS deals The below call flow shows generally how S-CUPS deals with a
with the 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----->|
| | |
| | Send the Offline |
| | Response |
| 3|<-----to UP via Si------|
|Offline Response| |
4|<---------------| |
| | Session delete |
| |<--------via Ci-------->|
| | |
Figure 4.3.3: Subscriber Session Delete INTERNET-DRAFT Simple BNG CUSP
| 2|------to CP via Si----->|
| | |
| | Send the Offline |
| | Response |
| 3|<-----to UP via Si------|
|Offline Response| |
4|<---------------| |
| | Session delete |
| | Request |
| |<--------via Ci---------|
| | Session delete |
| | Response |
| |---------via Ci-------->|
| | |
Figure 12: Subscriber Session Delete
Similar to the session creation process, when a UP receives an Similar to the session creation process, when a UP receives an
offline request from an RG, it will tunnel the request to a CP offline request from a RG, it will tunnel the request to a CP through
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 resource (e.g., IP address, bandwidth) that has been allocated to the resources (e.g., IP address, bandwidth) that have been allocated
the subscriber. And then, it may send a response to the UP through to the subscriber. Then, it sends a reply to the UP through the
the Service Interface, the UP will forward the response to the RG. Service Interface and the UP will forward the reply to the RG. At
At the same time, it will delete all the status of the session on the the same time, it will delete all the status of the session on the UP
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-------->|
| | | |
When a subscriber session is created on a UP, the UP will Figure 13: Events Report
periodically report statistics and detection results of the session
to the CP. When a session is created on an UP, the UP will periodically report
statistics information and detect results of the session to the CP.
INTERNET-DRAFT Simple BNG CUSP
5. S-CUSP Call Flows 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 the setting of interactions over the Service Interface followed by an overview of
various information on the UP by the CP using S-CUSP over the Control the setting of various information in the UP by the CP using S-CUSP
Interface. over the Control Interface.
S-CUSP messages are described in this document using Routing Backus
Naur Form (RBNF) as defined in [RFC5511].
5.1. IPoE 5.1. IPoE
5.1.1. DHCPv4 Access 5.1.1. DHCPv4 Access
The following sequence gives detailed procedures for DHCPv4 access. The following sequence shows detailed procedures for DHCPv4 access.
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------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | | | | | | |
skipping to change at page 25, line 25 skipping to change at page 28, line 43
| 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------>| |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 8|<---------via Ci--------| | | 8|<--------via Ci---------| |
| | Create subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | | | | | | |
| | Send DHCP ACK | | | | Send DHCP ACK | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | | | | | |
INTERNET-DRAFT Simple BNG CUSP
| DHCP ACK | | | | DHCP ACK | | |
12|<--------------| | | 12|<--------------| | |
| | | | | | | |
Figure 5.1.1: DHCPv4 Access Figure 14: DHCPv4 Access
Step 8 and 9 are implemented by the S-CUSP protocol. Step 8 and 9 are implemented by the S-CUSP protocol.
When a subscriber is authenticated and authorized by the AAA server, When a subscriber is authenticated and authorized by the AAA server,
the CP will create a subscriber session on the UP. This is achieved the CP will create a subscriber session on the UP. This is achieved
by sending a UPdate_Request message to the UP. by sending an Update_Request message to the UP.
The format of the Update_Request message is as follows: The format of the Update_Request message is shown as follows using
RBNF:
<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>]
The UP will reply with an Update_Response message, the format of the The UP will reply with an Update_Response message, the format of the
Update_Response is as follows: Update_Response message is as follows:
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
5.1.2. DHCPv6 Access 5.1.2. DHCPv6 Access
The following sequence gives detailed procedures for DHCPv6 access. The following sequence shows detailed procedures for DHCPv6 access.
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| Solicit | | | | Solicit | | |
1|-------------->| | | 1|-------------->| | |
| | Relay the Solicit | | | | Relay the Solicit | |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | | | | | | |
| | Send the Advertise | | | | Send the Advertise | |
| 4|<----to UP vis Si-------| | | 4|<----to UP vis Si-------| |
| Advertise | | | | Advertise | | |
5|<--------------| | | 5|<--------------| | |
| | | | | | | |
| Request | | | | Request | | |
6|-------------->| | | 6|-------------->| | |
INTERNET-DRAFT Simple BNG CUSP
| | Relay the Request | | | | Relay the Request | |
| 7|-----to CP via Si------>| | | 7|-----to CP via Si------>| |
| | | | | | | |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 8|<--------via Ci-------->| | | 8|<--------via Ci-------->| |
| | | | | | | |
| | Create subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
skipping to change at page 27, line 43 skipping to change at page 30, line 29
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | | | | | | |
| | Send Reply | | | | Send Reply | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | | | | | |
| Reply | | | | Reply | | |
12|<--------------| | | 12|<--------------| | |
| | | | | | | |
Figure 5.1.2: DHCPv6 Access Figure 15: DHCPv6 Access
Steps 1-7 are a standard DHCP IPv6 access process. The subscriber Steps 1-7 are a standard DHCP IPv6 access process. The subscriber
creation is triggered by a DHCP IPv6 request message. This message creation is triggered by a DHCP IPv6 request message. When this
means that the subscriber has passed the AAA authentication and message is received, it means that the subscriber has passed the AAA
authorization. Then the CP will create a subscriber session on the authentication and authorization. Then the CP will create a
UP. This is achieved by sending a UPdate_Request message to the UP subscriber session on the UP. This is achieved by sending an
(Step 8). Update_Request message to the UP (Step 8).
The format of the Update_Request message is as follows: The format of the Update_Request message is as follows:
<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>]
The UP will reply with an Update_Response message (Step 9), the The UP will reply with an Update_Response message (Step 9). The
format of the Update_Response is as follows: format of the Update_Response message is as follows:
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
5.1.3. IPv6 SLAAC Access 5.1.3. IPv6 SLAAC Access
The following flow describes the IPv6 SLAAC access process. The following flow shows the IPv6 SLAAC access process.
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| RS | | | | RS | | |
1|-------------->| | | 1|-------------->| | |
| | Relay the Router | | | | Relay the Router | |
| | Solicit (RS) | | | | Solicit (RS) | |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
skipping to change at page 29, line 46 skipping to change at page 31, line 52
| | 10|<------------->| | | 10|<------------->|
| | | | | | | |
| | Send a Neighbor | | | | Send a Neighbor | |
| | Advertise (NA) | | | | Advertise (NA) | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | | | | | |
| NA | | | | NA | | |
12|<--------------| | | 12|<--------------| | |
| | | | | | | |
Figure 5.1.3: IPv6 SLAAC Access Figure 16: IPv6 SLAAC Access
It starts with a Router Solicit (RS) request from an RG, it will be It starts with a Router Solicit (RS) request from an RG that is
tunneled to the CP when the UP receives the message. After the AAA tunneled to the CP by the UP. After the AAA authentication and
authentication and authorization, the CP will create a subscriber authorization, the CP will create a subscriber session on the UP.
session on the UP. This is achieved by sending a UPdate_Request
message to the UP (step 4). INTERNET-DRAFT Simple BNG CUSP
This is achieved by sending an Update_Request message to the UP (step
4).
The format of the Update_Request message is as follows: The format of the Update_Request message is as follows:
<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>]
The UP will reply with an Update_Response message (step 5). The The UP will reply with an Update_Response message (step 5), the
format of the Update_Response is as follows: format of the Update_Response message is as follows:
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
5.1.4. DHCPv6 + SLAAC Access 5.1.4. DHCPv6 + SLAAC Access
The following call flow describes the DHCP IPv6 and SLAAC access The following call flow shows the DHCP IPv6 and SLAAC access process.
process.
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| RS | | | | RS | | |
1|-------------->| | | 1|-------------->| | |
| | Relay the Router | | | | Relay the Router | |
| | Solicit (RA) | | | | Solicit (RA) | |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
skipping to change at page 31, line 32 skipping to change at page 33, line 4
| | | | | | | |
| | Send Router Advertise | | | | Send Router Advertise | |
| | (RA) | | | | (RA) | |
| 6|<----to UP vis Si-------| | | 6|<----to UP vis Si-------| |
| RA | | | | RA | | |
7|<--------------| | | 7|<--------------| | |
| | | | | | | |
|DHCPv6 Solicit | | | |DHCPv6 Solicit | | |
8|-------------->| | | 8|-------------->| | |
| | Relay DHCPv6 Solicit | | | | Relay DHCPv6 Solicit | |
INTERNET-DRAFT Simple BNG CUSP
| 9|-----to CP via Si------>| | | 9|-----to CP via Si------>| |
| | | | | | | |
| | Update subscriber | | | | Update subscriber | |
| | session Request | | | | session Request | |
| 10|<--------via Ci---------| | | 10|<--------via Ci---------| |
| | | | | | | |
| | Update subscriber | | | | Update subscriber | |
| | session Response | | | | session Response | |
| 11|---------via Ci-------->| | | 11|---------via Ci-------->| |
| | | | | | | |
| | | Accounting | | | | Accounting |
| | 12|<------------->| | | 12|<------------->|
| | | | | | | |
| | Send DHCPv6 Reply | | | | Send DHCPv6 Reply | |
| 13|<----to UP via Si-------| | | 13|<----to UP via Si-------| |
| | | | | | | |
| DHCPv6 Reply | | | | DHCPv6 Reply | | |
14|<--------------| | | 14|<--------------| | |
| | | | | | | |
Figure 5.1.4: DHCPv6 + SLAAC Access Figure 17: DHCPv6 + SLAAC Access
When a subscriber passed AAA authentication, the CP will create a When a subscriber passes AAA authentication, the CP will create a
subscriber session on the UP. This is achieved by sending a subscriber session on the UP. This is achieved by sending an
UPdate_Request message to the UP (step 4). Update_Request message to the UP (step 4).
<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>]
The UP will reply with an Update_Response message (step 5). The The UP will reply with an Update_Response message (step 5). The
format of the Update_Response is as follows: format of the Update_Response is as follows:
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
After receiving a DHCPv6 Solicit, the CP will update the subscriber After receiving a DHCPv6 Solicit, the CP will update the subscriber
session by sending a UPdate_Request message with new parameters to session by sending an Update_Request message with new parameters to
the UP (Step 10). the UP (Step 10).
The format of the Update_Request message is as follows: The format of the Update_Request message is as follows:
<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
The UP will reply with an Update_Response message (step 11). The The UP will reply with an Update_Response message (step 11). The
format of the Update_Response is as follows: format of the Update_Response is as follows:
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
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 process. 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------>| AAA | | 2|-----to CP via Si------>| |
| | | Req/Rep | | | | Accounting |
| | 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 33, line 30 skipping to change at page 34, line 53
| | 10|<------------->| | | 10|<------------->|
| | Send DHCP ACK | | | | Send DHCP ACK | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | | | | | |
| DHCP ACK | | | | DHCP ACK | | |
12|<--------------| | | 12|<--------------| | |
| RS | | | | RS | | |
13|-------------->| | | 13|-------------->| | |
| | Relay the Router | | | | Relay the Router | |
| | Solicit (RA) | | | | Solicit (RA) | |
| 14|-----to CP via Si------>| | | 14|-----to CP via Si------>| AAA |
| | | Accounting | | | | Req/Rep |
INTERNET-DRAFT Simple BNG CUSP
| | 15|<------------->| | | 15|<------------->|
| | | | | | | |
| | Update subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 16|<--------via Ci---------| | | 16|<--------via Ci---------| |
| | Update subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
| 17|---------via Ci-------->| | | 17|---------via Ci-------->| |
| | | | | | | |
| | Send Router Advertise | | | | Send Router Advertise | |
| | (RA) | | | | (RA) | |
| 18|<----to UP vis Si-------| | | 18|<----to UP vis Si-------| |
| RA | | | | RA | | |
19|<--------------| | | 19|<--------------| | |
| | | | | | | |
|DHCPv6 Solicit | | | |DHCPv6 Solicit | | |
skipping to change at page 34, line 18 skipping to change at page 35, line 41
| | session Response | | | | session Response | |
| 23|---------via Ci-------->| | | 23|---------via Ci-------->| |
| | | 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 5.1.5: DHCP Dual Stack Access Figure 18: DHCP Dual Stack Access
The DHCP dual stack access includes three Update_Request/ The DHCP dual stack access includes three sets of Update_Request/
Update_Response message exchanges to create/update DHCPv4/v6 Update_Response exchanges to create/update DHCPv4/v6 subscriber
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 Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
2. Create or Update? 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
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> <Subscriber Session Update Response TLV>
5.1.6. L2 Static Subscriber Access 5.1.6. L2 Static Subscriber Access
skipping to change at page 35, line 19 skipping to change at page 36, line 37
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Subscriber Session 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 Access| | | | Static Subscriber | |
| | Control List Req. | | | | Detection Req. | |
| 1|<-----to UP via Ci------| | | 1|<-----to UP via Ci------| |
| |Static Subscriber Access| | | | Static Subscriber | |
| | Control List Rep. | | | | Detection Rep. | |
| 2|------to CP 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---------| | | 3.5|<--------via Ci-------->| |
| | Create subscriber | | | | Create subscriber | |
INTERNET-DRAFT Simple BNG CUSP
| | 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 | |
skipping to change at page 36, line 15 skipping to change at page 37, line 33
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 |
| | | Req/Rep | | | | Req/Rep |
| | 5.3|<------------->| | | 5.3|<------------->|
| | Create subscriber | | | | Create subscriber | |
| | session Request | | | | session Request | |
| 5.4|<--------via Ci---------| | | 5.4|<--------via Ci-------->| |
| | Create subscriber | | | | Create subscriber | |
| | session Response | | | | session Response | |
| 5.5|---------via Ci-------->| | | 5.5|---------via Ci-------->| |
| | | | | | | |
| ARP/ND(REQ) | | | | ARP/ND(REQ) | | |
5.6|<--------------| | | 5.6|<--------------| | |
| ARP/ND(ACK) | | | | ARP/ND(ACK) | | |
5.7|-------------->| | | 5.7|-------------->| | |
| | | | | | | |
Figure 5.1.6: L2 Static Subscriber Access
For L2 static subscriber access, it always starts with a CP Figure 19: L2 Static Subscriber Access
installing a subscriber access control list on a UP. The subscriber
access control list is used by the UP to determine whether an RG is For L2 static subscriber access, the process starts with a CP
allowed to access the network. This is implemented by exchanging installing a static subscriber detection list on an UP. The list
Update_Request and Update_Response messages between CP and UP. The determines which subscribers will be detected. This is implemented
format of the messages are as follows: by exchanging Update_Request and Update_Response messages between CP
and UP. The format of the messages are as follows:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<IPv4 Static User Information TLV> <IPv4 Static Subscriber Detect TLVs>
<IPv6 Static User Information TLV> <IPv6 Static Subscriber Detect TLVs>
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV>
For L2 Static Subscriber Access, there are three ways to trigger the INTERNET-DRAFT Simple BNG CUSP
<Update Response TLV>
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 the RG. If the RG is online, it will reply with an ARP/ND to the
response to the UP. The UP will tunnel the ARP/ND to the CP UP. The UP will tunnel the ARP/ND to the CP through the Si. The
through the Si. It will then trigger the authentication process. CP then triggers the authentication process. If the
If the authentication result is positive. The CP will create a authentication result is positive. The CP will create a
corresponding subscriber session on the UP. corresponding subscriber session on the UP.
2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as 2. Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as
option 1 (triggered by UP). The difference is that the RG will option 1 (triggered by UP). The difference is that the RG will
actively send the ARP/ND to trigger the process. actively send the ARP/ND to trigger the process.
3. Triggered by RG IP traffic (5.1-5.7): This is for the case where 3. Triggered by RG IP traffic (5.1-5.7): This is for the case where
the RG has the ARP/ND entity, but the subscriber session on the the RG has the ARP/ND information, but the subscriber session on
UP is lost (e.g., due to failure on the UP, or the UP restarted). the UP is lost (e.g., due to failure on the UP, or the UP
That means the RG may keep sending IP packets to the UP. The restarted). That means the RG may keep sending IP packets to the
packets will trigger the UP to start a new access process. UP. The packets will trigger the UP to start a new access
process.
From a subscriber session point of view, the procedures and the From a subscriber session point of view, the procedures and the
message formats for the above three cases are the same, as follows: message formats for the above three cases are the same, 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session 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 describes 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------->| |
| | | | | | | |
| 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------->|<------------->|
| | | | | | | |
| 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 5.2.1: IPv4 PPPoE Access Figure 20: IPv4 PPPoE Access
From the above sequence, steps 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:
<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>
<Subscriber Session 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.
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 25 skipping to change at page 40, line 34
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 IP6CP | PPP IP6CP | | | PPP IP6CP | PPP IP6CP | |
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-------->| |
| | | | | | | |
| ND Negotiation| ND Negotiation | | | ND Negotiation| ND 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|<------------->|
| | | | | | | |
| 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 5.2.2: IPv6 PPPoE Access Figure 21: IPv6 PPPoE Access
From the above sequence, steps 1-4 are the standard PPPoE call flow. From the above sequence, steps 1-4 are the standard PPPoE call flow.
The UP is responsible for redirecting the PPPoE control packets to The 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 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:
<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>
<Subscriber Session 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 then, 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:
<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>
<Subscriber Session Update Response TLV>
INTERNET-DRAFT Simple BNG CUSP
<Update Response TLV>
5.2.3. PPPoE Dual Stack Access 5.2.3. PPPoE Dual Stack Access
The following figure describes 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 | |
1|<------------->|<---------via Si------->| | 1|<------------->|<---------via Si------->| |
| | | | | | | |
| PPP LCP | PPP LCP | | | PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| | 2|<------------->|<---------via Si------->| |
| | | AAA | | | | AAA |
skipping to change at page 41, line 47 skipping to change at page 42, line 51
| 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 | |
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---------| |
| | | | | | | |
| | Update v6 subscriber | | | | Update v6 subscriber | |
| | session Response | | | | session Response | |
| 10'|---------via Ci-------->| | | 10'|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 7"|<------------->| | | 7"|<------------->|
| | | | | | | |
Figure 5.2.3: PPPoE Dual Stack Access Figure 22: PPPoE Dual Stack Access
PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE
access. The process is as above. The formats of the messages are as access. The process is as above. The formats of the messages are as
follows: follows:
1. Create an IPv4 PPPoE subscriber session (5-6) 1. Create an IPv4 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>
<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>
<Subscriber Session 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>
<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>
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>
<Subscriber Session Update Response TLV> <Update Response TLV>
5.3. WLAN Access 5.3. WLAN Access
The following figure describes the WLAN access call flow. The following figure shows the WLAN access call flow.
RG UP CP AAA WEB Server RG UP CP AAA WEB Server
| | | | | | | | | |
| DHCP | | | | | DHCP | | | |
| Discovery | | | | | Discovery | | | |
1|------------>| | | | 1|------------>| | | |
| | DHCP | | | | | DHCP | | |
| | Discovery | | | | | Discovery | | |
| 2|-----via Si---->| AAA | | | 2|-----via Si---->| AAA | |
| | DHCP Offer |<-------->| | | | DHCP Offer |<-------->| |
skipping to change at page 44, line 4 skipping to change at page 45, line 4
| | | | | | | | | |
| | 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 44, line 32 skipping to change at page 45, line 35
| | | | | | | | | |
| | Update session | | | | | Update session | | |
| | Request | | | | | Request | | |
| 18|<----via Ci-----| | | | 18|<----via Ci-----| | |
| | | | | | | | | |
| | Update session | | | | | Update session | | |
| | Response | | | | | Response | | |
| 19|-----via Ci---->| | | | 19|-----via Ci---->| | |
| | | | | | | | | |
Figure 5.3: WLAN Access Figure 23: WLAN Access
WLAN access starts with the DHCP dial-up process (steps 1-6), after WLAN access starts with the DHCP dial-up process (steps 1-6), after
that the CP will create a subscriber session on the UP (step 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session 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>
<Subscriber Session 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 (step 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:
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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session 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 | | |
| 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 14 skipping to change at page 47, line 49
| | 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?---------------->|
| | | |
Figure 5.4.1: 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 a 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 a 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>
<Subscriber Session 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)
| | | | | | | | | |
| PPPoE | | | | | PPPoE | | | |
| Discovery | | | | | Discovery | | | |
1|<---------->| | | | 1|<---------->| | | |
| | | | | | | | | |
| PPP LCP | | | | | PPP LCP | | | |
skipping to change at page 48, line 4 skipping to change at page 48, line 36
3|<---------->|<--------------------->| | 3|<---------->|<--------------------->| |
| | | | | |
| | | | | |
| | L2TP tunnel | L2TP tunnel | | | L2TP tunnel | L2TP tunnel |
| | negotiation | negotiation | | | negotiation | negotiation |
| | SCCRQ/ | SCCRQ/ | | | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ | | | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN | | | SCCCN | SCCCN |
| 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 |
| | | subscriber | | | | subscriber |
| | | session | | | | session |
| | | Request | | | | Request |
| | 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 48, line 45 skipping to change at page 49, line 29
| | | session | | | | session |
| | | Request | | | | Request |
| | 11|<-----via Ci-------| | | 11|<-----via Ci-------|
| | | Update | | | | Update |
| | | subscriber | | | | subscriber |
| | | session | | | | session |
| | | Response | | | | Response |
| | 12|------via Ci------>| | | 12|------via Ci------>|
| | | | | | | |
Figure 5.4.2: IPv4 L2TP-LNS Access Figure 25: IPv4 L2TP-LNS Access
In this case, the BNG is running as an LNS and separated into LNS-CP In this case, the BNG is running as an LNS and separated into LNS-CP
and LNS-UP. Step 1-5 finish the normal L2TP dial-up process. When and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When
the L2TP session and tunnel negotiations are finished, the LNS-CP the L2TP session and tunnel negotiations are finished, the LNS-CP
will create a L2TP LNS subscriber session on the LNS-UP. The format will create an L2TP LNS subscriber session on the LNS-UP. The format
of messages are as follows: of messages are as follows:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV> <L2TP-LNS Subscriber TLV>
<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>
<Subscriber Session Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
After then, the LNS-CP will trigger a 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>
<Subscriber Session Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
5.4.3. L2TP LNS IPv6 Access 5.4.3. L2TP LNS IPv6 Access
RG LAC UP(LNS) AAA CP(LNS) RG LAC UP(LNS) AAA CP(LNS)
| | | | | | | | | |
| PPPoE | | | | | PPPoE | | | |
| Discovery | | | | | Discovery | | | |
1|<---------->| | | | 1|<---------->| | | |
| | | | | | | | | |
skipping to change at page 50, line 9 skipping to change at page 50, line 40
3|<---------->|<--------------------->| | 3|<---------->|<--------------------->| |
| | | | | |
| | | | | |
| | L2TP tunnel | L2TP tunnel | | | L2TP tunnel | L2TP tunnel |
| | negotiation | negotiation | | | negotiation | negotiation |
| | SCCRQ/ | SCCRQ/ | | | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ | | | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN | | | SCCCN | SCCCN |
| 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 |
| | | 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 17 skipping to change at page 51, line 48
| | | session | | | | session |
| | | Request | | | | Request |
| | 14|<-----via Ci-------| | | 14|<-----via Ci-------|
| | | Update | | | | Update |
| | | subscriber | | | | subscriber |
| | | session | | | | session |
| | | Response | | | | Response |
| | 15|------via Ci------>| | | 15|------via Ci------>|
| | | | | | | |
Figure 5.4.3 L2TP-LNS IPv6 Access Figure 26: L2TP-LNS IPv6 Access
Step 1-12 are the same as L2TP LNS IPv4 Access. Step 1-5 finish the Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5
normal L2TP dial-up process. When the L2TP session and tunnel finish the normal L2TP dial-up process. When the L2TP session and
negotiations are finished, the LNS-CP will create a L2TP LNS tunnel negotiations are finished, the LNS-CP will create an L2TP LNS
subscriber session on the LNS-UP. The formats of the messages are 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>
<Subscriber Session Update Response TLV> <Update Response TLV>
After that, the LNS-CP will trigger a AAA authentication. If the After that, the LNS-CP will trigger a AAA authentication. If the
authentication result is positive, a PPP IP6CP process will follow, authentication result is positive, a PPP IP6CP 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>
<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>
<Subscriber Session Update Response TLV> <Update Response TLV>
Then, a ND negotiation will be triggered by the RG. After the ND Then, an ND negotiation will be triggered by the RG. After the ND
negotiation, the CP will update the session with the following negotiation, the CP will update the session with the following
message exchanges: message exchanges:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LAC Subscriber TLV> <L2TP-LAC 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>
<Subscriber Session Update Response TLV> <Update Response TLV>
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 Response | | | | 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 |
| | access response 5|<------------->| | Subscriber | access reply 5|<------------->|
| 6|<---------via Si--------| | | access reply 6|<---------via Si--------| |
| Subscriber | | |
|access response| | |
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|<------------->|
| | | Public IP + | | | | Public IP + |
| | | Port range | | | | Port range |
| | | to Private IP| | | | to Private IP|
| | | mapping | | | | mapping |
| | | | | | | |
Figure 5.5: CGN Access Figure 27: CGN Access
The first step is to allocate one or more CGN address blocks to the The first steps allocate one or more CGN address blocks to the UP
UP (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.
<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>
Step 3-9 describe the general dial-up process in the case of CGN Steps 3-9 show the general dial-up process in the case of CGN mode.
mode. The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in
defined in above sections.
If a subscriber is a CGN subscriber, once the subscriber session INTERNET-DRAFT Simple BNG CUSP
above sections.
If a subscriber is a CGN subscriber, once the subscriber session is
created/updated, the UP will report the NAT information to the CP. 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
RG UP CP AAA WEB Server RG UP CP AAA WEB Server
| | | | | | | | | |
| User | | | | | User | | | |
| traffic | | | | | traffic | | | |
1|------------>| | | | 1|------------>| | | |
| | User | | | | | User | | |
| | traffic | | | | | traffic | | |
| 2|-----via Si---->| AAA | | | 2|-----via Si---->| AAA | |
| | | Req/Rep | | | | | Req/Rep | |
| | 3|<-------->| | | | 3|<-------->| |
skipping to change at page 55, line 39 skipping to change at page 55, line 4
| | | |
8|-----------------Redirected to Web server----------->| 8|-----------------Redirected to Web server----------->|
| | | |
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 | | |
| | Response | | | | | Response | | |
| 14|----via Ci----->| | | | 14|----via Ci----->| | |
| | | | | | | | | |
Figure 5.6.1: Web Authentication based L3 Leased Line Access Figure 28: Web Authentication based L3 Leased Line Access
In this case, IP traffic from the RG will trigger the CP to In this case, IP traffic from the RG will trigger the CP to
authenticate the RG by checking the source IP and the exchanges with authenticate the RG by checking the source IP and the exchanges with
the AAA server. Once the RG passed the authentication, the CP will the AAA server. Once the RG passed the authentication, the CP will
create a corresponding subscriber session on the UP through the create a corresponding subscriber session on the UP through the
following message exchanges: following message exchanges:
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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Subscriber Session Update Response TLV>
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 authentication passed, to finish the WEB authentication. Once the WEB authentication is
the CP will trigger another AAA authentication. After the AAA passed, the CP will trigger another AAA authentication. After the
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>
<Subscriber Session 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session Update Response TLV> <Update Response TLV>
5.6.2. User Traffic Trigger 5.6.2. User Traffic Trigger
RG UP CP AAA RG UP CP AAA
| | | | | | | |
| | L3 access | | | | L3 access | |
| | control list | | | | control list | |
| 1|<----via Ci-----| | | 1|<----via Ci-----| |
| User | | | | User | | |
| traffic | | | | traffic | | |
skipping to change at page 57, line 51 skipping to change at page 56, line 52
| | 4|<-------->| | | 4|<-------->|
| | | | | | | |
| | Create session | | | | Create session | |
| | Request | | | | Request | |
| 5|<----via Ci-----| | | 5|<----via Ci-----| |
| | Create session | | | | Create session | |
| | Response | | | | Response | |
| 6|----via Ci----->| | | 6|----via Ci----->| |
| | | | | | | |
Figure 5.6.2: 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 an 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>
<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>
<Subscriber Session 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>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Subscriber Session 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 | |
skipping to change at page 59, line 22 skipping to change at page 58, line 4
| | Create session | | | | Create session | |
| | Request | | | | Request | |
| 2|<----via Ci---->| | | 2|<----via Ci---->| |
| | | | | | | |
| | Create session | | | | Create session | |
| | Response | | | | Response | |
| 3|----via Ci----->| | | 3|----via Ci----->| |
| | | | | | | |
| Multicast | | | | Multicast | | |
| negotiation | | | | negotiation | | |
INTERNET-DRAFT Simple BNG CUSP
4|<----------->| | | 4|<----------->| | |
| | | | | | | |
Figure 5.6: Multicast Access Figure 30: Multicast Access
Multicast access starts with a 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:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Multicast Group Information TLV> <Multicast Group Information TLV>
<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>
<Subscriber Session 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>
<Multicast Group Information TLV> <Multicast Group Information TLV>
<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
6. S-CUSP Message Formats 6. S-CUSP Message Formats
An S-CUSP message consists of a common header followed by a variable- An S-CUSP message consists of a common header followed by a variable-
length body consisting entirely of TLVs. Receiving an S-CUSP message length body consisting entirely of TLVs. Receiving an S-CUSP message
with a missing mandatory TLV must trigger an Error message (see with an unknown message type or missing mandatory TLV MUST trigger an
Section 7.2 and 8.6). Conversely, if a TLV is optional, the TLV may Error message (see Section 6.7) or a response message with an Error
or may not be present. Optional TLVs are indicated in the message Information TLV (see Section 7.6).
formats shown in this document by being enclosed in square brackets.
Conversely, if a TLV is optional, the TLV may or may not be present.
Optional TLVs are indicated in the message formats shown in this
document by being enclosed in square brackets.
This section specifies the format of the common S-CUSP message header This section specifies the format of the common S-CUSP message header
and lists the defined message. and lists the defined messages.
Network byte order is used for all multi-byte fields. Network byte order is used for all multi-byte fields.
6.1. Common Message Header 6.1. Common Message Header
0 1 2 3 S-CUSP Common Message Header:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Ver | Resv | Message-Type | Message-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Resv | Message-Type | Message-Length |
| Reserved | Transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.1. S-CUSP Message Common Header Figure 6.1: S-CUSP Message Common Header
o Ver (4 bits): The major version of the protocol. This document o Ver (4 bits): The major version of the protocol. This document
specifies version 1. Different major versions of the protocol may specifies version 1. Different major versions of the protocol
have significantly different message structure and format except may have significantly different message structure and format
that the Ver field will always be in the same place at the except that the Ver field will always be in the same place at
beginning of each message. A successful S-CUSP session depends on the beginning of each message. A successful S-CUSP session
the CP and UP both using the same major version of the protocol. depends on the CP and the UP both using the same major version
of the protocol.
o Resv (4 bits): Reserved. must be sent as zero and ignored on o Resv (4 bits): Reserved. MUST be sent as zero and ignored on
receipt. receipt.
o Message-Type (8 bits): The set of message types specified in this o Message-Type (8 bits): The set of message types specified in
document is listed in Section 11.2.1. this document is listed in Section 9.1.
o Message-Length (16 bits): Total length of the CUSP message o Message-Length (16 bits): Total length of the S-CUSP message
including the common header, expressed in number of bytes as an including the common header, expressed in number of bytes as an
unsigned integer. unsigned integer.
o Transaction ID (16 bits): This field is used to identify requests. INTERNET-DRAFT Simple BNG CUSP
It is echoed back in any corresponding ACK / response / Error
message. o Transaction ID (16 bits): This field is used to identify
requests. It is echoed back in any corresponding ACK / response
/ Error message. It is RECOMMENDED that a monotonically
increasing value be used in successive message and that value
wrap back to zero after 0xFFFF. The contents of this field is
an opaque value that the receiver MUST NOT use for any purpose
except to echo back in a corresponding response and,
optionally, for logging.
6.2. Control Messages 6.2. Control Messages
This document defines the following control messages: This document defines the following control messages:
Type Name Notes and TLVs that can be carried Type Name Notes and TLVs that can be carried
---- ---- ------------------------------------ ---- ---- ------------------------------------
1 Hello Hello TLV, Keep-Alive TLV. 1 Hello Hello TLV, Keep-Alive TLV.
2 Keepalive A common header with the Keepalive message 2 Keepalive A common header with the Keepalive message
type. type.
3 Synch_Request Synchronization request. 3 Sync_Request Synchronization request.
4 Sync_Begin Synchronization starts. 4 Sync_Begin Synchronization starts.
5 Sync_Data Synchronization data: TLVs specified in 5 Sync_Data Synchronization data: TLVs specified in
Section 5. Section 5.
6 Sync_End End synchronization. 6 Sync_End End synchronization.
7 Update_Request TLVs specified in Sections 8.7 and 8.8. 7 Update_Request TLVs specified in Sections 7.6-7.9.
8 Update_Response TLVs specified in Sections 8.7 and 8.8. 8 Update_Response TLVs specified in Sections 7.6-7.9.
6.2.1. Hello Message 6.2.1. Hello Message
Hello message is used for S-CUSP session establishment and version Hello message is used for S-CUSP session establishment and version
negotiation. The detail of S-CUSP session establishment and version negotiation. The detail of S-CUSP session establishment and version
negotiation can be found in Section 4.1.1. negotiation can be found in Section 4.1.1.
The format of Hello message is as follows: The format of Hello message is as follows:
<Hello Message> ::= <Common Header> <Hello Message> ::= <Common Header>
skipping to change at page 62, line 17 skipping to change at page 61, line 5
<Keepalive TLV> <Keepalive TLV>
[<Error Information TLV>] [<Error Information TLV>]
The return code and negotiation result will be carried in the Error The return code and negotiation result will be carried in the Error
Information TLV. They are listed as follows: Information TLV. They are listed as follows:
0: Success, version negotiation success. 0: Success, version negotiation success.
1: Failure, malformed message received. 1: Failure, malformed message received.
INTERNET-DRAFT Simple BNG CUSP
2: One or more of the TLVs was not understood. 2: One or more of the TLVs was not understood.
1001: Version-Mismatch. The version negotiation fails. 1001: The version negotiation fails. The S-CUSP session
Terminate. The subsequent service processes corresponding to the establishment phase fails.
UP are suspended.
1002: The keepalive negotiation fails. The S-CUSP session
establishment phase fails.
1003: The establishment timer expires. session establishment
phase fails.
6.2.2. Keepalive Message 6.2.2. Keepalive Message
The Keepalive message is periodically sent by each end of an S-CUSP The Keepalive message is periodically sent by each end of an S-CUSP
session. It is used to detect whether the peer end is still alive. session. It is used to detect whether the peer end is still alive.
The Keepalive procedures are defined Section 4.1.1. The Keepalive procedures are defined Section 4.1.2.
The format of Keepalive message is as follows: The format of the Keepalive message is as follows:
<Keepalive Message> ::= <Common Header> <Keepalive Message> ::= <Common Header>
6.2.3. Synch_Request Message 6.2.3. Sync_Request Message
The Synch_Request message is used to request synchronization from an The Sync_Request message is used to request synchronization from an
S-CUSP peer. Both the CP and UP can request their to peer to S-CUSP peer. Both CP and UP can request their peer to synchronize
synchronize data. data.
The format of Synch_Request message is as follows: The format of the Sync_Request message is as follows:
<Keepalive Message> ::= <Common Header> <Sync_Request Message> ::= <Common Header>
A Synch_Request message may result in a Synch_Begin message from its A Sync_Request message may result in a Sync_Begin message from its
peer. The Synch_Begin message is defined in Section 6.2.4. peer. The Sync_Begin message is defined in Section 6.2.4.
6.2.4. Sync_Begin Message 6.2.4. Sync_Begin Message
The Sync_Begin message is a reply to a Sync_Request message. It is The Sync_Begin message is a reply to a Sync_Request message. It is
used to notify the synchronization requester as to whether the used to notify the synchronization requester whether the
synchronization can be started. synchronization can be started.
The format of Sync_Begin message is as follows: The format of Sync_Begin message is as follows:
<Keepalive Message> ::= <Common Header> <Sync_Begin Message> ::= <Common Header>
<Error Information TLV> <Error Information TLV>
INTERNET-DRAFT Simple BNG CUSP
The return codes are carried in the Error Information TLV. The codes The return codes are carried in the Error Information TLV. The codes
are listed below: are listed below:
0: Success, be ready to synchronize. 0: Success, be ready to synchronize.
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.
2001: Synch-NoReady. The data to be synchronized is not ready. 2001: Synch-NoReady. The data to be synchronized is not ready.
2002: Synch-Unsupport. The data synchronization is not supported. 2002: Synch-Unsupport. The data synchronization is not supported.
6.2.5. Sync_Data Message 6.2.5. Sync_Data Message
The Sync_Data message is used to synchronize data between CP and UP. The Sync_Data message is used to send data being synchronized between
Sync_Data message has the same function and format as Update_Request the CP and UP. The Sync_Data message has the same function and
message. The difference is that there is no ACK for Sync_Data format as the Update_Request message. The difference is that there
message. An error caused by the Sync_Data message will result in a is no ACK for a Sync_Data message. An error caused by the Sync_Data
Sync_End message. message will result in a Sync_End message.
There are two scenarios: There are two scenarios:
Synchronization from UP to CP: Synchronize the resource data to Synchronization from UP to CP: Synchronize the resource data to
CP. CP.
<Sync_Data Message> ::= <Common Header> <Sync_Data Message> ::= <Common Header>
[<Resource Reporting TLVs>] [<Resource Reporting TLVs>]
Synchronization from CP to UP: Synchronize all subscriber sessions Synchronization from CP to UP: Synchronize all subscriber sessions
to UP. As for which TLVs should be carried, it depends on the to UP. As for which TLVs should be carried, it depends on the
specific session data to be synchronized. This is equivalent to specific session data to be synchronized. This is equivalent to
create the specific session. Refer to Section 4.2.5 to see more create the specific session. Refer to Section 5 to see more
details. details.
<Sync_Data Message> ::= <Common Header> <Sync_Data Message> ::= <Common Header>
[<User Routing TLVs>] [<User Routing TLVs>]
[<User Information TLVs>] [<User Information TLVs>]
[<L2TP Subscriber TLVs>] [<L2TP Subscriber TLVs>]
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
6.2.6. Sync_End Message 6.2.6. Sync_End Message
The Sync_End message is used to indicate the end of synchronization The Sync_End message is used to indicate the end of a synchronization
process. The format of Sync_End message is as follows: process. The format of a Sync_End message is as follows:
<Keepalive Message> ::= <Common Header> INTERNET-DRAFT Simple BNG CUSP
<Sync_End Message> ::= <Common Header>
<Error Information TLV> <Error Information TLV>
The return/error codes are listed as follows: The return/error codes are listed as follows:
0: Success, synchronization finished. 0: Success, synchronization finished.
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.
6.2.7. Update_Request Message 6.2.7. Update_Request Message
The Update_Request message is a multi-task message, it can be used to The Update_Request message is a multi-task message, it can be used to
create, update and delete subscriber session on a UP. create, update, and delete subscriber sessions on a UP.
For session operations, the specific operation is controlled by the For session operations, the specific operation is controlled by the
"Oper" field of the carried TLVs. As defined in Section 7.1, the "Oper" field of the carried TLVs. As defined in Section 7.1, the
"Oper" can be set to either "update" or "delete" when a TLV is "Oper" can be set to either "update" or "delete" when a TLV is
carried in an Update_Request message. carried in an Update_Request message.
When the "Oper" set to update, it means to create or update a When the "Oper" set to update, it means to create or update a
subscriber session, if the "Oper" set to delete, it indicates to subscriber session, if the "Oper" set to delete, it indicates to
delete a corresponding session on a UP. delete a corresponding session on an UP.
The format of Update_Request message is as follows: The format of Update_Request message is as follows:
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
[<User Routing TLVs>] [<User Routing TLVs>]
[<User Information TLVs>] [<User Information TLVs>]
[<L2TP Subscriber TLVs>] [<L2TP Subscriber TLVs>]
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
Each Update_Request message will result in a 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 a UPdate_Request The Update_Response message is a response to an Update_Request
message. It is used to confirm the update request. The format of message. It is used to confirm the update request (or reject it in
Update_Response message is as follows: the case of an error). The format of an Update_Response message is
as follows:
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
[<Error Information TLV>]
INTERNET-DRAFT Simple BNG CUSP
<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 49 skipping to change at page 64, line 49
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.
6.3. Event Message 6.3. Event Message
The Event message is used to report subscriber session traffic The Event message is used to report subscriber session traffic
statistics and detection information. The format of Event message is statistics and detection information. The format of Event message is
as follows: as follows:
<Report Message> ::= <Common Header> <Event Message> ::= <Common Header>
[<User Traffic Statistics Report TLV>] [<User Traffic Statistics Report TLV>]
[<User Detection Result Report TLV>] [<User Detection Result Report TLV>]
INTERNET-DRAFT Simple BNG CUSP
6.4. Report Message 6.4. Report Message
The Report message is used to report board and interface status on a The Report message is used to report board and interface status on a
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 Notes and TLVs that can be carried Type Name TLV that is carried
---- ------------------- ------------------------------------ ---- ------------------- ------------------------
200 Addr_Allocation_Req Addr-Alloc-Req 200 Addr_Allocation_Req Address Allocation Request
201 Addr_Allocation_Ack Addr-Alloc-Resp 201 Addr_Allocation_Ack Address Allocation Response
202 Addr_Renew_Req Addr-Renew-Req 202 Addr_Renew_Req Address Renewal Request
203 Addr_Renew_Ack Addr-Renew-Resp 203 Addr_Renew_Ack Address Renewal Response
204 Addr_Release_Req Addr-Release-Req 204 Addr_Release_Req Address Release Request
205 Addr_Release_Ack Addr-Release-Resp 205 Addr_Release_Ack Address Release Response
6.5.1. Addr_Allocation_Req Message 6.5.1. Addr_Allocation_Req Message
The Addr_Allocation_Req message is used to request CGN address The Addr_Allocation_Req message is used to request CGN address
allocation. The format of Addr_Allocation_Req message is as follows: allocation. The format of Addr_Allocation_Req message is as follows:
<Addr_Allocation_Req Message> ::= <Common Header> <Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV> <Address Allocation Request TLV>
6.5.2. Addr_Allocation_Ack Message 6.5.2. Addr_Allocation_Ack Message
The Addr_Allocation_Ack message is a response to an The Addr_Allocation_Ack message is a response to an
Addr_Allocation_Req message. The format of Addr_Allocation_Ack Addr_Allocation_Req message. The format of Addr_Allocation_Ack
message is as follows: message is as follows:
<Addr_Allocation_Ack Message> ::= <Common Header> <Addr_Allocation_Ack Message> ::= <Common Header>
<Address Allocation Response TLV> <Address Allocation Response TLV>
INTERNET-DRAFT Simple BNG CUSP
6.5.3. Addr_Renew_Req Message 6.5.3. Addr_Renew_Req Message
The Addr_Renew_Req message is used to request address renewal. The The Addr_Renew_Req message is used to request address renewal. The
format of Addr_Renew_Req message is as follows: format of Addr_Renew_Req message is as follows:
<Addr_Renew_Req Message> ::= <Common Header> <Addr_Renew_Req Message> ::= <Common Header>
<Address Renewal Request TLV> <Address Renewal Request TLV>
6.5.4. Addr_Renew_Ack Message 6.5.4. Addr_Renew_Ack Message
skipping to change at page 67, line 26 skipping to change at page 66, line 36
format of Addr_Release_Req message is as follows: format of Addr_Release_Req message is as follows:
<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_Renew_Ack Message> ::= <Common Header> <Addr_Release_Ack Message> ::= <Common Header>
<Address Renewal Release TLV> <Address Renewal Response TLV>
6.6. Vendor Message 6.6. Vendor Message
The vendor message is as follows: The Vendor message is, in conjunction with the vendor TLV and vendor
sub-TLV, can be used by vendors to extend the S-CUSP protocol. It's
message type is 11. If the receiver does not recognize the message,
an Error message will be returned to the sender.
Type Name Notes and TLVs that can be carried The format of the Vendor message is as follows:
---- ---- ------------------------------------
11 Vendor Vendor-Defined, any other TLV(s) as <Vendor Message> ::= <Common Header>
implemented by the vendor.
INTERNET-DRAFT Simple BNG CUSP
<Vendor TLV>
[<any other TLVs as specified by the vendor>]
6.7 Error Message
The Error message is defined to return some critical error
information to the sender. If a receiver does not know the message
type of a received message, it MUST return an Error message to the
sender.
The format of the Error message is as below:
<Error Message> ::= <Common Header>
<Error Information TLV>
INTERNET-DRAFT Simple BNG CUSP
7. S-CUSP TLVs and Sub-TLVs 7. S-CUSP TLVs and Sub-TLVs
This section specifies the following This section specifies the following:
o the format of the TLVs that appear in S-CUSP messages, o the format of the TLVs that appear in S-CUSP messages,
o the format of the sub-TLVs that appear within the values of some o the format of the sub-TLVs that appear within the values of some
TLVs, and TLVs, and
o the format of some basic data fields that appear within TLVs or o the format of some basic data fields that appear within TLVs or
sub-TLVs. sub-TLVs.
In addition, it lists all defined TLVs and sub-TLVs. See Section 9 for a list of all defined TLVs and sub-TLVs.
7.1. Common TLV Header 7.1. Common TLV Header
S-CUSP messages consist of the common header specified in Section 7.1 S-CUSP messages consist of the common header specified in Section 6.1
followed by TLVs formatted as specified in this section. followed by TLVs formatted as specified in this section.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper | TLV-Type | TLV-Length | | Oper | TLV-Type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.1. Common TLV Header Figure 32: Common TLV Header
o Oper (4 bits): For Message-Types that indicate an operation on a o Oper (4 bits): For Message-Types that indicate an operation on a
data set, the Oper field is interpreted as Update, Delete, or data set, the Oper field is interpreted as Update, Delete, or
Reserved as specified in Section 9.3. For all other Message- Reserved as specified in Section 9.3. For all other Message-Types,
Types, the Oper field must be sent as zero and ignored on receipt. the Oper field MUST be sent as zero and ignored on receipt.
o TLV-Type (12 bits): The Type of a TLV, that is the meaning and o TLV-Type (12 bits): The Type of a TLV, that is the meaning and
format of the Value part, are determined by the TLV- Type of the format of the Value part, are determined by the TLV-Type of the
TLV. See Section 9.2. TLV. See Section 9.2.
o TLV-Length (2 bytes): The length of the Value portion of the TLV o TLV-Length (2 bytes): The length of the Value portion of the TLV
in bytes as an unsigned integer. in bytes as an unsigned integer.
o Value (variable length): This is the value portion of the TLV o Value (variable length): This is the value portion of the TLV
whose size is given by TLV-Length. The value portion consists of whose size is given by TLV-Length. The value portion consists of
fields, frequently using one of the basic data field types (see fields, frequently using one of the basic data field types (see
Section 7.2) and sub-TLVs (see Section 7.3). Section 7.2) and sub-TLVs (see Section 7.3).
INTERNET-DRAFT Simple BNG CUSP
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 o STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section
Section 7.3) to provide the length. 7.3) to provide the length. The use of this data type in S-CUSP is
to provide convenient labels for use by network operators in
configuring and debugging their networks and interpreting S-CUSP
messages. These labels should not be seen by subscribers. They are
normally interpreted as ASCII [RFC20].
o MAC-Addr: 6 octets. Ethernet MAC Address. 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.
o VLAN ID: 2 octets. As follows [802.1Q]: o VLAN ID: 2 octets. As follows [802.1Q]:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRI |D| VLAN-ID | | PRI |D| VLAN-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PRI: Priority. Default value 7.
D: Drop Eligibility Indicator (DEI). Default value 0. PRI: Priority. Default value 7.
VLAN-ID: Unsigned integer in the range 1-4094. (0 and
4095 are not valid VLAN IDs[802.1Q].) D: Drop Eligibility Indicator (DEI). Default value 0.
VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are
not valid VLAN IDs [802.1Q].)
INTERNET-DRAFT Simple BNG CUSP
7.3. Sub-TLV Format and Sub-TLVs 7.3. Sub-TLV Format and Sub-TLVs
In some cases, the Value portion of a TLV, as specified above, can In some cases, the Value portion of a TLV, as specified above, can
contain one or more Sub-TLVs formatted as follows: contain one or more Sub-TLVs formatted as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 7.3. 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 sub- 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-TLV occurs. See the TLV Type of the TLV within which the sub-TVL occurs. See
Section 9.4. Section 9.4.
o Length (2 bytes): The length of the Value portion of the sub-TLV o Length (2 bytes): The length of the Value portion of the sub-
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-TLV o Value (variable length): This is the value portion of the sub-
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.
7.3.1. Name sub-TLVs 7.3.1. Name sub-TLVs
This document defines the following name sub-TLVs, it is used to This document defines the following name sub-TLVs that are used to
carry the name of the corresponding object. The length of each sub- carry the name of the corresponding object. The length of each of
TLV are variable from 1 to 255 octets. The value is STRING type. these sub-TLV is variable from 1 to 255 octets. The value is of type
STRING padded with zeros octets to 4-octet alignment.
Type Sub-TLV Name Meaning Type Sub-TLV Name Meaning
----- -------------------- ------------------- ----- -------------------- -------------------
1 VRF-Name The name of a VRF 1 VRF-Name The name of a VRF
2 Ingress-QoS-Profile The name of an ingress QoS profile 2 Ingress-QoS-Profile The name of an ingress QoS profile
3 Egress-QoS-Profile The name of an egress QoS profile 3 Egress-QoS-Profile The name of an egress QoS profile
4 User-ACL-Policy The name of an ACL policy 4 User-ACL-Policy The name of an ACL policy
5 Multicast-ProfileV4 The name of an IPv4 multicast profile 5 Multicast-ProfileV4 The name of an IPv4 multicast profile
6 Multicast-ProfileV6 The name of an IPv6 multicast profile 6 Multicast-ProfileV6 The name of an IPv6 multicast profile
7 NAT-Instance The name of a NAT instance 7 NAT-Instance The name of a NAT instance
8 Pool-Name The name of an address pool 8 Pool-Name The name of an address pool
INTERNET-DRAFT Simple BNG CUSP
7.3.2. Ingress-CAR sub-TLV 7.3.2. Ingress-CAR sub-TLV
Ingress-CAR sub-TLV indicates the authorized upstream Committed The Ingress-CAR sub-TLV indicates the authorized upstream Committed
Access Rate (CAR) parameters. The sub-TLV type of Ingress-CAR sub- Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR
TLV is 9, the sub-TLV length is 16 octets. The format is as defined sub-TLV is 9 and the sub-TLV length is 16. The format is as shown in
below: Figure 34.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR | | CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR | | PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS | | CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBD | | PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.3.2 Ingress-CAR sub-TLV Figure 34: Ingress-CAR sub-TLV
Where: Where:
CIR: 4 bytes in length, indicates the guaranteed rate in bits/ CIR (4 bytes): Guaranteed rate in bits/second.
second.
PIR: 4 bytes in length, indicates the burst rate in bits/second. PIR (4 bytes): Burst rate in bits/second.
CBS: 4 bytes in length, indicates the token bucket in bytes. CBS (4 bytes): The token bucket in bytes.
PBS: 4 bytes in length, indicates the burst token bucket in bytes. PBS (4 bytes): Burst token bucket in bytes.
These fields are unsigned integers. These fields are unsigned integers. More details about CIR, PIR, CBS,
and PBS can be found in [RFC2698].
7.3.3. Egress-CAR sub-TLV 7.3.3. Egress-CAR sub-TLV
Ingress-CAR sub-TLV indicates the authorized downstream Committed The Egress-CAR sub-TLV indicates the authorized downstream Committed
Access Rate (CAR) parameters. The sub-TLV type of Egress-CAR sub-TLV Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub-
is 10, the sub-TLV length is 16 octets. The format is as defined TLV is 10 and its sub-TLV length is 16 octets. The format of the
below: value part is as defined below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.3.3 Egress-CAR sub-TLV 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: Egress-CAR sub-TLV
Where: Where:
CIR: 4 bytes in length, indicates the guaranteed rate in bits/ CIR (4 bytes): Guaranteed rate in bits/second.
second.
PIR: 4 bytes in length, indicates the burst rate in bits/second. PIR (4 bytes): Burst rate in bits/second.
CBS: 4 bytes in length, indicates the token bucket in bytes. CBS (4 bytes): The token bucket in bytes.
PBS: 4 bytes in length, indicates the burst token bucket in bytes. PBS (4 bytes): Burst token bucket in bytes.
These fields are unsigned integers. These fields are unsigned integers. More details about CIR, PIR, CBS,
and PBS can be found in [RFC2698].
7.3.4. If-Desc sub-TLV 7.3.4. If-Desc sub-TLV
If-Desc sub-TLV is defined to describe an interface. The sub-TLV The If-Desc sub-TLV is defined to designate an interface. It is an
type is 11, the sub-TLV length is 12 octets. The sub-TLV format is optional sub-TLV that may be carried in those TLVs that have an "if-
as follows: index" or "out-if-index" field. The If-Desc sub-TLV is used as a
local unique identifier within a BNG.
0 1 2 3 The sub-TLV type is 11 and the sub-TLV length is 12 octets. The
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 format depends on the If-Type. The format of the value part is as
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ follows:
| If-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chassis | Slot | Port Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.3.4. If-Desc sub-TLV INTERNET-DRAFT Simple BNG CUSP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (1-5)| Chassis | Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Slot | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc sub-TLV (Physical Port)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (6-7) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logic-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc sub-TLV (Virtual Port)
Figure 36: If-Desc sub-TLV Formats
Where: Where:
If-Type: 8 bits in length, indicates the type of an interface. If-Type: 8 bits in length, indicates the type of an interface.
Following types are defined in this document: Following types are defined in this document:
0: Reserved, 0: Reserved
1: Fast Ethernet (FE) 1: Fast Ethernet (FE)
2: GE 2: GE
3: 10GE 3: 10GE
4: 100GE 4: 100GE
5: Eth-Trunk 5: Eth-Trunk
6: Tunnel 6: Tunnel
7: VE 7: VE
8-255: Reserved. 8-255: Reserved.
Chassis: Identify the chassis that the interface belongs to. Chassis (8 bits): Identifies the chassis that the interface
belongs to.
Slot: Identify the slot that the interface belongs to. Slot (16 bits): Identifies the slot that the interface belongs to.
Port Information Sub-slot (16 bits): Identifies the sub-slot the interface belongs
to.
if the If-Type identifies a physical interface (e.g., If Type: Port Number (16 bits): An identifier of a physical port/interface
1-5), the Port Information consists of a 1-byte Physical Slot (e.g., If-Type: 1-5). It is locally significant within the
number followed by a 1-byte Physical port number. slot/sub-slot.
If-Type identifies a virtual port (e.g., If-Type: 6-7), the INTERNET-DRAFT Simple BNG CUSP
Port Information consists of a 2 byte logical number of the
virtual interface.
Sub-Port number: The number of the Sub-Port. Sub-port Number (32 bits): An identifier of the sub-port. Locally
significant within its "parent" port (physical or virtual).
Logic-ID (32 bits): An identifier of a virtual interface (e.g.,
If-Type: 6-7)
7.3.5. IPv6 Address List sub-TLV 7.3.5. IPv6 Address List sub-TLV
The IPv6 Address List sub-TLV is used to convey one or more IPv6 The IPv6 Address List sub-TLV is used to convey one or more IPv6
addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV
type is 12, the sub-TLV length is variable. type is 12, the sub-TLV length is variable.
The format of IPv6 Addresses sub-TLV is as follows: The format of IPv6 Addresses sub-TLV is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 73, line 27 skipping to change at page 74, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~ ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~ ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~ ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.3.5. IPv6 Address List sub-TLV Figure 37: IPv6 Address List sub-TLV
Where: Where:
IP Address (IPv6-Address): Each IP Address is an IP-Address type, IP Address (IPv6-Address): Each IP Address is an IP-Address type,
carries an IPv6 address. carries an IPv6 address.
7.3.6. Vendor sub-TLV
The Vendor sub-TLV is intended to be used inside the value portion of
the Vendor TLV (Section 7.13). It provides a Sub-Type that
effectively extends the sub-TLV type in the sub-TLV header and
provides for versioning of vendor sub-TLVs.
The value part of the Vendor sub-TLV is formatted as follows:
INTERNET-DRAFT Simple BNG CUSP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ value (other as specified by vendor) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: Vendor sub-TLV
Where:
The sub-TLV type: 13.
The sub-TLV length: variable.
Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865].
Sub-Type (2 bytes): Used by the Vendor to distinguish multiple
different sub-TLVs.
Sub-Type-Version (2 bytes): Used by the Vendor to distinguish
different versions of a Vendor Defined sub-TLV sub-Type.
value: as specified by the vendor.
Since Vendor code will be handling the sub-TLV after the Vendor ID
field is recognized, the remainder of the sub-TLV can be organized
however the vendor wants. But it desirable for a vendor to be able to
define multiple different vendor sub-TLVs and to keep track of
different versions of its vendor defined sub-TLVs. Thus, it is
RECOMMENDED that the vendor assign a Sub-Type value for each of that
vendor's sub-TLVs that is different from other Sub-Type values that
vendor has used. Also, when modifying a vendor defined sub-TLV in a
way potentially incompatible with a previous definition, the vendor
SHOULD increase the value it is using in the Sub-Type-Version field.
INTERNET-DRAFT Simple BNG CUSP
7.4. The Hello TLV 7.4. The Hello TLV
The Hello TLV is defined to be carried in the Hello message for The Hello TLV is defined to be carried in the Hello message for
version and capabilities negotiation. It indicates the S-CUSP sub- version and capabilities negotiation. It indicates the S-CUSP sub-
version and capabilities supported. The format of Hello TLV is as version and capabilities supported. The format of Hello TLV is as
follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerSupported | | VerSupported |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities | | Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.4: Hello TLV Figure 39: Hello TLV
Where: Where:
The TLV type is 100. The TLV type is 100.
The TLV length is 12 octets. The TLV length is 12 octets.
The value field include three parts: The value field consists of three parts:
VerSupported: 32 bits in length. This is a bit map of the Sub- VerSupported: 32 bits in length. This is a bit map of the Sub-
Versions of the S-CUSP protocol that the sender supports. This Versions of the S-CUSP protocol that the sender supports. This
document specifies Sub-Version zero of Major Version 1, that is, document specifies Sub-Version zero of Major Version 1, that
Version 1.0. The VerSupported field must be non-zero. Bit 0 is, Version 1.0. The VerSupported field MUST be non-zero. The
indicates support of Sub-Version zero, bit 1 indicates support of VerSupported bits are numbered from 0 as the most significant
Sub-Version one, etc. bit. Bit 0 indicates support of Sub-Version zero, bit 1
indicates support of Sub-Version one, etc.
Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS
[RFC2865]. [RFC2865].
Capabilities: 32 bits in length. Flags that indicate the support Capabilities: 32 bits in length. Flags that indicate the
of particular capabilities by the sender of the Hello. support of particular capabilities by the sender of the Hello.
No Capabilities are defined in this document and so
implementations will set this field to zero. The Capabilities
field of the Hello TLV MUST be checked before any other TLVs in
the Hello because capabilities defined in the future might
extend existing TLVs or permit new TLVs.
After the exchange of Hello messages, the CP and UP each perform a After the exchange of Hello messages, the CP and UP each perform a
logical AND of the Sub-Version supported by the CP and the UP and logical AND of the Sub-Version supported by the CP and the UP and
separately perform a logical AND of the Capabilities bits fields for separately perform a logical AND of the Capabilities bits fields for
the CP and the UP. the CP and the UP.
INTERNET-DRAFT Simple BNG CUSP
If the result of the AND of the Sub-Versions supported is zero, then If the result of the AND of the Sub-Versions supported is zero, then
no session can be established and the connection is torn down. If no session can be established and the connection is torn down. If the
the result of the AND of the Sub-Versions supported is non-zero, then result of the AND of the Sub-Versions supported is non-zero, then the
the session uses the highest Sub-Version supported by both the CP and session uses the highest Sub-Version supported by both the CP and UP.
UP.
For example, if one side supports Sub-Versions 1, 3, 4, and 5 For example, if one side supports Sub-Versions 1, 3, 4, and 5
(VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4
(VerSupported = 0x38000000) then 3 and 4 are the Sub-Versions in (VerSupported = 0x38000000) then 3 and 4 are the Sub-Versions in
common and 4 is the highest Sub-Version supported by both sides. So common and 4 is the highest Sub-Version supported by both sides. So
Sub-Version 4 is used for the session that has been negotiated. Sub-Version 4 is used for the session that has been negotiated.
The result of the logical AND of the Capabilities bits will show what The result of the logical AND of the Capabilities bits will show what
additional capabilities both sides support. If this result is zero, additional capabilities both sides support. If this result is zero,
there are no such capabilities so none can be used during the there are no such capabilities so none can be used during the
session. If this result is non-zero, it shows the additional session. If this result is non-zero, it shows the additional
capabilities that can be used during the session. The CP and the UP capabilities that can be used during the session. The CP and the UP
must not use a capability unless both advertise support. MUST NOT use a capability unless both advertise support.
7.5. The Keep Alive TLV 7.5. The Keep Alive TLV
The Keep Alive TLV is defined to be carried in the Hello message. It The Keep Alive TLV is defined to be carried in the Hello message. It
provides timing information for the keep alive feature. The format provides timing information for the keep alive feature. The format
of Hello TLV is as follows: of Hello TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive | DeadTimer | Reserved | | Keepalive | DeadTimer | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.5: Keep Alive TLV Figure 40: Keep Alive TLV
Where: Where:
The TLV type: 102. The TLV type: 102.
The value of length: 4 octets. The value of length: 4 octets.
Keepalive, 8 bits in length. Indicates the maximum period of time Keepalive (8 bits): Indicates the maximum period of time (in
(in seconds) between two consecutive S-CUSP messages sent by the seconds) between two consecutive S-CUSP messages sent by the
sender of the message containing this TLV as an unsigned integer. sender of the message containing this TLV as an unsigned integer.
The minimum value for the Keepalive is 1 second. When set to 0, The minimum value for the Keepalive is 1 second. When set to 0,
once the session is established, no further Keepalive messages are once the session is established, no further Keepalive messages are
sent to the remote peer. A recommended value for the Keepalive sent to the remote peer. A RECOMMENDED value for the Keepalive
frequency is 30 seconds. frequency is 30 seconds.
DeadTimer, 8 bits in length. Specifies the amount of time as an DeadTimer (8 bits in length): Specifies the amount of time as an
unsigned integer number of seconds after the expiration of which unsigned integer number of seconds after the expiration of which
INTERNET-DRAFT Simple BNG CUSP
the S-CUSP peer can declare the session with the sender of the the S-CUSP peer can declare the session with the sender of the
Hello message to be down if no S-CUSP message has been received. Hello message to be down if no S-CUSP message has been received.
The DeadTimer shouldbe set to 0 and must be ignored if the The DeadTimer SHOULD be set to 0 and MUST be ignored if the
Keepalive is set to 0. A recommended value for the DeadTimer is 4 Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4
times the value of the Keepalive. times the value of the Keepalive.
The Reserved bits MUST be sent as zero and ignored on receipt.
7.6. The Error Information TLV 7.6. The Error Information TLV
The Error Information TLV is a common TLV that can be used in many The Error Information TLV is a common TLV that can be used in many
Response (e.g., Update_Response message) and ACK messages (e.g., Response (e.g., Update_Response message) and ACK messages (e.g.,
Addr_Allocation_Ack message, etc.). It is used to convey the Addr_Allocation_Ack message, etc.). It is used to convey the
information about an error in the received S-CUSP message. The information about an error in the received S-CUSP message. The
format of the Error Information TLV is as follows: format of the Error Information TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reserved | TLV Type | | Message-Type | Reserved | TLV-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.6: Error Information TLV Figure 41: Error Information TLV
Where: Where:
The TLV type: 101. The TLV type: 101.
The value of length: 8 octets. The value of length: 8 octets.
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): If the error was inside a TLV, this the TLV- TLV-Type (2 bytes): Indicates which TLV caused the error.
Type of that TLV.
Status Code: 4 bytes in length. Indicate the specific Error Code Error Code: 4 bytes in length. Indicate the specific Error Code
(see Section 11.2.5). (see Section 9.5).
7.7. BAS Function Enabler TLV 7.7. BAS Function Enabler TLV
The BAS Function Enabler TLV is used by a CP to control the access The BAS Function Enabler TLV is used by a CP to control the access
mode, authentication methods, and other related functions of an mode, authentication methods, and other related functions of an
INTERNET-DRAFT Simple BNG CUSP
interface on a UP. interface on a UP.
The format of the BAS Function Enabler TLV value part is as follows: The format of the BAS Function Enabler 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 7.7: BAS Function Enabler TLV Figure 42: BAS Function Enabler 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 77, line 18 skipping to change at page 79, line 38
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.
Access-Mode: 1 byte in length, indicates the access mode of the Access-Mode: 1 byte in length, indicates the access mode of the
interface. This document defines following values: interface. This document defines following values:
0: Layer 2 subscriber; 0: Layer 2 subscriber;
1: Layer 3 subscriber; 1: Layer 3 subscriber;
2: Layer 2 leased line; 2: Layer 2 leased line;
3: Layer 3 leased line; 3: Layer 3 leased line;
4-255: Reserved. 4-255: Reserved.
Auth-Method4: 1 byte in length, for IPv4 scenario, it indicates Auth-Method4: 1 byte in length, for IPv4 scenario, it indicates
the authentication on this interface; this field is defined as a the authentication on this interface; this field is defined as a
bitmap, this document defines following values (other bits are bitmap, this document defines following values (other bits are
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.
Auth-Method6: 1 byte in length, for IPv6 scenario, it indicates Auth-Method6: 1 byte in length, for IPv6 scenario, it indicates
the authentication on this interface; this field is defined as a the authentication on this interface; this field is defined as a
bitmap, this document defines following values (other bits are bitmap, this document defines following values (other bits are
reserved and must be sent as zero and ignored on receipt):
0x1: PPPoE authentication; INTERNET-DRAFT Simple BNG CUSP
0x2: DOT1X authentication; reserved and MUST be sent as zero and ignored on receipt):
0x1: PPPoE authentication;
0x2: DOT1X authentication;
0x4: Web authentication; 0x4: Web authentication;
0x8: Web fast authentication; 0x8: Web fast authentication;
0x10: Binding authentication; 0x10: Binding authentication;
The flags field is defined as follows: sub-TLVs: The IF-Desc sub-TLV can be carried.
If-Desc sub-TLV: carries the interface information.
0 1 2 3 The flags field is defined as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.7.1: Interface Flags 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Figure 43: Interface Flags
F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a Where:
subscriber go to online. 1: enabled, 0: disabled.
S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a F (IPv4 Trigger) bit: Indicates whether IPv4 packets can
subscriber go to online. 1: enabled, 0: disabled. trigger a subscriber to go online. 1: enabled, 0: disabled.
A (ARP Trigger) bit: Indicates whether ARP packets can trigger a S (IPv6 Trigger) bit: Indicates whether IPv6 packets can
subscriber go to online. 1: enabled, 0: disabled. trigger a subscriber to go online. 1: enabled, 0: disabled.
N (ND Trigger) bit: Indicates whether ND packets can trigger a A (ARP Trigger) bit: Indicates whether ARP packets can trigger
subscriber go to online. 1: enabled, 0: disabled. a subscriber to go online. 1: enabled, 0: disabled.
I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable N (ND Trigger) bit: Indicates whether ND packets can trigger a
traffic detection. 0: Disable traffic detection. subscriber to go online. 1: enabled, 0: disabled.
P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable I (IPoE-Flow-Check): Used for UP detection. IPoE 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 and P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable
can process ARP requests across different Port+VLANs. 0: The ARP traffic detection. 0: Disable traffic detection.
proxy is not enabled on the interface, and only the ARP requests
of the same Port+VLAN are processed.
Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy
can process ND requests across different Port+VLANs. 0: The ND and can process ARP requests across different Port+VLANs. 0:
proxy is not enabled on the interface, and only the ND requests of The ARP proxy is not enabled on the interface, and only the ARP
the same Port+VLAN are processed. MBZ: Reserved bits that must be requests of the same Port+VLAN are processed.
sent as zero and ignored on receipt.
Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and
can process ND requests across different Port+VLANs. 0: The ND
proxy is not enabled on the interface, and only the ND requests
of the same Port+VLAN are processed.
INTERNET-DRAFT Simple BNG CUSP
MBZ: Reserved bits that MUST be sent as zero and ignored on
receipt.
7.8. Routing TLVs 7.8. Routing TLVs
Normally, after an S-CUSP session established between a UP and CP, Normally, after an S-CUSP session is established between a UP and a
the CP will allocate one or more blocks of IP addresses to the UP. CP, the CP will allocate one or more blocks of IP addresses to the
Those IP addresses will be allocated to subscribers who will dial-up UP. Those IP addresses will be allocated to subscribers who will
to the UP. In order to make sure that other nodes within the network dial-up to the UP. In order to make sure that other nodes within the
learn how to reach those IP addresses, the CP needs to install one or network learn how to reach those IP addresses, the CP needs to
more routes that can reach those IP addresses on the UP and notify install one or more routes that can reach those IP addresses on the
the UP to advertise the routes to the network. UP and notify the UP to advertise the routes to the network.
The Routing TLVs are used by a CP to notify a UP of the network 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
Data_Sycn 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.
The format of this TLV is as follows: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index | | Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost | | Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A| | Route Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.8.1: 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. Carry 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.
Dest-Address: IPv4 type. Identify the destination address. Dest-Address (IPv4-Address type): Identifies the destination
address.
Next-Hop: IPv4 type. Identify the next hop address. Next-Hop: (IPv4-Address type): Identifies the next hop address.
Out-If-Index: 4 bytes in length. Indicates the interface index. Out-If-Index (4 bytes): Indicates the interface index.
Cost: 4 bytes in length. The cost value of the route. Cost (4 bytes): The cost value of the route.
Tag: 4 bytes in length. The tag value of the route. Tag (4 bytes): The tag value of the route.
Route-Type: 2 bytes in length. Indicate the route type. The Route-Type (2 bytes): Indicates the route type. The options are
options are as follows: as follows:
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,
1: advertised. 1: advertised.
sub-TLVs: VRF-Name Sub-TLV can be carried. sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried.
VRF-Name sub-TLV: indicates which VRF the route belongs to.
If-Desc sub-TLV: carries the interface information.
The Reserved field must be sent as zero and ignored on receipt. 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 the this TLV is as follows: The format of this TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.8.2: IPv6 Routing TLV 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 45: IPv6 Routing TLV
Where: Where:
The TLV Type: 7 The TLV Type: 7
The TLV Length: Variable The TLV Length: Variable
User-ID: 4 bytes in length. Carry 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 type. Identify the destination address. IPv6 Dest-Address (IPv6-Address type): Identifies the destination
address.
IPv6 Next-Hop: IPv6 type. Identify the next hop address. IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop
address.
Out-If-Index: 4 bytes in length. Indicates the interface index. Out-If-Index (4 bytes): Indicates the interface index.
Cost: 4 bytes in length. The cost value of the route. Cost (4 bytes): The cost value of the route.
Tag: 4 bytes in length. The tag value of the route. Tag (4 bytes): The tag value of the route.
Route-Type: 2 bytes in length. Indicate the route type. The Route-Type: (2 bytes): Indicates the route type. The options are
options are as follows: as follows:
0: User host route INTERNET-DRAFT Simple BNG CUSP
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,
1: advertised. 1: advertised.
VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried.
VRF-Name sub-TLV: Indicates the VRF to which the subscriber
belongs.
If-Desc sub TLV: carries the interface information.
The Reserved field must be sent as zero and ignored on receipt. 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
information about a user to a UP.
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 a 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Oper ID | Reserved | | User MAC | Oper ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Type |Sub-access Type| Account Type | Address Family| | Access Type |Sub-access Type| Account Type | Address Family|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect Times | Detect Interval | | Detect Times | Detect Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.1: Basic Subscriber TLV Figure 46: Basic Subscriber TLV
Where: Where:
The TLV Type: 2 The TLV Type: 2.
The TLV Length: variable in length; The TLV Length: variable in length.
User-ID (4 bytes): The identifier of a subscriber. User-ID (4 bytes): The identifier of a subscriber.
User-Mac (MAC-Addr): The MAC Address of a subscriber. Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero
means non-PPPoE subscriber.
User-Mac (MAC-Addr type): The MAC Address of a subscriber.
Oper-ID (1 byte): Indicates the ID of an operation performed by a 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.
Session-ID (4 bytes): Session ID of a PPPoE subscriber. Zero Reserved (1 byte): MUST be sent as zero and ignored on receipt.
means non-PPPoE subscriber.
Access-Type (1 byte): Access-Type (1 byte):
1: PPP access (PPP) 1: PPP access (PPP)
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)
4: PPP over Ethernet access (PPPoE) 4: PPP over Ethernet access (PPPoE)
5: PPPoE over VLAN access (PPPoEoVLAN) 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)
15: L2TP LAC tunnel access (L2TP_LAC) 15: L2TP LAC tunnel access (L2TP_LAC)
16: L2TP LNS tunnel access (L2TP_LNS) 16: L2TP LNS tunnel access (L2TP_LNS)
Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP
relay is used. relay is used.
0: Reserved 0: Reserved
1: PPP Relay (for LAC) 1: PPP Relay (for LAC)
2: PPP termination (for LNS) 2: PPP termination (for LNS)
Account-Type(1 byte): Account-Type(1 byte):
0: Collects statistics on IPv4 and IPv6 traffic of terminals 0: Collects statistics on IPv4 and IPv6 traffic of terminals
independently. independently.
1: Collects statistics on IPv4 and IPv6 traffic of terminals. 1: Collects statistics on IPv4 and IPv6 traffic of terminals.
Address Family (1 byte) Address Family (1 byte)
1: IPv4 1: IPv4
2: IPv6 2: IPv6
3: dual stack 3: dual stack
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. The default value of PRI indicates that the VLAN ID is invalid. The default value of PRI
is 7, the value of DEI is 0, and the value of VID is 1~4094. The is 7, the value of DEI is 0, and the value of VID is 1~4094. The
PRI value can also be obtained by parsing terminal packets. PRI value can also be obtained by parsing terminal packets.
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
skipping to change at page 85, line 13 skipping to change at page 86, line 44
2: IPv6 2: IPv6
3: dual stack 3: dual stack
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. The default value of PRI indicates that the VLAN ID is invalid. The default value of PRI
is 7, the value of DEI is 0, and the value of VID is 1~4094. The is 7, the value of DEI is 0, and the value of VID is 1~4094. The
PRI value can also be obtained by parsing terminal packets. PRI value can also be obtained by parsing terminal packets.
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 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.
If-Index (4 bytes): Interface index. If-Index (4 bytes): Interface index.
The Reserved field must be sent as zero and ignored on receipt. Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried.
VRF-Name sub-TLV: Indicates the VRF to which the subscriber
belongs.
If-Desc sub-TLV: carries the interface information.
INTERNET-DRAFT Simple BNG CUSP
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 a 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:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSS | Reserved |M| | MSS | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | Reserved | | MRU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Number | | Magic Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Magic Number | | Peer Magic Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.2: PPP Subscriber TLV Figure 47: PPP Subscriber TLV
Where: Where:
The TLV type: 3. The TLV type: 3.
The TLV length: 12 octets. The TLV length: 12 octets.
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. MSS-Value (2 bytes): Indicates the MSS value (in bytes).
MSS-Enable(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. MRU (2 bytes): PPPoE local MRU (in bytes).
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 a UPdate_Request message when for a BNG user. It will be carried in an Update_Request message when
IPv4 IPoE, PPPoE access are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User IPv4 Address | | User IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway IPv4 Address | | Gateway IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P| | MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name sub-TLV ~ ~ VRF-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.3: IPv4 Subscriber TLV Figure 48: IPv4 Subscriber TLV
Where: Where:
The TLV type: 4. The TLV type: 4.
The TLV length: variable. The TLV length: variable.
User-ID (4 bytes): The identifier of a subscriber. User-ID (4 bytes): The identifier of a subscriber.
User-IPv4 (IPv4-Address): The IPv4 address of the subscriber. User-IPv4 (IPv4-Address): The IPv4 address of the subscriber.
skipping to change at page 87, line 28 skipping to change at page 89, line 5
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.
The Reserved field must be sent as zero and ignored on receipt. INTERNET-DRAFT Simple BNG CUSP
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 a UPdate_Request message when for a BNG user. It will be carried in an Update_Request message when
IPv6 IPoE, PPPoE access are 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:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User ID | | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User PD-Addresses (IPv6 Address List sub-TLV) ~ ~ User PD-Address (IPv6 Address List sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway ND-Addresses (IPv6 Address List sub-TLV) ~ ~ Gateway ND-Address (IPv6 Address List sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User IANA Address | | User IANA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 ~ ~ VRF Name sub-TLV (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.4: IPv6 Subscriber TLV Figure 749: IPv6 Subscriber TLV
Where: Where:
The TLV type: 5. The TLV type: 5.
The TLV length: variable. The TLV length: variable.
User-ID (4 bytes): The identifier of a subscriber. User-ID (4 bytes): The identifier of a subscriber.
User PD-Addresses (IPv6 Address List): Carry 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): Carry 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:
off; 1: on. off; 1: on.
MTU (2 bytes): The MTU value. The default value is 1500. MTU (2 bytes): The MTU value. The default value is 1500.
VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. VRF-Name Sub-TLV: Indicates the VRF to which the subscriber
belongs.
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 TLV 7.9.5. IPv4 Static Subscriber Detect TLV
The IPv4 Static Subscriber TLV is defined to carry IPv4 related The IPv4 Static Subscriber Detect TLV is defined to carry IPv4
information for a static access BNG user. It will be carried in a related information for a static access subscriber. It will be
UPdate_Request message when IPv4 static access is used. carried in an Update_Request message when IPv4 static access on a UP
needs to be enabled.
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Address | | User Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Address | | Gateway Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Reserved | | User MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name sub-TLV ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.5: IPv4 Static Subscriber TLV Figure 750: 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.
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. Valid values are 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 of the C-VID. Valid values are 1~4094. For a single-layer that of the C-VID. A valid value is 1~4094. For a single-layer
VLAN, set this parameter to PeVid. VLAN, set this parameter to PeVid.
User Address (IPv4-Addr): The user's IPv4 address. User Address (IPv4-Addr): The user's IPv4 address.
Gateway Address (IPv4-Addr): The gateway's IPv4 Address. Gateway Address (IPv4-Addr): The gateway's IPv4 Address.
User-MAC (MAC-Addr): The MAC address of the subscriber. User-MAC (MAC-Addr type): The MAC address of the subscriber.
VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried.
VRF-Name sub-TLV: Indicates the VEF to which the subscriber
belongs.
If-Desc sub-TLV: Carries the interface information.
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 TLV 7.9.6. IPv6 Static Subscriber Detect TLV
The IPv6 Static Subscriber TLV is defined to carry IPv6 related The IPv6 Static Subscriber Detect TLV is defined to carry IPv6
information for a static access BNG subscriber. It will be carried related information for a static access subscriber. It will be
in a UPdate_Request message when IPv6 static access is used. carried in an Update_Request message when needed to enable IPv6
static subscriber detection on a UP.
INTERNET-DRAFT Simple BNG CUSP
The format of the TLV value part is as follows: The format of the TLV value part is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Address ~ ~ User Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway Address ~ ~ Gateway Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Reserved | | User MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name sub-TLV ~ ~ sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.6: Static IPv6 Subscriber TLV Figure 51: IPv6 Static Subscriber Detect TLV
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.
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. Valid values are 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 of the C-VID. Valid values are 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.
User Address (IPv6-Addr): The subscriber's IPv6 address. User Address (IPv6-Address type): The subscriber's IPv6 address.
Gateway Address (IPv6-Addr): The gateway's IPv6 Address. Gateway Address (IPv6-Address type): The gateway's IPv6 Address.
User-MAC (MAC-Addr): The MAC address of the subscriber. User-MAC (MAC-Addr type): The MAC address of the subscriber.
VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF. sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried
VRF-Name Sub-TLV: Indicates the VRF to which the subscriber
belongs.
If-Desc sub-TLV: Carries the interface information.
The Reserved field must be sent as zero and ignored on receipt. INTERNET-DRAFT Simple BNG CUSP
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
a 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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.7: L2TP-LAC Subscriber TLV Figure 52: L2TP-LAC Subscriber TLV
Where: Where:
The TLV type: 11. The TLV type: 11.
The TLV length: 12 octets. The TLV length: 12 octets.
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.
skipping to change at page 92, line 17 skipping to change at page 93, line 49
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.
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-LAC 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
a 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.8: L2TP-LAC Subscriber Information TLV Figure 53: L2TP-LNS Subscriber TLV
Where: Where:
The TLV type: 12. The TLV type: 12.
The TLV length: 12 octets. The TLV length: 12 octets.
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.
skipping to change at page 93, line 13 skipping to change at page 95, line 5
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: The format of the TLV value part is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Destination Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLV (VRF Name sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.9: L2TP-LAC Tunnel TLV 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Destination Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 54: L2TP-LAC Tunnel TLV
Where:
The TLV type: 13. The TLV type: 13.
The TLV length: variable. The TLV length: variable.
Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel. Local-Tunnel-ID (2 bytes): The local ID of the L2TP 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.
Source-Port (2 bytes): The source UDP port number of an L2TP Source-Port (2 bytes): The source UDP port number of an L2TP
skipping to change at page 94, line 13 skipping to change at page 95, line 54
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Destination Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLV (VRF Name sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7.9.10: L2TP-LAC Tunnel TLV INTERNET-DRAFT Simple BNG CUSP
where: 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