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

Versions: 00

rtgwg                                                              S. Hu
Internet-Draft                                                  L. Huang
Intended status: Informational                                     R. Gu
Expires: April 29, 2018                                     China Mobile
                                                           Victor. Lopez
                                                              Telefonica
                                                               Jun. Song
                                                           Michael. Wang
                                                                  Huawei
                                                        October 26, 2017


  Requirements for Control Plane and User Plane Separated BNG Protocol
                draft-cuspdt-rtgwg-cusp-requirements-00

Abstract

   This document introduces the Control Plane and User Plane separated
   BNG architecture and defines a set of associated terminology.  This
   document also defines a set of protocol requirements to Control Plane
   and User Plane Separated BNG (CUSP).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 29, 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



Hu, et al.               Expires April 29, 2018                 [Page 1]


Internet-Draft            Requirements for CUSP             October 2017


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Concept and Terminology . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  CU Separated BNG Model  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Internal interfaces between the CP and UP . . . . . . . .   5
   4.  The usage of CU separation BNG protocol . . . . . . . . . . .   6
   5.  Control Plane and User Plane Separation Protocol Requirements   7
     5.1.  Transmit information tables . . . . . . . . . . . . . . .   7
     5.2.  Scalability . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Message Priority  . . . . . . . . . . . . . . . . . . . .   8
     5.4.  Reliability . . . . . . . . . . . . . . . . . . . . . . .   8
     5.5.  Support for Secure Communication  . . . . . . . . . . . .   8
     5.6.  Version negotiation . . . . . . . . . . . . . . . . . . .   8
     5.7.  Capability Exchange . . . . . . . . . . . . . . . . . . .   9
     5.8.  CP primary/backup capability  . . . . . . . . . . . . . .   9
     5.9.  Event Notification  . . . . . . . . . . . . . . . . . . .   9
     5.10. Query Statistics  . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   BNG is an Ethernet-centric IP edge router, and the aggregation point
   for the user traffic.  To provide centralized session management,
   flexible address allocation, high scalability for subscriber
   management capacity, and cost-efficient redundancy, the CU separated
   BNG is introduced [BBF-CloudCO].  The CU separated Service Control
   Plane could be virtualized and centralized, which is responsible for
   user access authentication and setting forwarding entries of user
   plane.  The routing control and forwarding plane, i.e. BNG user plane
   (local), could be distributed across the infrastructure.

   This document introduces the Control Plane and User Plane separated
   BNG architecture and modeling.  This document also defines the
   protocol requirements to Control Plane and User Plane Separated BNG
   (CUSP).





Hu, et al.               Expires April 29, 2018                 [Page 2]


Internet-Draft            Requirements for CUSP             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.  The CP is a user control management component
   which support to manage UP's resources such as the user entry and
   user's QoS policy

   UP: User Plane.  UP is a network edge and user policy implementation
   component.  The traditional router's Control Plane and forwarding
   plane are both preserved on BNG devices in the form of a user plane.

3.  CU Separated BNG Model

   The following figure describes the architecture of CU separation BNG


























Hu, et al.               Expires April 29, 2018                 [Page 3]


