idnits 2.17.1 draft-cuspdt-rtgwg-cu-separation-bng-architecture-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: ---------------------------------------------------------------------------- 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 (December 16, 2018) is 1958 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Hu 2 Intended status: Informational F. Qin 3 Z. Li 4 China Mobile 5 T. Chua 6 Singapore Telecommunications Ltd 7 V. Lopez 8 Telefonica 9 D. Eastlake 10 Z. Wang 11 J. Song 12 Huawei 13 Expires: June 15, 2018 December 16, 2018 15 Architecture for Control Plane and User Plane Separated BNG 16 draft-cuspdt-rtgwg-cu-separation-bng-architecture-03.txt 18 Abstract 20 This document defines an architecture for Broadband Network Gateway 21 (BNG) devices with control plane (CP) and user plane (UP) separation. 22 BNG-CP is a user control management component while BNG-UP takes 23 responsibility as the network edge and user policy implementation 24 component. Both BNG-CP and BNG-UP are core components for fixed 25 broadband services and are deployed separately at different network 26 layers. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Distribution of this document is unlimited. Comments should be sent 34 to the authors or the RGTWG working group mailing list: 35 rtgwg@ietf.org. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 49 Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents 54 1. Introduction............................................3 55 1.1 Motivation.............................................3 57 2. Terminology.............................................4 59 3. CU Separated BNG Architecture...........................5 60 3.1 Internal Interfaces Between the CP and UP..............7 62 4. Usage of the CU Separation BNG..........................8 64 5. Security Considerations................................10 65 6. IANA Considerations....................................10 67 Normative References......................................11 68 Informative References....................................11 70 Authors' Addresses........................................12 72 1. Introduction 74 A Broadband Network Gateway (BNG) device is defined as an Ethernet- 75 centric IP edge router, and the aggregation point for the user 76 traffic. It performs Ethernet aggregation and packet forwarding via 77 IP/MPLS, and supports user management, access protocols termination, 78 QoS and policy management, etc. 80 This document introduce an architecture for BNG devices with control 81 plane (CP) and user plane (UP) separation. BNG-CP is a user control 82 management component while BNG-UP takes responsibility as the network 83 edge and user policy implementation components. Both BNG-CP and BNG- 84 UP are core components for fixed broadband services and are deployed 85 separately at different network layers in the network. 87 1.1 Motivation 89 The rapid development of new services, such as 4K, IoT, etc., and 90 increasing numbers of home broadband service users present some new 91 challenges for BNGs such as: 93 Low resource utilization: The traditional BNG acts as both a 94 gateway for user access authentication and accounting and an IP 95 network's Layer 3 edge. The mutually affecting nature of the 96 tightly coupled control plane and forwarding plane makes it 97 difficult to achieve the maximum performance of either plane. 99 Complex management and maintenance: Due to the large numbers of 100 traditional BNGs, a network must have each device configured one 101 at a time when deploying global service policies. As the network 102 expands and new services are introduced, this deployment mode will 103 cease to be feasible as it is unable to manage services 104 effectively and rectify faults rapidly. 106 Slow service provisioning: The coupling of control plane and 107 forwarding plane, in addition to a distributed network control 108 mechanism, means that any new technology has to rely heavily on 109 the existing network devices. 111 To address these challenges for fixed networks, a cloud-based BNG 112 with CU separation conception is defined in [TR-384]. The main idea 113 of Control-Plane and User-Plane separation is to extract and 114 centralize the user management functions of multiple BNG devices, 115 forming an unified and centralized control plane (CP). And the 116 traditional router's Control Plane and Forwarding Plane are both 117 preserved on BNG devices in the form of a user plane (UP). Note that 118 the CU separation concept has also be introduced in the 3GPP 5G 119 architecture [3GPP.23.501]. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 The following acronyms are used as specified below: 131 AAA: Authentication Authorization Accounting. 133 BNG: Broadband Network Gateway. A broadband remote access server 134 (BRAS (Broadband Access Server), B-RAS or BBRAS) that routes 135 traffic to and from broadband remote access devices such as 136 digital subscriber line access multiplexers (DSLAM) on an 137 Internet service provider's (ISP) network. BRAS can also be 138 referred to as a Broadband Network Gateway (BNG). 140 CP: Control Plane. The CP is a user control management component 141 which manages the UP's resources such as the user entry and 142 user's QoS policy 144 DHCP: Dynamic Host Configuration Protocol. 146 MANO: Management and Orchestration. 148 NFV: Network Function Virtualization. 150 NFVI: NFV Infrastructure. 152 PPPoE: Point-to-Point Protocol over Ethernet. 154 UP: User Plane. UP is a network edge and user policy implementation 155 component. The traditional router's Control Plane and forwarding 156 plane are both preserved on BNG devices in the form of a user 157 plane. 159 3. CU Separated BNG Architecture 161 The functions in a traditional BNG can be divided into two parts: one 162 is the user access management function, the other is the router 163 function. In a cloud-based BNG, we find that tearing these two 164 functions apart can make a difference. The user management function 165 can be centralized and deployed as a concentrated module or device, 166 which can be called BNG-CP (Control Plane). The other functions, such 167 as the router function and forwarding engine, can be deployed in the 168 form of the BNG User Plane. Thus the Cloud-based BNG architecture is 169 made up of control plane and user plane. 171 The following figure describes the architecture of CU separated BNG: 173 +------------------------------------------------------------------+ 174 | Neighboring policy and resource management systems | 175 | | 176 | +-------------+ +-----------+ +---------+ +----------+ | 177 | |AAA Server| |DHCP Server| | EMS | | MANO | | 178 | +-------------+ +-----------+ +---------+ +----------+ | 179 +------------------------------------------------------------------+ 181 +------------------------------------------------------------------+ 182 | CU-separated BNG system | 183 | +--------------------------------------------------------------+ | 184 | | +----------+ +----------+ +------++------++-----------+ | | 185 | | | Address | |Subscriber| | AAA ||PPPoE/|| UP | | | 186 | | |management| |management| | ||IPoE ||management | | | 187 | | +----------+ +----------+ +------++------++-----------+ | | 188 | | CP | | 189 | +--------------------------------------------------------------+ | 190 | | 191 | | 192 | | 193 | +---------------------------+ +--------------------------+ | 194 | | +------------------+ | | +------------------+ | | 195 | | | Routing control | | | | Routing control | | | 196 | | +------------------+ | ... | +------------------+ | | 197 | | +------------------+ | | +------------------+ | | 198 | | |Forwarding engine | | | |Forwarding engine | | | 199 | | +------------------+ UP | | +------------------+ UP| | 200 | +---------------------------+ +--------------------------+ | 201 +------------------------------------------------------------------+ 203 Figure 1. Architecture of CU Separated BNG 205 As in Figure 1, the BNG Control Plane could be virtualized and 206 centralized, which provides significant benefits such as centralized 207 session management, flexible address allocation, high scalability for 208 subscriber management capacity, and cost-efficient redundancy, etc. 210 The functional components inside the BNG Service Control Plane can be 211 implemented as Virtual Network Functions (VNFs) and hosted in a 212 Network Function Virtualization Infrastructure (NFVI). 214 The User Plane Management module in the BNG control plane centrally 215 manages the distributed BNG User Planes (e.g. load balancing), as 216 well as the setup, deletion, and maintenance of channels between 217 Control Planes and User Planes. Other modules in the BNG control 218 plane, such as address management, AAA, etc., are responsible for the 219 connection with outside subsystems in order to fulfill those 220 services. Note that the User Plane SHOULD support both physical and 221 virtual network functions. For example, BNG user plane L3 forwarding 222 related network functions can be disaggregated and distributed across 223 the physical infrastructure. And the other control plane and 224 management plane functions in the CU Separation BNG can be moved into 225 the NFVI for virtualization [TR-384]. 227 The details of CU separated BNG's function components are as 228 following: 230 The Control Plane should supports: 232 (1) Address management: unified address pool management. 234 (2) AAA: This component performs Authentication, Authorization and 235 Accounting, together with Radius/DIAMETER. The BNG communicates 236 with the AAA server to check whether the subscriber who sent an 237 Access-Request has network access authority. Once the subscriber 238 goes online, this component together with the Service Control 239 component implement accounting, data capacity limitation, and QoS 240 enforcement policies. 242 (3) Subscriber management: user entry management and forwarding 243 policy management. 245 (4) PPPoE/IPoE: process user dialup packets of PPPoE/IPoE. 247 (5) UP management: management of UP interface status, and the setup, 248 deletion, and maintenance of channels between CP and UP. 250 The User Plane should supports: 252 (1) Control plane functions including routing, multicast, and MPLS. 254 (2) Forwarding plane functions including traffic forwarding, QoS and 255 traffic statistics collection. 257 3.1 Internal Interfaces Between the CP and UP 259 To support the communication between the Control Plane and User 260 Plane, several interfaces are involved. Figure 2 illustrates the 261 internal interfaces of CU Separated BNG. 263 +-----------------------------------+ 264 | | 265 | BNG-CP | 266 | | 267 +--+--------------+--------------+--+ 268 | | | 269 1. Service | 2. Control | 3. Management| 270 Interface | Interface | Interface | 271 | | | 272 +--+--------------+--------------+--+ 273 | | 274 | BNG-UP | 275 | | 276 +-----------------------------------+ 278 Figure 2. Internal Interfaces Between the CP and UP of the BNG 280 Service Interface: The CP and UP use this interface to establish 281 VXLAN tunnels with each other and transmit PPPoE and IPoE 282 packets over the VXLAN tunnels which are present in 283 [hu-nvo3-vxlan-gpe-extension-for-vbng]. 285 Control Interface: The CP uses this interface to deliver service 286 entries, and the UP uses this interface to report service 287 events to the CP. The requirements of this interface is 288 introduced in [cuspdt-rtgwg-cusp-requirements], and the 289 carrying protocol is presented in 290 [cuspdt-rtgwg-cu-separation-bng-protocol], the information 291 model of this interface is presented in 292 [cuspdt-rtgwg-cu-separation-infor-model]. 294 Management Interface: The CP uses this interface to deliver 295 configurations to the UP. This interface runs NETCONF 296 [cusp-rtgwg-cu-separation-yang-model]. 298 4. Usage of the CU Separation BNG 300 In the CU separated BNG scenario, there are several processes when a 301 home user accesses the Internet: 303 (1) User dialup packets of PPPoE or IPoE from BNG-UP that will be 304 send to the BNG-CP from a BNG-UP's Service Interface. 306 (2) BNG-CP processes the dialup packet. Confirming with the outside 307 neighboring systems in the management network, BNG-CP makes the 308 decision to permit or deny the dial through certification. 310 (3) After that, the BNG-CP tells the UP to do the responding 311 forwarding actions with related policies. 313 (4) If the user is certificated and permitted, the UP forwards the 314 traffic into the Internet with related policies such as limited 315 bandwidth, etc. Otherwise, the user is denied to access the 316 Internet. 318 In the actual deployment, a CU separated BNG device is composed of a 319 CP and one or more UPs. The CP is centrally deployed and takes 320 responsibility as a user control management component managing UP's 321 resources such as the user entry and forwarding policy. A UP is 322 distributed in the bottom of the figure acting as a network edge and 323 user policy implementation component. 325 In order to fulfill a service, neighboring policy and resource 326 management systems are deployed outside. In the neighboring system, 327 different service systems such as Radius/DIAMETER. server, DHCP 328 server and EMS are included. If BNG-CP is virtualized as a NFV, the 329 NFVI management system MANO is also included here. A BNG-CP has 330 connections with the outside neighboring systems to transmit 331 management traffic. 333 The deployment scenario is shown in the following figure: 335 +------------------------------------------------------------------+ 336 | Neighboring policy and resource management systems | 337 | | 338 | +-------------+ +-----------+ +---------+ +----------+ | 339 | | AAA Server| |DHCP Server| | EMS | | MANO | | 340 | +-------------+ +-----------+ +---------+ +----------+ | 341 +------------------------+-----------------------------------------+ 342 | 343 | 344 +-----------------+-----------------+ 345 | | 346 | BNG-CP | 347 | | 348 +-+-----------+------------+--------+ 349 Service| Control| Management| ||| 350 Interface| Interface| Interface| ||| 351 (VXLAN)| (CUSP)| (NETCONF)| ||| 352 | | | ||| 353 +-+-----------+------------+-+ +---------------------------+ 354 | | | | 355 | BNG-UP | | BNG-UP... | 356 | | | | 357 +-------+--------------------+ +---------------+-----------+ 358 | | 359 | | 360 +-------------+-------------+ +--------------+------------+ 361 | | | | 362 | Access Network | | Access Network | 363 | | | | 364 +-+-----------+-----------+-+ +-+---------+----------+----+ 365 | | | | | | 366 | | | | | | 367 +--+---+ +----+-+ +---+--+ +----+-+ +----+-+ +--+---+ 368 |User11| |User12| ... |User1N| |User21| |User22| ... |User2N| 369 +------+ +------+ +------+ +------+ +------+ +------+ 371 Figure 3. Deployment Example 373 5. Security Considerations 375 TBD. 377 6. IANA Considerations 379 This document requires no IANA actions. 381 Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, DOI 385 10.17487/RFC2119, March 1997, . 388 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 389 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 390 May 2017, . 392 Informative References 394 [_3GPP.23.501] "System Architecture for the 5G System", 3GPP GPP TS 395 23.501 15.0.0, 2018. 397 [cuspdt-rtgwg-cu-separation-bng-deployment] Gu, R., "Deployment Model 398 of Control Plane and User Plane Separated BNG", draft- 399 cuspdt-rtgwg-cu-separation-bng-deployment, work in 400 progress, 2018. 402 [cuspdt-rtgwg-cu-separation-bng-protocol] Wang, Z., "Control-Plane 403 and User-Plane separation BNG control channel Protocol", 404 draft-cuspdt-rtgwg-cu-separation-bng-protocol, work in 405 progress, 2018. 407 [cuspdt-rtgwg-cu-separation-infor-model] Wang, Z., "Information Model 408 of Control-Plane and User- Plane separation BNG", draft- 409 cuspdt-rtgwg-cu-separation-infor-model, work in progress, 410 2018. 412 [cuspdt-rtgwg-cusp-requirements] Hu, S., "Requirements for Control 413 Plane and User Plane Separated BNG Protocol", draft-cuspdt- 414 rtgwg-cusp-requirements, work in progress, 2018. 416 [cuspdt-rtgwg-cu-separation-yang-model] Hu, F., "YANG Data Model for 417 Configuration Interface of Control-Plane and User-Plane 418 separation BNG", draft-cuspdt-rtgwg-cu-separation-yang- 419 model, work in progress, 2018. 421 [hu-nov3-vxlan-gpe-extension-for-vbng] Huang, L., "VXLAN GPE 422 Extension for Packets Exchange Between Control and User 423 Plane of vBNG", draft-hu-nvo3-vxlan-gpe-extension-for-vbrg, 424 work in progress, 2017. 426 [TR-384] Broadband Forum, "Cloud Central Office Reference 427 Architectural Framework", BBF TR-384, 2018. 429 Authors' Addresses 431 Shujun Hu 432 China Mobile 433 32 Xuanwumen West Ave, Xicheng District 434 Beijing, Beijing 100053 435 China 437 Email: hushujun@chinamobile.com 439 Fengwei Qin 440 China Mobile 441 32 Xuanwumen West Ave, Xicheng District 442 Beijing, Beijing 100053 443 China 445 Email: qinfengwei@chinamobile.com 447 Zhenqiang Li 448 China Mobile 449 32 Xuanwumen West Ave, Xicheng District 450 Beijing, Beijing 100053 451 China 453 Email: lizhenqiang@chinamobile.com 455 Tee Mong Chua 456 Singapore Telecommunications Limited 457 31 Exeter Road, #05-04 Comcentre Podium Block 458 Singapore City 239732 459 Singapore 461 Email: teemong@singtel.com 463 Victor Lopez 464 Telefonica 465 Spain 467 Email: victor.lopezalvarez@telefonica.com 468 Donald Eastlake, 3rd 469 Huawei Technologies 470 1424 Pro Shop Court 471 Davenport, FL 33896 472 USA 474 Phone: +1-508-333-2270 475 Email: d3e3e3@gmail.com 477 Zitao Wang 478 Huawei Technologies 479 101 Software Avenue, Yuhua District 480 Nanjing, Jiangsu 210012 481 China 483 Email: wangzitao@huawei.com 485 Jun Song 486 Huawei Technologies 487 101 Software Avenue, Yuhua District 488 Nanjing, Jiangsu 210012 489 China 491 Email: song.jun@huawei.com 493 Copyright, Disclaimer, and Additional IPR Provisions 495 Copyright (c) 2018 IETF Trust and the persons identified as the 496 document authors. All rights reserved. 498 This document is subject to BCP 78 and the IETF Trust's Legal 499 Provisions Relating to IETF Documents 500 (http://trustee.ietf.org/license-info) in effect on the date of 501 publication of this document. Please review these documents 502 carefully, as they describe your rights and restrictions with respect 503 to this document. Code Components extracted from this document must 504 include Simplified BSD License text as described in Section 4.e of 505 the Trust Legal Provisions and are provided without warranty as 506 described in the Simplified BSD License.