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

Versions: 00 01

rtgwg                                                         S. Wadhwa
Internet Draft                                               K. DeSmedt
Intended status: Informational                                    Nokia
Expires: Jan 2, 2019                                          R. Shinde
                                                           Reliance Jio
                                                           July 2, 2018




         Architecture for Control and User Plane Separation on BNG
                    draft-wadhwa-rtgwg-bng-cups-00.txt


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 2, 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
   (http://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



Wadhwa, et al          Expires January 2, 2019                 [Page 1]


Internet-Draft        Architecture for BNG CUPS               July 2018


   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.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.

Abstract

   This document discusses separation of subscriber-management control
   plane and data-plane for BNG. Traditionally, the BNG provides
   aggregation of fixed access nodes (such as DSLAM and OLTs) over
   Ethernet and provides subscriber management and traffic management
   functions for residential subscribers. The BNG has however evolved
   to become a multi-access edge device that also provides termination
   of subscribers over fixed-wireless and hybrid access. Therefore,
   this document proposes interfaces between control and user-plane of
   a BNG that can support multi-access BNG.

Table of Contents


   1. Introduction...................................................3
      1.1. Requirements Language.....................................3
   2. CUPS for BNG...................................................3
      2.1. Convergence...............................................6
   3. Interfaces for CUPS............................................7
      3.1. In-band Signaling Channel.................................7
      3.2. State Control Interface...................................8
         3.2.1. Session level state management.......................9
         3.2.2. Session level event notifications...................14
         3.2.3. Node level management...............................15
      3.3. Management Interface.....................................16
   4. Protocol Selection for CUPS Interfaces........................17
   5. Address Pool Management.......................................18
   6. Security Considerations.......................................18
   7. IANA Considerations...........................................18
   8. References....................................................19
      8.1. Normative References.....................................19
      8.2. Informative References...................................19





Wadhwa, et al.         Expires January 2, 2019                 [Page 2]


Internet-Draft        Architecture for BNG CUPS               July 2018


1. Introduction

   This document describes requirements and architecture for separation
   of subscriber management control plane and user plane for the BNG.
   In rest of the document the control plane is referred to as CP, user
   plane as UP, and the separation is referred to as CUPS (control and
   user plane separation). The draft describes the functional
   decomposition between CP and UP, and applicability of CUPS to a BNG
   that can support multiple access technologies such as fixed (DSL or
   Fiber), fixed-wireless (LTE,5G) and hybrid access i.e. simultaneous
   fixed and wireless access described in BBF [WT378]. The subsequent
   sections of the draft also define the interfaces required between CP
   and UP and briefly discusses a candidate base protocol for these
   interfaces.



1.1. Requirements Language

   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 RFC 2119 [RFC2119].

2. CUPS for BNG

   In a CUPS architecture, signaling to setup subscriber sessions CP
   terminates signaling to setup subscriber sessions, and interfaces
   with the UP to create forwarding state for these sessions on the UP.

   For fixed access subscribers, the CP terminates the signaling
   protocols (e.g. DHCP, PPPoE, SLAAC) from the customer premise,
   performs authorization/authentication with AAA Server, participates
   in address assignment, and then interfaces with the UP to create
   state related to forwarding and SLA management for the subscriber
   sessions on the UP. A subscriber session is a single IP connection,
   such as an IPoE or PPPoE session. The session can be single-stack
   (IPv4 or IPv6 only), or dual-stack (both IPv4 and IPv6). A CPE can
   have multiple sessions, if multiple IP connections are required
   (e.g. on per service, or one per device behind the CPE).

   The CP also processes solicited or unsolicited event notifications
   from the UP e.g. periodic accounting updates, usage reports, or
   session inactivity notifications. The interface between CP and UP
   that is used by the CP to manage session related forwarding state on
   the UP is being referred to as "state control interface".
   Asynchronous event notifications from UP to CP are also part of this
   interface.


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


Internet-Draft        Architecture for BNG CUPS               July 2018


   In typical fixed access deployments, signaling (e.g. DHCPv4/v6,
   PPPoE, ICMPv6 RS/RA) to setup the subscriber sessions is in-band,
   and hence the UP receives the signaling messages from the customer
   premise. The UP should transparently forward (unmodified) in-band
   control messages as received from the customer premise to the CP and
   return messages from CP to the customer premise. Therefore, an in-
   band signaling channel is required between UP and CP. With a typical
   "CUPS BNG" deployment, the CP and UP are connected over a network,
   and the in-band signaling channel must be over a tunnel.

   The UP performs forwarding and traffic management for the subscriber
   sessions. The infrastructure routing and signaling is done on the
   local control plane of the UP for fast convergence on network
   topology changes.

   A typical deployment architecture for CUPS includes a centralized CP
   running as a VNF interacting with multiple BNG UP instances that may
   be more distributed than the CP and could run as VNF or PNF. In this
   model, the CP and UP association is 1:N. This composite system
   containing CP VNF and one or more UP instances is referred to as a
   "CUPS BNG" in rest of the document. For operational ease, the CP
   MUST provide a single point for control and management for the
   entire "CUPS BNG". It MUST expose a single interface on behalf of
   the "CUPS BNG" to external systems such as AAA servers, OSS/BSS,
   Policy and charging servers. The CP VNF MUST support scale-out in
   order to cope with growth in number of subscriber sessions and/or
   increase in number of UP instances in the "CUPS BNG". Figure 1 below
   shows the functional components and interfaces for a "CUPS BNG".





















Wadhwa, et al.         Expires January 2, 2019                 [Page 4]


Internet-Draft        Architecture for BNG CUPS               July 2018




               +--------------------------------------+
               | +--------+ +-----+  +-----+  +-----+ |
               | | AAA    | |PCRF |  | OCS |  | OSS | |
               | | Server | +-----+  +-----+  +-----+ |
               | +--------+                           |
               +----------------+---------------------+
                                |
                                |
    "CUPS BNG"                  |
   +----------------------------+------------------------------------+
   |   CP                                                            |
   |   +--------------------------+--------------------------------+ |
   |   | +-----------+ +------------------+ +--------+ +---------+ | |
   |   | | Address   | | PPPoE, DHCPv4/v6 | | RADIUS | | S11/N11 | | |
   |   | | Pool Mmmt | | IPv6 RS/RA,      | | CLIENT | +---------+ | |
   |   | +-----------+ | L2TP LAC         | +--------+             | |
   |   |               +------------------+  +----+  +----+        | |
   |   |                                     | Gx |  | Gy |        | |
   |   |                                     +----+  +----+        | |
   |   +-----------------------------------------------------------+ |
   |          |                  |                   |               |
   |          | Management       |In-band            | State         |
   |          | Interface        |Signaling          | Control       |
   |          |                  |Channel            | Interface     |
   |          |                  |                   |               |
   |  --------+--+------------------+--+----------------+---+------- |
   |          |                        |                    |        |
   |    UP    |               UP       |            UP      |        |
   |    +-----+---------+    +---------+-----+    +---------+-----+  |
   |    | Local CP      |    | Local CP      |    | Local CP      |  |
   |    | Routing, MPLS |    | Routing, MPLS |    | Routing, MPLS |  |
   |    | IGMP, BFD     |    | IGMP, BFD     |    | IGMP, BFD     |  |
   |    +---------------+    +---------------+    +---------------+  |
   |    | Forwarding    |    | Forwarding    |    | Forwarding    |  |
   |    | Traffic Mgmt  |    | Traffic Mgmt  |    | Traffic Mgmt  |  |
   |    +---------------+    +---------------+    +---------------+  |
   |                                                                 |
   +-----------------------------------------------------------------+

                                  CUPS BNG System







Wadhwa, et al.         Expires January 2, 2019                 [Page 5]


Internet-Draft        Architecture for BNG CUPS               July 2018




2.1. Convergence

   A single BNG can support subscribers over fixed, "fixed-wireless" or
   hybrid access. When a residential gateway has fixed-wireless access
   (LTE or 5G), then the BNG participates in 3GPP signaling with an MME
   or AMF (i.e. support 3GPP S11 and N11 interfaces) to setup
   connections from (NG)RAN. With Hybrid access the customer premise
   initiates both fixed and wireless connections. The BNG in this case
   aggregates subscribers over Ethernet from fixed access nodes (DSLAMs
   and OLTs), but simultaneously terminates connections from (NG)RAN by
   participating in signaling with MME or AMF (S11/N11 interface).
   These deployment models are drivers for fixed-mobile convergence. It
   is important to ensure that the interfaces between CP and UP for
   CUPS can support not only fixed L2 access, but also the converged
   access scenario shown in Figure 2. One key requirement on the CP in
   these cases is the need to participate in 3GPP signaling (which is
   out-of-band) to setup the data-path. The data-path is a GTP-u (GPRS
   Tunneling protocol - User Plane) tunnel from the RAN (i.e. S1-u
   interface for LTE) as described in 3GPP [TS29281], and it terminates
   on the UP. It carries data traffic but also subscriber signaling
   messages (e.g. DHCPv4, DHCPv6, SLAAC) from the customer premise. The
   UP therefore still requires an in-band signaling channel to
   transport these protocol messages to the CP.



        CUPS-BNG
            +-------------------+  S11    +----------+
            |     +------+      |(GTP-c)  | +------+ |
            |     |  CP  |------|---------|-|  MME | |
            |     +---+--+      |         | +------+ |
            |         |         |         | +------+ |
            |         |         |       +-|-| RAN  | |--+     +-----+
            |   ------+-----    |  S1-u | | +------+ |   \    |     |
            |     |       |     |(GTP-u)| +----------+    +---|     |
            |     |       |     | (DHCP |                     | CPE |
            |     |       |     | SLAAC)|                     |     |
            |   +----+  +----+  | (Data)|                 +---|     |
            |   | UP |  | UP |--|-------+     +-----+    /    +-----+
            |   |    |  |    |--|-------------| AN  |---+
            |   +----+  +----+  |    Eth      +-----+
            |                   | (DHCP,PPPoE)
            +-------------------+   (Data)

                          "CUPS BNG" with Converged Access


Wadhwa, et al.         Expires January 2, 2019                 [Page 6]


Internet-Draft        Architecture for BNG CUPS               July 2018




3. Interfaces for CUPS

   A "CUPS BNG" MUST support the following interfaces between CP and
   UP, as shown in the figure in section 2.

3.1. In-band Signaling Channel

   Section 2 describes the need for a signaling channel between CP and
   UP to transport in-band control messages between CP and the customer
   premise. Following are some key requirements for this interface.

     . The UP MUST pass the access circuit identifier over which the
        signaling messages are received as meta-data to the CP. This
        includes port, VLAN tags, tunnel endpoint IPs, any tunnel
        identifiers such as GTP TEID, MPLS labels, L2TP tunnel-id etc.
        The UP MUST also pass the L2 or L3 transport service that the
        access circuit is associated with. In case the control message
        PDU is carried in an Ethernet frame, then the UP SHOULD pass
        the received Ethernet frame to the CP. Both access circuit
        identifier and information in the Ethernet header are required
        by the CP to construct successful response packet (control
        message) back towards the customer premise.  The access circuit
        identifier MUST be reflected from CP to UP, so UP can identify
        the access circuit over which it needs to send the CP's
        response packet. In the control message sent from UP to CP, the
        UP MUST also include the local MAC address associated with
        access circuit. This is because certain control messages from
        the customer premise are destined to a broadcast MAC (e.g. DHCP
        DISCOVER) or multicast (e.g. ICMPv6 RS), so CP cannot infer the
        local MAC from these messages. Certain messages also require
        the local MAC address to be inserted in the message (e.g. Link-
        Layer address in ICMPv6 RA messages)

     . The CP MUST be able to control the UP to forward only specific
        control messages to the CP.

     . The CP MUST be able to control the UP to block certain control
        messages received on a particular access circuit.

     . The CP MUST be able to control the UP to limit the rate of
        control messages (of specified type) to be sent by the UP.

     . The CP MUST be able to prioritize reception of certain control
        messages over others in a granular manner (e.g. prioritize DHCP



Wadhwa, et al.         Expires January 2, 2019                 [Page 7]


Internet-Draft        Architecture for BNG CUPS               July 2018


        RENEWS over DISCOVERS or prioritize PPP Keepalive over other
        messages).

     . The in-band signaling channel MUST support both fixed and
        converged access as described in section 2.1. The tunnel used
        for transporting these messages should therefore support both
        Ethernet and IP payloads.



3.2. State Control Interface

   The CP and UP can exchange sate at two levels using the "state
   control interface". One is at the node level and includes node-level
   information such as supported features, software releases, available
   resources, and operational state (e.g. active, failed, or
   overloaded). The other is at the subscriber session level.
   Subscriber session is described in section 2. The session level
   state includes basic forwarding and traffic management rules per
   session, that need to be provided by the CP to the UP in order to
   control per session forwarding and traffic management on the UP. It
   also includes state that triggers routing related actions on the UP.
   The session level state can include asynchronous event notifications
   from UP to CP, such as notifications to report per session usage
   (periodically or based on thresholds), notification to report
   session inactivity, and session liveness.

   The interactions between CP and UP over "state control interface"
   can be categorized as:

   o Session level state management
   o Session level event notifications
   o Node level management

   Following sub-sections provide more details on these interactions.
   The interactions between CP and UP over "state control interface"
   are modeled via abstract request/response messages between CP and
   UP. These messages will need to be defined as part of the protocol
   specification for this interface.

   The protocol selected to implement this interface MUST support both
   fixed access and converged access (described in section 2.1) on BNG







Wadhwa, et al.         Expires January 2, 2019                 [Page 8]


Internet-Draft        Architecture for BNG CUPS               July 2018


3.2.1. Session level state management

   Once the CP has successfully authorized and/or authenticated the
   subscriber session, and completed address assignment, it uses the
   "state control interface" to install forwarding and related state
   for the session on the forwarding path of the UP. This is abstracted
   as a "session create request" call from CP to UP, as shown in the
   figure below. The UP MUST ack or NACK via a response back to CP.

   Since BNG can support different access types (e.g. fixed L2 access,
   or tunneled L3 in case of fixed-wireless, or a combination in case
   of hybrid access), it is important that the forwarding state
   information for the subscriber sessions, sent from CP to UP, can be
   specified as flexible packet matching rules and set of actions
   related to forwarding and traffic management. The UP should be able
   to use these match rules and actions to derive various lookup tables
   and processing in the forwarding path to forward traffic to and from
   the CPE.

   The basic forwarding state in upstream direction (i.e. access to
   network) and downstream direction (i.e. network to access)
   fundamentally consists of session identification and one or more
   actions. Following shows a logical representation of a directive
   from CP to UP to install basic forwarding state on the UP for fixed
   L2 access (i.e. access from DSLAM or OLTs over Ethernet).

     Direction Upstream - Access to Network:
      Subscriber-identification: Port/VLAN-tag(s) + subscriber-MAC
      Action: remove encapsulation, IP FIB lookup, forward to network.

     Direction Downstream - Network to Access:
      Subscriber-identification: IP address
      Action: lookup IP DA, build encapsulation using Port/VLAN-tag(s)+
     subscriber-MAC, forward to access.

   Optionally, the IP address assigned to the CPE can also be provided
   for subscriber-identification (e.g. for anti-spoofing) in the
   upstream direction.
   In case of PPPoE sessions, the subscriber-identification for
   upstream direction and encapsulation for downstream direction also
   includes the PPPoE session-id.

   Based on the directive from CP to UP (as shown in the example
   above), the UP can then populate appropriate tables in the
   forwarding path, e.g. subscriber lookup tables, IP-FIB, and ARP or
   IPv6 Neighbor discovery table. It can also program the packet



Wadhwa, et al.         Expires January 2, 2019                 [Page 9]


Internet-Draft        Architecture for BNG CUPS               July 2018


   processing in both upstream and downstream direction based on the
   specified actions.


   In case of "fixed-wireless" access, the access circuit is a GTP-u
   tunnel. In this case there is no physical interface (or port), and
   hence the CP MUST provide a tunnel definition to the UP to use as
   access circuit in upstream direction, and encapsulation in
   downstream direction. The tunnel definition will include the tunnel
   endpoint IP, and TEID that is established via out-of-band signaling
   between the CP and the customer premise. It can also include the
   routing context for transporting the tunnel.


   In addition to setting up the forwarding state as directed by the
   CP, the UP also needs to announce in routing the aggregate prefixes
   from which the CP assigns IPv4 and IPv6 addresses (or prefixes) to
   the CPEs. The CP SHOULD provide these aggregate prefixes to the UP
   as part session state. In case the aggregate prefixes are not
   provided, the UP MUST announce individual CPE addresses in routing,
   or it MAY try to aggregate in case addresses for multiple CPEs are
   from a contiguous address space.

   The CPE can have a routed subnet behind it (aka framed-route). CP
   can learn the framed-routes during authentication/authorization. The
   CP should provide the framed-route to the UP as part of session
   state. The UP MUST install this route in the forwarding path and
   associate it with the forwarding state of the corresponding
   subscriber session. It should also announce this in routing towards
   the Network.

   The CP MUST also provide to the UP the address assigned as IP
   gateway address to the CPEs in DHCP. The UP MUST locally configure
   this address appropriately, such that it can respond to ARP requests
   for this address from the CPEs.

   The session sate on the UP is always controlled by the CP i.e. the
   UP just follows the directive from the CP to install, modify and
   delete the session state. In addition to the basic forwarding state,
   the CP can also associate, update and disassociate other related
   state with the session e.g. state related to:

     . Filtering
     . SLA management
     . Statistics collection
     . Credit control
     . Traffic mirroring for legal intercept


Wadhwa, et al.         Expires January 2, 2019                [Page 10]


Internet-Draft        Architecture for BNG CUPS               July 2018


     . NAT
     . Application aware policies



   BNG deployments use hierarchical QoS (H-QOS) models which follows
   from a combination of link-layer over-subscription, multi-service
   networks and multiple layers of aggregation. For example, a common
   hierarchy exists of at least a QoS layer per access-node, and per
   CPE. The CP MUST provide SLA management information to the UP per
   CPE. This includes applicable QoS parameters (e.g. rates, queues,
   markings) and the QoS hierarchy to which the CPE belongs. The CP may
   choose to signal this via a QoS policy that is locally pre-
   configured on the UP.



































Wadhwa, et al.         Expires January 2, 2019                [Page 11]


Internet-Draft        Architecture for BNG CUPS               July 2018


                                                              +------+
       +---+          +---+                    +---+          | AAA  |
       |CPE|          |UP |                    |CP |          |Server|
       +---+          +---+                    +---+          +------+
         |DHCP Discover |                         |               |
         |------------->|                         |               |
         |              |                         |               |
         |              |     DHCP Discover       |               |
         |              |-----------------------> |               |
         |              |In-band signaling channel|               |
         |              |                         |               |
         |              |                         |Access Request |
         |              |                         |-------------->|
         |              |                         |               |
         |              |                         |Access Accept  |
         |              |                         |<--------------|
         |              |                         |               |
         |              |      DHCP Offer         |               |
         |              |<------------------------|               |
         |              |In-band signaling channel|               |
         | DHCP Offer   |                         |               |
         |<-------------|                         |               |
         |              |                         |               |
         |DHCP Request  |                         |               |
         |------------->|                         |               |
         |              |                         |               |
         |              |     DHCP Request        |               |
         |              |-----------------------> |               |
         |              | In-band signaling channel
         |              |                         |               |
         |              | Session Creation Req    |               |
         |              |<----------------------- |               |
         |              |                         |               |
         |              | Session Creation Resp.  |               |
         |              |-----------------------> |               |
         |              |                         |               |
         |              |                         |               |
         |              |      DHCP ACK           |               |
         |              |<----------------------- |               |
         |              |In-band signaling channel|               |
         |  DHCP Ack    |                         |               |
         |<-------------|                         |               |
       +---+          +---+                    +---+          +------+
       |CPE|          |UP |                    |CP |          | AAA  |
       +---+          +---+                    +---+          |Server|
                                                              +------+
                             Session Creation Sequence


Wadhwa, et al.         Expires January 2, 2019                [Page 12]


Internet-Draft        Architecture for BNG CUPS               July 2018




   CP can trigger update of session state on the UP, triggered by re-
   authentication or COA from AAA or policy-server, as show in the
   figure below.

                                               +------+
       +---+                    +---+          | AAA  |
       |UP |                    |CP |          |Server|
       +---+                    +---+          +--+---+
         |                        | CoA Request   |
         |                        |<--------------|
         |                        |               |
         | Session Modify Req     |               |
         |<-----------------------|               |
         |                        |               |
         | Session Modify Resp    |               |
         |----------------------->|               |
         |                        |               |
         |                        |   CoA Ack     |
         |                        |-------------->|
       +---+                    +---+          +--+---+
       |UP |                    |CP |          | AAA  |
       +---+                    +---+          |Server|
                                               +------+

                                Session Modification

   CP can trigger the deletion of session state based on signaling
   messages (as shown in the figure below), administrative action or
   disconnect-message initiated from the AAA server.


















Wadhwa, et al.         Expires January 2, 2019                [Page 13]


Internet-Draft        Architecture for BNG CUPS               July 2018


       +---+             +---+             +---+       +-------+
       |CPE|             |UP |             |CP |       | AAA   |
       +---+             +---+             +---+       |Server |
         | DHCP Release    | DHCP Release    |         +-------+
         |---------------->|---------------->|               |
         |                 |                 |               |
         |                 | Session Del Req |               |
         |                 |<----------------|               |
         |                 |                 |               |
         |                 | Session Del Resp|               |
         |                 | (final usage)   | Acct Stop     |
         |                 |---------------->|(final usage)  |
         |                 |                 |-------------->|
         |                 |                 } Acct Stop Resp|
         |                 |                 |<--------------|
       +---+              +---+            +----+         +-------+
       |CPE|              |UP |            | CP |         | AAA   |
       +---+              +---+            +----+         |Server |
                                                          +-------+

                                  Session Deletion