Internet-Draft            Requirements for CUSP             October 2017


    +------------------------------------------------------------------+
    |        Neighboring policy and resource management systems        |
    |                                                                  |
    |   +-------------+   +-----------+   +---------+   +----------+   |
    |   |Radius Server|   |DHCP Server|   |   EMS   |   |   MANO   |   |
    |   +-------------+   +-----------+   +---------+   +----------+   |
    +------------------------------------------------------------------+

    +------------------------------------------------------------------+
    |                       CU-separated BNG system                    |
    | +--------------------------------------------------------------+ |
    | |+----------+  +----------+ +------++------++-----------+      | |
    | || Address  |  |Subscriber| |Radius||PPPoE/||    UP     |      | |
    | ||management|  |management| |      ||IPoE  ||management |      | |
    | |+----------+  +----------+ +------++------++-----------+      | |
    | |+----------+  +----------+ +------++------++-----------+      | |
    | |                              CP                              | |
    | +--------------------------------------------------------------+ |
    | +---------------------------+      +--------------------------+  |
    | |  +------------------+     |      |  +------------------+    |  |
    | |  | Routing control  |     |      |  | Routing control  |    |  |
    | |  +------------------+     | ...  |  +------------------+    |  |
    | |  +------------------+     |      |  +------------------+    |  |
    | |  |Forwarding engine |     |      |  |Forwarding engine |    |  |
    | |  +------------------+  UP |      |  +------------------+  UP|  |
    | +---------------------------+      +--------------------------+  |
    +------------------------------------------------------------------+
                     Architecture of CU Separation BNG


   Briefly, a CU separated BNG is made up of a Control Plane (CP) and a
   set of User Planes (UPs) [BBF-CloudCO], [I-D.draft-gu-nfvrg-cloud-
   bng-architecture].  The Control Plane is a user control management
   component which support to manage UP's resources such as the user
   entry and user's QoS policy, for example, the access bandwidth and
   priority management.  This Control Plane could be virtualized and
   centralized.  The functional 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
   planes and user planes [BBF-CloudCO], [I-D.draft-gu-nfvrg-cloud-bng-
   architecture].  And the User Plane (UP) is a network edge and user
   policy implementation component.  It can support the forwarding plane
   functions on traditional BNG devices, such as traffic forwarding,
   QoS, and traffic statistics collection, and it can also support the
   control plane functions on traditional BNG devices, such as routing,




Hu, et al.               Expires April 29, 2018                 [Page 4]


Internet-Draft            Requirements for CUSP             October 2017


   multicast, etc.[BBF-CloudCO],[I-D.draft-gu-nfvrg-cloud-bng-
   architecture]

3.1.  Internal interfaces between the CP and UP

   To support the communication between the Control Plane and User
   Plane, several interfaces are involved.  The Figure 2 illustrates the
   internal interfaces of CU Separated BNG.

                         +----------------------------------+
                         |                                  |
                         |              BRAS-CP             |
                         |                                  |
                         +--+--------------+--------------+-+
                            |              |              |
                  Service   |   Control    |   Management |
                  Interface |   Interface  |   Interface  |
                            |              |              |
                         +--+--------------+--------------+-+
                         |                                  |
                         |              BRAS-UP             |
                         |                                  |
                         +-----------------+----------------+
                                           |
                                           |
                                  +--------+--------+
                                  |                 |
                                  | Access Network  |
                                  |                 |
                                  +--------+--------+
                                           |
                                      +----+----+
                                      |         |
                                      |   User  |
                                      |         |
                                      +---------+


                    Internal interfaces between the CP and UP



   Service interface: The CP and UP use this interface to establish
   VXLAN tunnels with each other and transmit PPPoE and IPoE packets
   over the VXLAN tunnels.






Hu, et al.               Expires April 29, 2018                 [Page 5]


Internet-Draft            Requirements for CUSP             October 2017


   Control interface: The CP uses this interface to deliver service
   entries, and the UP uses this interface to report service events to
   the CP.

   Management interface: The CP uses this interface to deliver
   configurations to the UP.  This interface runs NETCONF.

4.  The usage of CU separation BNG protocol


                     -----------------
                 ////                 \\\\
             ////                         \\\\
           //          Cloud                  \\
          |                                     |
         |                                       |
        |                                         |
        |                                         |
         |        +-----------------+            |
          |       |  Control Plane  |           |
           \\     |                 |         //
             \\\\ +------+----------+     ////
                 \\\\    |            ////
                     -----------------
                         |
                +--------+----------+-------------+-----+
                |                   |             |     |
          User's information     IP  ddress      QoS:  .......
          May Including:            |            CIR;         :
          User ID;                  |            PIR;   |
          User MAC;                 |            CBS;   |
          Access method(PPPoE,      |            PBS;   |
          IPoE, etc)                |            ......
          ..... |                   |              |
                +-------------------V--------------+
                                    |
                        +-----------+
                        |                                    -------
                        |                                 ///       \\\
 +------+       +-------v---------+       +--------+     |             |
 | OLT  |       | User Plane      |       |  Core  |    |    Internet
 |      +-------+                 +-------+  Routing-----+             |
 +------+       +-----------------+       +--------+      \\\       ///
                                                             -------
                    CU Separation BNG






