idnits 2.17.1 draft-wadhwa-rtgwg-bng-cups-protocol-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Dec 14, 2018) is 1959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2131' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC2516' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 650, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 rtgwg S. Wadhwa 2 Internet Draft K. DeSmedt 3 Intended status: Informational P. Muley 4 Expires: Jun 13, 2019 Nokia 5 R. Shinde 6 Reliance Jio 7 J. Newton 8 Vodafone 9 R. Hoffman 10 TELUS 11 S. Pani 12 Juniper Networks 13 Dec 14, 2018 15 Requirements for Protocol between Control and User Plane on BNG 16 draft-wadhwa-rtgwg-bng-cups-protocol-requirements-01.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on April 17, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. 63 Abstract 65 Traditionally, the BNG provides aggregation of fixed access nodes 66 (such as DSLAM and OLTs) over Ethernet and provides subscriber 67 management and traffic management functions for residential 68 subscribers. The BNG has however evolved to become a multi-access 69 edge device that also provides termination of subscribers over 70 fixed-wireless and hybrid access. An overall architecture and 71 interfaces required between separated control and user-plane for a 72 multi-access BNG are described in draft-wadhwa-rtgwg-bng-cups- 73 01.txt. This document discusses requirements for protocol between 74 subscriber-management control-plane and user-plane for BNG to 75 achieve separation. 77 Contents 78 1. Introduction...................................................3 79 1.1. Requirements Language.....................................3 80 2. Requirements for "CUPS protocol"...............................3 81 2.1. State Control Interface Requirements......................5 82 2.2. Extensibility.............................................8 83 2.3. Scalability and Performance...............................9 84 2.4. Transport Protocol.......................................10 85 2.5. In-band Control Channel Requirements.....................10 86 2.6. Resiliency...............................................12 87 2.7. Security.................................................13 88 3. "CUPS protocol" candidate.....................................13 89 4. Security Considerations.......................................14 90 5. Management Interface Requirements.............................14 91 6. IANA Considerations...........................................15 92 7. References....................................................15 93 7.1. Normative References.....................................15 94 7.2. Informative References...................................16 96 1. Introduction 98 This document describes a set of requirements for protocol between 99 subscriber-management control and user plane for BNG, that need to 100 be met, in order to achieve separation. In rest of the document the 101 control plane is referred to as CP, user plane as UP, and the 102 separation is referred to as CUPS (control and user plane 103 separation). The protocol between control and user-plane to achieve 104 separation is referred to as "CUPS protocol". These requirements 105 should form the basis for "CUPS protocol" selection. The functional 106 decomposition between CP and UP, and applicability of CUPS to a BNG 107 that can support multiple access technologies such as fixed (DSL or 108 Fiber), fixed-wireless (LTE,5G) and hybrid access are described in 109 [CUPS]. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Requirements for "CUPS protocol" 119 [CUPS] defines overall operation and architecture for control and 120 user-plane separation on BNG. It also defines key functional 121 interfaces between CP and UP, as shown in Fig 1, to realize the 122 separation. "CUPS protocol" MUST provide support for information 123 exchange to realize the "state control interface" and "in-band 124 signaling channel" as defined in [CUPS]. 126 +--------------------------------------+ 127 | +--------+ +-----+ +-----+ +-----+ | 128 | | AAA | |PCRF | | OCS | | OSS | | 129 | | Server | +-----+ +-----+ +-----+ | 130 | +--------+ | 131 +----------------+---------------------+ 132 | 133 | 134 "CUPS BNG" | 135 +----------------------------+------------------------------------+ 136 | CP | 137 | +--------------------------+--------------------------------+ | 138 | | +-----------+ +------------------+ +--------+ +---------+ | | 139 | | | Address | | PPPoE, DHCPv4/v6 | | RADIUS | | S11/N11 | | | 140 | | | Pool Mmmt | | IPv6 RS/RA, | | CLIENT | +---------+ | | 141 | | +-----------+ | L2TP LAC | +--------+ | | 142 | | +------------------+ +----+ +----+ | | 143 | | | Gx | | Gy | | | 144 | | +----+ +----+ | | 145 | +-----------------------------------------------------------+ | 146 | | | | | 147 | | Management |In-band | State | 148 | | Interface |Signaling | Control | 149 | | |Channel | Interface | 150 | | | | | 151 | --------+--+------------------+--+----------------+---+------- | 152 | | | | | 153 | UP | UP | UP | | 154 | +-----+---------+ +---------+-----+ +---------+-----+ | 155 | | Local CP | | Local CP | | Local CP | | 156 | | Routing, MPLS | | Routing, MPLS | | Routing, MPLS | | 157 | | IGMP, BFD | | IGMP, BFD | | IGMP, BFD | | 158 | +---------------+ +---------------+ +---------------+ | 159 | | Forwarding | | Forwarding | | Forwarding | | 160 | | Traffic Mgmt | | Traffic Mgmt | | Traffic Mgmt | | 161 | +---------------+ +---------------+ +---------------+ | 162 | | 163 +-----------------------------------------------------------------+ 165 CUPS BNG System 167 2.1. State Control Interface Requirements 169 . "CUPS protocol" MUST support convergence on BNG, where the CPEs 170 terminating connections on the BNG can have fixed-access (e.g. 171 xDSL/PON/Ethernet), fixed-wireless access (LTE/5G) or hybrid- 172 access (i.e. combined fixed and wireless access). 174 . "CUPS protocol" MUST support messages and information exchange for 175 node level management. There needs to exist a concept of 176 association between CP and UP. When the CP or UP comes online it 177 should setup an association with the configured or discovered 178 peers via a message exchange. In association setup, the nodes 179 should be able to exchange supported capabilities, version of 180 software, load/overload information, and resource information. 181 Also, any node-wide parameters can be exchanged during association 182 setup. 184 . "CUPS protocol" MUST allow either node to update the association 185 to report changed feature capabilities, overload condition, 186 resource exhaustion or any other node-wide parameters. 188 . "CUPS protocol" MUST provide support for UP to request a graceful 189 association release from the CP. 191 . "CUPS protocol" MUST support periodic node-level heartbeat 192 exchange between CP and UP to detect if the peer is reachable and 193 active. 195 . "CUPS protocol" MUST support exchange of messages and information 196 elements (IEs) between CP and UP for session level state 197 management on the UP. 198 A subscriber session is a single IP connection, such as an IPoE or 199 PPPoE session. A CPE can have multiple sessions, if multiple IP 200 connections are required (e.g. one per service, or one per device 201 behind the CPE). The session level state on the UP, managed from 202 the CP includes: 204 o Data-plane state for forwarding data traffic from subscriber 205 sessions in upstream direction (access to network), and 206 downstream direction (network to access). 208 o Forwarding state related to in-band control plane messages 209 (such as messages for DHCP, PPPoE, SLAAC) that are forwarded 210 from CPE to CP via the UP (in upstream direction), and from 211 CP to CPE via the UP (in downstream direction). 212 . In addition to the basic forwarding state, the "CUPS protocol" 213 MUST support messages and information elements (IEs) for CP to 214 associate, update and disassociate other data-plane related state 215 with the session e.g. state related to: 216 o Filtering 217 o SLA management 218 o Statistics collection 219 o Credit control (usage monitoring and reporting) 220 o Traffic mirroring for legal intercept 221 o NAT 222 o Application (L4-L7) aware policies 224 . Depending on the type of access and the network between access- 225 nodes and the BNG, the subscriber traffic from the CPEs can be 226 encapsulated and transported over an L2 connection or over an L3 227 tunnel. Common scenarios for fixed access include Ethernet (q-in- 228 q,.1q), L2oGRE, L2TPv3, VxLAN, and MPLS PW. For fixed-wireless the 229 access is over a GTP tunnel (as defined in [CUPS]). The tunnel 230 transport for L3 tunneled subscriber traffic can IPv4 or IPv6. The 231 subscriber traffic itself can be IPv4, IPv6 or PPPoE. In case of 232 PPPoE, the BNG can terminate PPPoE or tunnel it over L2TP to 233 another gateway. The data-plane on the BNG decapsulates the 234 upstream (access->network) traffic and routes it towards the 235 network in appropriate routing-context, and optionally perform NAT 236 before routing. It determines the subscriber for downstream 237 (network->access) IP traffic, encapsulates it appropriately before 238 forwarding towards the access. In addition, it does traffic- 239 management and SLA management, maintains traffic statistics and 240 optionally monitors and reports usage. The "CUPS protocol" MUST 241 be able to carry state from CP to UP for IPv4, IPv6 and PPPoE 242 sessions, for various flavors of transport connections mentioned 243 above. 245 . Given the variety of access types on the CPE and type of transport 246 networks between access-nodes and BNG (as outlined above) , the 247 "CUPS protocol" MUST specify forwarding state information for the 248 subscriber sessions, for both data and in-band control, as 249 flexible packet matching rules and set of actions related to 250 forwarding and traffic management, rather than just fixed-format 251 lookup tables understood by particular UP implementation. Using 252 the flexible match rules and actions conveyed in the "CUPS 253 protocol" IEs, the UP should unambiguously be able to derive 254 various lookup tables and processing in the forwarding path to 255 forward traffic to and from the CPE. The basic forwarding state in 256 upstream direction (i.e. access to network) and downstream 257 direction (i.e. network to access) fundamentally consists of 258 session identification and one or more actions. Following shows a 259 logical representation of a directive from CP to UP to install 260 basic forwarding state on the UP for fixed L2 access (i.e. access 261 from DSLAM or OLTs over Ethernet). 263 o Direction Upstream - Access to Network: 264 . Subscriber-session identification: Port/VLAN-tag(s) 265 + subscriber-MAC + Session IP address + PPPoE 266 Session-ID 267 . Action: remove encapsulation (i.e. Ethernet and 268 PPPoE/PPP headers), apply policer, do IP FIB 269 lookup, forward to network. 271 o Direction Downstream - Network to Access: 272 . Subscriber-session identification: IP address 273 . Action: apply subscriber-shaper, build 274 encapsulation using (PPPoE session-id and 275 Port/VLAN-tag(s)+ subscriber-MAC), forward to 276 access. 278 Examples of actions and processing related to forwarding and 279 traffic management include encapsulation/decapsulation, table 280 lookups, drop, forward, mirror, count, redirect, police, classify, 281 queue, shape etc. 283 . In addition to packet-matching rules and actions to setup data- 284 path on the UP, the "CUPS protocol" MUST allow CP to specify 285 subscriber routing and IP interface related information. This 286 includes the following: 288 o Aggregate IPv4 subnets and IPv6 prefixes that are used for 289 assigning addresses or prefixes (e.g. IPv6 delegated- 290 prefix) to subscribers on a UP. These are announced in 291 routing by the UP to draw downstream traffic. 292 o UE's IP address and subnet mask. 293 o Default gateway IP address within the subscriber subnets. 294 This is used to draw upstream traffic from the CPEs and 295 the UP is required to respond to ICMP requests for this 296 address from the CPEs. 297 o Subnets for network behind a CPE (also known as framed- 298 routes). 300 . The "CUPS protocol" MUST provide support for CP to specify session 301 level HQOS related information to the UP. A common QOS hierarchy 302 on BNG consists of at least a QoS layer per access-node, and per 303 CPE. "CUPS protocol" MUST provide support for CP to specify QoS 304 parameters (e.g. rates, queues, markings) and the QoS hierarchy to 305 which the CPE belongs, to the UP. The CP may choose to signal this 306 via a QoS policy that is locally pre-configured on the UP. "CUPS 307 protocol" MUST provide support for CP to specify HQOS-policy that 308 the session is associated with. 310 . "CUPS protocol" MUST support asynchronous session level event 311 notifications from UP to CP. Session level asynchronous 312 notifications include: 314 o Periodic usage-reports 315 o Threshold based usage-reports 316 o Inactivity timeout 317 o Subscriber unreachability detection 319 . "CUPS protocol" MUST support asynchronous node level event 320 notifications from UP to CP. Example includes switchover 321 notification in case ports or UP failures when node level 322 redundancy is enabled. 324 2.2. Extensibility 326 . "CUPS protocol" MUST support exchange of software version and 327 feature capabilities when a node level association is setup 328 between a CP and UP. 330 . "CUPS protocol" MUST encode information in messages as TLVs. 332 . "CUPS protocol" MUST allow extension to defined Information 333 Elements (IEs) i.e. it MUST allow adding new information to 334 existing IEs while maintaining backwards compatibility. 336 . "CUPS protocol" MUST allow addition of new IEs exchanged in 337 protocol messages. 339 . "CUPS protocol" MUST support vendor specific IEs (modelled as 340 TLVs) by carving out TLV space for vendor specific extensions. 342 . "CUPS protocol" processing on UP MUST support graceful handling 343 when an unknown TLV is received. The UP MUST ignore unknown TLV 344 and continue with normal message processing. This ensures the 345 CP MAY send non-mandatory TLVs to the UP. However, CP MUST only 346 send mandatory TLVs if it knows the UP will accept it (based on 347 local configuration or based on capability exchange during 348 association setup). A TLV is considered mandatory if session 349 state cannot be installed or updated without it. 351 2.3. Scalability and Performance 353 . A single CP VNF can control multiple UP nodes. Each UP can 354 support its maximum scale of subscriber sessions as allowed by 355 its data-plane. External control plane running as a VNF can 356 horizontally scale-out as needed with the growth in CUPS 357 system-wide subscriber scale. In typical deployments CP may be 358 centralized whereas the UPs may be distributed, with multiple 359 L2 or L3 hops between CP and UPs. There are scenarios where a 360 large number of sessions may be getting created or deleted 361 close in time via "CUPS protocol". It is important that latency 362 to bring subscribers online is minimized. The transport 363 protocol chosen for "CUPS protocol" MUST NOT suffer from head- 364 of-line (HOL) blocking where transport of messages related to 365 one subscriber can be adversely impacted by messages being 366 exchanged for other subscribers. 368 . "CUPS protocol" MUST limit chattiness by minimizing number of 369 messages required to create fully functional subscriber on the 370 UP with complete forwarding, traffic management, HQOS, and 371 routing state. Ideally, a single request/response message 372 exchange between CP and UP should be able to create subscriber 373 with all the required state in the data-plane. The "CUPS 374 protocol" message that creates the subscriber session MUST 375 therefore be able to signal IEs for all the required subscriber 376 state. 378 . To further reduce latency the protocol MUST be binary encoded. 380 . "CUPS protocol" MUST allow dynamic scale-out for control plane 381 VNF with the growth in subscriber scale of the CUPS system, as 382 more UPs are added to the CUPS system or more ports are enabled 383 on a UP in a CUPS system. 385 . The "CUPS Protocol" MUST allow mechanism to provide balancing 386 of processing load amongst compute resources of control-plane 387 VNF that supports dynamic scale-out. 389 . "CUPS protocol" SHOULD support signaling of overload state and 390 optionally overload mitigation parameters from UP to CP, when 391 UP determines the incoming signaling from CP is exceeding (or 392 about to exceed) its nominal processing capacity. Overload 393 mitigation can include a temporary message throttling on CP 394 towards UP. Mitigation parameters can include message rate and 395 validity time for the specified rate. 397 2.4. Transport Protocol 399 . As mentioned in section 2.3, the transport protocol used for 400 "CUPS protocol" MUST NOT suffer from HOL blocking. 401 Therefore, TCP is not an option for the transport protocol. 403 . Ideally, the transport protocol SHOULD preserve message 404 boundary with datagram semantics and should be available or 405 easily implementable on any simple forwarding devices. 406 Therefore, UDP is the preferred option. 408 . "CUPS protocol" MUST therefore support reliability and 409 ordering for exchanged messages. The reliability and 410 ordering can be based on request/response with message 411 sequencing and re-transmissions. 413 2.5. In-band Control Channel Requirements 415 . "CUPS protocol" MUST support setting up of control channel 416 between UP and CP for transporting in-band control messages 417 (e.g. DHCPv4/v6 and PPPoE) received on the UP (from CPEs) to 418 the CP, and for return messages sent from CP to the UP 419 (destined to CPEs). 421 . There can be a L3 network between CP and UPs. Therefore, L3 422 tunneling is required between CP and UP to carry messages for 423 in-band control plane protocols. "CUPS protocol" MUST support 424 exchange of tunnel identifiers between CP and UP. 426 . Because L2 access setup is in-band, control plane messages will 427 arrive on the UP before any per-session state is learned. 428 Therefore, "CUPS protocol" MUST support messages and 429 information exchange to install forwarding state related to in- 430 band control plane messages that do not match any existing 431 subscriber session. These messages should be forwarded to the 432 CP over a common default control channel. 434 . The in-band control channel setup by "CUPS protocol" MUST have 435 support for UP to pass access-circuit identifier over which the 436 signaling messages are received from the CPEs. Based on type of 437 access, access-circuit identifier can include port/VLAN tags or 438 tunnel identifiers which includes tunnel endpoint IPs and de- 439 multiplexers such as GTP TEID, MPLS labels, L2TP tunnel-id etc. 440 "CUPS protocol" MUST support setting up logically separate 441 control channels for in-band control messages per access- 442 circuit. 444 . In case of fixed-access CPEs with Ethernet based network 445 between access-nodes and BNG, the control messages are received 446 in Ethernet frames. The Ethernet frame carrying the control 447 messages received on UP MUST be carried over the control 448 channel to the CP, as outlined in [CUPS]. In case of fixed- 449 wireless access, control messages (e.g. DHCPv4 and DHCPv6) are 450 received on the UP over GTP-u tunnel from the RAN. The GTP-u 451 tunnel directly carries IP payload. Therefore, control channel 452 setup via "CUPS protocol" MUST support transporting both 453 Ethernet and IP payloads. 455 . "CUPS protocol" MUST provide support for CP to specify the 456 control protocols that should be forwarded by the UP over in- 457 band control channel to the CP. 459 . The "CUPS protocol" SHOULD have support for CP to specify rate- 460 limits for specific control protocols and optionally specific 461 messages within a control protocol, that the UP should enforce. 463 . The "CUPS protocol" SHOULD provide support for CP to direct the 464 UP to drop certain control messages received on a particular 465 access-circuit. 467 . The "CUPS protocol" SHOULD provide support for CP to prioritize 468 reception of certain control messages over others. 470 2.6. Resiliency 472 . "CUPS protocol" MUST allow support for both 1:1 (hot standby) 473 and N:M (warm standby) UP node level redundancy. 475 . "CUPS protocol" MUST provide support for CP to specify the 476 "redundancy domain" that a subscriber session is associated 477 with during session level state creation on the UP. The 478 "redundancy domain" is set of resources that share fate with 479 respect to switchover on failure, e.g. a set of VLANs on a 480 port, or a set of ports on a UP, or entire UP. "CUPS protocol" 481 MUST also provide support for CP to provide relevant parameters 482 to UP about the "redundancy domains". The UPs can then locally 483 preform failure detection and switchover for the redundancy 484 domains. 486 . The "CUPS protocol" MUST provide support for UP to notify the 487 CP about switchover event. This notification must be on the 488 granularity of "redundancy domain" on a UP. 490 . For warm standby redundancy, "CUPS protocol" MUST provide 491 support for CP to create session level state on the backup UP 492 node(s) for all subscribers associated with the impacted 493 "redundancy domain". 495 . "CUPS protocol" MUST support in-service software upgrade (ISSU) 496 on UPs. The protocol MUST provide support for UP to notify CP 497 when it is completed ISSU to the new software release. 499 2.7. Security 501 "CUPS protocol" MUST be compatible with proven security mechanisms 502 such as IPSEC or DTLS to satisfy following security requirements: 504 . Data-integrity and confidentiality MUST be ensured for the 505 information exchanged via "CUPS protocol". 507 . Protection against man-in-the-middle attacks MUST be provided. 509 . Anti-replay protection MUST be provided. 511 3. "CUPS protocol" candidate 513 3GPP has defined PFCP (Packet Forwarding Control Protocol) in 514 [TS29244] as the interface between CP and UP for LTE gateways. This 515 protocol is suited for large scale state management between CP and 516 UP and can be extended for BNG providing converged access. The 517 protocol provides a good base for satisfying the requirements 518 outlined in this draft for BNG "CUPS protocol". Following are some 519 of the key attributes of this protocol/ 521 . It supports management of forwarding and QOS enforcement state 522 on the UP from CP. 524 . It also supports usage reporting from UP to CP. 526 . It is over UDP transport and doesn't suffer from any HOL 527 blocking. 529 . It provides reliable operation based on request/response with 530 message sequencing and retransmissions. 532 . It provides support for graceful handling of overload on UP. 534 . The protocol is extensible and allows addition of new IEs. 536 . For fixed access BNG, the protocol requires simple extensions 537 in the form of additional IEs. The required extensions are 538 mainly due to fact that typically a fixed access BNG requires 539 tighter control over L2 behavior and manages access and 540 subscriber using L2 identifiers (such as VLANs and MAC 541 addresses), whereas mobile access works in terms of L3, either 542 routed or tunneled. 544 . [TS29244] also describes an in-band signaling channel based on 545 GTP-u tunnel between CP and UP. GTP-u (GPRS Tunneling protocol 546 User Plane) is defined in 3GPP [TS29281] and defines a 547 tunneling protocol which carries IP payloads. The protocol runs 548 over a UDP/IP stack and uses UDP port number 2152. Data within 549 a tunnel can be multiplexed based on Tunnel Endpoint 550 Identifiers (TEIDs). The protocol supports optional sequence 551 numbers. The protocol supports extension headers to allow 552 development of new features. GTP-u tunnels are signaled between 553 CP and UP, and it is possible to associate filters to forward 554 or block certain control packets from UP to CP. The payload 555 type carried by GTP-u can be extended to Ethernet (via payload 556 type in extension header). The tunnel encapsulation can also be 557 extended by introducing an additional NSH (network services 558 header) to carry any required meta-data. 560 4. Security Considerations 562 For security between CP and UP, Network Domain Security (NDS) as 563 defined in [TS33210] can be considered. As per NDS, the network can 564 be split into security domains. Communication within a single 565 security domain is considered secure, and protocols can operate 566 without any additional security. When communication has to cross 567 security domains, then IPSEC can be used. 569 5. Management Interface Requirements 571 . The CP MUST provide a single point for management of entire 572 "CUPS BNG" to the operator. 574 . Management interface for the CUPS system MUST provide support 575 for both configuration of UPs, and state retrieval. 577 . Management interface MUST support transactional configuration 578 from CP to UPs, based on a well-defined data schema. 579 Transactional configuration may be achieved by editing a 580 candidate configuration on the UP which is subsequently 581 activated (commit) or by providing the whole transaction in a 582 single command. In case UP data-stores are used, it MUST be 583 possible for the CP to lock a data-store for exclusive access. 585 . The management interface MUST support transaction confirmation, 586 where an unconfirmed transaction gets reverted automatically 587 after a timeout even if the transaction succeeded. This is to 588 avoid configuration errors where a valid configuration breaks 589 communication between UP and CP, requiring on-site 590 intervention. 592 . The management interface MUST support state retrieval based on 593 a well-defined data schema. This includes retrieval for any 594 state that is not signaled via the state control interface. 596 . The management interface MUST support unsolicited signaling of 597 state changes (events) from UP to CP i.e. MUST provide 598 telemetry for events. Even while state changes are sent 599 unsolicited, the CP SHOULD be able to subscribe to a specific 600 subset of state it is interested in. 602 . The management interface MUST provide security through an 603 existing mechanism such as (D)TLS or IPSEC to guarantee 604 confidentiality and authenticity and protect against replay and 605 man in the middle attacks. 607 6. IANA Considerations 609 None. 611 7. References 613 7.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [CUPS] Wadhwa, S. et al., "Architecture for control and user 619 plane separation on BNG, July 2019. 620 https://datatracker.ietf.org/doc/draft-wadhwa-rtgwg-bng- 621 cups/ 623 [TS29244] 3GPP, "Interface between the Control Plane and the User 624 Plane Nodes", TS 29.244 15.2.0, June 2018, 625 https://portal.3gpp.org/desktopmodules/Specifications/Sp 626 ecificationDetails.aspx?specificationId=3111. 628 [TS29281] 3GPP, "General Packet Radio System (GPRS) Tunneling 629 Protocol User Plane (GTPv1-U)", TS 29.281 15.3.0, June 630 2018, 631 https://portal.3gpp.org/desktopmodules/Specifications/Sp 632 ecificationDetails.aspx?specificationId=1699. 634 [TS33210] 3GPP, "Network Domain Security (NDS); IP network layer 635 security", TS 33.210 15.0.0, June 2018, 636 https://portal.3gpp.org/desktopmodules/Specifications/ 637 SpecificationDetails.aspx?specificationId=2279. 639 7.2. Informative References 641 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 642 2131, DOI 10.17487/RFC2131, March 1997, https://www.rfc- 643 editor.org/info/rfc2131. 645 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, 646 D., and R. Wheeler, "A Method for Transmitting PPP Over 647 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 648 February 1999, https://www.rfc-editor.org/info/rfc2516. 650 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 651 C., and M. Carney, "Dynamic Host Configuration Protocol 652 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 653 2003, https://www.rfc-editor.org/info/rfc3315. 655 Authors' Addresses 657 Sanjay Wadhwa 658 Nokia 659 777 East Middlefield Road 660 Mountain View 661 USA 663 Email: Sanjay.wadhwa@nokia.com 664 Killian De Smedt 665 Nokia 666 Copernicuslaan 50 667 Antwerp 668 Belgium 670 Email: Killian.de_smedt@nokia.com 672 Praveen Muley 673 Nokia 674 805. E. Middle Field Rd. 675 Mountain View, CA, 94043 676 USA 678 Email: praveen.muley@nokia.com 680 Rajesh Shinde 681 Reliance Jio Infocomm Ltd. 682 Reliance Corporate Park 683 Thane Belapur Road, Ghansoli 684 Navi Mumbai 400710 685 India 687 Email: Rajesh.A.Shinde@ril.com 689 Jonathan Newton 690 Vodafone 691 Waterside House 692 Bracknell 693 United Kingdom 695 Email: jonathan.newton@vodafone.com 697 Ryan Hoffman 698 TELUS 699 1525 10th Ave SW 700 Calgary, Alberta 701 Canada 703 Email: ryan.hoffman@telus.com 704 Subrat Pani 705 Juniper Networks 706 10 Technology Park Dr. 707 Westford, MA 708 USA 710 Email: spani@juniper.net