Internet DRAFT - draft-wcg-i2rs-cu-separation-infor-model
draft-wcg-i2rs-cu-separation-infor-model
i2rs M. Wang, Ed.
Internet-Draft Huawei
Intended status: Informational R. Gu
Expires: May 2, 2018 China Mobile
Victor. Lopez
Telefonica
S. Hu
China Mobile
October 29, 2017
Information Model of Control-Plane and User-Plane separation BNG
draft-wcg-i2rs-cu-separation-infor-model-02
Abstract
To improve network resource utilization and reduce the operation
expense, the Control-Plane and User-Plane separation conception is
raised [I-D.gu-nfvrg-cloud-bng-architecture]. This document
describes the information model for the interface between Control-
Plane and User-Plane separation BNG. This information model may
involve both control channel interface and configuration channel
interface. The interface for control channel allows the Control-
Plane to send several flow tables to the User-Plane, such as user's
information table, user's interface table, and user's QoS table, etc.
And it also allows the User-Plane to report the resources and
statistics information to the Control-Plane. The interface for
configuration channel is in charge of the version negotiation of
protocols between the Control-Plane and User-Plane, the configuration
for devices of Control-Plane and User-Plane, and the reports of User-
Plane's capabilities, etc. The information model defined in this
document enables defining a standardized data model. Such a data
model can be used to define an interface to the CU separation 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."
Wang, et al. Expires May 2, 2018 [Page 1]
Internet-Draft Infor Model for CU separation October 2017
This Internet-Draft will expire on May 2, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Control Plane and User Plane separation BNG Information Model
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Service Data Model Usage . . . . . . . . . . . . . . . . 6
4. Information Model . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Information Model for Control-Plane . . . . . . . . . . . 9
4.1.1. User-Related Information . . . . . . . . . . . . . . 11
4.1.1.1. User Basic Information Model . . . . . . . . . . 11
4.1.1.2. IPv4 Information Model . . . . . . . . . . . . . 12
4.1.1.3. IPv6 Information Model . . . . . . . . . . . . . 13
4.1.1.4. QoS Information Model . . . . . . . . . . . . . . 14
4.1.2. Interface Related Information . . . . . . . . . . . 15
4.1.2.1. Interface Information Model . . . . . . . . . . . 15
4.1.3. Device Related Information . . . . . . . . . . . . . 16
4.1.3.1. Address field distribute Table . . . . . . . . . 17
4.2. Information Model for User Plane . . . . . . . . . . . . 17
4.2.1. Port Resources of UP . . . . . . . . . . . . . . . . 18
4.2.2. Traffic Statistics Infor . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Normative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Wang, et al. Expires May 2, 2018 [Page 2]
Internet-Draft Infor Model for CU separation October 2017
1. Introduction
The rapid development of new services, such as 4K, IoT, etc, and
increasing numbers of home broadband service users present some new
challenges for BNGs such as:
Low resource utilization: The traditional BNG acts as both a
gateway for user access authentication and accounting and an IP
network's Layer 3 edge. The mutually affecting nature of the
tightly coupled control plane and forwarding plane makes it
difficult to achieve the maximum performance of either plane.
Complex management and maintenance: Due to the large numbers of
traditional BNGs, a network must have each device configured one
at a time when deploying global service policies. As the network
expands and new services are introduced, this deployment mode will
cease to be feasible as it is unable to manage services
effectively and rectify faults rapidly.
Slow service provisioning: The coupling of control plane and
forwarding plane, in addition to a distributed network control
mechanism, means that any new technology has to rely heavily on
the existing network devices.
To address these challenges, cloud-based BNG with CU separation
conception is raised [I-D.gu-nfvrg-cloud-bng-architecture]. The main
idea of Control-Plane and User-Plane separation method is to extract
and centralize the user management functions of multiple BNG devices,
forming an unified and centralized control plane (CP). And the
traditional router's Control Plane and Forwarding Plane are both
preserved on BNG devices in the form of a user plane (UP).
This document describes an information model for the interface
between Control-Plane and User-Plane separation BNG. This
information model may involve both control channel interface and
configuration channel interface. The interface for control channel
allows the Control-Plane to send several flow tables to the User-
Plane, such as user's information table, user's interface table, and
user's QoS table, etc. And it also allows User-Plane to report the
resources and statistics information to the Control-Plane. The
interface for configuration channel is in charge of the version
negotiation of protocols between the Control-Plane and User-Plane,
the configuration for the devices of Control-Plane and User-Plane,
and the report of User-Plane's capabilities, etc. The information
model defined in this document enables defining a standardized data
model. Such a data model can be used to define an interface to the
CU separation BNG.
Wang, et al. Expires May 2, 2018 [Page 3]
Internet-Draft Infor Model for CU separation October 2017
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. CP is a user control management component which
supports the management of UP's resources such as the user entry and
forwarding 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. Control Plane and User Plane separation BNG Information Model
Overview
Briefly, a CU separation BNG is made up of a centralized CP and a set
of UPs. The CP is a user control management component which supports
to manage UP's resources such as the user entry and forwarding
policy, for example, the access bandwidth and priority management.
And the 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 collection, and it can also support the control plane
functions on traditional BNG devices, such as routing, multicast,
etc.
The following figure describes the architecture of CU separation BNG
Wang, et al. Expires May 2, 2018 [Page 4]
Internet-Draft Infor Model for CU separation October 2017
+-----+ +-----+ +-----+ +-----+
|EMS | |DHCP | |AAA | |policy
| | |server |server |server
+----|+ +---|-+ +--|--+ +--|--+
| | | |
| | | |
| | | |
| | | |
+----|---------|---------|---------|----+
| +--|----+ +--|--+ +---|--+ +----|--+ |
| |address| | sub | | AAA | |service| |
| |mgt | | Mgt | | | |control| |
| +-------+ +-----+ +------+ +-------+ |
| | Control Plane
| +--------------------------------+ |
| | User plane management | |
| | | |
| +-------------|------------------+ |
+-----------------|---------------------+
|
|
|
|----------------|-----------------|
| | |
| | |
+--------|-----+ +------|-------+ +------|------+
| +---------+ | | +---------+ | |+-----|----+ |
| | routing | | | | routing | | || routing | |
| | control | | | | control | | || control | |
| +---------+ | | +---------+ | |+----------+ |
| +----------+ | | +----------+ | |+----------+ | User Plane
| |forwarding| | | |forwarding| | ||forwarding| |
| |plane | | | |plane | | ||plane | |
| +----------+ | | +----------+ | |+----------+ |
+--------------+ +--------------+ +-------------+
The CU separated BNG is shown in above figure. The BNG Control Plane
could be virtualized and centralized, which provides significant
benefits such as centralized session management, flexible address
allocation, high scalability for subscriber management capacity, and
cost-efficient redundancy, etc. The functional components 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, maintenance of channels between Control
Wang, et al. Expires May 2, 2018 [Page 5]
Internet-Draft Infor Model for CU separation October 2017
Planes and User Planes. Other modules in the BNG control plane, such
as address management, AAA, and etc., are responsible for the
connection with outside subsystems in order to fulfill the service.
The routing control and forwarding Plane in the BNG User Plane
(local) could be distributed across the infrastructure.
3.1. Service Data Model Usage
The idea of the information model is to propose a set of generic and
abstract information models. The models are intended to be used in
both Control Plane and User Planes. A typical scenario would be that
this model can be used as a compendium for the interface between
Control Plane and User Planes of CU separation BNG, that
corresponding data model or TLVs can be defined to realize the
communication between the Control Plane and User Planes.
Wang, et al. Expires May 2, 2018 [Page 6]
Internet-Draft Infor Model for CU separation October 2017
-----------------
//// \\\\
//// \\\\
// Cloud \\
| |
| |
| |
| |
| +-----------------+ |
| | Control Plane | |
\\ | | //
\\\\ +---------+-------+ ////
\\\\ | ////
------------------
|
+------------------+-----------+-----+
| | | |
User's information IP address QoS: .......
May Including: ...... CIR; |
User ID; | PIR; |
User MAC; | CBS; |
Access method(PPPoE, | PBS; |
IPoE, etc) ...... | ...... |
| | | |
+------------------V-----------+-----+
|
+----+
| -------
| /// \\\
+------+ +-------v---------+ +--------+ | |
| OTL | | User Plane | | Core | | Internet |
| +-------+ +-------+ Routing|-----| |
+------+ +-----------------+ +--------+ \\\ ///
-------
CU Separation BNG
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, user's IP address, and
QoS, etc. Then the control plane can transmit these tables to the
User planes. User planes receive these tables, parses it, matches
these rules, and then performs corresponding actions.
Wang, et al. Expires May 2, 2018 [Page 7]
Internet-Draft Infor Model for CU separation October 2017
4. Information Model
This section specifies the information model in Routing Backus-Naur
Form [I-D.gu-nfvrg-cloud-bng-architecture]. This grammar intends to
help readers better understand the English text description in order
to derive a data model. However it may not provide all the details
provided by the English text. When there is a lack of clarity in
grammar the English text will take precedence.
This section describes information model that represents the concept
of the interface of CU separation BNG which is languages and
protocols neutral.
The following figure describes the Overview of Information Model for
CU separation BNG.
<cu-separation-bng-infor-model>::=<control-plane-information-model>
<user-plane-information-model>
<control-plane-information-model>::=<user-related-infor-model>
<interface-related-infor-model>
<device-related-infor-model>
<user-related-infor-model>::= <user-basic-information>
[<ipv4-informatiom>]|[<ipv6-information>]
[<qos-information>]
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
<interface-related-infor-model>::=<interface-information>
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
Wang, et al. Expires May 2, 2018 [Page 8]
Internet-Draft Infor Model for CU separation October 2017
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
<device-related-infor-model>::=<address-field-distribute>
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
<user-plane-information-model>::=<port-resources-infor-model>
<traffic-statistics>
<port-resource-information>::=<IF_INDEX><IF_NAME>
<IF_TYPE><LINK_TYPE>
<MAC_ADDRESS><IF_PHY_STATE>
<MTU>
<traffic-statistics-information>::=<USER_ID><STATISTICS_TYPE>
<INGRESS_STATIISTICS_PACKETS>
<INGRESS STATISTICS_BYTES>
<EGRESS_STATISTICS_PACKETS>
<EGRESS_STATISTICS_BYTES>
4.1. Information Model for Control-Plane
This section describes information model for the Control-Plane (CP).
As mentioned in section 3, the Control Plane is a user control
management component which manages the user's information, User-
Plane's resources and forwarding policy, etc. The control plane can
generate several tables which contain a set of rules based on the
resources and specific requirements of user's service. After that,
the control plane sends the tables to User Planes, and User planes
receive the tables, parse them, match the rules, and then perform
corresponding actions.
The Routing Backus-Naur Form grammar below illustrates the
Information model for Control-Plane:
Wang, et al. Expires May 2, 2018 [Page 9]
Internet-Draft Infor Model for CU separation October 2017
<control-plane-information-model>::=<user-related-infor-model>
<interface-related-infor-model>
<device-related-infor-model>
<user-related-infor-model>::= <user-basic-information>
[<ipv4-informatiom>]|[<ipv6-information>]
[<qos-information>]
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
<interface-related-infor-model>::=<interface-information>
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
<device-related-infor-model>::=<address-field-distribute>
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
user-related-infor-model: present the attributes which can describe
the user's profile, such as user's basic information, qos, and IP
address, etc.
interface-related-infor-model: present the attributes which relate to
some physical/virtual interface. This model can be used to indicate
which kinds of service can be supported by interfaces.
Wang, et al. Expires May 2, 2018 [Page 10]
Internet-Draft Infor Model for CU separation October 2017
device-related-infor-model: present the attributes which relate to
specific device. For example the control plane can manage and
distribute the users, which belong to same subnet, to some specific
devices. And the user plane's devices provide corresponding service
for these users.
4.1.1. User-Related Information
The user related information are a bunch of attributes which may bind
to specific users. For example, the control plane can use a unified
ID to distinguish different users and distribute the IP address and
QoS rules to a specific user. In this section, the user related
information models are presented. The user related information
models include the user information model, IPv4/IPv6 information
model, QoS information model, etc.
The Routing Backus-Naur Form grammar below illustrates the user
related information model:
<user-related-infor-model>::= <user-basic-information>
[<ipv4-informatiom>]|[<ipv6-information>]
[<qos-information>]
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
4.1.1.1. User Basic Information Model
The User Basic Information model contains a set of attributes to
describe the basic information of a specific user, such as user's mac
address, access type (via PPPoE, IPoE, etc), inner vlan ID, outer
vlan ID, etc.
Wang, et al. Expires May 2, 2018 [Page 11]
Internet-Draft Infor Model for CU separation October 2017
The Routing Backus-Naur Form grammar below illustrates the user basic
information model:
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
USER_ID: is the identifier of user. This parameter is a unique and
mandatory, it can be used to distinguish different users.
MAC_ADDRESS: is the MAC address of the user.
ACCESS_TYPE: This attribute is an optional parameter. It can be used
to indicate the protocol be used for user's accessing, such as PPPoE,
IPoE, etc.
SESSION_ID: This attribute is an optional parameter. It can be used
as the identifier of PPPoE session.
INNER_VLAN-ID: The identifier of user's inner VLAN.
OUTER_VLAN_ID: The identifier of user's outer VLAN.
USER_INTERFACE: This attribute specifies the binding interface of a
specific user. The ifIndex of the interface MAY be included. This
is the 32-bit ifIndex assigned to the interface by the device as
specified by the Interfaces Group MIB [RFC2863]. The ifIndex can be
utilized within a management domain to map to an actual interface,
but it is also valuable in public applications [RFC5837]. The
ifIndex can be used as an opaque token to discern which interface of
User-Plane is providing corresponding service for specific user.
4.1.1.2. IPv4 Information Model
The IPv4 information model presents the user's IPv4 parameters. It
is an optional constructs. The Routing Backus-Naur Form grammar
below illustrates the user's IPv4 information model:
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
USER_ID: is the identifier of user. This parameter is unique and
mandatory. This attribute is used to distinguish different users.
And it collaborates with other IPv4 parameters to present the user's
IPv4 information.
Wang, et al. Expires May 2, 2018 [Page 12]
Internet-Draft Infor Model for CU separation October 2017
USER_IPV4: This attribute specifies the user's IPv4 address, and it's
usually used in user plane discovery and ARP reply message.
MASK_LENGTH: This attribute specifies the user's subnet masks lengths
which can identify a range of IP addresses that are on the same
network.
GATEWAY: This attribute specifies the user's gateway, and it's
usually used in User Plane discovery and ARP reply message.
VRF: is the identifier of VRF instance.
4.1.1.3. IPv6 Information Model
The IPv6 information model presents the user's IPv6 parameters. It
is an optional constructs. The Routing Backus-Naur Form grammar
below illustrates the user's IPv6 information model:
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
USER_ID: is the identifier of user. This parameter is unique and
mandatory. This attribute is used to distinguish different users.
And it collaborates with other IPv6 parameters to present the user's
IPv4 information.
USER_IPV6: This attribute specifies the user's IPv6 address, and it
usually be used in neighbor discovery (ND discovery).
PREFIX_LEN: This attribute specifies the user's subnet prefix lengths
which can identify a range of IP addresses that are on the same
network.
PD_ADDRESS: In IPv6 networking, DHCPv6 prefix delegation is used to
assign a network address prefix and automate configuration and
provisioning of the public routable addresses for the network. This
attribute specifies the user's DHCPv6 prefix delegation address, and
it's usually used in neighbor discovery (ND discovery).
PD_PREFIX_LEN: This attribute specifies the user's DHCPv6 delegation
prefix length, and it's usually used in neighbor discovery (ND
discovery).
VRF: is the identifier of VRF instance
Wang, et al. Expires May 2, 2018 [Page 13]
Internet-Draft Infor Model for CU separation October 2017
4.1.1.4. QoS Information Model
In CU separation BNG, the Control-Plane (CP) generates the QoS table
base on UP's bandwidth resources and specific QoS requirements of
user's services. This table contains a set of QoS matching rules
such as user's committed information rate, peak information rate,
committed burst size, etc. And it is an optional constructs. The
Routing Backus-Naur Form grammar below illustrates the user's qos
information model:
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
USER_ID: is the identifier of user. This parameter is unique and
mandatory. This attribute is used to distinguish different users.
And it collaborates with other qos parameters to present the user's
qos information.
CIR: In BNG network, the Committed Information Rate (CIR) is the
bandwidth for a user guaranteed by an internet service provider to
work under normal conditions. This attribute is used to indicate the
user's committed information rate, and it usually collaborates with
other qos attributes (such as PIR, CBS, PBS, etc) to present the
user's QoS profile.
PIR: Peak Information Rate (PIR) is a burstable rate set on routers
and/or switches that allows throughput overhead. This attribute is
used to indicate the user's peak information rate, and it usually
collaborate with other QoS attributes (such as CIR, CBS, PBS, etc) to
present the user's QoS profile.
CBS: The Committed Burst Size (CBS) specifies the relative amount of
reserved buffers for a specific ingress network's forwarding class
queue or egress network's forwarding class queue. This attribute is
used to indicate the user's committed burst size, and it usually
collaborates with other qos attributes (such as CIR, PIR, PBS, etc)
to present the user's QoS profile.
PBS: The Peak Burst Size (PBS) sepcifies the maximum size of the
first token bucket. This attribute is used to indicate the user's
peak burst size, and it usually collaborate with other qos attributes
(such as CIR, PIR, CBS, etc) to present the user's QoS profile.
QOS_PROFILE: This attribute specifies the standard profile provided
by the operator. It can be used as a QoS template which is defined
Wang, et al. Expires May 2, 2018 [Page 14]
Internet-Draft Infor Model for CU separation October 2017
as a list of classes of services and associated properties. The
properties may include:
o Rate-limit: used to rate-limit the class of service. The value
is expressed as a percentage of the global service bandwidth.
o latency: used to define the latency constraint of the class.
The latency constraint can be expressed as the lowest possible
latency or a latency boundary expressed in milliseconds.
o jitter: used to define the jitter constraint of the class. The
jitter constraint can be expressed as the lowest possible jitter
or a jitter boundary expressed in microseconds.
o bandwidth: used to define a guaranteed amount of bandwidth for
the class of service. It is expressed as a percentage.
4.1.2. Interface Related Information
This model contains the necessary information for the interface. It
is used to indicate which kind of service can be supported by this
interface. The Routing Backus-Naur Form grammar below illustrates
the interface related information model:
<interface-related-infor-model>::=<interface-information>
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
4.1.2.1. Interface Information Model
The interface model mentioned here is a logical construct that
identifies a specific process or a type of network service. In CU
separation BNG network, the Control-Plane (CP) generates the
Interface-Infor table based on the available resources, which are
received from the User-Plane (UP), and the specific requirements of
user's services.
The Routing Backus-Naur Form grammar below illustrates the interface
information model:
Wang, et al. Expires May 2, 2018 [Page 15]
Internet-Draft Infor Model for CU separation October 2017
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
IFINDEX: The IfIndex is the 32-bit index assigned to the interface by
the device as specified by the Interfaces Group MIB [RFC2863]. The
ifIndex can be utilized within a management domain to map to an
actual interface, but it is also valuable in public applications.
The ifIndex can be used as an opaque token to discern which interface
of User-Plane is providing corresponding service for specific user.
BAS_ENABLE: This is a flag, and if it is TRUE, the BRAS is enabled on
this interface.
PPP_Only: This is a flag, and if it is TRUE, the interface only
supports PPP user.
IPV4_TRIG: This is a flag, and if it is TRUE, the interface supports
that the user can be triggered to connect the internet by using IPv4
message.
IPV6_TRIG: This is a flag, and if it is TRUE, the interface supports
that the user can be triggered to connect the internet by using IPv6
message.
ND-TRIG: This is a flag, and if it is TRUE, the interface supports
that the user can be triggered to connect the internet by using
neighbor discovery message.
ARP_PROXY: This is a flag, and if it is TRUE, the ARP PROXY is
enabled on this interface.
4.1.3. Device Related Information
The device related information model presents the attributes which
related to specific device. For example the control plane can manage
and distribute the users, who belong to same subnet, to some specific
devices. And then the user plane's devices can provide corresponding
service for these users. The Routing Backus-Naur Form grammar below
illustrates the device related information model:
Wang, et al. Expires May 2, 2018 [Page 16]
Internet-Draft Infor Model for CU separation October 2017
<device-related-infor-model>::=<address-field-distribute>
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
4.1.3.1. Address field distribute Table
In CU separation BNG information model, the Control-Plane (CP)
generates and sends this Address field distribute table to UP. Based
on this table, the user-plane's devices can be divided into several
blocks, and each block is in charge of working for users with the
same subnet. The Routing Backus-Naur Form grammar below illustrates
the address field distribute information model:
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
4.2. Information Model for User Plane
This section describes information model for the interface of User
Plane (UP). As mentioned in section 3, the UP is a network edge and
user policy implementation component. It supports: Forwarding plane
functions on traditional BNG devices, including traffic forwarding,
QoS, and traffic statistics collection and Control plane functions on
traditional BNG devices, including routing, multicast, and MPLS.
In CU separation BNG information model, the CP generates tables and
provides the rules. The UP plays two roles:
1. It receives these tables, parses it, and matches these rules,
then performs corresponding actions.
2. It also generates several tables to report the available
resources (such as usable interfaces, etc) and statistical
information to CP.
The Routing Backus-Naur Form grammar below illustrates the User Plane
information model:
Wang, et al. Expires May 2, 2018 [Page 17]
Internet-Draft Infor Model for CU separation October 2017
<user-plane-information-model>::=<port-resources-infor-model>
<traffic-statistics>
port-resource-information>::=<IF_INDEX><IF_NAME>
<IF_TYPE><LINK_TYPE>
<MAC_ADDRESS><IF_PHY_STATE>
<MTU>
<traffic-statistics-information>::=<USER_ID><STATISTICS_TYPE>
<INGRESS_STATIISTICS_PACKETS>
<INGRESS STATISTICS_BYTES>
<EGRESS_STATISTICS_PACKETS>
<EGRESS_STATISTICS_BYTES>
4.2.1. Port Resources of UP
The User Plane can generate the network resource table, which
contains a bunch of attributes to present the available network
resources, for example the usable interfaces.
The Figure below illustrates the Port Resources Information Table of
User-Plane:
<port-resource-information>::<IF_INDEX><IF_NAME>
<IF_TYPE><LINK_TYPE>
<MAC_ADDRESS><IF_PHY_STATE>
<MTU>
IFINDEX: IfIndex is the 32-bit index assigned to the interface by the
device as specified by the Interfaces Group MIB [RFC2863]. The
ifIndex can be utilized within a management domain to map to an
actual interface, but it is also valuable in public applications.
The ifIndex can be used as an opaque token to discern which interface
of User-Plane is available.
IF_NAME: the textual name of the interface. The value of this object
should be the name of the interface as assigned by the local device
and should be suitable for use in commands entered at the device's
`console'. This might be a text name, such as `le0' or a simple port
number, such as `1', depending on the interface naming syntax of the
device. If several entries in the ifTable together represent a
single interface as named by the device, then each will have the same
value of ifName.
IF_TYPE: the type of interface, such as Ethernet, GE, Eth-Trunk, etc.
Wang, et al. Expires May 2, 2018 [Page 18]
Internet-Draft Infor Model for CU separation October 2017
LINK_TYPE: This attribute specifies the type of link, such as point-
to-point, broadcast, multipoint, point-to-multipoint, private and
public (accessibility and ownership), etc.
MAC_ADDRESS: This attribute specifies the available interface's MAC
address.
IF_PHY_STATE: The current operational state of the interface. This
is an enumeration type node:
1- Up: ready to pass packets;
2- Down
3- Testing: in some test mode;
4- Unknow: status cannot be determined for some reason;
5- Dormant;
6- Not present: some component is missing.
MTU: This attribute specifies the available interface's MTU (Maximum
Transmission Unit).
4.2.2. Traffic Statistics Infor
The user-plane also generates the traffic statistics table to report
the current traffic statistics.
The Figure below illustrates the Traffic Statistics Infor model of
User-Plane:
<traffic-statistics-information>::=<USER_ID><STATISTICS_TYPE>
<INGRESS_STATIISTICS_PACKETS>
<INGRESS STATISTICS_BYTES>
<EGRESS_STATISTICS_PACKETS>
<EGRESS_STATISTICS_BYTES>
USER_ID: is the identifier of user. This parameter is unique and
mandatory. This attribute is used to distinguish different users.
And it collaborates with other statistics parameters such as ingress
packets, egress packets, etc, to report the user's status profile.
STATISTICS_TYPE: This attributes specifies the traffic type such as
IPv4, IPv6, etc.
Wang, et al. Expires May 2, 2018 [Page 19]
Internet-Draft Infor Model for CU separation October 2017
INGRESS_STATIISTICS_PACKETS: This attribute specifies the Ingress
Statistics Packets of specific user.
INGRESS STATISTICS_BYTES: This attribute specifies the Ingress
Statistics Bytes of specific user.
EGRESS_STATISTICS_PACKETS: This attribute specifies the Egress
Statistics Packets of specific user.
EGRESS_STATISTICS_BYTES: This attribute specifies the Egress
Statistics Bytes of specific user.
5. Security Considerations
None.
6. IANA Considerations
None.
7. Normative References
[I-D.gu-nfvrg-cloud-bng-architecture]
Gu, R. and S. Hu, "Control and User Plane Separation
Architecture of BNG", draft-gu-nfvrg-cloud-bng-
architecture-01 (work in progress), July 2017.
[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>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/info/rfc2863>.
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
N., and JR. Rivers, "Extending ICMP for Interface and
Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837,
April 2010, <https://www.rfc-editor.org/info/rfc5837>.
Authors' Addresses
Wang, et al. Expires May 2, 2018 [Page 20]
Internet-Draft Infor Model for CU separation October 2017
Michael Wang (editor)
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangzitao@huawei.com
Rong Gu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: gurong_cmcc@outlook.com
Victor Lopez
Telefonica
Sur 3 building, 3rd floor, Ronda de la Comunicacion s/n
Madrid 28050
Spain
Email: victor.lopezalvarez@telefonica.com
Sujun Hu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: shujun_hu@outlook.com
Wang, et al. Expires May 2, 2018 [Page 21]
