<?xml version="1.0" encoding="UTF-8"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">[
<!ENTITY I-D.ietf-i2rs-yang-network-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-yang-network-topo.xml">
<!ENTITY I-D.zhuang-i2rs-yang-dc-fabric-network-topology "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhuang-i2rs-yang-dc-fabric-network-topology.xml">
 <!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-usecase-reqs-summary.xml">
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
]>     
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="info" docName=" draft-cuspdt-rtgwg-cusp-requirements-03" ipr="trust200902">

 <front>

  <!-- The abbreviated title is used in the page header- it is only
       necessary if the full title is longer than 39 characters -->
  <title abbrev="Requirements for CUSP">
Requirements for Control Plane and User Plane Separated BNG Protocol
  </title>
  <author fullname="Shujun Hu" initials="S." surname="Hu">
      <organization>China Mobile</organization>
	  <address>
        <postal>
          <street>32 Xuanwumen West Ave, Xicheng District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>shujun_hu@outlook.com</email>
      </address>
  </author>
	
  <author fullname="Victor Lopez" initials="V." surname="Lopez">
      <organization>Telefonica</organization>
      <address>
        <postal>
          <street>Sur 3 building, 3rd floor, 
		  Ronda de la Comunicación s/n</street>

          <city>Madrid</city>

          <code>28050</code>

          <country>Spain</country>
        </postal>	  
        <email>victor.lopezalvarez@telefonica.com</email>
      </address>
  </author>
  
  <author fullname="Fengwei Qin" initials="F." surname="Qin">
      <organization>China Mobile</organization>
	  <address>
        <postal>
          <street>32 Xuanwumen West Ave, Xicheng District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>qinfengwei@chinamobile.com</email>
      </address>
  </author> 
  
  <author fullname="Zhenqiang Li" initials="Z." surname="Li">
      <organization>China Mobile</organization>
	  <address>
        <postal>
          <street>32 Xuanwumen West Ave, Xicheng District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>lizhenqiang@chinamobile.com</email>
      </address>
  </author> 
    <author initials="T." surname="Chua" fullname="Tee Mong Chua">
      <organization>Singapore Telecommunications Limited</organization>

      <address>
        <postal>
          <street>31 Exeter Road, #05-04 Comcentre Podium Block </street>

          <city>Singapore City</city>
		  
          <code>239732</code>

          <country>Singapore</country>
        </postal>

        <email>teemong@singtel.com</email>
      </address>
  </author>   
   <author initials="Donald." surname="Eastlake" fullname="Donald Eastlake, 3rd">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>1424 Pro Shop Court</street>

          <city>Davenport</city>

          <region>FL</region>

          <code>33896</code>

          <country>USA</country>
        </postal>

        <email>d3e3e3@gmail.com</email>
      </address>
  </author>   
   <author initials="M." surname="Wang" fullname="Michael Wang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>wangzitao@huawei.com</email>
      </address>
  </author>
   <author initials="J." surname="Song" fullname="Jun Song">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>song.jun@huawei.com</email>
      </address>
  </author>
  <date month="October" year="2018"></date>
  <!-- If the month and year are both specified and are the current ones,
       xml2rfc will fill in the current day for you. If only the current
       year is specified, xml2rfc will fill in the current day and month
       for you. If the year is not the current one, it is necessary to
       specify at least a month (xml2rfc assumes day="1" if not specified
       for the purpose of calculating the expiry date).  With drafts it is
       normally sufficient to specify just the year. -->

  <!-- Meta-data Declarations -->

  <area>RTG Area</area>
  <workgroup>rtgwg</workgroup>

  <abstract>
<t>
This document introduces the Control Plane and User Plane separated BNG (Broadband Network Gateway) architecture and defines a set of associated terminology. It also specifies a set of protocol requirements for communication between the BNG-CP and the BNG-UPs in the Control Plane and User Plane Separated BNG.
</t>
  </abstract>

 </front>

 <middle>

  <!-- BEGIN 1. Introduction -->
  <section title="Introduction">
<t>
A Broadband Network Gateway (BNG) is an Ethernet-centric IP edge router and the aggregation point for user traffic.  To provide centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, the CU separated BNG is introduced [TR-384].  The CU separated Service Control Plane could be virtualized and centralized; it is responsible for user access authentication and sending forwarding entries to user planes. The routing control and forwarding plane, i.e. BNG user plane (local), could be distributed across the infrastructure.
</t>

<t>
This document introduces the Control Plane and User Plane separated BNG architecture and modeling. 
This document also defines the protocol requirements for Control Plane and User Plane Separated BNG (CUSP).
</t>
</section>
  <!-- END 1. Introduction -->

<!-- BEGIN 2. Terminology -->
  <section title="Concept and Terminology">
    <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

    </t>
	<section title="Terminology">
        <t>BNG: Broadband Network Gateway.  A broadband remote access server (BRAS, B-RAS or BBRAS) that 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).</t>
		<t>CP: Control Plane.  The CP is a user control management component which manages UP's resources such as the user entry and user's QoS policy.</t>
		<t>CUSP: Control Plane and User Plane Separated BNG Protocol.</t>
		<t>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.</t>		
      </section>
   </section>
  <!-- END 2. Terminology -->  

  
  <section title="CU Separated BNG Model">

