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

Versions: 00 01 02 03

rtgwg                                                              S. Hu
Internet-Draft                                              China Mobile
Intended status: Informational                          Donald. Eastlake
Expires: April 25, 2019                                     M. Wang, Ed.
                                                                  Huawei
                                                                V. Lopez
                                                              Telefonica
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                                 T. Chua
                                    Singapore Telecommunications Limited
                                                        October 22, 2018


    Information Model of Control-Plane and User-Plane Separation BNG
            draft-cuspdt-rtgwg-cu-separation-infor-model-03

Abstract

   To improve network resource utilization and reduce operational
   expense, the Control-Plane and User-Plane separation concept is
   defined in Broadband Forum TR-384.  This document describes the
   information model for the interface between the Control-Plane (CP)
   and the User-Plane (UP) in the CP/UP separation BNG.  This
   information model may involve both the control channel interface and
   the configuration channel interface.  The interface for the control
   channel allows the Control-Plane to send flow tables to the User-
   Plane, such as user's information table, user's interface table, and
   user's QoS table.  And it also allows the User-Plane to report
   resource and statistics information to the Control-Plane.  The
   interface for the configuration channel is in charge of the protocol
   version negotiation between the Control-Plane and User-Plane, the
   configuration for devices of the Control-Plane and User-Plane, and
   the reports of User-Plane's capabilities, etc.  The information model
   defined in this document supports defining a standardized data model.
   Such a data model can be used to specify 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 April 25, 2019                 [Page 1]


Internet-Draft        Infor Model for CU Separation         October 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 April 25, 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 . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   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.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  20



Hu, et al.               Expires April 25, 2019                 [Page 2]


Internet-Draft        Infor Model for CU Separation         October 2018


     7.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   To improve network resource utilization and reduce operational
   expense, the Control-Plane and User-Plane separation concept is
   defined in Broadband Forum [TR-384].  The motivation for and
   architecture of the Control-Plane and User-Plane separation BNG is
   discussed in [I.D.cuspdt-rtgwg-cu-separation-bng-architecture].

   This document describes an information model for the interface
   between the Control-Plane (CP) and the User-Plane (UP) separation in
   the CP / UP Separated BNG.  This information model may involve both
   the control channel interface and the 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 protocol 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 supports defining a
   standardized data model.  Such a data model can be used to define an
   interface to the CU separation BNG.

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






Hu, et al.               Expires April 25, 2019                 [Page 3]


Internet-Draft        Infor Model for CU Separation         October 2018


   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 that manages
   UP's resources such as the user entry and forwarding policy, for
   example, the access bandwidth and priority management.  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.



































Hu, et al.               Expires April 25, 2019                 [Page 4]


Internet-Draft        Infor Model for CU Separation         October 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     | |
     | +----------+ |   | +----------+ |  |+----------+ |
     +--------------+   +--------------+  +-------------+
                  Figure 1. CU Separated BNG

   The CU separated BNG is shown in Figure 1.  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 Virtual Network
   Functions (VNFs) and hosted in a Network Function Virtualization
   Infrastructure (NFVI).

   The User Plane Management module in the BNG control plane centrally
   manages the distributed BNG User Planes (e.g. load balancing), as



Hu, et al.               Expires April 25, 2019                 [Page 5]


Internet-Draft        Infor Model for CU Separation         October 2018


   well as the setup, deletion, maintenance of channels between Control
   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 provide 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 this information model is to propose a set of generic and
   abstract information models to be used in both Control Plane and User
   Planes.  A typical scenario would be that this model can be used as a
   compendium to realize the communication between the Control Plane and
   User Planes of the CU separation BNG.





































Hu, et al.               Expires April 25, 2019                 [Page 6]


