idnits 2.17.1 draft-wadhwa-rtgwg-bng-cups-protocol-requirements-00.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 (Oct 22, 2018) is 1984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2131' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC2516' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 611, 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: Apr 21, 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 Oct 22, 2018 15 Requirements for Protocol between Control and User Plane on BNG 16 draft-wadhwa-rtgwg-bng-cups-protocol-requirements-00.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 22, 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. IANA Considerations...........................................14 91 6. References....................................................14 92 6.1. Normative References.....................................14 93 6.2. Informative References...................................15 95 1. Introduction 97 This document describes a set of requirements for protocol between 98 subscriber-management control and user plane for BNG, that need to 99 be met, in order to achieve separation. In rest of the document the 100 control plane is referred to as CP, user plane as UP, and the 101 separation is referred to as CUPS (control and user plane 102 separation). The protocol between control and user-plane to achieve 103 separation is referred to as "CUPS protocol". These requirements 104 should form the basis for "CUPS protocol" selection. The functional 105 decomposition between CP and UP, and applicability of CUPS to a BNG 106 that can support multiple access technologies such as fixed (DSL or 107 Fiber), fixed-wireless (LTE,5G) and hybrid access are described in 108 [CUPS]. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. Requirements for "CUPS protocol" 118 [CUPS] defines overall operation and architecture for control and 119 user-plane separation on BNG. It also defines key functional 120 interfaces between CP and UP, as shown in Fig 1, to realize the 121 separation. "CUPS protocol" MUST provide support for information 122 exchange to realize the "state control interface" and "in-band 123 signaling channel" as defined in [CUPS]. 125 +--------------------------------------+ 126 | +--------+ +-----+ +-----+ +-----+ | 127 | | AAA | |PCRF | | OCS | | OSS | | 128 | | Server | +-----+ +-----+ +-----+ | 129 | +--------+ | 130 +----------------+---------------------+ 131 | 132 | 133 "CUPS BNG" | 134 +----------------------------+------------------------------------+ 135 | CP | 136 | +--------------------------+--------------------------------+ | 137 | | +-----------+ +------------------+ +--------+ +---------+ | | 138 | | | Address | | PPPoE, DHCPv4/v6 | | RADIUS | | S11/N11 | | | 139 | | | Pool Mmmt | | IPv6 RS/RA, | | CLIENT | +---------+ | | 140 | | +-----------+ | L2TP LAC | +--------+ | | 141 | | +------------------+ +----+ +----+ | | 142 | | | Gx | | Gy | | | 143 | | +----+ +----+ | | 144 | +-----------------------------------------------------------+ | 145 | | | | | 146 | | Management |In-band | State | 147 | | Interface |Signaling | Control | 148 | | |Channel | Interface | 149 | | | | | 150 | --------+--+------------------+--+----------------+---+------- | 151 | | | | | 152 | UP | UP | UP | | 153 | +-----+---------+ +---------+-----+ +---------+-----+ | 154 | | Local CP | | Local CP | | Local CP | | 155 | | Routing, MPLS | | Routing, MPLS | | Routing, MPLS | | 156 | | IGMP, BFD | | IGMP, BFD | | IGMP, BFD | | 157 | +---------------+ +---------------+ +---------------+ | 158 | | Forwarding | | Forwarding | | Forwarding | | 159 | | Traffic Mgmt | | Traffic Mgmt | | Traffic Mgmt | | 160 | +---------------+ +---------------+ +---------------+ | 161 | | 162 +-----------------------------------------------------------------+ 164 CUPS BNG System 166 2.1. State Control Interface Requirements 168 . "CUPS protocol" MUST support convergence on BNG, where the CPEs 169 terminating connections on the BNG can have fixed-access (e.g. 170 xDSL/PON/Ethernet), fixed-wireless access (LTE/5G) or hybrid- 171 access (i.e. combined fixed and wireless access). 173 . "CUPS protocol" MUST support messages and information exchange for 174 node level management. There needs to exist a concept of 175 association between CP and UP. When the CP or UP comes online it 176 should setup an association with the configured or discovered 177 peers via a message exchange. In association setup, the nodes 178 should be able to exchange supported capabilities, version of 179 software, load/overload information, and resource information. 180 Also, any node-wide parameters can be exchanged during association 181 setup. 183 . "CUPS protocol" MUST allow either node to update the association 184 to report changed feature capabilities, overload condition, 185 resource exhaustion or any other node-wide parameters. 187 . "CUPS protocol" MUST provide support for UP to request a graceful 188 association release from the CP. 190 . "CUPS protocol" MUST support periodic node-level heartbeat 191 exchange between CP and UP to detect if the peer is reachable and 192 active. 194 . "CUPS protocol" MUST support exchange of messages and information 195 elements (IEs) between CP and UP for session level state 196 management on the UP. 197 A subscriber session is a single IP connection, such as an IPoE or 198 PPPoE session. A CPE can have multiple sessions, if multiple IP 199 connections are required (e.g. one per service, or one per device 200 behind the CPE). The session level state on the UP, managed from 201 the CP includes: 203 o Data-plane state for forwarding data traffic from subscriber 204 sessions in upstream direction (access to network), and 205 downstream direction (network to access). 207 o Forwarding state related to in-band control plane messages 208 (such as messages for DHCP, PPPoE, SLAAC) that are forwarded 209 from CPE to CP via the UP (in upstream direction), and from 210 CP to CPE via the UP (in downstream direction). 211 . In addition to the basic forwarding state, the "CUPS protocol" 212 MUST support messages and information elements (IEs) for CP to 213 associate, update and disassociate other data-plane related state 214 with the session e.g. state related to: 215 o Filtering 216 o SLA management 217 o Statistics collection 218 o Credit control (usage monitoring and reporting) 219 o Traffic mirroring for legal intercept 220 o NAT 221 o Application (L4-L7) aware policies 223 . Depending on the type of access and the network between access- 224 nodes and the BNG, the subscriber traffic from the CPEs can be 225 encapsulated and transported over an L2 connection or over an L3 226 tunnel. Common scenarios for fixed access include Ethernet (q-in- 227 q,.1q), L2oGRE, L2TPv3, VxLAN, and MPLS PW. For fixed-wireless the 228 access is over a GTP tunnel (as defined in [CUPS]). The tunnel 229 transport for L3 tunneled subscriber traffic can IPv4 or IPv6. The 230 subscriber traffic itself can be IPv4, IPv6 or PPPoE. In case of 231 PPPoE, the BNG can terminate PPPoE or tunnel it over L2TP to 232 another gateway. The data-plane on the BNG decapsulates the 233 upstream (access->network) traffic and routes it towards the 234 network in appropriate routing-context, and optionally perform NAT 235 before routing. It determines the subscriber for downstream 236 (network->access) IP traffic, encapsulates it appropriately before 237 forwarding towards the access. In addition, it does traffic- 238 management and SLA management, maintains traffic statistics and 239 optionally monitors and reports usage. The "CUPS protocol" MUST 240 be able to carry state from CP to UP for IPv4, IPv6 and PPPoE 241 sessions, for various flavors of transport connections mentioned 242 above. 244 . Given the variety of access types on the CPE and type of transport 245 networks between access-nodes and BNG (as outlined above) , the 246 "CUPS protocol" MUST specify forwarding state information for the 247 subscriber sessions, for both data and in-band control, as 248 flexible packet matching rules and set of actions related to 249 forwarding and traffic management, rather than just fixed-format 250 lookup tables understood by particular UP implementation. Using 251 the flexible match rules and actions conveyed in the "CUPS 252 protocol" IEs, the UP should unambiguously be able to derive 253 various lookup tables and processing in the forwarding path to 254 forward traffic to and from the CPE. The basic forwarding state in 255 upstream direction (i.e. access to network) and downstream 256 direction (i.e. network to access) fundamentally consists of 257 session identification and one or more actions. Following shows a 258 logical representation of a directive from CP to UP to install 259 basic forwarding state on the UP for fixed L2 access (i.e. access 260 from DSLAM or OLTs over Ethernet). 262 o Direction Upstream - Access to Network: 263 . Subscriber-session identification: Port/VLAN-tag(s) 264 + subscriber-MAC + Session IP address + PPPoE 265 Session-ID 266 . Action: remove encapsulation (i.e. Ethernet and 267 PPPoE/PPP headers), apply policer, do IP FIB 268 lookup, forward to network. 270 o Direction Downstream - Network to Access: 271 . Subscriber-session identification: IP address 272 . Action: apply subscriber-shaper, build 273 encapsulation using (PPPoE session-id and 274 Port/VLAN-tag(s)+ subscriber-MAC), forward to 275 access. 277 Examples of actions and processing related to forwarding and 278 traffic management include encapsulation/decapsulation, table 279 lookups, drop, forward, mirror, count, redirect, police, classify, 280 queue, shape etc. 282 . In addition to packet-matching rules and actions to setup data- 283 path on the UP, the "CUPS protocol" MUST allow CP to specify 284 subscriber routing and IP interface related information. This 285 includes the following: 287 o Aggregate IPv4 subnets and IPv6 prefixes that are used for 288 assigning addresses or prefixes (e.g. IPv6 delegated- 289 prefix) to subscribers on a UP. These are announced in 290 routing by the UP to draw downstream traffic. 291 o UE's IP address and subnet mask. 292 o Default gateway IP address within the subscriber subnets. 293 This is used to draw upstream traffic from the CPEs and 294 the UP is required to respond to ICMP requests for this 295 address from the CPEs. 296 o Subnets for network behind a CPE (also known as framed- 297 routes). 299 . The "CUPS protocol" MUST provide support for CP to specify session 300 level HQOS related information to the UP. A common QOS hierarchy 301 on BNG consists of at least a QoS layer per access-node, and per 302 CPE. "CUPS protocol" MUST provide support for CP to specify QoS 303 parameters (e.g. rates, queues, markings) and the QoS hierarchy to 304 which the CPE belongs, to the UP. The CP may choose to signal this 305 via a QoS policy that is locally pre-configured on the UP. "CUPS 306 protocol" MUST provide support for CP to specify HQOS-policy that 307 the session is associated with. 309 . "CUPS protocol" MUST support asynchronous session level event 310 notifications from UP to CP. Session level asynchronous 311 notifications include: 313 o Periodic usage-reports 314 o Threshold based usage-reports 315 o Inactivity timeout 316 o Subscriber unreachability detection 318 . "CUPS protocol" MUST support asynchronous node level event 319 notifications from UP to CP. Example includes switchover 320 notification in case ports or UP failures when node level 321 redundancy is enabled. 323 2.2. Extensibility 325 . "CUPS protocol" MUST support exchange of software version and 326 feature capabilities when a node level association is setup 327 between a CP and UP. 329 . "CUPS protocol" MUST encode information in messages as TLVs. 331 . "CUPS protocol" MUST allow extension to defined Information 332 Elements (IEs) i.e. it MUST allow adding new information to 333 existing IEs while maintaining backwards compatibility. 335 . "CUPS protocol" MUST allow addition of new IEs exchanged in 336 protocol messages. 338 . "CUPS protocol" MUST support vendor specific IEs (modelled as 339 TLVs) by carving out TLV space for vendor specific extensions. 341 . "CUPS protocol" processing on UP MUST support graceful handling 342 when an unknown TLV is received. The UP MUST ignore unknown TLV 343 and continue with normal message processing. This ensures the 344 CP MAY send non-mandatory TLVs to the UP. However, CP MUST only 345 send mandatory TLVs if it knows the UP will accept it (based on 346 local configuration or based on capability exchange during 347 association setup). A TLV is considered mandatory if session 348 state cannot be installed or updated without it. 350 2.3. Scalability and Performance 352 . A single CP VNF can control multiple UP nodes. Each UP can 353 support its maximum scale of subscriber sessions as allowed by 354 its data-plane. External control plane running as a VNF can 355 horizontally scale-out as needed with the growth in CUPS 356 system-wide subscriber scale. In typical deployments CP may be 357 centralized whereas the UPs may be distributed, with multiple 358 L2 or L3 hops between CP and UPs. There are scenarios where a 359 large number of sessions may be getting created or deleted 360 close in time via "CUPS protocol". It is important that latency 361 to bring subscribers online is minimized. The transport 362 protocol chosen for "CUPS protocol" MUST NOT suffer from head- 363 of-line (HOL) blocking where transport of messages related to 364 one subscriber can be adversely impacted by messages being 365 exchanged for other subscribers. 367 . "CUPS protocol" MUST limit chattiness by minimizing number of 368 messages required to create fully functional subscriber on the 369 UP with complete forwarding, traffic management, HQOS, and 370 routing state. Ideally, a single request/response message 371 exchange between CP and UP should be able to create subscriber 372 with all the required state in the data-plane. The "CUPS 373 protocol" message that creates the subscriber session MUST 374 therefore be able to signal IEs for all the required subscriber 375 state. 377 . To further reduce latency the protocol MUST be binary encoded. 379 . "CUPS protocol" MUST allow dynamic scale-out for control plane 380 VNF with the growth in subscriber scale of the CUPS system, as 381 more UPs are added to the CUPS system or more ports are enabled 382 on a UP in a CUPS system. 384 . The "CUPS Protocol" MUST allow mechanism to provide balancing 385 of processing load amongst compute resources of control-plane 386 VNF that supports dynamic scale-out. 388 . "CUPS protocol" SHOULD support signaling of overload state and 389 optionally overload mitigation parameters from UP to CP, when 390 UP determines the incoming signaling from CP is exceeding (or 391 about to exceed) its nominal processing capacity. Overload 392 mitigation can include a temporary message throttling on CP 393 towards UP. Mitigation parameters can include message rate and 394 validity time for the specified rate. 396 2.4. Transport Protocol 398 . As mentioned in section 2.3, the transport protocol used for 399 "CUPS protocol" MUST NOT suffer from HOL blocking. 400 Therefore, TCP is not an option for the transport protocol. 402 . Ideally, the transport protocol SHOULD preserve message 403 boundary with datagram semantics and should be available or 404 easily implementable on any simple forwarding devices. 405 Therefore, UDP is the preferred option. 407 . "CUPS protocol" MUST therefore support reliability and 408 ordering for exchanged messages. The reliability and 409 ordering can be based on request/response with message 410 sequencing and re-transmissions. 412 2.5. In-band Control Channel Requirements 414 . "CUPS protocol" MUST support setting up of control channel 415 between UP and CP for transporting in-band control messages 416 (e.g. DHCPv4/v6 and PPPoE) received on the UP (from CPEs) to 417 the CP, and for return messages sent from CP to the UP 418 (destined to CPEs). 420 . There can be a L3 network between CP and UPs. Therefore, L3 421 tunneling is required between CP and UP to carry messages for 422 in-band control plane protocols. "CUPS protocol" MUST support 423 exchange of tunnel identifiers between CP and UP. 425 . Because L2 access setup is in-band, control plane messages will 426 arrive on the UP before any per-session state is learned. 427 Therefore, "CUPS protocol" MUST support messages and 428 information exchange to install forwarding state related to in- 429 band control plane messages that do not match any existing 430 subscriber session. These messages should be forwarded to the 431 CP over a common default control channel. 433 . The in-band control channel setup by "CUPS protocol" MUST have 434 support for UP to pass access-circuit identifier over which the 435 signaling messages are received from the CPEs. Based on type of 436 access, access-circuit identifier can include port/VLAN tags or 437 tunnel identifiers which includes tunnel endpoint IPs and de- 438 multiplexers such as GTP TEID, MPLS labels, L2TP tunnel-id etc. 439 "CUPS protocol" MUST support setting up logically separate 440 control channels for in-band control messages per access- 441 circuit. 443 . In case of fixed-access CPEs with Ethernet based network 444 between access-nodes and BNG, the control messages are received 445 in Ethernet frames. The Ethernet frame carrying the control 446 messages received on UP MUST be carried over the control 447 channel to the CP, as outlined in [CUPS]. In case of fixed- 448 wireless access, control messages (e.g. DHCPv4 and DHCPv6) are 449 received on the UP over GTP-u tunnel from the RAN. The GTP-u 450 tunnel directly carries IP payload. Therefore, control channel 451 setup via "CUPS protocol" MUST support transporting both 452 Ethernet and IP payloads. 454 . "CUPS protocol" MUST provide support for CP to specify the 455 control protocols that should be forwarded by the UP over in- 456 band control channel to the CP. 458 . The "CUPS protocol" SHOULD have support for CP to specify rate- 459 limits for specific control protocols and optionally specific 460 messages within a control protocol, that the UP should enforce. 462 . The "CUPS protocol" SHOULD provide support for CP to direct the 463 UP to drop certain control messages received on a particular 464 access-circuit. 466 . The "CUPS protocol" SHOULD provide support for CP to prioritize 467 reception of certain control messages over others. 469 2.6. Resiliency 471 . "CUPS protocol" MUST allow support for both 1:1 (hot standby) 472 and N:M (warm standby) UP node level redundancy. 474 . "CUPS protocol" MUST provide support for CP to specify the 475 "redundancy domain" that a subscriber session is associated 476 with during session level state creation on the UP. The 477 "redundancy domain" is set of resources that share fate with 478 respect to switchover on failure, e.g. a set of VLANs on a 479 port, or a set of ports on a UP, or entire UP. "CUPS protocol" 480 MUST also provide support for CP to provide relevant parameters 481 to UP about the "redundancy domains". The UPs can then locally 482 preform failure detection and switchover for the redundancy 483 domains. 485 . The "CUPS protocol" MUST provide support for UP to notify the 486 CP about switchover event. This notification must be on the 487 granularity of "redundancy domain" on a UP. 489 . For warm standby redundancy, "CUPS protocol" MUST provide 490 support for CP to create session level state on the backup UP 491 node(s) for all subscribers associated with the impacted 492 "redundancy domain". 494 . "CUPS protocol" MUST support in-service software upgrade (ISSU) 495 on UPs. The protocol MUST provide support for UP to notify CP 496 when it is completed ISSU to the new software release. 498 2.7. Security 500 "CUPS protocol" MUST be compatible with proven security mechanisms 501 such as IPSEC or DTLS to satisfy following security requirements: 503 . Data-integrity and confidentiality MUST be ensured for the 504 information exchanged via "CUPS protocol". 506 . Protection against man-in-the-middle attacks MUST be provided. 508 . Anti-replay protection MUST be provided. 510 3. "CUPS protocol" candidate 512 3GPP has defined PFCP (Packet Forwarding Control Protocol) in 513 [TS29244] as the interface between CP and UP for LTE gateways. This 514 protocol is suited for large scale state management between CP and 515 UP and can be extended for BNG providing converged access. The 516 protocol provides a good base for satisfying the requirements 517 outlined in this draft for BNG "CUPS protocol". Following are some 518 of the key attributes of this protocol/ 520 . It supports management of forwarding and QOS enforcement state 521 on the UP from CP. 523 . It also supports usage reporting from UP to CP. 525 . It is over UDP transport and doesn't suffer from any HOL 526 blocking. 528 . It provides reliable operation based on request/response with 529 message sequencing and retransmissions. 531 . It provides support for graceful handling of overload on UP. 533 . The protocol is extensible and allows addition of new IEs. 535 . For fixed access BNG, the protocol requires simple extensions 536 in the form of additional IEs. The required extensions are 537 mainly due to fact that typically a fixed access BNG requires 538 tighter control over L2 behavior and manages access and 539 subscriber using L2 identifiers (such as VLANs and MAC 540 addresses), whereas mobile access works in terms of L3, either 541 routed or tunneled. 543 . [TS29244] also describes an in-band signaling channel based on 544 GTP-u tunnel between CP and UP. GTP-u (GPRS Tunneling protocol 545 User Plane) is defined in 3GPP [TS29281] and defines a 546 tunneling protocol which carries IP payloads. The protocol runs 547 over a UDP/IP stack and uses UDP port number 2152. Data within 548 a tunnel can be multiplexed based on Tunnel Endpoint 549 Identifiers (TEIDs). The protocol supports optional sequence 550 numbers. The protocol supports extension headers to allow 551 development of new features. GTP-u tunnels are signaled between 552 CP and UP, and it is possible to associate filters to forward 553 or block certain control packets from UP to CP. The payload 554 type carried by GTP-u can be extended to Ethernet (via payload 555 type in extension header). The tunnel encapsulation can also be 556 extended by introducing an additional NSH (network services 557 header) to carry any required meta-data. 559 4. Security Considerations 561 For security between CP and UP, Network Domain Security (NDS) as 562 defined in [TS33210] can be considered. As per NDS, the network can 563 be split into security domains. Communication within a single 564 security domain is considered secure, and protocols can operate 565 without any additional security. When communication has to cross 566 security domains, then IPSEC can be used. 568 5. IANA Considerations 570 None. 572 6. References 574 6.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 [CUPS] Wadhwa, S. et al., "Architecture for control and user 580 plane separation on BNG, July 2019. 581 https://datatracker.ietf.org/doc/draft-wadhwa-rtgwg-bng- 582 cups/ 584 [TS29244] 3GPP, "Interface between the Control Plane and the User 585 Plane Nodes", TS 29.244 15.2.0, June 2018, 586 https://portal.3gpp.org/desktopmodules/Specifications/Sp 587 ecificationDetails.aspx?specificationId=3111. 589 [TS29281] 3GPP, "General Packet Radio System (GPRS) Tunneling 590 Protocol User Plane (GTPv1-U)", TS 29.281 15.3.0, June 591 2018, 592 https://portal.3gpp.org/desktopmodules/Specifications/Sp 593 ecificationDetails.aspx?specificationId=1699. 595 [TS33210] 3GPP, "Network Domain Security (NDS); IP network layer 596 security", TS 33.210 15.0.0, June 2018, 597 https://portal.3gpp.org/desktopmodules/Specifications/ 598 SpecificationDetails.aspx?specificationId=2279. 600 6.2. Informative References 602 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 603 2131, DOI 10.17487/RFC2131, March 1997, https://www.rfc- 604 editor.org/info/rfc2131. 606 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, 607 D., and R. Wheeler, "A Method for Transmitting PPP Over 608 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 609 February 1999, https://www.rfc-editor.org/info/rfc2516. 611 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 612 C., and M. Carney, "Dynamic Host Configuration Protocol 613 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 614 2003, https://www.rfc-editor.org/info/rfc3315. 616 Authors' Addresses 618 Sanjay Wadhwa 619 Nokia 620 777 East Middlefield Road 621 Mountain View 622 USA 624 Email: Sanjay.wadhwa@nokia.com 625 Killian De Smedt 626 Nokia 627 Copernicuslaan 50 628 Antwerp 629 Belgium 631 Email: Killian.de_smedt@nokia.com 633 Praveen Muley 634 Nokia 635 805. E. Middle Field Rd. 636 Mountain View, CA, 94043 637 USA 639 Email: praveen.muley@nokia.com 641 Rajesh Shinde 642 Reliance Jio Infocomm Ltd. 643 Reliance Corporate Park 644 Thane Belapur Road, Ghansoli 645 Navi Mumbai 400710 646 India 648 Email: Rajesh.A.Shinde@ril.com 650 Jonathan Newton 651 Vodafone 652 Waterside House 653 Bracknell 654 United Kingdom 656 Email: jonathan.newton@vodafone.com 658 Ryan Hoffman 659 TELUS 660 1525 10th Ave SW 661 Calgary, Alberta 662 Canada 664 Email: ryan.hoffman@telus.com 665 Subrat Pani 666 Juniper Networks 667 10 Technology Park Dr. 668 Westford, MA 669 USA 671 Email: spani@juniper.net