Internet DRAFT - draft-cuspdt-rtgwg-cu-separation-bng-deployment
draft-cuspdt-rtgwg-cu-separation-bng-deployment
INTERNET-DRAFT R. Gu
Intended status: Informational S. Hu
China Mobile
M. Wang
D. Eastlake
Huawei
F. Hu
ZTE
Expires: June 11, 2019 December 12, 2018
Control Plane and User Plane Separated BNG Deployment Model
draft-cuspdt-rtgwg-cu-separation-bng-deployment-02
Abstract
This document describes the deployment model for a Broadband Network
Gateway (BNG) device with Control Plane (CP) and User Plane(UP)
separation. It is intended to give guidance for the deployment of CP
and UP separated BNG devices in an operators' network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors or the BESS working group mailing list: bess@ietf.org.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Gu, et al. [Page 1]
*
INTERNET-DRAFT Separated BNG Deployment Model
Table of Contents
1. Introduction and Overview...............................3
2. Concept and Terminology.................................5
2.1 Terminology............................................5
3. BNG with CP and UP Separation Deployment Model..........6
3.1 CP and UP of BNG Deployment Within One District........6
3.2. CP and UP of BNG Deployment in Multiple Districts.....7
4. The Process of BNG with CUPS in Home Service...........10
5. High Availability Considerations.......................11
6. Security Considerations................................12
7. IANA Considerations....................................12
Normative References......................................13
Informative References....................................13
Authors' Addresses........................................14
<
Gu, et al. [Page 2]
INTERNET-DRAFT Separated BNG Deployment Model
1. Introduction and Overview
A Broadband Network Gateway (BNG) is an Ethernet-centric IP edge
router and acts as the aggregation point for the user traffic with
some additional functions such as address management and cooperating
with AAA (Radius/Diameter) systems and subscriber management. Because
of the rapid development of new services, such as 4K, IoT, etc. and
the increasing numbers of distributed home broadband service users,
high resource utilization, high-efficiency management, and fast
service provisioning are required. This calls for a new BNG
architecture with CP and UP separation, which is also called Cloud
BNG, as proposed in [BBF-CloudCO] [TR-384].
The CP and UP separation architecture of the BNG is composed of a
Control Plane and a User Plane, with the concentrated CP responsible
for control and management of the UP's resources and subscribers'
information, and with the distributed UP taking charge of policy
implementation and traffic forwarding. The obvious advantages of this
new architecture are listed below.
Resource Utilization Improvement: A centralized Control Plane
provides unified management capability for network
resources and users information. The CP has an overview of
all the resources and can distribute resources as specific
users require, thus resources can be totally controlled and
balanced.
Management with High Efficiency: A centralized CP provides a unified
management interface to the outside systems such as EMS,
DHCP Server, AAA Server, etc. In this situation, management
can be easier for the centralized CP as it's the only
device interfacing with the outside systems.
Dynamic and Flexible: The CP can be virtualized as a VNF with MANO
management in an NFVI, while the UP can be a virtual
machine or physical device as needed. A software-oriented
CP can be designed with flexibility. The CP can handle all
the situations dynamically over a wide range from few users
accessing to large numbers of users accessing.
Fast TTM: The CP and UP can be deployed separately with the CP
deployed centrally and the UP deployed in distribution
closer to users. Thus, according to different situations
such as session overload or extremely high throughput, the
CP and UP can be extended separately. This can help shorten
the time to market (TTM).
As noted, the new BNG architecture has CP and UP separation. The CP
and UP are deployed with separation due to practical requirements.
This document gives the CU separation BNG deployment model for actual
Gu, et al. [Page 3]
INTERNET-DRAFT Separated BNG Deployment Model
deployments.
Gu, et al. [Page 4]
INTERNET-DRAFT Separated BNG Deployment Model
2. Concept and Terminology
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.1 Terminology
BNG: Broadband Network Gateway. A broadband remote access server
(BRAS, B-RAS or BBRAS) routes traffic to and from broadband
remote access devices such as digital subscriber line access
multiplexers (DSLAM) on an Internet service provider's (ISP)
network. BRAS can also be referred to as a Broadband Network
Gateway (BNG).
CP: Control Plane. The CP is a user control management component
which manages UP's resources such as the user entry and user's
QoS policy
CUPS: Control/User Plane Separation
UP: User Plane. The UP is a network edge and user policy
implementation component. The traditional router's Control Plane
and forwarding plane are both preserved on BNG devices in the
form of a user plane.
TTM: Time to Market. It is the length of time it takes from a product
or a service being conceived until it is available for sale.
MANO: Management and Orchestration. Functions are collectively
provided by NFVO, VNFM and VIM.
VNF: Virtual Network Function. Implementation of a Network Function
that can be deployed on a Network Function Virtualization
Infrastructure (NFVI).
PNF: Physical Network Function
DHCP: Dynamic Host Configuration Protocol
PPPoE: Point-to-Point Protocol over Ethernet
IPoE: Internet Protocol over Ethernet
Gu, et al. [Page 5]
INTERNET-DRAFT Separated BNG Deployment Model
3. BNG with CP and UP Separation Deployment Model
3.1 CP and UP of BNG Deployment Within One District
+-------------------+
| |
| Internet |
| |
+---------^---------+
|
+---+---+
| | +------------------------+
| CR | | |
| | | +--------+ |
+---^---+ | +------+ AAA | |
| | | +--------+ |
| | +--+---+ |
+---+---+ | | | +--------+ |
| +---SERVICE----+ | +--+ DHCP | |
| BNG-UP+---CONTROL----+ | BNG | +--------+ |
|VNF/PNF+----MGNT------+ | -CP | |
+---^---+ | | VNF | +--------+ |
| | | +--+ EMS | |
| | | | +--------+ |
+---+---+ | +--+---+ |
| | | | +--------+ |
| OLT | | +------+ MANO | |
| | | +--------+ |
+---^---+ | Management Network |
| +------------------------+
+---+---+
| USER |
+-------+
Figure 1: Cloud BNG Deployed in One District
Take a one district example as in Figure 1. Here BNG-CP and BNG-UP
are separated as deployed. Since the CP is computationally intensive,
a virtualized CP acting as a VNF can meet the requirements of
flexibility and fast calculation. The UP is traffic intensive, which
can be virtualized or stay physical depending on traffic. The
virtualized UP with low expense and high flexibility can be suitable
for light traffic. In high traffic, special hardware is needed with
high traffic forwarding performance.
In order to fulfill the function of a BNG, the BNG-CP needs to
communicate with outside systems such as a AAA (Radius/Diameter)
server and many others in the management network. In addition, the
Gu, et al. [Page 6]
INTERNET-DRAFT Separated BNG Deployment Model
BNG-CP has three interfaces with the BNG-UP separated by their
traffic categories: Service Interface, Control Interface, and
Management Interface.
+-------------------------------------+
| |
| BNG-CP |
| |
+--+--------------+----------------+--+
| | |
1. Service | 2. Control | 3. Management |
Interface | Interface | Interface |
| | |
+--+--------------+----------------+--+
| |
| BNG-UP |
| |
+-------------------------------------+
Figure 2. Internal Interfaces Between the BNG CP and UP
The functions of the three interfaces are as follows:
Service Interface: The CP and UP use this interface to establish
VXLAN tunnels with each other and transmit PPPoE and IPoE
packets over the VXLAN tunnels for authentication.
Control Interface: The CP uses this interface to deliver service
entries to the UP, and the UP uses this interface to report
service events to the CP.
Management Interface: The CP uses this interface to deliver basic
configurations to the UP. This interface uses NETCONF.
Several related drafts exist describing these interfaces in detail.
The VXLAN-GPE extension draft for C/U separated BNG is related to the
Service Interface [huang-nov3-vxlan-gpe-extension-for-vbng]. The
draft YANG data model for CU separated BNG focuses on Management
Interface, seeing in [cuspdt-rtgwg-cu-separation-yang-model]. Another
two drafts [cuspdt-rtgwg-cusp-requirements] and [cuspdt-rtgwg-cu-
separation-infor-model] are related to the control interface giving
an information model abstraction and suitable protocol.
3.2. CP and UP of BNG Deployment in Multiple Districts
Gu, et al. [Page 7]
INTERNET-DRAFT Separated BNG Deployment Model
+-------------------+
| |
| Internet |
| |
+---------^---------+
| +------+ +----+ +---+ +----+
+---+---+ |Radius| |DHCP| |EMS| |MANO|
| | +---+--+ +--+-+ +-+-+ +-+--+
| | | | | |
+---+ CR +-----+ +---+-------+-----+-----+--+
| | | | | BNG-CP |
| | | | +---.--.------------.------+
| +---^---+ +---------.--.--+ .
| ....|.................... . | .
| . | ............ | .
| . +-------+ . | .........
+-+---.-+ +-+---.-+ +---+-.-+
| | | | | |
| BNG-UP| | BNG-UP| | BNG-UP|
|VNF/PNF| |VNF/PNF| |VNF/PNF|
+---^---+ +---^---+ +---^---+
| | |
| | |
+---+---+ +---+---+ +---+---+
| OLT | | OLT | | OLT |
+---+---+ +---+---+ +---+---+
+-----|-----+ | +-----|-----+
+---+---+ +---+---+ +---+---+ +---+---+ +---+---+
|USER A1| |USER A2| |USER B1| |USER C1| |USER C2|
+-------+ +-------+ +-------+ +-------+ +-------+
Figure 3: Cloud BNG Deployed in Several Districts
If subscribers are distributed in several districts, the CP can be
deployed centrally with the UP deployed in different districts close
to subscribers as shown in Figure 3. Thus the deployment model can be
a bit complex.
Take three districts A, B. and C for example. Here three UPs are
placed with one shared CP. The CP is usually deployed in a Core Data
Center such as in a provincial datacenter with UPs in edge Date
Centers such as city datacenters. In this Data Centers design, we
have core data centers and edge data centers according to their
location and responsibility. Core data centers are often planned in
provinces for control and management, while edge data centers are in
cities or towns for easy service access.
In this scenario, a centralized CP interfaces to the subsystems
outside and communicate with all these UPs for control and
management.
Gu, et al. [Page 8]
INTERNET-DRAFT Separated BNG Deployment Model
Under the CP's control, the corresponding traffic is forwarded by UP
to the Internet.
Gu, et al. [Page 9]
INTERNET-DRAFT Separated BNG Deployment Model
4. The Process of BNG with CUPS in Home Service
Take a user Bob accessing to the Internet using Home Broadband
Service as an example. The process includes the service traffic from
user to the internet and signaling traffic between BNG-UP and BNG-CP.
Below is the whole process.
(1) User Bob dials up with packets of PPPoE or IPoE from BNG-UP which
will be sent to the BNG-CP with the user's information. This is
signaling traffic.
(2) The BNG-CP processes the dialup packets. Confirming with the
outside neighboring systems in the management network, the BNG-CP
makes the decision to permit or deny of the dial access through
certification. In this step, the BNG-CP manages resources and
generates tables with information such as User Info, IP Info, QoS
Info, etc. This is signaling traffic.
(3) The BNG-CP sends tables to the corresponding UP or to one UP it
chooses from the corresponding UPs. This is signaling traffic.
(4) The BNG-UP receives the tables, matches rules and performs
corresponding actions.
(5) If Bob is certificated and permitted, the UP forwards their
traffic into the Internet with related policies such as limited
bandwidth, etc. Otherwise, Bob is denied to access the Internet.
This is service traffic.
From Step 2 to Step 4, the information model defined in
[cuspdt-rtgwg-cu-separation-infor-model] can be used.
Gu, et al. [Page 10]
INTERNET-DRAFT Separated BNG Deployment Model
5. High Availability Considerations
As the BNG-CP takes responsibility for control and management, such
as communicating with outside systems, generating flow tables, and
managing the UP's resources, high availability of this key component
should be considered. Some redundancy should be adopted for
reliability, such as N+N or N+K active standby BNG-CPs. N+N standby
means 1:1 backup for each BNG-CP, which enables easy rapid switch of
any number of BNG-CP to their backup but is expensive because it
requires a large number of backup CPs. N+K means a smaller number of
backup CPs, for example N2:1 backup where N2<N which is less
expensive but does not handle more than 1 failure in the N2 subset of
N BNG-CPs.
Gu, et al. [Page 11]
INTERNET-DRAFT Separated BNG Deployment Model
6. Security Considerations
TBD.
7. IANA Considerations
This document requires no IANA actions.
Gu, et al. [Page 12]
INTERNET-DRAFT Separated BNG Deployment Model
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174> .in -10
Informative References
[hu-nov3-vxlan-gpe-extension-for-vbng] Huang, L., "VXLAN GPE
Extension for Packets Exchange Between Control and User
Plane of vBNG", draft-hu-nvo3-vxlan-gpe-extension-for-vbrg,
work in progress, 2017.
[cuspdt-rtgwg-cu-separation-yang-model] Hu, F., "YANG Data Model for
Configuration Interface of Control-Plane and User-Plane
separation BNG", draft-cuspdt-rtgwg-cu-separation-yang-
model, work in progress, 2018.
[cuspdt-rtgwg-cusp-requirements] Hu, S., "Requirements for Control
Plane and User Plane Separated BNG Protocol", draft-cuspdt-
rtgwg-cusp-requirements, work in progress, 2018.
[cuspdt-rtgwg-cu-separation-infor-model] Wang, Z., "Information Model
of Control-Plane and User- Plane separation BNG", draft-
cuspdt-rtgwg-cu-separation-infor-model, work in progress,
2018.
[TR-384] BroadBand Forum, "Cloud Central Office Reference
Architectural Framework", January 2018.
Gu, et al. [Page 13]
INTERNET-DRAFT Separated BNG Deployment Model
Authors' Addresses
Rong Gu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: gurong_cmcc@outlook.com
Sujun Hu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: shujun_hu@outlook.com
Michael Wang
Huawei Technologies
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangzitao@huawei.com
Donald Eastlake, 3rd
Huawei Technologies
1424 Pro Shop Court
Davenport, FL 33896
USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Fangwei Hu
ZTE Corporation
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Gu, et al. [Page 14]
INTERNET-DRAFT Separated BNG Deployment Model
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Gu, et al. [Page 15]
