[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

rtgwg                                                              S. Hu
Internet-Draft                                              China Mobile
Intended status: Informational                              M. Wang, Ed.
Expires: January 3, 2019                                          Huawei
                                                                V. Lopez
                                                              Telefonica
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                                 T. Chua
                                    Singapore Telecommunications Limited
                                                            July 2, 2018


    Information Model of Control-Plane and User-Plane separation BNG
            draft-cuspdt-rtgwg-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 [TR-384].  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/.





Hu, et al.               Expires January 3, 2019                [Page 1]


Internet-Draft        Infor Model for CU separation            July 2018


   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.

   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  . . . . . . . . . . . . . . . . . . . . . . .  21



Hu, et al.               Expires January 3, 2019                [Page 2]


Internet-Draft        Infor Model for CU separation            July 2018


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 [TR-384],
   [I-D.cuspdt-rtgwg-cu-separation-bng-deployment].  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.



Hu, et al.               Expires January 3, 2019                [Page 3]


Internet-Draft        Infor Model for CU separation            July 2018


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














Hu, et al.               Expires January 3, 2019                [Page 4]


Internet-Draft        Infor Model for CU separation            July 2018


             +-----+    +-----+    +-----+   +-----+
             |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



Hu, et al.               Expires January 3, 2019                [Page 5]


Internet-Draft        Infor Model for CU separation            July 2018


   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.




































Hu, et al.               Expires January 3, 2019                [Page 6]


Internet-Draft        Infor Model for CU separation            July 2018


                    -----------------
                ////                 \\\\
            ////                         \\\\
          //              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.





Hu, et al.               Expires January 3, 2019                [Page 7]


Internet-Draft        Infor Model for CU separation            July 2018


4.  Information Model

   This section specifies the information model in Routing Backus-Naur
   Form [RFC5511].  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>



Hu, et al.               Expires January 3, 2019                [Page 8]


Internet-Draft        Infor Model for CU separation            July 2018


 <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:












Hu, et al.               Expires January 3, 2019                [Page 9]


Internet-Draft        Infor Model for CU separation            July 2018


 <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.



Hu, et al.               Expires January 3, 2019               [Page 10]


Internet-Draft        Infor Model for CU separation            July 2018


   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.




Hu, et al.               Expires January 3, 2019               [Page 11]


Internet-Draft        Infor Model for CU separation            July 2018


   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 (4 bytes): is the identifier of user.  This parameter is a
   unique and mandatory, it can be used to distinguish different users.

   MAC_ADDRESS (6 bytes): is the MAC address of the user.

   ACCESS_TYPE (2 bytes): 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 (4 bytes): This attribute is an optional parameter.  It
   can be used as the identifier of PPPoE session.

   INNER_VLAN-ID (2 bytes): The identifier of user's inner VLAN.

   OUTER_VLAN_ID (2 bytes): The identifier of user's outer VLAN.

   USER_INTERFACE (4 bytes): 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 (4 bytes): 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.



Hu, et al.               Expires January 3, 2019               [Page 12]


Internet-Draft        Infor Model for CU separation            July 2018


   USER_IPV4 (4 bytes): This attribute specifies the user's IPv4
   address, and it's usually used in user plane discovery and ARP reply
   message.

   MASK_LENGTH (4 bytes): This attribute specifies the user's subnet
   masks lengths which can identify a range of IP addresses that are on
   the same network.

   GATEWAY (4 bytes): This attribute specifies the user's gateway, and
   it's usually used in User Plane discovery and ARP reply message.

   VRF (4 bytes): 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 (4 bytes): 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 (2 bytes): This attribute specifies the user's IPv6
   address, and it usually be used in neighbor discovery (ND discovery).

   PREFIX_LEN (4 bytes): 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 (4 bytes): 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 (4 bytes): This attribute specifies the user's DHCPv6
   delegation prefix length, and it's usually used in neighbor discovery
   (ND discovery).

   VRF (4 bytes): is the identifier of VRF instance




Hu, et al.               Expires January 3, 2019               [Page 13]


Internet-Draft        Infor Model for CU separation            July 2018


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 (4 bytes): 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 (4 bytes): 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 (4 bytes): 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 (4 bytes): 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 (4 bytes): 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 (4 bytes): This attribute specifies the standard profile
   provided by the operator.  It can be used as a QoS template which is



Hu, et al.               Expires January 3, 2019               [Page 14]


Internet-Draft        Infor Model for CU separation            July 2018


   defined 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:






Hu, et al.               Expires January 3, 2019               [Page 15]


Internet-Draft        Infor Model for CU separation            July 2018


    <interface-information>::=<IFINDEX><BAS_ENABLE>
                              <service-type>

    <service-type>::=<PPP_Only><IPV4_TRIG>
                     <IPV6_TRIG><ND-TRIG>
                     <ARP_PROXY>


   IFINDEX (4 bytes): 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 (2 bytes): This is a flag, and if it is TRUE, the BRAS is
   enabled on this interface.

   PPP_Only (2 bytes): This is a flag, and if it is TRUE, the interface
   only supports PPP user.

   IPV4_TRIG (2 bytes): 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 (2 bytes): 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 (2 bytes): 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 (2 bytes): 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:






Hu, et al.               Expires January 3, 2019               [Page 16]


Internet-Draft        Infor Model for CU separation            July 2018


   <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:









Hu, et al.               Expires January 3, 2019               [Page 17]


Internet-Draft        Infor Model for CU separation            July 2018


   <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 (4 bytes): 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 (64 bytes): 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 (4 bytes): the type of interface, such as Ethernet, GE, Eth-
   Trunk, etc.





Hu, et al.               Expires January 3, 2019               [Page 18]


Internet-Draft        Infor Model for CU separation            July 2018


   LINK_TYPE (4 bytes): 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 (6 bytes): This attribute specifies the available
   interface's MAC address.

   IF_PHY_STATE (1 bytes): 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 (4 bytes): 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 (4 bytes): This attributes specifies the traffic type
   such as IPv4, IPv6, etc.



Hu, et al.               Expires January 3, 2019               [Page 19]


Internet-Draft        Infor Model for CU separation            July 2018


   INGRESS_STATIISTICS_PACKETS (8 bytes): This attribute specifies the
   Ingress Statistics Packets of specific user.

   INGRESS STATISTICS_BYTES (8 bytes): This attribute specifies the
   Ingress Statistics Bytes of specific user.

   EGRESS_STATISTICS_PACKETS (8 bytes): This attribute specifies the
   Egress Statistics Packets of specific user.

   EGRESS_STATISTICS_BYTES (8 bytes): This attribute specifies the
   Egress Statistics Bytes of specific user.

5.  Security Considerations

   None.

6.  IANA Considerations

   None.

7.  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.

   [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>.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, DOI 10.17487/RFC5511, April
              2009, <https://www.rfc-editor.org/info/rfc5511>.

   [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>.





Hu, et al.               Expires January 3, 2019               [Page 20]


Internet-Draft        Infor Model for CU separation            July 2018


Authors' Addresses

   Shujun Hu
   China Mobile
   32 Xuanwumen West Ave, Xicheng District
   Beijing, Beijing  100053
   China

   Email: hushujun@chinamobile.com


   Michael Wang (editor)
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: wangzitao@huawei.com


   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






Hu, et al.               Expires January 3, 2019               [Page 21]


Internet-Draft        Infor Model for CU separation            July 2018


   Tee Mong Chua
   Singapore Telecommunications Limited
   31 Exeter Road, #05-04 Comcentre Podium Block
   Singapore City  239732
   Singapore

   Email: teemong@singtel.com












































Hu, et al.               Expires January 3, 2019               [Page 22]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/