<t>Figure 1 shows the architecture of CU separated BNG</t>
<t><figure>
<artwork>

    +------------------------------------------------------------------+
    |        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|  |
    | +---------------------------+      +--------------------------+  |
    +------------------------------------------------------------------+
                     Figure 1. Architecture of CU Separated BNG

</artwork>
</figure>
</t>
<t>
Briefly, a CU separated BNG is made up of a Control Plane (CP) and a set of User Planes (UPs) [TR-384], [I-D.cuspdt-rtgwg-cu-separation-bng-deployment].  The Control Plane is a user control management component which  manages UP's resources such as the user entry and user's Quality of Service (QoS) policy, for example, the access bandwidth and priority management.  This Control Plane could be virtualized and centralized.  The functional modules inside the BNG Service Control Plane can be implemented as Virutl 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 well as the setup, deletion, update, and maintenance of channels between control planes and user planes [TR-384], [I-D.cuspdt-rtgwg-cu-separation-bng-deployment].  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, multicast, etc [TR-384], [I-D.cuspdt-rtgwg-cu-separation-bng-deployment].
</t>
<section title="Internal interfaces between the CP and UP">
 <t>To support communication between the Control Plane and User Plane, several interfaces are involved. Figure 2 illustrates the three internal 
 	interfaces of CU Separated BNG.
 </t>
 <t><figure>

 <artwork>
                +----------------------------------+
                |                                  |
                |               BNG-CP             |
                |                                  |
                +--+--------------+--------------+-+
                   |              |              |
         1.Service |   2.Control  |  3.Management|
         Interface |   Interface  |   Interface  |
                   |              |              |
                +--+--------------+--------------+-+
                |                                  |
                |               BNG-UP             |
                |                                  |
                +----------------------------------+
                
       Figure 2. Interfaces between the BNG-CP and the BNG-UP
</artwork>
</figure>
</t>
<t>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.
</t>
<t>Control interface: The CP uses this interface to deliver service entries, and the UP uses this interface to report service events to the CP.
</t>
<t>Management interface: The CP uses this interface to deliver configurations to the UP.  This interface uses NETCONF.
</t>
<t>The CUSP (Control plane and User plane Separated BNG protocol) defines the control interface, and specifies the communication between the centralized control plane and user planes.
This protocol should be designed to support establishing and maintaining a conversation between CP and UPs, and transporting the tables that are specified in [draft-cuspdt-rtgwg-cu-separation-infor-model].  </t>
</section>

</section>
<section title="The usage of CU separation BNG protocol">
 <t><figure>

 <artwork>

                     -----------------
                 ////                 \\\\
             ////                         \\\\
           //          Cloud                  \\
          |                                     |
         |                                       |
        |                                         |
        |                                         |
         |        +-----------------+            |
          |       |  Control Plane  |           |
           \\     |                 |         //
             \\\\ +------+----------+     ////
                 \\\\    |            ////
                     ----+------------
                         | Control Interface (CUSP)
                +--------+----------+-------------+-----+
                |                   |             |     |
          User's information     IP  address     QoS:  .......
          May Include:            |            CIR;         :
          User ID;                  |            PIR;   |
          User MAC;                 |            CBS;   |
          Access method(PPPoE,      |            PBS;   |
          IPoE, etc)                |            ......
          ..... |                   |              |
                +-------------------V--------------+
                                    |
                        +-----------+
                        |                                    -------
                        |                                 ///       \\\
 +------+       +-------v---------+       +--------+     |             |
 | OLT  |       | User Plane      |       | Core   |    |    Internet   |
 |      +-------+                 +-------+ Routing+-----+             |
 +------+       +-----------------+       +--------+      \\\       ///
                                                             -------
                 Figure 3. CU Separation BNG protocol usage

</artwork>
</figure>
</t>
<t>
As shown in Figure 3, when users access the BNG network, the control plane solicits user information (such as user's ID, user's MAC, user's access methods, for example via PPPoE/IPoE), associates users with available bandwidth which is reported by User planes, and, based on the service's requirement, generates 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, parse them, and then perform corresponding actions.
</t>
</section>
<section title="Control Plane and User Plane Separation Protocol Requirements">
 <t>
This section specifies the requirements for the CU separation protocol.</t>
<section title="Transmit information tables ">
<t>
The Control Plane and User Plane Separation Protocol MUST allow the CP to send tables to each User Plane device. 
<list style="none"> 
<t>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.     
</t>
<t>b)	CU separation protocol should support data encoded as either XML or binary. It allows user information data to be read, saved, and manipulated with tools specific to XML or binary.</t>
<t>c)	In order to provide centralized session management, high scalability for subscriber management capacity, and cost-efficient redundancy, batching ability should be provided.  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 practical.  Furthermore, the protocol MUST support the ability to specify if a command group MUST have all-or-nothing semantics.
</t>
<t>d)  The CU Separation protocol SHOULD be able to support at least
   hundreds of UP devices and tens of thousands of ports.  For example,
   the protocol field sizes corresponding to UP or port numbers SHALL be
   large enough to support the minimum required numbers.  This
   requirement does not relate to the performance of the system as the
   number of UPs or ports in the system grows.
