idnits 2.17.1 draft-wadhwa-rtgwg-bng-cups-03.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document date (Mar 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2131' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC2516' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 805, 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 (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 gwg S. Wadhwa 2 Internet Draft K. DeSmedt 3 Intended status: Informational Nokia 4 Expires: September 11, 2019 R. Shinde 5 Reliance Jio 6 J. Newton 7 Vodafone 8 R. Hoffman 9 TELUS 10 P. Muley 11 Nokia 12 Subrat Pani 13 Juniper Networks 14 Mar 11, 2019 16 Architecture for Control and User Plane Separation on BNG 17 draft-wadhwa-rtgwg-bng-cups-03.txt 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on September 11, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. 64 Abstract 66 This document discusses separation of subscriber-management control 67 plane and data-plane for BNG. Traditionally, the BNG provides 68 aggregation of fixed access nodes (such as DSLAM and OLTs) over 69 Ethernet and provides subscriber management and traffic management 70 functions for residential subscribers. The BNG has however evolved 71 to become a multi-access edge device that also provides termination 72 of subscribers over fixed-wireless and hybrid access. Therefore, 73 this document proposes interfaces between control and user-plane of 74 a BNG that can support multi-access BNG. 76 Table of Contents 78 1. Introduction...................................................3 79 1.1. Requirements Language.....................................3 80 2. CUPS for BNG...................................................3 81 2.1. Convergence...............................................5 82 3. Interfaces for CUPS............................................6 83 3.1. In-band Signaling Channel.................................7 84 3.2. State Control Interface...................................8 85 3.2.1. Session level state management.......................8 86 3.2.2. Session level event notifications...................14 87 3.2.3. Node level management...............................15 88 3.2.4. Node level event notifications......................16 89 3.3. Management Interface.....................................17 90 4. Protocol Selection for CUPS Interfaces........................17 91 5. Address Pool Management.......................................19 92 6. Security Considerations.......................................19 93 7. IANA Considerations...........................................19 94 8. References....................................................20 95 8.1. Normative References.....................................20 96 8.2. Informative References...................................20 98 1. Introduction 100 This document describes requirements and architecture for separation 101 of subscriber management control plane and user plane for the BNG. 102 In rest of the document the control plane is referred to as CP, user 103 plane as UP, and the separation is referred to as CUPS (control and 104 user plane separation). The draft describes 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 i.e. simultaneous 108 fixed and wireless access described in BBF [WT378]. The subsequent 109 sections of the draft also define the interfaces required between CP 110 and UP and briefly discusses a candidate base protocol for these 111 interfaces. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. CUPS for BNG 121 In a CUPS architecture, signaling to setup subscriber sessions CP 122 terminates signaling to setup subscriber sessions, and interfaces 123 with the UP to create forwarding state for these sessions on the UP. 125 For fixed access subscribers, the CP terminates the signaling 126 protocols (e.g. DHCP, PPPoE, SLAAC) from the customer premise, 127 performs authorization/authentication with AAA Server, participates 128 in address assignment, and then interfaces with the UP to create 129 state related to forwarding and SLA management for the subscriber 130 sessions on the UP. A subscriber session is a single IP connection, 131 such as an IPoE or PPPoE session. The session can be single-stack 132 (IPv4 or IPv6 only), or dual-stack (both IPv4 and IPv6). A CPE can 133 have multiple sessions, if multiple IP connections are required 134 (e.g. on per service, or one per device behind the CPE). 136 The CP also processes solicited or unsolicited event notifications 137 from the UP e.g. periodic accounting updates, usage reports, or 138 session inactivity notifications. The interface between CP and UP 139 that is used by the CP to manage session related forwarding state on 140 the UP is being referred to as "state control interface". 141 Asynchronous event notifications from UP to CP are also part of this 142 interface. 144 In typical fixed access deployments, signaling (e.g. DHCPv4/v6, 145 PPPoE, ICMPv6 RS/RA) to setup the subscriber sessions is in-band, 146 and hence the UP receives the signaling messages from the customer 147 premise. The UP should transparently forward (unmodified) in-band 148 control messages as received from the customer premise to the CP and 149 return messages from CP to the customer premise. Therefore, an in- 150 band signaling channel is required between UP and CP. With a typical 151 "CUPS BNG" deployment, the CP and UP are connected over a network, 152 and the in-band signaling channel must be over a tunnel. 154 The UP performs forwarding and traffic management for the subscriber 155 sessions. The infrastructure routing and signaling is done on the 156 local control plane of the UP for fast convergence on network 157 topology changes. In rest of the document the term "UP" is used 158 generically for both functions performed by the local control plane 159 on the UP and the data-plane. 161 A typical deployment architecture for CUPS includes a centralized CP 162 running as a VNF interacting with multiple BNG UP instances that may 163 be more distributed than the CP and could run as VNF or PNF. In this 164 model, the CP and UP association is 1:N. This composite system 165 containing CP VNF and one or more UP instances is referred to as a 166 "CUPS BNG" in rest of the document. For operational ease, the CP 167 MUST provide a single point for control and management for the 168 entire "CUPS BNG". It MUST expose a single interface on behalf of 169 the "CUPS BNG" to external systems such as AAA servers, OSS/BSS, 170 Policy and charging servers. The CP VNF MUST support scale-out in 171 order to cope with growth in number of subscriber sessions and/or 172 increase in number of UP instances in the "CUPS BNG". Figure 1 below 173 shows the functional components and interfaces for a "CUPS BNG". 175 | 176 "CUPS BNG" | 177 +----------------------------+------------------------------------+ 178 | CP | 179 | +--------------------------+--------------------------------+ | 180 | | +-----------+ +------------------+ +--------+ +---------+ | | 181 | | | Address | | PPPoE, DHCPv4/v6 | | RADIUS | | S11/N11 | | | 182 | | | Pool Mmmt | | IPv6 RS/RA, | | CLIENT | +---------+ | | 183 | | +-----------+ | L2TP LAC | +--------+ | | 184 | | +------------------+ +----+ +----+ | | 185 | | | Gx | | Gy | | | 186 | | +----+ +----+ | | 187 | +-----------------------------------------------------------+ | 188 | | | | | 189 | | Management |In-band | State | 190 | | Interface |Signaling | Control | 191 | | |Channel | Interface | 192 | | | | | 193 | --------+--+------------------+--+----------------+---+------- | 194 | | | | | 195 | UP | UP | UP | | 196 | +-----+---------+ +---------+-----+ +---------+-----+ | 197 | | Local CP | | Local CP | | Local CP | | 198 | | Routing, MPLS | | Routing, MPLS | | Routing, MPLS | | 199 | | IGMP, BFD | | IGMP, BFD | | IGMP, BFD | | 200 | +---------------+ +---------------+ +---------------+ | 201 | | Forwarding | | Forwarding | | Forwarding | | 202 | | Traffic Mgmt | | Traffic Mgmt | | Traffic Mgmt | | 203 | +---------------+ +---------------+ +---------------+ | 204 | | 205 +-----------------------------------------------------------------+ 207 CUPS BNG System 209 2.1. Convergence 211 A single BNG can support subscribers over fixed, "fixed-wireless" or 212 hybrid access. When a residential gateway has fixed-wireless access 213 (LTE or 5G), then the BNG participates in 3GPP signaling with an MME 214 or AMF (i.e. support 3GPP S11 and N11 interfaces) to setup 215 connections from (NG)RAN. With Hybrid access the customer premise 216 initiates both fixed and wireless connections. The BNG in this case 217 aggregates subscribers over Ethernet from fixed access nodes (DSLAMs 218 and OLTs), but simultaneously terminates connections from (NG)RAN by 219 participating in signaling with MME or AMF (S11/N11 interface). 220 These deployment models are drivers for fixed-mobile convergence. It 221 is important to ensure that the interfaces between CP and UP for 222 CUPS can support not only fixed L2 access, but also the converged 223 access scenario shown in Figure 2. One key requirement on the CP in 224 these cases is the need to participate in 3GPP signaling (which is 225 out-of-band) to setup the data-path. The data-path is a GTP-u (GPRS 226 Tunneling protocol - User Plane) tunnel from the RAN (i.e. S1-u 227 interface for LTE) as described in 3GPP [TS29281], and it terminates 228 on the UP. It carries data traffic but also subscriber signaling 229 messages (e.g. DHCPv4, DHCPv6, SLAAC) from the customer premise. The 230 UP therefore still requires an in-band signaling channel to 231 transport these protocol messages to the CP. 233 CUPS-BNG 234 +-------------------+ S11 +----------+ 235 | +------+ |(GTP-c) | +------+ | 236 | | CP |------|---------|-| MME | | 237 | +---+--+ | | +------+ | 238 | | | | +------+ | 239 | | | +-|-| RAN | |--+ +-----+ 240 | ------+----- | S1-u | | +------+ | \ | | 241 | | | |(GTP-u)| +----------+ +---| | 242 | | | | (DHCP | | CPE | 243 | | | | SLAAC)| | | 244 | +----+ +----+ | (Data)| +---| | 245 | | UP | | UP |--|-------+ +-----+ / +-----+ 246 | | | | |--|-------------| AN |---+ 247 | +----+ +----+ | Eth +-----+ 248 | | (DHCP,PPPoE) 249 +-------------------+ (Data) 251 "CUPS BNG" with Converged Access 253 3. Interfaces for CUPS 255 A "CUPS BNG" MUST support the following interfaces between CP and 256 UP, as shown in the figure in section 2. 258 3.1. In-band Signaling Channel 260 Section 2 describes the need for a signaling channel between CP and 261 UP to transport in-band control messages between CP and the customer 262 premise. Following are some key requirements for this interface. 264 . The UP MUST pass the access circuit identifier over which the 265 signaling messages are received as meta-data to the CP. This 266 includes port, VLAN tags, tunnel endpoint IPs, any tunnel 267 identifiers such as GTP TEID, MPLS labels, L2TP tunnel-id etc. 268 The UP MUST also pass the L2 or L3 transport service that the 269 access circuit is associated with. In case the control message 270 PDU is carried in an Ethernet frame, then the UP SHOULD pass 271 the received Ethernet frame to the CP. Both access circuit 272 identifier and information in the Ethernet header are required 273 by the CP to construct successful response packet (control 274 message) back towards the customer premise. The access circuit 275 identifier MUST be reflected from CP to UP, so UP can identify 276 the access circuit over which it needs to send the CP's 277 response packet. In the control message sent from UP to CP, the 278 UP MUST also include the local MAC address associated with 279 access circuit. This is because certain control messages from 280 the customer premise are destined to a broadcast MAC (e.g. DHCP 281 DISCOVER) or multicast (e.g. ICMPv6 RS), so CP cannot infer the 282 local MAC from these messages. Certain messages also require 283 the local MAC address to be inserted in the message (e.g. Link- 284 Layer address in ICMPv6 RA messages) 286 . The CP MUST be able to control the UP to forward only specific 287 control messages to the CP. 289 . The CP MUST be able to control the UP to block certain control 290 messages received on a particular access circuit. 292 . The CP MUST be able to control the UP to limit the rate of 293 control messages (of specified type) to be sent by the UP. 295 . The CP MUST be able to prioritize reception of certain control 296 messages over others in a granular manner (e.g. prioritize DHCP 297 RENEWS over DISCOVERS or prioritize PPP Keepalive over other 298 messages). 300 . The in-band signaling channel MUST support both fixed and 301 converged access as described in section 2.1. The tunnel used 302 for transporting these messages should therefore support both 303 Ethernet and IP payloads. 305 3.2. State Control Interface 307 The CP and UP can exchange state at two levels using the "state 308 control interface". One is at the node level and includes node-level 309 information such as supported features, software releases, available 310 resources, and operational state (e.g. active, failed, or 311 overloaded). The other is at the subscriber session level. 312 Subscriber session is described in section 2. The session level 313 state includes basic forwarding and traffic management rules per 314 session, that need to be provided by the CP to the UP in order to 315 control per session forwarding and traffic management on the UP. It 316 also includes state that triggers routing related actions on the UP. 317 The session level state can include asynchronous event notifications 318 from UP to CP, such as notifications to report per session usage 319 (periodically or based on thresholds), notification to report 320 session inactivity, and session liveness. 322 The interactions between CP and UP over "state control interface" 323 can be categorized as: 325 o Session level state management 326 o Session level event notifications 327 o Node level management 328 o Node level event notifications 330 Following sub-sections provide more details on these interactions. 331 The interactions between CP and UP over "state control interface" 332 are modeled via abstract request/response messages between CP and 333 UP. These messages will need to be defined as part of the protocol 334 specification for this interface. 336 The protocol selected to implement this interface MUST support both 337 fixed access and converged access (described in section 2.1) on BNG 339 3.2.1. Session level state management 341 Once the CP has successfully authorized and/or authenticated the 342 subscriber session, and completed address assignment, it uses the 343 "state control interface" to install forwarding and related state 344 for the session on the forwarding path of the UP. This is abstracted 345 as a "session create request" call from CP to UP, as shown in the 346 figure below. The UP MUST ack or NACK via a response back to CP. 348 Since BNG can support different access types (e.g. fixed L2 access, 349 or tunneled L3 in case of fixed-wireless, or a combination in case 350 of hybrid access), it is important that the forwarding state 351 information for the subscriber sessions, sent from CP to UP, can be 352 specified as flexible packet matching rules and set of actions 353 related to forwarding and traffic management. The UP should be able 354 to use these match rules and actions to derive various lookup tables 355 and processing in the forwarding path to forward traffic to and from 356 the CPE. 358 The basic forwarding state in upstream direction (i.e. access to 359 network) and downstream direction (i.e. network to access) 360 fundamentally consists of session identification and one or more 361 actions. Following shows a logical representation of a directive 362 from CP to UP to install basic forwarding state on the UP for fixed 363 L2 access (i.e. access from DSLAM or OLTs over Ethernet). 365 Direction Upstream - Access to Network: 366 Subscriber-identification: Port/VLAN-tag(s) + subscriber-MAC 367 Action: remove encapsulation, IP FIB lookup, forward to network. 369 Direction Downstream - Network to Access: 370 Subscriber-identification: IP address 371 Action: lookup IP DA, build encapsulation using Port/VLAN-tag(s)+ 372 subscriber-MAC, forward to access. 374 Optionally, the IP address assigned to the CPE can also be provided 375 for subscriber-identification (e.g. for anti-spoofing) in the 376 upstream direction. 377 In case of PPPoE sessions, the subscriber-identification for 378 upstream direction and encapsulation for downstream direction also 379 includes the PPPoE session-id. 381 Based on the directive from CP to UP (as shown in the example 382 above), the UP can then populate appropriate tables in the 383 forwarding path, e.g. subscriber lookup tables, IP-FIB, and ARP or 384 IPv6 Neighbor discovery table. It can also program the packet 385 processing in both upstream and downstream direction based on the 386 specified actions. 388 In case of "fixed-wireless" access, the access circuit is a GTP-u 389 tunnel. In this case there is no physical interface (or port), and 390 hence the CP MUST provide a tunnel definition to the UP to use as 391 access circuit in upstream direction, and encapsulation in 392 downstream direction. The tunnel definition will include the tunnel 393 endpoint IP, and TEID that is established via out-of-band signaling 394 between the CP and the customer premise. It can also include the 395 routing context for transporting the tunnel. 397 In addition to setting up the forwarding state as directed by the 398 CP, the UP also needs to announce in routing the aggregate prefixes 399 from which the CP assigns IPv4 and IPv6 addresses (or prefixes) to 400 the CPEs. The CP SHOULD provide these aggregate prefixes to the UP 401 as part session state. In case the aggregate prefixes are not 402 provided, the UP MUST announce individual CPE addresses in routing, 403 or it MAY try to aggregate in case addresses for multiple CPEs are 404 from a contiguous address space. 406 The CPE can have a routed subnet behind it (aka framed-route). CP 407 can learn the framed-routes during authentication/authorization. The 408 CP should provide the framed-route to the UP as part of session 409 state. The UP MUST install this route in the forwarding path and 410 associate it with the forwarding state of the corresponding 411 subscriber session. It should also announce this in routing towards 412 the Network. 414 The CP MUST also provide to the UP the address assigned as IP 415 gateway address to the CPEs in DHCP. The UP MUST locally configure 416 this address appropriately, such that it can respond to ARP requests 417 for this address from the CPEs. 419 The session sate on the UP is always controlled by the CP i.e. the 420 UP just follows the directive from the CP to install, modify and 421 delete the session state. In addition to the basic forwarding state, 422 the CP can also associate, update and disassociate other related 423 state with the session e.g. state related to: 425 . Filtering 426 . SLA management 427 . Statistics collection 428 . Credit control 429 . Traffic mirroring 430 . Traffic Steering 431 . NAT 432 . Application aware policies 434 BNG deployments use hierarchical QoS (H-QOS) models which follows 435 from a combination of link-layer over-subscription, multi-service 436 networks and multiple layers of aggregation. For example, a common 437 hierarchy exists of at least a QoS layer per access-node, and per 438 CPE. The CP MUST provide SLA management information to the UP per 439 CPE. This includes applicable QoS parameters (e.g. rates, queues, 440 markings) and the QoS hierarchy to which the CPE belongs. The CP may 441 choose to signal this via a QoS policy that is locally pre- 442 configured on the UP. 444 +------+ 445 +---+ +---+ +---+ | AAA | 446 |CPE| |UP | |CP | |Server| 447 +---+ +---+ +---+ +------+ 448 |DHCP Discover | | | 449 |------------->| | | 450 | | | | 451 | | DHCP Discover | | 452 | |-----------------------> | | 453 | |In-band signaling channel| | 454 | | | | 455 | | |Access Request | 456 | | |-------------->| 457 | | | | 458 | | |Access Accept | 459 | | |<--------------| 460 | | | | 461 | | DHCP Offer | | 462 | |<------------------------| | 463 | |In-band signaling channel| | 464 | DHCP Offer | | | 465 |<-------------| | | 466 | | | | 467 |DHCP Request | | | 468 |------------->| | | 469 | | | | 470 | | DHCP Request | | 471 | |-----------------------> | | 472 | | In-band signaling channel 473 | | | | 474 | | Session Creation Req | | 475 | |<----------------------- | | 476 | | | | 477 | | Session Creation Resp. | | 478 | |-----------------------> | | 479 | | | | 480 | | | | 481 | | DHCP ACK | | 482 | |<----------------------- | | 483 | |In-band signaling channel| | 484 | DHCP Ack | | | 485 |<-------------| | | 486 +---+ +---+ +---+ +------+ 487 |CPE| |UP | |CP | | AAA | 488 +---+ +---+ +---+ |Server| 489 +------+ 490 Session Creation Sequence 492 CP can trigger update of session state on the UP, triggered by re- 493 authentication or COA from AAA or policy-server, as show in the 494 figure below. 496 +------+ 497 +---+ +---+ | AAA | 498 |UP | |CP | |Server| 499 +---+ +---+ +--+---+ 500 | | CoA Request | 501 | |<--------------| 502 | | | 503 | Session Modify Req | | 504 |<-----------------------| | 505 | | | 506 | Session Modify Resp | | 507 |----------------------->| | 508 | | | 509 | | CoA Ack | 510 | |-------------->| 511 +---+ +---+ +--+---+ 512 |UP | |CP | | AAA | 513 +---+ +---+ |Server| 514 +------+ 516 Session Modification 518 CP can trigger the deletion of session state based on signaling 519 messages (as shown in the figure below), administrative action or 520 disconnect-message initiated from the AAA server. 522 +---+ +---+ +---+ +-------+ 523 |CPE| |UP | |CP | | AAA | 524 +---+ +---+ +---+ |Server | 525 | DHCP Release | DHCP Release | +-------+ 526 |---------------->|---------------->| | 527 | | | | 528 | | Session Del Req | | 529 | |<----------------| | 530 | | | | 531 | | Session Del Resp| | 532 | | (final usage) | Acct Stop | 533 | |---------------->|(final usage) | 534 | | |-------------->| 535 | | } Acct Stop Resp| 536 | | |<--------------| 537 +---+ +---+ +----+ +-------+ 538 |CPE| |UP | | CP | | AAA | 539 +---+ +---+ +----+ |Server | 540 +-------+ 542 Session Deletion 544 3.2.2. Session level event notifications 546 UP can asynchronously generate Session level event notifications to 547 the CP. An example of asynchronous notification is periodic usage 548 reporting from UP to the CP, so that the CP can report the usage to 549 a AAA server via interim accounting-updates. The CP can set the 550 periodicity of this notification on the UP based on interim 551 accounting interval configured by the operator on the CP. 553 +------+ 554 +---+ +---+ | AAA | 555 |UP | |CP | |Server| 556 +---+ +---+ +------+ 557 | | | 558 | | | 559 |Async Event Notification| | 560 | (periodic usage) | | 561 |----------------------->| | 562 | | | 563 |Async Event Response | | 564 |<-----------------------|Acct Update Req | 565 | |--------------->| 566 | |Acct Update Resp| 567 | |<---------------| 568 +---+ +---+ +------+ 569 |UP | |CP | | AAA | 570 +---+ +---+ |Server| 571 +------+ 573 Async Event Notification for periodic usage 575 Following are some other examples requiring asynchronous 576 notifications from UP to CP. 578 o Threshold based usage reporting 579 o Inactivity timeout 580 o Subscriber unreachability detection 582 The protocol for "state control interface" MUST support asynchronous 583 notifications from UP to CP. 585 3.2.3. Node level management 587 There needs to exist a concept of association between CP and UP. When 588 the CP or UP comes online it should setup an association with 589 configured or discovered peers via a message exchange. In association 590 setup, the nodes should be able to exchange supported capabilities, 591 version of software, load/overload information, and resource 592 information. Also, any node-wide parameters can be exchanged during 593 association setup. 595 No session state related messages should be accepted from the peer by 596 either CP or UP unless an association exists. 598 Either node should be able to update the association to report changed 599 feature capabilities, overload condition, resource exhaustion or any 600 other node-wide parameters. 602 The UP should be able to request a graceful association release from 603 the CP. In this case the CP should delete all sessions from that UP and 604 process the final stats report for each session and send it in 605 accounting-stop to the AAA server. During this process the CP MUST not 606 create new sessions on the UP. Once all sessions are successfully 607 deleted, the CP should release the association. 609 There needs to be a periodic node-level heartbeat exchange between CP 610 and UP to detect if the peer is reachable and active. If peer is 611 determined to be down based on heartbeat messages, then all the data- 612 plane session state associated with the peer should be deleted. 614 +---+ +---+ 615 |UP | |CP | 616 +---+ +---+ 617 | | 618 | | 619 | Association Setup Req | 620 |----------------------->| 621 | | 622 | Association Setup Resp | 623 |<-----------------------| 624 | | 625 | Periodic Heartbeats | 626 |<---------------------->| 627 | | 628 +---+ +---+ 629 |UP | |CP | 630 +---+ +---+ 632 Node Association Setup and Maintenance 634 3.2.4. Node level event notifications 636 There needs to be support for asynchronous node level event 637 notifications from UP to CP. Example includes switchover 638 notification in case ports or UP failures when UP node level warm- 639 standby redundancy is enabled. Based on this notification, the CP 640 can create session state for all the sessions associated with the 641 failure domain on the new primary UP. 643 3.3. Management Interface 645 The CP MUST provide a single point for local management of "CUPS 646 BNG" system to the operator. This requires a management interface 647 between CP and each of its associated UPs for pushing configuration 648 to the UP and retrieving operational state from the UP. The 649 interface MUST minimally include BNG specific configuration and 650 state. 652 The Management interface SHOULD support transactional configuration 653 from CP to UPs and SHOULD support state retrieval, both based on a 654 well-defined data schema. The management interface SHOULD support 655 unsolicited signaling of state changes (events) from UP to CP i.e. 656 MUST provide telemetry for events. Either gNMI or NETCONF can be 657 considered as acceptable candidates for model driven management 658 interface. 660 4. Resiliency 662 "CUPS BNG" system MUST be protected against failure of CP VNF and 663 MUST be able to recover the session state without operator 664 intervention and reliance on CPEs. This can be achieved by providing 665 redundancy for processing resources within CP VNF and maintaining 666 redundant instance of session state. 668 Protection against UP failures based on 1:1 UP (hot-redundancy) and 669 N:M (warm-redundancy) SHOULD be supported. For 1:1 hot-redundancy 670 the CP needs to create data-plane state for sessions on both UPs 671 that form a redundant pair, using the "state control interface". The 672 CP needs to ensure the data-plane state for a session stays 673 synchronized between the two nodes. A given session's data-plane 674 should only be active on one UP in the pair, which serves as active 675 UP for the session. However, sessions that share the redundant UP 676 pair can be distributed between the two UPs for active forwarding. 678 N:M warm-redundancy (N > M) can be supported via creation of data- 679 plane state on the designated backup chassis after the failure has 680 been detected. This would result in longer failover times than 1:1 681 hot-redundancy. 683 Redundant network connectivity between CP and UPs MUST be supported. 684 In the "CUPS BNG" architecture, it is important to configure 685 redundant connectivity that doesn't share fate. 687 5. Protocol Selection for CUPS Interfaces 689 It is important that the selected protocol for "state control 690 interface" between CP and UP works not just for fixed access but 691 also works for converged access on BNG. 3GPP has defined PFCP 692 (Packet Forwarding Control Protocol) in [TS29244] as the interface 693 between CP and UP for LTE gateways. This protocol is suited for 694 large scale state management between CP and UP. Following are some 695 of the key attributes of this protocol: 697 o It supports management of forwarding and QOS enforcement state 698 on the UP from CP. It also supports usage reporting from UP to 699 CP. 700 o It is over UDP transport and doesn't suffer from any HOL 701 blocking. 702 o It provides reliable operation based on request/response with 703 message sequencing and retransmissions. 704 o It provides an overload control procedure where overload on UP 705 can be handled gracefully. 706 o The protocol is extensible and allows addition of new IEs. 708 For fixed access BNG, the protocol requires simple extensions in 709 form of additional IEs. The required extensions are mainly due to 710 fact that typically a fixed access BNG requires tighter control 711 over L2 behavior and manages access and subscriber using L2 712 identifiers (such as VLANs and MAC addresses), whereas mobile 713 access works in terms of L3, either routed or tunneled. 715 The details of the protocol as applicable to the BNG and the 716 required extensions will be defined in a separate draft. 718 [TS29244] also describes an in-band signaling channel based on 719 GTP-u tunnel between CP and UP. GTP-u (GPRS Tunneling protocol - 720 User Plane) is defined in 3GPP [TS29281] and defines a tunneling 721 protocol which carries IP payloads. The protocol runs over a 722 UDP/IP stack and uses UDP port number 2152. Data within a tunnel 723 can be multiplexed based on Tunnel Endpoint Identifiers (TEIDs). 724 The protocol supports optional sequence numbers. The protocol 725 supports extension headers to allow development of new features. 726 GTP-u tunnels are signaled between CP and UP, and it is possible 727 to associate filters to block certain control packets from being 728 forwarded form UP to CP. The payload type carried by GTP-u can be 729 extended to Ethernet (via payload type in extension header). The 730 tunnel encapsulation can also be extended similarly to carry any 731 required meta-data. 733 6. Address Pool Management 735 The CP MUST support management of IPv4 and IPv6 address pools, where 736 each pool can contain one or more subnets. The pool management MUST 737 support pool selection based on one or more of the following 738 criteria: 740 o UP 741 o Access port on the UP. 742 o Redundancy domain on the UP (e.g. set of access ports that 743 share fate with respect to switchovers due to failures, when UP 744 node level redundancy is enabled). 745 o Service (e.g. HSI, VoIP, IPTV etc.). 746 o Location (e.g. based on circuit-id/remote-id or part of 747 circuit-id/remote-id in DHCP and PPPoE). 749 Pool management on CP SHOULD NOT statically link subnets to UPs but 750 SHOULD dynamically allocate subnets to UP based on load i.e. on- 751 demand, and signal allocated subnets using the "state control 752 interface" as described in section 3.2.1. This allows for better IP 753 resource utilization and less subnet fragmentation. 755 7. Security Considerations 757 For security between CP and UP, Network Domain Security (NDS) as 758 defined in [TS33210] can be considered. As per NDS, the network can 759 be split into security domains. Communication within a single 760 security domain is considered secure, and protocols can operate 761 without any additional security. When communication has to cross 762 security domains, then IPSEC can be used. 764 8. IANA Considerations 766 None. 768 9. References 770 9.1. Normative References 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, March 1997. 775 [TS29244] 3GPP, "Interface between the Control Plane and the User 776 Plane Nodes", TS 29.244 15.2.0, June 2018, 777 https://portal.3gpp.org/desktopmodules/Specifications/Sp 778 ecificationDetails.aspx?specificationId=3111. 780 [TS29281] 3GPP, "General Packet Radio System (GPRS) Tunneling 781 Protocol User Plane (GTPv1-U)", TS 29.281 15.3.0, June 782 2018, 783 https://portal.3gpp.org/desktopmodules/Specifications/Sp 784 ecificationDetails.aspx?specificationId=1699. 786 [TS33210] 3GPP, "Network Domain Security (NDS); IP network layer 787 security", TS 33.210 15.0.0, June 2018, 788 https://portal.3gpp.org/desktopmodules/Specifications/ 789 SpecificationDetails.aspx?specificationId=2279. 791 [WT378] BBF, "Nodal Requirements for Hybrid Access Broadband 792 Networks", WT-378, 2018. 794 9.2. Informative References 796 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 797 2131, DOI 10.17487/RFC2131, March 1997, https://www.rfc- 798 editor.org/info/rfc2131. 800 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, 801 D., and R. Wheeler, "A Method for Transmitting PPP Over 802 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 803 February 1999, https://www.rfc-editor.org/info/rfc2516. 805 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 806 C., and M. Carney, "Dynamic Host Configuration Protocol 807 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 808 2003, https://www.rfc-editor.org/info/rfc3315. 810 Authors' Addresses 812 Sanjay Wadhwa 813 Nokia 814 777 East Middlefield Road 815 Mountain View 816 USA 818 Email: Sanjay.wadhwa@nokia.com 819 Killian De Smedt 820 Nokia 821 Copernicuslaan 50 822 Antwerp 823 Belgium 825 Email: Killian.de_smedt@nokia.com 827 Rajesh Shinde 828 Reliance Jio Infocomm Ltd. 829 Reliance Corporate Park 830 Thane Belapur Road, Ghansoli 831 Navi Mumbai 400710 832 India 834 Email: Rajesh.A.Shinde@ril.com 836 Jonathan Newton 837 Vodafone 838 Waterside House 839 Bracknell 840 United Kingdom 842 Email: jonathan.newton@vodafone.com 844 Ryan Hoffman 845 TELUS 846 1525 10th Ave SW 847 Calgary, Alberta 848 Canada 850 Email: ryan.hoffman@telus.com 852 Praveen Muley 853 Nokia 854 805. E. Middle Field Rd. 855 Mountain View, CA, 94043 856 USA 858 Email: praveen.muley@nokia.com 860 Subrat Pani 861 Juniper Networks 862 10 Technology Park Dr. 863 Westford, MA 864 USA 866 Email: spani@juniper.net