Hu, et al.               Expires April 29, 2018                 [Page 6]


Internet-Draft            Requirements for CUSP             October 2017


   As shown in above figure, when users access to the BNG network, the
   control plane solicits these users' information (such as user's ID,
   user's MAC, user's access methods, for example via PPPoE/IPoE),
   associates them with available bandwidth which are reported by User
   planes, and based on the service's requirement to generate a set of
   tables, which may include user's information, UP's IP segment, and
   QoS, etc.  Then the control plane can transmit these tables to the
   User planes.  User planes receive these tables, parses it, matches
   these rules, and then performs corresponding actions.

5.  Control Plane and User Plane Separation Protocol Requirements

   This section specifies some of the requirements that the CU
   separation protocol SHOULD support.

5.1.  Transmit information tables

   The Control Plane and User Plane Separation Protocol MUST allow the
   CP to send tables to each User Plane device.

      a) The current BNG service requires that the UP should support at
      least 2000 users being accessed every second.  And every user
      requires at least 2000 bytes.  To achieve high performance, the CU
      Separation protocol SHOULD be lightweight.

      b) CU separation protocol should support XML/binary data which
      serves as the encoding format.  It allows user information data be
      read, saved, and manipulated with tools specific to XML/binary.

      c) Furthermore, in order to provide centralized session
      management, high scalability for subscriber management capacity,
      and cost-efficient redundancy, batching ability should be
      involved.  The CU Separation protocol should be able to group an
      ordered set of commands to a UP device.  Each such group of
      commands SHOULD be sent to the UP in as few messages as possible.
      Furthermore, the protocol MUST support the ability to specify if a
      command group MUST have all-or-nothing semantics.

5.2.  Scalability

   The CU Separation protocol SHOULD be able to supporting at least
   hundreds of UP devices and tens of thousands of ports.  For example,
   the protocol field sizes corresponding to UP or port numbers SHALL be
   large enough to support the minimum required numbers.  This
   requirement does not relate to the performance of the system as the
   number of UPs or ports in the system grows.





Hu, et al.               Expires April 29, 2018                 [Page 7]


Internet-Draft            Requirements for CUSP             October 2017


5.3.  Message Priority

   The CU Separation protocol MUST provide a means to express the
   protocol message priorities.

5.4.  Reliability

   In Network, a heartbeat is a periodic signal generated by hardware or
   software to indicate normal operation or to synchronize other parts
   of network system.

   In CU separation BNG, the heartbeat is sent between CP and UPs at a
   regular interval in the order of seconds.  If the CP/UP does not
   receive a heartbeat for a time--usually a few heartbeat intervals--
   the CP/UP that should have sent the heartbeat is assumed to have
   failed.

   The CU separation protocol should support some kind of heartbeat
   monitor mechanism.  And this mechanism should have ability to
   distinguish whether the interruption is an actual failure.  For
   example, in some scenarios (i.e.  CP/UP update, etc), the connection
   between the UP and CP need to be interrupted.  In this case, the
   interruption should not be reported.

5.5.  Support for Secure Communication

   As mentioned above, CP may send some information tables to the UP
   which may critical to the functioning of a network (e.g, User
   Information, IPv4/IPv6 information) and may reflect the business
   relationships (e.g, QoS, service level agreements, etc).  Therefore,
   it MUST be supported to ensure the integrity of all CU Separation
   protocol messages and protect against man-in-the-middle attacks.

   And the CP Separation protocol should support multiple security
   mechanisms to satisfy various scenarios.  For example, when the
   special lines are implemented between the CP and UPs, the key chain
   SHOULD be supported.  And if some VPNs are deployed between the CP
   and UPS, the TLS SHOULD be supported.  In case of the CP and UPs
   cross several domains (i.e. cross third-party network), the IPsec
   SHOULD be supported.