3.2.2. Session level event notifications

   UP can asynchronously generate Session level event notifications to
   the CP. An example of asynchronous notification is periodic usage
   reporting from UP to the CP, so that the CP can report the usage to
   a AAA server via interim accounting-updates. The CP can set the
   periodicity of this notification on the UP based on interim
   accounting interval configured by the operator on the CP.

















Wadhwa, et al.         Expires January 2, 2019                [Page 14]


Internet-Draft        Architecture for BNG CUPS               July 2018


                                                +------+
       +---+                    +---+           | AAA  |
       |UP |                    |CP |           |Server|
       +---+                    +---+           +------+
         |                        |                |
         |                        |                |
         |Async Event Notification|                |
         | (periodic usage)       |                |
         |----------------------->|                |
         |                        |                |
         |Async Event Response    |                |
         |<-----------------------|Acct Update Req |
         |                        |--------------->|
         |                        |Acct Update Resp|
         |                        |<---------------|
       +---+                    +---+           +------+
       |UP |                    |CP |           | AAA  |
       +---+                    +---+           |Server|
                                                +------+

                    Async Event Notification for periodic usage



   Following are some other examples requiring asynchronous
   notifications from UP to CP.

          o Threshold based usage reporting
          o Inactivity timeout
          o Subscriber unreachability detection


   The protocol for "state control interface" MUST support asynchronous
   notifications from UP to CP.