Internet-Draft        Infor Model for CU Separation         October 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|-----|             |
+------+       +-----------------+       +--------+      \\\       ///
                                                            -------
                        Figure 2. CU Separation BNG


   As shown in Figure 2, when users access 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 is reported by User planes, and
   based on the service's requirements generates a set of tables, which
   may include user's information, user's IP address, and QoS.  Then the
   control plane can transmit these tables to the User planes.  User
   planes receive these tables, parse them, matches these rules, and
   then performs corresponding actions.





Hu, et al.               Expires April 25, 2019                 [Page 7]


Internet-Draft        Infor Model for CU Separation         October 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, the English text will
   take precedence.

   This section describes the information model that represents the
   interface of the CU separation BNG that is language and protocol
   neutral.

   The following Routing BNF grammar 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 April 25, 2019                 [Page 8]


Internet-Draft        Infor Model for CU Separation         October 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 specifies the Information
   model for Control-Plane:












Hu, et al.               Expires April 25, 2019                 [Page 9]


Internet-Draft        Infor Model for CU Separation         October 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: presents the attributes that can describe
   the user's profile, such as user's basic information, qos, and IP
   address.

   interface-related-infor-model: presents the attributes that 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 April 25, 2019                [Page 10]


Internet-Draft        Infor Model for CU Separation         October 2018


   device-related-infor-model: presents the attributes which relate to a
   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 is a collection of attributes bound 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 specifies 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 the user's
   MAC address, access type (via PPPoE, IPoE, etc), inner VLAN ID, outer
   VLAN ID, etc.




Hu, et al.               Expires April 25, 2019                [Page 11]


Internet-Draft        Infor Model for CU Separation         October 2018


   The Routing Backus-Naur Form grammar below specifies 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 for a user.  This parameter is
   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 being used for the user's
   access, 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 12-bit identifier of user's inner VLAN
   in network byte order.  The unused high-order 4 bits MUST be sent as
   zero and ignored on receipt.

   OUTER_VLAN_ID (2 bytes): The 12-bit identifier of user's outer VLAN
   in network byte order.  The unused high-order 4 bits MUST be sent as
   zero and ignored on receipt.

   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 the 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 sepcifies the user's IPv4 information model:

   <ipv4-informatiom>::=<USER_ID><USER_IPV4>
                        <MASK_LENGTH><GATEWAY>
                        <VRF>




Hu, et al.               Expires April 25, 2019                [Page 12]


Internet-Draft        Infor Model for CU Separation         October 2018


   USER_ID (4 bytes): is the identifier of user.  This parameter is
   unique and mandatory.  This attribute is used to distinguish
   different users.  In conjunction with other IPv4 parameters it links
   the user to the user's IPv4 information.

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

   MASK_LENGTH (4 bytes): This attribute specifies the user's subnet
   mask length 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
   is 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 specifies 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.  in conjunction with other IPv6 parameters, I tlink
   the user to the user's IPv6 information.

   USER_IPV6 (2 bytes): This attribute specifies the user's IPv6
   address.  It is usually 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 is usually used in neighbor discovery (ND discovery).





Hu, et al.               Expires April 25, 2019                [Page 13]


Internet-Draft        Infor Model for CU Separation         October 2018


   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 a VRF instance

4.1.1.4.  QoS Information Model

   In the CU separation BNG, the Control-Plane (CP) generates the QoS
   table base based on the UP's bandwidth resources and the specific QoS
   requirements ofof the 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 itIs is an optional
   constructs.  The Routing Backus-Naur Form grammar below
   illustratesspecifies 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.  within conjunction with other qos parameters it
   links the user to the user's qos information.

   CIR (4 bytes): In a BNG network, the Committed Information Rate (CIR)
   is the bandwidth available for a user guaranteed by an internet
   service provider under normal conditions.  This attribute is used to
   indicate the user's committed information rate, and it usually
   appears with other qos attributes (such as PIR, CBS, PBS, etc) to
   give the user's QoS profile.

   PIR (4 bytes): Peak Information Rate (PIR) is a burstable rate set on
   routers and/or switches that allow throughput bursts.  This attribute
   is used to indicate the user's peak information rate.  In conjunction
   with with other QoS attributes (such as CIR, CBS, PBS, etc) it is
   used to give 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.
   In conjunction with other qos attributes (such as CIR, PIR, PBS, etc)
   it is used to give the user's QoS profile.

   PBS (4 bytes): The Peak Burst Size (PBS) specifies the maximum size
   of the first token bucket.  This attribute is used to indicate the



