rtgwg S. Hu
Internet-Draft China Mobile
Intended status: Informational V. Lopez
Expires: January 3, 2019 Telefonica
F. Qin
Z. Li
China Mobile
T. Chua
Singapore Telecommunications Limited
M. Wang
J. Song
Huawei
July 2, 2018
Requirements for Control Plane and User Plane Separated BNG Protocol
draft-cuspdt-rtgwg-cusp-requirements-02
Abstract
This document introduces the Control Plane and User Plane separated
BNG architecture and defines a set of associated terminology. What's
more, this document focuses on defining a set of protocol
requirements for the BNG-CP and BNG-UPs communication in the Control
Plane and User Plane Separated BNG.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 3, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hu, et al. Expires January 3, 2019 [Page 1]
Internet-Draft Requirements for CUSP July 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. CU Separated BNG Model . . . . . . . . . . . . . . . . . . . 3
3.1. Internal interfaces between the CP and UP . . . . . . . . 5
4. The usage of CU separation BNG protocol . . . . . . . . . . . 6
5. Control Plane and User Plane Separation Protocol Requirements 7
5.1. Transmit information tables . . . . . . . . . . . . . . . 7
5.2. Message Priority . . . . . . . . . . . . . . . . . . . . 7
5.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Support for Secure Communication . . . . . . . . . . . . 8
5.5. Version negotiation . . . . . . . . . . . . . . . . . . . 8
5.6. Capability Exchange . . . . . . . . . . . . . . . . . . . 9
5.7. CP primary/backup capability . . . . . . . . . . . . . . 9
5.8. Event Notification . . . . . . . . . . . . . . . . . . . 9
5.9. Query Statistics . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
BNG is an Ethernet-centric IP edge router, and the aggregation point
for the user traffic. To provide centralized session management,
flexible address allocation, high scalability for subscriber
management capacity, and cost-efficient redundancy, the CU separated
BNG is introduced [TR-384]. The CU separated Service Control Plane
could be virtualized and centralized, which is responsible for user
access authentication and setting forwarding entries to user planes.
The routing control and forwarding plane, i.e. BNG user plane
(local), could be distributed across the infrastructure.
This document introduces the Control Plane and User Plane separated
BNG architecture and modeling. This document also defines the
Hu, et al. Expires January 3, 2019 [Page 2]
Internet-Draft Requirements for CUSP July 2018
protocol requirements for Control Plane and User Plane Separated BNG
(CUSP).
2. Concept and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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 supports to manage UP's resources such as the user entry and
user's QoS policy
UP: User Plane. 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.
3. CU Separated BNG Model
The following figure describes the architecture of CU separated BNG
Hu, et al. Expires January 3, 2019 [Page 3]
Internet-Draft Requirements for CUSP July 2018
+------------------------------------------------------------------+
| Neighboring policy and resource management systems |
| |
| +-------------+ +-----------+ +---------+ +----------+ |
| |Radius Server| |DHCP Server| | EMS | | MANO | |
| +-------------+ +-----------+ +---------+ +----------+ |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| CU-separated BNG system |
| +--------------------------------------------------------------+ |
| | +----------+ +----------+ +------++------++-----------+ | |
| | | Address | |Subscriber| |Radius||PPPoE/|| UP | | |
| | |management| |management| | ||IPoE ||management | | |
| | +----------+ +----------+ +------++------++-----------+ | |
| | CP | |
| +--------------------------------------------------------------+ |
| |
| |
| |
| +---------------------------+ +--------------------------+ |
| | +------------------+ | | +------------------+ | |
| | | Routing control | | | | Routing control | | |
| | +------------------+ | ... | +------------------+ | |
| | +------------------+ | | +------------------+ | |
| | |Forwarding engine | | | |Forwarding engine | | |
| | +------------------+ UP | | +------------------+ UP| |
| +---------------------------+ +--------------------------+ |
+------------------------------------------------------------------+
Architecture of CU Separated BNG
Briefly, a CU separated BNG is made up of a Control Plane (CP) and a
set of User Planes (UPs) [TR-384],
[I-D.cuspdt-rtgwg-cu-separation-bng-deployment]. The Control Plane
is a user control management component which supports to manage UP's
resources such as the user entry and user's QoS policy, for example,
the access bandwidth and priority management. This Control Plane
could be virtualized and centralized. The functional modules inside
the BNG Service Control Plane can be implemented as VNFs and hosted
in a NFVI. The User Plane Management module in the BNG control plane
centrally manages the distributed BNG user planes (e.g. load
balancing), as well as the setup, deletion, update, and maintenance
of channels between control planes and user planes [TR-384],
[I-D.cuspdt-rtgwg-cu-separation-bng-deployment]. And the User Plane
(UP) is a network edge and user policy implementation component. It
can support the forwarding plane functions on traditional BNG
devices, such as traffic forwarding, QoS, and traffic statistics
Hu, et al. Expires January 3, 2019 [Page 4]
Internet-Draft Requirements for CUSP July 2018
collection, and it can also support the control plane functions on
traditional BNG devices, such as routing, multicast, etc [TR-384],
[I-D.cuspdt-rtgwg-cu-separation-bng-deployment].
3.1. Internal interfaces between the CP and UP
To support the communication between the Control Plane and User
Plane, several interfaces are involved. Figure 2 illustrates the
internal interfaces of CU Separated BNG.
+----------------------------------+
| |
| BNG-CP |
| |
+--+--------------+--------------+-+
| | |
1.Service | 2.Control | 3.Management|
Interface | Interface | Interface |
| | |
+--+--------------+--------------+-+
| |
| BNG-UP |
| |
+----------------------------------+
Internal interfaces between the CP and UP of the BNG device
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.
Control interface: The CP uses this interface to deliver service
entries, and the UP uses this interface to report service events to
the CP.
Management interface: The CP uses this interface to deliver
configurations to the UP. This interface runs NETCONF.
The CUSP (Control plane and User plane Separated BNG protocol)
defines the control interface, and specifies the communication
between the centralized control plane and user planes. This protocol
should be designed to support establishing and maintaining a
conversation between CP and UPs, and transporting the tables which
specified in [draft-cuspdt-rtgwg-cu-separation-infor-model].
Hu, et al. Expires January 3, 2019 [Page 5]
Internet-Draft Requirements for CUSP July 2018
4. The usage of CU separation BNG protocol
-----------------
//// \\\\
//// \\\\
// Cloud \\
| |
| |
| |
| |
| +-----------------+ |
| | Control Plane | |
\\ | | //
\\\\ +------+----------+ ////
\\\\ | ////
----+------------
| Control Interface (CUSP)
+--------+----------+-------------+-----+
| | | |
User's information IP address QoS: .......
May Including: | CIR; :
User ID; | PIR; |
User MAC; | CBS; |
Access method(PPPoE, | PBS; |
IPoE, etc) | ......
..... | | |
+-------------------V--------------+
|
+-----------+
| -------
| /// \\\
+------+ +-------v---------+ +--------+ | |
| OLT | | User Plane | | Core | | Internet |
| +-------+ +-------+ Routing+-----+ |
+------+ +-----------------+ +--------+ \\\ ///
-------
CU Separation BNG protocol usage
As shown in above figure, when users access to the BNG network, the
control plane solicits these users' information (such as user's ID,
user's MAC, user's access methods, for example via PPPoE/IPoE),
associates them with available bandwidth which are reported by User
planes, and based on the service's requirement to generate a set of
tables, which may include user's information, UP's IP segment, and
QoS, etc. Then the control plane can transmit these tables to the
Hu, et al. Expires January 3, 2019 [Page 6]
Internet-Draft Requirements for CUSP July 2018
User planes. User planes receive these tables, parse them, match
these rules, and then perform corresponding actions.
5. Control Plane and User Plane Separation Protocol Requirements
This section specifies some of the requirements that the CU
separation protocol SHOULD support.
5.1. Transmit information tables
The Control Plane and User Plane Separation Protocol MUST allow the
CP to send tables to each User Plane device.
a) The current BNG service requires that the UP should support at
least 2000 users being accessed every second. And every user
requires at least 2000 bytes. To achieve high performance, the CU
Separation protocol SHOULD be lightweight.
b) CU separation protocol should support XML/binary data which
serves as the encoding format. It allows user information data to
be read, saved, and manipulated with tools specific to XML/binary.
c) In order to provide centralized session management, high
scalability for subscriber management capacity, and cost-efficient
redundancy, batching ability should be involved. The CU
Separation protocol should be able to group an ordered set of
commands to a UP device. Each such group of commands SHOULD be
sent to the UP in as few messages as possible. Furthermore, the
protocol MUST support the ability to specify if a command group
MUST have all-or-nothing semantics.
d) The CU Separation protocol SHOULD be able to support at least
hundreds of UP devices and tens of thousands of ports. For
example, the protocol field sizes corresponding to UP or port
numbers SHALL be large enough to support the minimum required
numbers. This requirement does not relate to the performance of
the system as the number of UPs or ports in the system grows.
5.2. Message Priority
The CU Separation protocol MUST provide a means to express the
protocol message priorities.
5.3. Reliability
Heartbeat is a periodic signal generated by hardware or software to
indicate normal operation or to synchronize other parts of network
system.
Hu, et al. Expires January 3, 2019 [Page 7]
Internet-Draft Requirements for CUSP July 2018
In CU separation BNG, the heartbeat is sent between CP and UPs at a
regular interval in the order of seconds. If the CP/UP does not
receive a heartbeat for a time--usually a few heartbeat intervals--
the CP/UP that should have sent the heartbeat is assumed to have
failed.
The CU separation protocol should support some kind of heartbeat
monitor mechanism. And this mechanism should have ability to
distinguish whether the interruption is an actual failure. For
example, in some scenarios (i.e. CP/UP update, etc), the connection
between the UP and CP need to be interrupted. In this case, the
interruption should not be reported.
5.4. Support for Secure Communication
As mentioned above, CP may send some information tables to the UP
which may be critical to the network function (e.g, User Information,
IPv4/IPv6 information) and may reflect the business information (e.g,
QoS, service level agreements, etc). Therefore, it MUST be supported
to ensure the integrity of all CU Separation protocol messages and
protect against man-in-the-middle attacks.
And the CP Separation protocol should support multiple security
mechanisms to satisfy various scenarios. For example, when the
special lines are implemented between the CP and UPs, the key chain
SHOULD be supported. And if some VPNs are deployed between the CP
and UPS, the TLS SHOULD be supported. In case of the CP and UPs
cross several domains (i.e. cross third-party network), the IPsec
SHOULD be supported.
5.5. Version negotiation
The CU separated BNG may consist of different vendors' devices.
Since different vendors' device may implement different versions of
protocol, therefore, the CU separation protocol should provide some
mechanisms to perform the version negotiation.
The version negotiation is the process that the CU separated BNG's
Control-Plane uses to evaluate the protocol versions supported by
both the control-plane and the user-plane devices. Then a suitable
protocol version is selected for communication in CUSP. The process
is a "negotiation" because it requires identifying the most recent
protocol version that is supported by both the control-plane and the
user-plane devices.
Hu, et al. Expires January 3, 2019 [Page 8]
Internet-Draft Requirements for CUSP July 2018
5.6. Capability Exchange
The UP Capability Report displays the devices profile, service
capability, and other assigned capabilities within the CU separated
BNG. The CU separation protocol should provide some mechanism to
exchange the UP device's capability
5.7. CP primary/backup capability
A backup CP for disaster recovery is required for the CU separated
BNG network. And the CUSP should provide some mechanism to implement
the backup CP:
a) In some scenarios, there may be two CP devices both declaring
the primary CP. Thus the CUSP should support or associate with
some mechanisms to determine which CP is the primary device.
b) In the scenario of the primary CP down, the CUSP should support
switching between primary and backup CP.
5.8. Event Notification
The CUSP protocol SHOULD be able to asynchronously notify the CP of
events on the UP such as failures and changes in available resources
and capabilities. Some scenarios which may initiate the event
notification list as follows.
a) Sending response message: As mentioned above, the control plane
solicits users' information, associates them with available
bandwidth, and generates a set of tables based on the service's
requirement. Then the control plane transmits these tables to the
conresponding User plane. The UP should respond with an event
notification to inform the CP that the tables are received.
b) User trace: The user trace mechanism can support the Control
Plane to trace and monitor the network status for users (for
example the real-time bandwidth, etc) , debug the user's
application. Therefore, the UPs SHOULD be able to notify the CP
with the User trace message.
c) Sending statistics parameters: In CU separation BNG, the User-
plane will report the traffic statistics parameters to the
Control-plane, such as the ingress packets, ingress bytes, egress
packets, egress bytes, etc. These parameters can help to measure
the BNG network performance. Available network resources can be
allocated basing on the statistics parameters by the BNG-CP.
Therefore, the UPs SHOULD be able to notify the CP with statistics
parameters.
Hu, et al. Expires January 3, 2019 [Page 9]
Internet-Draft Requirements for CUSP July 2018
d) Report the result of User Detect: "User Detect" message will be
send periodically to detect user dial-up and disconnect. The UPs
SHOULD be able to notify the CP with the result of User Detect.
5.9. Query Statistics
The CUSP protocol MUST provide a means for the CP to be able to query
statistics (performance monitoring) from the UP.
6. Security Considerations
None.
7. IANA Considerations
None.
8. Normative References
[I-D.cuspdt-rtgwg-cu-separation-bng-deployment]
Gu, R., Hu, S., and Z. Wang, "Deployment Model of Control
Plane and User Plane Separation BNG", draft-cuspdt-rtgwg-
cu-separation-bng-deployment-00 (work in progress),
October 2017.
[I-D.cuspdt-rtgwg-cu-separation-infor-model]
Wang, Z., Gu, R., Lopezalvarez, V., and S. Hu,
"Information Model of Control-Plane and User-Plane
separation BNG", draft-cuspdt-rtgwg-cu-separation-infor-
model-00 (work in progress), February 2018.
[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>.
Authors' Addresses
Shujun Hu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: shujun_hu@outlook.com
Hu, et al. Expires January 3, 2019 [Page 10]
Internet-Draft Requirements for CUSP July 2018
Victor Lopez
Telefonica
Sur 3 building, 3rd floor, Ronda de la Comunicacion s/n
Madrid 28050
Spain
Email: victor.lopezalvarez@telefonica.com
Fengwei Qin
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: qinfengwei@chinamobile.com
Zhenqiang Li
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: lizhenqiang@chinamobile.com
Tee Mong Chua
Singapore Telecommunications Limited
31 Exeter Road, #05-04 Comcentre Podium Block
Singapore City 239732
Singapore
Email: teemong@singtel.com
Michael Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangzitao@huawei.com
Hu, et al. Expires January 3, 2019 [Page 11]
Internet-Draft Requirements for CUSP July 2018
Jun Song
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: song.jun@huawei.com
Hu, et al. Expires January 3, 2019 [Page 12]