3.2.3. Node level management

There needs to exist a concept of association between CP and UP. When
the CP or UP comes online it should setup an association with
configured or discovered peers via a message exchange. In association
setup, the nodes should be able to exchange supported capabilities,
version of software, load/overload information, and resource
information. Also, any node-wide parameters can be exchanged during
association setup.



Wadhwa, et al.         Expires January 2, 2019                [Page 15]


Internet-Draft        Architecture for BNG CUPS               July 2018


No session state related messages should be accepted from the peer by
either CP or UP unless an association exists.

Either node should be able to update the association to report changed
feature capabilities, overload condition, resource exhaustion or any
other node-wide parameters.

The UP should be able to request a graceful association release from
the CP. In this case the CP should delete all sessions from that UP and
process the final stats report for each session and send it in
accounting-stop to the AAA server. During this process the CP MUST not
create new sessions on the UP. Once all sessions are successfully
deleted, the CP should release the association.

There needs to be a periodic node-level heartbeat exchange between CP
and UP to detect if the peer is reachable and active. If peer is
determined to be down based on heartbeat messages, then all the session
state associated with the peer should be deleted.


       +---+                    +---+
       |UP |                    |CP |
       +---+                    +---+
         |                        |
         |                        |
         | Association Setup Req  |
         |----------------------->|
         |                        |
         | Association Setup Resp |
         |<-----------------------|
         |                        |
         | Periodic Heartbeats    |
         |<---------------------->|
         |                        |
       +---+                    +---+
       |UP |                    |CP |
       +---+                    +---+


                       Node Association Setup and Maintenance