Hu, et al.               Expires April 25, 2019                [Page 14]


Internet-Draft        Infor Model for CU Separation         October 2018


   user's peak burst size.  In conjunction with other qos attributes
   (such as CIR, PIR, CBS, etc) it is used to give 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 that is
   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 an interface.  It
   is used to indicate which kind of service can be supported by this
   interface.  The Routing Backus-Naur Form grammar below specifies 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.



Hu, et al.               Expires April 25, 2019                [Page 15]


Internet-Draft        Infor Model for CU Separation         October 2018


   The Routing Backus-Naur Form grammar below specifies the interface
   information model:

    <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 the User-Plane is providing the 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 the user being triggered to connect to the internet by using
   an IPv4 message.

   IPV6_TRIG (2 bytes): This is a flag, and if it is TRUE, the interface
   supports that the user being triggered to connect to the internet by
   using an IPv6 message.

   ND-TRIG (2 bytes): This is a flag, and if it is TRUE, the interface
   supports the user being triggered to connect to the internet by using
   a neighbor discovery message.

   ARP_PROXY (2 bytes): This is a flag, and if it is TRUE, ARP PROXY is
   enabled on this interface.

4.1.3.  Device Related Information

   The device related information model presents the attributes which
   relate to a specific device.  For example the control plane can
   manage and distribute the users, who belong to the same subnet, to
   some specific devices.  And then the user plane's devices can provide
   the corresponding service for these users.  The Routing Backus-Naur
   Form grammar below specifies the device related information model:



Hu, et al.               Expires April 25, 2019                [Page 16]


Internet-Draft        Infor Model for CU Separation         October 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 the 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 sepcifies 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 the information model for the interface of to
   the User Plane (UP).  As mentioned in section Section 3, the UP is a
   network edge and user policy implementation component.  It supports
   the following: 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 entries.  The UP plays two roles:

   1.  It receives these tables, parses them, 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 specifies the User Plane
   information model:








Hu, et al.               Expires April 25, 2019                [Page 17]


Internet-Draft        Infor Model for CU Separation         October 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 Routing BNF grammar below illustratesspecifies 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 the 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 April 25, 2019                [Page 18]


Internet-Draft        Infor Model for CU Separation         October 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 byte): 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 specifies 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.  In conjunction with other statistics parameters
   such as ingress packets, egress packets, etc, it is used 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 April 25, 2019                [Page 19]


Internet-Draft        Infor Model for CU Separation         October 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.  References

7.1.  Normative References

   [I-D.cuspdt-rtgwg-cu-separation-bng-architecture]
              Hu, S., Qin, F., Li, Z., Chua, T., Wang, Z., and J. Song,
              "Architecture for Control Plane and User Plane Separated
              BNG", draft-cuspdt-rtgwg-cu-separation-bng-architecture-01
              (work in progress), July 2018.

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







Hu, et al.               Expires April 25, 2019                [Page 20]


Internet-Draft        Infor Model for CU Separation         October 2018


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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [TR-384]   Broadband Forum, ""Cloud Central Office Reference
              Architectural Framework",", BBF TR-384, January. 2018.

Authors' Addresses

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

   Email: hushujun@chinamobile.com


   Donald Eastlake, 3rd
   Huawei
   1424 Pro Shop Court
   Davenport, FL  33896
   USA

   Email: d3e3e3@gmail.com


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

   Email: wangzitao@huawei.com





Hu, et al.               Expires April 25, 2019                [Page 21]


Internet-Draft        Infor Model for CU Separation         October 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

















Hu, et al.               Expires April 25, 2019                [Page 22]


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