</t>
</list>
</t>

</section>


<section title="Message Priority">
<t>
The CU Separation protocol MUST provide a means to express the protocol message priorities.
</t>
</section>

<section title="Reliability">
<t>
Heartbeat is a periodic signal generated by hardware or software to test for some aspects of normal operation or to synchronize other parts of network system.  
</t>
<t>
In the CU separation BNG, a heartbeat is sent between CP and UPs at a regular interval on 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.
</t>
<t>
The CU separation protocol should support some kind of heartbeat monitoring 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. 
</t>
</section>

<section title="Support for Secure Communication">
<t>
As mentioned above, CP may send some information tables to the UP which may be critical to the network function (e.g, User Information, IPv4/IPv6 information) and may reflect the business information (e.g, QoS, service level agreements, etc).  Therefore, supporting the integrity of all CU Separation protocol messages and protecting against man-in-the-middle attacks MUST be supported.
</t>
<t>
The CP Separation protocol should support security in a variety of scenarios. For example, the connections between the CP and UPs could be dedicated lines, VPNs within one domain, or could cross several domains, that is, cross third party networks. Thus it is likely that more than one security mechanism SHOULD be supported. TLS and IPsec are good candidates for such mechanisms.
</t>
</section>

<section title="Version negotiation">
<t>
The CU separated BNG may consist of different vendors' devices implementing different versions of protocol. Threfore, the CU separation protocol MUST provide some mechanisms to perform the version negotiation.
</t>
<t>
Version negotiation is the process that the CU separated BNG's Control-Plane uses to evaluate the protocol versions supported by both the control-plane and the user-plane devices.  Then a suitable protocol version is selected for communication in CUSP.  The process is a "negotiation" because it requires identifying the most recent protocol version that is supported by both the control-plane and the user-plane devices or determining that they have no version in common.
</t>
</section>

<section title="Capability Exchange">
<t>
The UP Capability Report displays the device's profile, service capability, and other assigned capabilities within the CU separated BNG.  The CU separation protocol should MUST provide some mechanism to exchange the UP device's capabilities.
</t>
</section>

<section title="CP primary/backup capability">
<t>
A backup CP for failure recovery is required for the CU separated BNG network. And the CUSP should provide some mechanism to implement the backup CP: 
<list style="none"> 
<t>a) In some scenarios, there may be two CP devices both declaring the primary CP. Thus the CUSP should support or associate with some mechanisms to 
determine which CP is the primary device.
</t>
<t>b) In the scenario of the primary CP down, the CUSP should support switching between primary and backup CP. 
</t>
</list>
</t>
</section>

<section title="Event Notification">
<t>
The CUSP protocol SHOULD be able to asynchronously notify the CP of events on the UP such as failures and changes in available resources and capabilities.  Some scenarios that may initiate event notifications are listed below. 
<list style="none"> 
<t>a)	Sending response message: As mentioned above, the control plane solicits users' information, associates them with available bandwidth, 
and generates a set of tables based on the service’s requirement. Then the control plane transmits these tables to the conresponding User plane. 
The UP should respond with an event notification to inform the CP that the tables are received.
</t>
<t>b)	User trace: The user trace mechanism can support the Control Plane tracing and monitoring the network status for users (for example the real-time bandwidth, etc), to help debug the user's application.  Therefore, the UPs SHOULD be able to notify the CP with the User trace message.</t>
<t>
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 measure the BNG network performance. 
Available network resources can be allocated basing on the statistics parameters by the BNG-CP. Therefore, the UPs SHOULD be able to notify the CP with statistics parameters. 
</t>
<t>
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.
</t>

</list>
</t>
</section>

<section title="Query Statistics">
<t>
The CUSP protocol MUST provide a means for the CP to be able to query statistics (performance monitoring) from the UP.
</t>
</section>

</section>
	
	 

    
  

  <section title="Security Considerations">
    <t>
As this is an Informational requirements document, detailed technical Security Considerations are not included. However, Section 5.4 covers general security requirements and Section 5.7 covers backup requirements relevant to some denial of service scenarios.
    </t>
  </section>



  <section title="IANA Considerations">
    <t>
This document requires no IANA actions.
    </t>
  </section>


 </middle>

 <back>

  <references title="Normative References">

<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.I-D.draft-cuspdt-rtgwg-cu-separation-bng-deployment-00"?>
<?rfc include="reference.I-D.draft-cuspdt-rtgwg-cu-separation-infor-model-00"?>
  </references>
    <references title="Informative References">
      <reference anchor="TR-384">
        <front>
          <title> "Cloud Central Office Reference Architectural Framework", </title>

          <author>
            <organization>Broadband Forum</organization>
          </author>

          <date month="January." year="2018"/>
        </front>

        <seriesInfo name="BBF" value="TR-384"/>
      </reference>
    </references>

 </back>

</rfc>
