rtgwg S. Wadhwa Internet Draft K. DeSmedt Intended status: Informational P. Muley Expires: Apr 21, 2019 Nokia R. Shinde Reliance Jio J. Newton Vodafone R. Hoffman TELUS S. Pani Juniper Networks Oct 22, 2018 Requirements for Protocol between Control and User Plane on BNG draft-wadhwa-rtgwg-bng-cups-protocol-requirements-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 April 22, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Wadhwa, et al Expires April 22, 2019 [Page 1] Internet-Draft Architecture for BNG CUPS October 2018 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 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 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. An overall architecture and interfaces required between separated control and user-plane for a multi-access BNG are described in draft-wadhwa-rtgwg-bng-cups- 01.txt. This document discusses requirements for protocol between subscriber-management control-plane and user-plane for BNG to achieve separation. Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................3 2. Requirements for "CUPS protocol"...............................3 2.1. State Control Interface Requirements......................5 2.2. Extensibility.............................................8 2.3. Scalability and Performance...............................9 2.4. Transport Protocol.......................................10 2.5. In-band Control Channel Requirements.....................10 2.6. Resiliency...............................................12 2.7. Security.................................................13 3. "CUPS protocol" candidate.....................................13 4. Security Considerations.......................................14 5. IANA Considerations...........................................14 Wadhwa, et al. Expires April 22, 2019 [Page 2] Internet-Draft Architecture for BNG CUPS October 2018 6. References....................................................14 6.1. Normative References.....................................14 6.2. Informative References...................................15 1. Introduction This document describes a set of requirements for protocol between subscriber-management control and user plane for BNG, that need to be met, in order to achieve separation. 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 protocol between control and user-plane to achieve separation is referred to as "CUPS protocol". These requirements should form the basis for "CUPS protocol" selection. 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 are described in [CUPS]. 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. Requirements for "CUPS protocol" [CUPS] defines overall operation and architecture for control and user-plane separation on BNG. It also defines key functional interfaces between CP and UP, as shown in Fig 1, to realize the separation. "CUPS protocol" MUST provide support for information exchange to realize the "state control interface" and "in-band signaling channel" as defined in [CUPS]. Wadhwa, et al. Expires April 22, 2019 [Page 3] Internet-Draft Architecture for BNG CUPS October 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 April 22, 2019 [Page 4] Internet-Draft Architecture for BNG CUPS October 2018 2.1. State Control Interface Requirements . "CUPS protocol" MUST support convergence on BNG, where the CPEs terminating connections on the BNG can have fixed-access (e.g. xDSL/PON/Ethernet), fixed-wireless access (LTE/5G) or hybrid- access (i.e. combined fixed and wireless access). . "CUPS protocol" MUST support messages and information exchange for 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 the 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. . "CUPS protocol" MUST allow either node to update the association to report changed feature capabilities, overload condition, resource exhaustion or any other node-wide parameters. . "CUPS protocol" MUST provide support for UP to request a graceful association release from the CP. . "CUPS protocol" MUST support periodic node-level heartbeat exchange between CP and UP to detect if the peer is reachable and active. . "CUPS protocol" MUST support exchange of messages and information elements (IEs) between CP and UP for session level state management on the UP. A subscriber session is a single IP connection, such as an IPoE or PPPoE session. A CPE can have multiple sessions, if multiple IP connections are required (e.g. one per service, or one per device behind the CPE). The session level state on the UP, managed from the CP includes: o Data-plane state for forwarding data traffic from subscriber sessions in upstream direction (access to network), and downstream direction (network to access). o Forwarding state related to in-band control plane messages (such as messages for DHCP, PPPoE, SLAAC) that are forwarded Wadhwa, et al. Expires April 22, 2019 [Page 5] Internet-Draft Architecture for BNG CUPS October 2018 from CPE to CP via the UP (in upstream direction), and from CP to CPE via the UP (in downstream direction). . In addition to the basic forwarding state, the "CUPS protocol" MUST support messages and information elements (IEs) for CP to associate, update and disassociate other data-plane related state with the session e.g. state related to: o Filtering o SLA management o Statistics collection o Credit control (usage monitoring and reporting) o Traffic mirroring for legal intercept o NAT o Application (L4-L7) aware policies . Depending on the type of access and the network between access- nodes and the BNG, the subscriber traffic from the CPEs can be encapsulated and transported over an L2 connection or over an L3 tunnel. Common scenarios for fixed access include Ethernet (q-in- q,.1q), L2oGRE, L2TPv3, VxLAN, and MPLS PW. For fixed-wireless the access is over a GTP tunnel (as defined in [CUPS]). The tunnel transport for L3 tunneled subscriber traffic can IPv4 or IPv6. The subscriber traffic itself can be IPv4, IPv6 or PPPoE. In case of PPPoE, the BNG can terminate PPPoE or tunnel it over L2TP to another gateway. The data-plane on the BNG decapsulates the upstream (access->network) traffic and routes it towards the network in appropriate routing-context, and optionally perform NAT before routing. It determines the subscriber for downstream (network->access) IP traffic, encapsulates it appropriately before forwarding towards the access. In addition, it does traffic- management and SLA management, maintains traffic statistics and optionally monitors and reports usage. The "CUPS protocol" MUST be able to carry state from CP to UP for IPv4, IPv6 and PPPoE sessions, for various flavors of transport connections mentioned above. . Given the variety of access types on the CPE and type of transport networks between access-nodes and BNG (as outlined above) , the "CUPS protocol" MUST specify forwarding state information for the subscriber sessions, for both data and in-band control, as flexible packet matching rules and set of actions related to forwarding and traffic management, rather than just fixed-format lookup tables understood by particular UP implementation. Using the flexible match rules and actions conveyed in the "CUPS protocol" IEs, the UP should unambiguously be able to derive Wadhwa, et al. Expires April 22, 2019 [Page 6] Internet-Draft Architecture for BNG CUPS October 2018 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). o Direction Upstream - Access to Network: . Subscriber-session identification: Port/VLAN-tag(s) + subscriber-MAC + Session IP address + PPPoE Session-ID . Action: remove encapsulation (i.e. Ethernet and PPPoE/PPP headers), apply policer, do IP FIB lookup, forward to network. o Direction Downstream - Network to Access: . Subscriber-session identification: IP address . Action: apply subscriber-shaper, build encapsulation using (PPPoE session-id and Port/VLAN-tag(s)+ subscriber-MAC), forward to access. Examples of actions and processing related to forwarding and traffic management include encapsulation/decapsulation, table lookups, drop, forward, mirror, count, redirect, police, classify, queue, shape etc. . In addition to packet-matching rules and actions to setup data- path on the UP, the "CUPS protocol" MUST allow CP to specify subscriber routing and IP interface related information. This includes the following: o Aggregate IPv4 subnets and IPv6 prefixes that are used for assigning addresses or prefixes (e.g. IPv6 delegated- prefix) to subscribers on a UP. These are announced in routing by the UP to draw downstream traffic. o UE's IP address and subnet mask. o Default gateway IP address within the subscriber subnets. This is used to draw upstream traffic from the CPEs and the UP is required to respond to ICMP requests for this address from the CPEs. o Subnets for network behind a CPE (also known as framed- routes). Wadhwa, et al. Expires April 22, 2019 [Page 7] Internet-Draft Architecture for BNG CUPS October 2018 . The "CUPS protocol" MUST provide support for CP to specify session level HQOS related information to the UP. A common QOS hierarchy on BNG consists of at least a QoS layer per access-node, and per CPE. "CUPS protocol" MUST provide support for CP to specify QoS parameters (e.g. rates, queues, markings) and the QoS hierarchy to which the CPE belongs, to the UP. The CP may choose to signal this via a QoS policy that is locally pre-configured on the UP. "CUPS protocol" MUST provide support for CP to specify HQOS-policy that the session is associated with. . "CUPS protocol" MUST support asynchronous session level event notifications from UP to CP. Session level asynchronous notifications include: o Periodic usage-reports o Threshold based usage-reports o Inactivity timeout o Subscriber unreachability detection . "CUPS protocol" MUST support asynchronous node level event notifications from UP to CP. Example includes switchover notification in case ports or UP failures when node level redundancy is enabled. 2.2. Extensibility . "CUPS protocol" MUST support exchange of software version and feature capabilities when a node level association is setup between a CP and UP. . "CUPS protocol" MUST encode information in messages as TLVs. . "CUPS protocol" MUST allow extension to defined Information Elements (IEs) i.e. it MUST allow adding new information to existing IEs while maintaining backwards compatibility. . "CUPS protocol" MUST allow addition of new IEs exchanged in protocol messages. . "CUPS protocol" MUST support vendor specific IEs (modelled as TLVs) by carving out TLV space for vendor specific extensions. Wadhwa, et al. Expires April 22, 2019 [Page 8] Internet-Draft Architecture for BNG CUPS October 2018 . "CUPS protocol" processing on UP MUST support graceful handling when an unknown TLV is received. The UP MUST ignore unknown TLV and continue with normal message processing. This ensures the CP MAY send non-mandatory TLVs to the UP. However, CP MUST only send mandatory TLVs if it knows the UP will accept it (based on local configuration or based on capability exchange during association setup). A TLV is considered mandatory if session state cannot be installed or updated without it. 2.3. Scalability and Performance . A single CP VNF can control multiple UP nodes. Each UP can support its maximum scale of subscriber sessions as allowed by its data-plane. External control plane running as a VNF can horizontally scale-out as needed with the growth in CUPS system-wide subscriber scale. In typical deployments CP may be centralized whereas the UPs may be distributed, with multiple L2 or L3 hops between CP and UPs. There are scenarios where a large number of sessions may be getting created or deleted close in time via "CUPS protocol". It is important that latency to bring subscribers online is minimized. The transport protocol chosen for "CUPS protocol" MUST NOT suffer from head- of-line (HOL) blocking where transport of messages related to one subscriber can be adversely impacted by messages being exchanged for other subscribers. . "CUPS protocol" MUST limit chattiness by minimizing number of messages required to create fully functional subscriber on the UP with complete forwarding, traffic management, HQOS, and routing state. Ideally, a single request/response message exchange between CP and UP should be able to create subscriber with all the required state in the data-plane. The "CUPS protocol" message that creates the subscriber session MUST therefore be able to signal IEs for all the required subscriber state. . To further reduce latency the protocol MUST be binary encoded. . "CUPS protocol" MUST allow dynamic scale-out for control plane VNF with the growth in subscriber scale of the CUPS system, as more UPs are added to the CUPS system or more ports are enabled on a UP in a CUPS system. Wadhwa, et al. Expires April 22, 2019 [Page 9] Internet-Draft Architecture for BNG CUPS October 2018 . The "CUPS Protocol" MUST allow mechanism to provide balancing of processing load amongst compute resources of control-plane VNF that supports dynamic scale-out. . "CUPS protocol" SHOULD support signaling of overload state and optionally overload mitigation parameters from UP to CP, when UP determines the incoming signaling from CP is exceeding (or about to exceed) its nominal processing capacity. Overload mitigation can include a temporary message throttling on CP towards UP. Mitigation parameters can include message rate and validity time for the specified rate. 2.4. Transport Protocol . As mentioned in section 2.3, the transport protocol used for "CUPS protocol" MUST NOT suffer from HOL blocking. Therefore, TCP is not an option for the transport protocol. . Ideally, the transport protocol SHOULD preserve message boundary with datagram semantics and should be available or easily implementable on any simple forwarding devices. Therefore, UDP is the preferred option. . "CUPS protocol" MUST therefore support reliability and ordering for exchanged messages. The reliability and ordering can be based on request/response with message sequencing and re-transmissions. 2.5. In-band Control Channel Requirements . "CUPS protocol" MUST support setting up of control channel between UP and CP for transporting in-band control messages (e.g. DHCPv4/v6 and PPPoE) received on the UP (from CPEs) to the CP, and for return messages sent from CP to the UP (destined to CPEs). . There can be a L3 network between CP and UPs. Therefore, L3 tunneling is required between CP and UP to carry messages for in-band control plane protocols. "CUPS protocol" MUST support exchange of tunnel identifiers between CP and UP. Wadhwa, et al. Expires April 22, 2019 [Page 10] Internet-Draft Architecture for BNG CUPS October 2018 . Because L2 access setup is in-band, control plane messages will arrive on the UP before any per-session state is learned. Therefore, "CUPS protocol" MUST support messages and information exchange to install forwarding state related to in- band control plane messages that do not match any existing subscriber session. These messages should be forwarded to the CP over a common default control channel. . The in-band control channel setup by "CUPS protocol" MUST have support for UP to pass access-circuit identifier over which the signaling messages are received from the CPEs. Based on type of access, access-circuit identifier can include port/VLAN tags or tunnel identifiers which includes tunnel endpoint IPs and de- multiplexers such as GTP TEID, MPLS labels, L2TP tunnel-id etc. "CUPS protocol" MUST support setting up logically separate control channels for in-band control messages per access- circuit. . In case of fixed-access CPEs with Ethernet based network between access-nodes and BNG, the control messages are received in Ethernet frames. The Ethernet frame carrying the control messages received on UP MUST be carried over the control channel to the CP, as outlined in [CUPS]. In case of fixed- wireless access, control messages (e.g. DHCPv4 and DHCPv6) are received on the UP over GTP-u tunnel from the RAN. The GTP-u tunnel directly carries IP payload. Therefore, control channel setup via "CUPS protocol" MUST support transporting both Ethernet and IP payloads. . "CUPS protocol" MUST provide support for CP to specify the control protocols that should be forwarded by the UP over in- band control channel to the CP. . The "CUPS protocol" SHOULD have support for CP to specify rate- limits for specific control protocols and optionally specific messages within a control protocol, that the UP should enforce. . The "CUPS protocol" SHOULD provide support for CP to direct the UP to drop certain control messages received on a particular access-circuit. Wadhwa, et al. Expires April 22, 2019 [Page 11] Internet-Draft Architecture for BNG CUPS October 2018 . The "CUPS protocol" SHOULD provide support for CP to prioritize reception of certain control messages over others. 2.6. Resiliency . "CUPS protocol" MUST allow support for both 1:1 (hot standby) and N:M (warm standby) UP node level redundancy. . "CUPS protocol" MUST provide support for CP to specify the "redundancy domain" that a subscriber session is associated with during session level state creation on the UP. The "redundancy domain" is set of resources that share fate with respect to switchover on failure, e.g. a set of VLANs on a port, or a set of ports on a UP, or entire UP. "CUPS protocol" MUST also provide support for CP to provide relevant parameters to UP about the "redundancy domains". The UPs can then locally preform failure detection and switchover for the redundancy domains. . The "CUPS protocol" MUST provide support for UP to notify the CP about switchover event. This notification must be on the granularity of "redundancy domain" on a UP. . For warm standby redundancy, "CUPS protocol" MUST provide support for CP to create session level state on the backup UP node(s) for all subscribers associated with the impacted "redundancy domain". . "CUPS protocol" MUST support in-service software upgrade (ISSU) on UPs. The protocol MUST provide support for UP to notify CP when it is completed ISSU to the new software release. Wadhwa, et al. Expires April 22, 2019 [Page 12] Internet-Draft Architecture for BNG CUPS October 2018 2.7. Security "CUPS protocol" MUST be compatible with proven security mechanisms such as IPSEC or DTLS to satisfy following security requirements: . Data-integrity and confidentiality MUST be ensured for the information exchanged via "CUPS protocol". . Protection against man-in-the-middle attacks MUST be provided. . Anti-replay protection MUST be provided. 3. "CUPS protocol" candidate 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 and can be extended for BNG providing converged access. The protocol provides a good base for satisfying the requirements outlined in this draft for BNG "CUPS protocol". Following are some of the key attributes of this protocol/ . It supports management of forwarding and QOS enforcement state on the UP from CP. . It also supports usage reporting from UP to CP. . It is over UDP transport and doesn't suffer from any HOL blocking. . It provides reliable operation based on request/response with message sequencing and retransmissions. . It provides support for graceful handling of overload on UP. . The protocol is extensible and allows addition of new IEs. . For fixed access BNG, the protocol requires simple extensions in the 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 Wadhwa, et al. Expires April 22, 2019 [Page 13] Internet-Draft Architecture for BNG CUPS October 2018 addresses), whereas mobile access works in terms of L3, either routed or tunneled. . [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 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 forward or block certain control packets from 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 by introducing an additional NSH (network services header) to carry any required meta-data. 4. 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. 5. IANA Considerations None. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [CUPS] Wadhwa, S. et al., "Architecture for control and user plane separation on BNG, July 2019. https://datatracker.ietf.org/doc/draft-wadhwa-rtgwg-bng- cups/ Wadhwa, et al. Expires April 22, 2019 [Page 14] Internet-Draft Architecture for BNG CUPS October 2018 [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. 6.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 April 22, 2019 [Page 15] Internet-Draft Architecture for BNG CUPS October 2018 Authors' Addresses Sanjay Wadhwa Nokia 777 East Middlefield Road Mountain View USA Email: Sanjay.wadhwa@nokia.com Wadhwa, et al. Expires April 22, 2019 [Page 16] Internet-Draft Architecture for BNG CUPS October 2018 Killian De Smedt Nokia Copernicuslaan 50 Antwerp Belgium Email: Killian.de_smedt@nokia.com Praveen Muley Nokia 805. E. Middle Field Rd. Mountain View, CA, 94043 USA Email: praveen.muley@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 Jonathan Newton Vodafone Waterside House Bracknell United Kingdom Email: jonathan.newton@vodafone.com Ryan Hoffman TELUS 1525 10th Ave SW Calgary, Alberta Canada Email: ryan.hoffman@telus.com Wadhwa, et al. Expires April 22, 2019 [Page 17] Internet-Draft Architecture for BNG CUPS October 2018 Subrat Pani Juniper Networks 10 Technology Park Dr. Westford, MA USA Email: spani@juniper.net Wadhwa, et al. Expires April 22, 2019 [Page 18]