3.3. Management Interface

   The CP MUST provide a single point for management of entire "CUPS
   BNG" to the operator. This includes managing configuration and state


Wadhwa, et al.         Expires January 2, 2019                [Page 16]


Internet-Draft        Architecture for BNG CUPS               July 2018


   of the CP and all the associated UPs. A management interface MUST be
   supported between CP and each of its associated UPs for pushing
   configuration to the UP and retrieving operational state from the
   UP. A model driven NETCONF interface is a candidate for the
   management interface.



4. Protocol Selection for CUPS Interfaces

   It is important that the selected protocol for "state control
   interface" between CP and UP works not just for fixed access but
   also works for converged access on BNG. 3GPP has defined PFCP
   (Packet Forwarding Control Protocol) in [TS29244] as the interface
   between CP and UP for LTE gateways. This protocol is suited for
   large scale state management between CP and UP. Following are some
   of the key attributes of this protocol:

     o It supports management of forwarding and QOS enforcement state
        on the UP from CP. It also supports usage reporting from UP to
        CP.
     o It is over UDP transport and doesn't suffer from any HOL
        blocking.
     o It provides reliable operation based on request/response with
        message sequencing and retransmissions.
     o It provides an overload control procedure where overload on UP
        can be handled gracefully.
     o The protocol is extensible and allows addition of new IEs.


     For fixed access BNG, the protocol requires simple extensions in
     form of additional IEs. The required extensions are mainly due to
     fact that typically a fixed access BNG requires tighter control
     over L2 behavior and manages access and subscriber using L2
     identifiers (such as VLANs and MAC addresses), whereas mobile
     access works in terms of L3, either routed or tunneled.

     The details of the protocol as applicable to the BNG and the
     required extensions will be defined in a separate draft.

     [TS29244] also describes an in-band signaling channel based on
     GTP-u tunnel between CP and UP. GTP-u (GPRS Tunneling protocol -
     User Plane) is defined in 3GPP [TS29281] and defines a tunneling
     protocol which carries IP payloads. The protocol runs over a
     UDP/IP stack and uses UDP port number 2152. Data within a tunnel
     can be multiplexed based on Tunnel Endpoint Identifiers (TEIDs).
     The protocol supports optional sequence numbers. The protocol