5.6.  Version negotiation

   The CU separation BNG may consist of different vendor's devices.
   Since different vendors' device may implement different version of
   protocol, therefore, the CU separation protocol should provide some
   mechanisms to perform the version negotiation.




Hu, et al.               Expires April 29, 2018                 [Page 8]


Internet-Draft            Requirements for CUSP             October 2017


   The version negotiation is the process that the CU separation BNG's
   Control-Plane uses to evaluate the protocol versions that are
   supported by the control-plane and the user-plane devices, and select
   the protocol version it will use when communicating with the exchange
   user-plane devices.  The process is a "negotiation" because it
   requires identifying the most recent protocol version that is
   supported by both the control-plane and the user-plane devices.

5.7.  Capability Exchange

   The UP Capability Report displays the devices profile, service
   capability, and other assigned capabilities within the CU separation
   BNG.  The CU separation protocol should provide some mechanism to
   exchange the UP device's capability

5.8.  CP primary/backup capability

   A backup CP for disaster recovery is required for the CU separation
   BNG network.  And the CUSP should provide some mechanism to implement
   the backup CP:

      a) In some scenarios, there are maybe two CP devices which declare
      that they are the primary CP.  In this situation, the CUSP should
      support or associate with some mechanisms to determine which CP is
      the primary device.

      b) In the some scenarios the primary CP downs, the CUSP should
      support to switching between primary and backup CP.

5.9.  Event Notification

   The CUSP protocol SHOULD be able to asynchronously notify the CP of
   events on the UP such as failures or change in available resources or
   capabilities.  There are some scenarios may initiate the event
   notification:

      a) Sending response message: As mentioned above, the control plane
      solicits these users' information, associates them with available
      bandwidth, and based on the service's requirement to generate a
      set of tables.  Then the control plane transmit these tables to
      the User planes.  The UPs should respond with an event
      notification to inform the CP that the tables are received.

      b) User trace: The user trace mechanism can support the Control
      Plane to trace and monitor the network state for users (for
      example the real-time bandwidth, etc) , debug the user's
      application.  Therefore, the UPs SHOULD be able to notify the CP
      with the User trace message.



Hu, et al.               Expires April 29, 2018                 [Page 9]


Internet-Draft            Requirements for CUSP             October 2017


      c) Sending statistics parameters: In CU separation BNG, the User-
      plane will report the traffic statistics parameters to the
      Control-plane, such as the ingress packets, ingress bytes, egress
      packets, egress bytes, etc.  These parameters can help to
      measurement the BNG network status.  The Control-Plane can base on
      the statistics parameters to allocate available network resources.
      Therefore, the UPs SHOULD be able to notify the CP with statistics
      parameters.

      d) Report the result of User Detect: "User Detect" message will be
      send periodically to detect user dial-up and disconnect.  The UPs
      SHOULD be able to notify the CP with the result of User Detect.

5.10.  Query Statistics

   The CUSP protocol MUST provide a means for the CP to be able to query
   statistics (monitor performance) from the UP.

6.  Security Considerations

   None.

7.  IANA Considerations

   None.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

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

   Email: shujun_hu@outlook.com









Hu, et al.               Expires April 29, 2018                [Page 10]


Internet-Draft            Requirements for CUSP             October 2017


   Lu Huang
   China Mobile
   32 Xuanwumen West Ave, Xicheng District
   Beijing, Beijing  100053
   China

   Email: hlisname@yahoo.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


   Jun Song
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: song.jun@huawei.com


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

   Email: wangzitao@huawei.com








Hu, et al.               Expires April 29, 2018                [Page 11]


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