Wadhwa, et al.         Expires January 2, 2019                [Page 17]


Internet-Draft        Architecture for BNG CUPS               July 2018


     supports extension headers to allow development of new features.
     GTP-u tunnels are signaled between CP and UP, and it is possible
     to associate filters to block certain control packets from being
     forwarded form UP to CP. The payload type carried by GTP-u can be
     extended to Ethernet (via payload type in extension header). The
     tunnel encapsulation can also be extended similarly to carry any
     required meta-data.



5. Address Pool Management

   The CP MUST support management of IPv4 and IPv6 address pools, where
   each pool can contain one or more subnets. The pool management MUST
   support pool selection based on one or more of the following
   criteria:

     o UP
     o Access port on the UP.
     o Redundancy domain on the UP (e.g. set of access ports that
        share fate with respect to switchovers due to failures, when UP
        node level redundancy is enabled).
     o Service (e.g. HSI, VoIP, IPTV etc.).
     o Location (e.g. based on circuit-id/remote-id or part of
        circuit-id/remote-id in DHCP and PPPoE).

   Pool management on CP SHOULD NOT statically link subnets to UPs but
   SHOULD dynamically allocate subnets to UP based on load i.e. on-
   demand, and signal allocated subnets using the "state control
   interface" as described in section 3.2.1. This allows for better IP
   resource utilization and less subnet fragmentation.



6. Security Considerations

   For security between CP and UP, Network Domain Security (NDS) as
   defined in [TS33210] can be considered. As per NDS, the network can
   be split into security domains. Communication within a single
   security domain is considered secure, and protocols can operate
   without any additional security. When communication has to cross
   security domains, then IPSEC can be used.

7. IANA Considerations

   None.



Wadhwa, et al.         Expires January 2, 2019                [Page 18]


Internet-Draft        Architecture for BNG CUPS               July 2018


8. References

8.1. Normative References

  [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [TS29244]   3GPP, "Interface between the Control Plane and the User
               Plane Nodes", TS 29.244 15.2.0, June 2018,
               https://portal.3gpp.org/desktopmodules/Specifications/Sp
               ecificationDetails.aspx?specificationId=3111.

   [TS29281]   3GPP, "General Packet Radio System (GPRS) Tunneling
               Protocol User Plane (GTPv1-U)", TS 29.281 15.3.0, June
               2018,
               https://portal.3gpp.org/desktopmodules/Specifications/Sp
               ecificationDetails.aspx?specificationId=1699.

  [TS33210]    3GPP, "Network Domain Security (NDS); IP network layer
               security", TS 33.210 15.0.0, June 2018,
               https://portal.3gpp.org/desktopmodules/Specifications/
               SpecificationDetails.aspx?specificationId=2279.

  [WT378]     BBF, "Nodal Requirements for Hybrid Access Broadband
               Networks", WT-378, 2018.





8.2. Informative References

  [RFC2131]    Droms, R., "Dynamic Host Configuration Protocol", RFC
               2131, DOI 10.17487/RFC2131, March 1997, https://www.rfc-
               editor.org/info/rfc2131.

  [RFC2516]    Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone,
               D., and R. Wheeler, "A Method for Transmitting PPP Over
               Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
               February 1999, https://www.rfc-editor.org/info/rfc2516.

  [RFC3315]    Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
               C., and M. Carney, "Dynamic Host Configuration Protocol
               for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
               2003, https://www.rfc-editor.org/info/rfc3315.




Wadhwa, et al.         Expires January 2, 2019                [Page 19]


Internet-Draft        Architecture for BNG CUPS               July 2018


Authors' Addresses

   Sanjay Wadhwa
   Nokia
   777 East Middlefield Road
   Mountain View
   USA

   Email: Sanjay.wadhwa@nokia.com


   Killian De Smedt
   Nokia
   Copernicuslaan 50
   Antwerp
   Belgium

   Email: Killian.de_smedt@nokia.com


   Rajesh Shinde
   Reliance Jio Infocomm Ltd.
   Reliance Corporate Park
   Thane Belapur Road, Ghansoli
   Navi Mumbai 400710
   India

   Email: Rajesh.A.Shinde@ril.com





















Wadhwa, et al.         Expires January 2, 2019                [Page 20]


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