idnits 2.17.1 draft-cuspdt-rtgwg-cu-separation-bng-architecture-04.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 (March 11, 2019) is 1873 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: September 10, 2019 March 11, 2019 15 Architecture for Control Plane and User Plane Separated BNG 16 draft-cuspdt-rtgwg-cu-separation-bng-architecture-04.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 A BNG-CP is a user control management component while a 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 user traffic. 76 It performs Ethernet aggregation and packet forwarding via IP/MPLS, 77 and supports user management, access protocols termination, QoS, 78 policy management, etc. 80 This document describes an architecture for BNG devices with control 81 plane (CP) and user plane (UP) separation. A BNG-CP is a user 82 control management component while a BNG-UP takes responsibility as 83 the network edge and user policy implementation components. Both BNG- 84 CP and BNG- UP are core components for fixed broadband services and 85 are deployed separately at different network layers in the network. 87 1.1 Motivation 89 The rapid development of new services, such as 4K TV, 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 gateway 94 for user access authentication and accounting and an IP network's 95 Layer 3 edge. The mutually affecting nature of the tightly 96 coupled control plane and forwarding plane makes it difficult to 97 achieve the maximum performance of either plane. 99 Complex management and maintenance: Due to the large numbers of 100 traditional BNGs, configuring each device in a network is very 101 tedious when deploying global service policies. As the network 102 expands and new services are introduced, this deployment mode 103 will 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, the framework for a 112 cloud-based BNG with CU separation conception is defined in [TR-384]. 113 The main idea of Control-Plane and User-Plane separation is to 114 extract and centralize the user management functions of multiple BNG 115 devices, forming a unified and centralized control plane (CP). And 116 the 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 been 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 EMS: Element Management System. 148 IPoE: IP over Ethernet. 150 MANO: Management and Orchestration. 152 NFV: Network Function Virtualization. 154 NFVI: NFV Infrastructure. 156 PPPoE: Point-to-Point Protocol over Ethernet. 158 UP: User Plane. UP is a network edge and user policy implementation 159 component. The traditional router's Control Plane and forwarding 160 plane are both preserved on BNG devices in the form of a user 161 plane. 163 3. CU Separated BNG Architecture 165 The functions in a traditional BNG can be divided into two parts: one 166 is the user access management function, the other is the router 167 function. In a cloud-based BNG, we find that tearing these two 168 functions apart can make a difference. The user management function 169 can be centralized and deployed as a concentrated module or device, 170 called the BNG-CP (Control Plane). The other functions, such as the 171 router function and forwarding engine, can be deployed in the form of 172 the BNG User Plane. Thus, the Cloud-based BNG architecture is made up 173 of control plane and user plane. 175 The following figure describes the architecture of CU separated BNG: 177 +------------------------------------------------------------------+ 178 | Neighboring policy and resource management systems | 179 | | 180 | +-------------+ +-----------+ +---------+ +----------+ | 181 | |AAA Server| |DHCP Server| | EMS | | MANO | | 182 | +-------------+ +-----------+ +---------+ +----------+ | 183 +------------------------------------------------------------------+ 185 +------------------------------------------------------------------+ 186 | CU-separated BNG system | 187 | +--------------------------------------------------------------+ | 188 | | +----------+ +----------+ +------++------++-----------+ | | 189 | | | Address | |Subscriber| | AAA ||PPPoE/|| UP | | | 190 | | |management| |management| | ||IPoE ||management | | | 191 | | +----------+ +----------+ +------++------++-----------+ | | 192 | | CP | | 193 | +--------------------------------------------------------------+ | 194 | | 195 | | 196 | | 197 | +---------------------------+ +--------------------------+ | 198 | | +------------------+ | | +------------------+ | | 199 | | | Routing control | | | | Routing control | | | 200 | | +------------------+ | ... | +------------------+ | | 201 | | +------------------+ | | +------------------+ | | 202 | | |Forwarding engine | | | |Forwarding engine | | | 203 | | +------------------+ UP | | +------------------+ UP| | 204 | +---------------------------+ +--------------------------+ | 205 +------------------------------------------------------------------+ 207 Figure 1. Architecture of CU Separated BNG 209 As in Figure 1, the BNG Control Plane could be virtualized and 210 centralized, which provides significant benefits such as centralized 211 session management, flexible address allocation, high scalability for 212 subscriber management capacity, and cost-efficient redundancy, etc. 214 The functional components inside the BNG Service Control Plane can be 215 implemented as Virtual Network Functions (VNFs) and hosted in a 216 Network Function Virtualization Infrastructure (NFVI). 218 The User Plane Management module in the BNG control plane centrally 219 manages the distributed BNG User Planes (e.g. load balancing), as 220 well as the setup, deletion, and maintenance of channels between 221 Control Planes and User Planes. Other modules in the BNG control 222 plane, such as address management, AAA, etc., are responsible for the 223 connection with outside subsystems in order to fulfill those 224 services. Note that the User Plane SHOULD support both physical and 225 virtual network functions. For example, BNG user plane L3 forwarding 226 related network functions can be disaggregated and distributed across 227 the physical infrastructure. And the other control plane and 228 management plane functions in the CU Separation BNG can be moved into 229 the NFVI for virtualization [TR-384]. 231 The details of CU separated BNG's function components are as 232 following: 234 The Control Plane should support: 236 (1) Address management: unified address pool management. 238 (2) AAA: This component performs Authentication, Authorization and 239 Accounting, together with RADIUS/DIAMETER. The BNG communicates 240 with the AAA server to check whether the subscriber who sent an 241 Access-Request has network access authority. Once the subscriber 242 goes online, this component together with the Service Control 243 component implement accounting, data capacity limitation, and QoS 244 enforcement policies. 246 (3) Subscriber management: user entry management and forwarding 247 policy management. 249 (4) PPPoE/IPoE: process user dialup packets via PPPoE/IPoE. 251 (5) UP management: management of UP interface status, and the setup, 252 deletion, and maintenance of channels between CP and UP. 254 The User Plane should support: 256 (1) Control plane functions including routing, multicast, and MPLS. 258 (2) Forwarding plane functions including traffic forwarding, QoS and 259 traffic statistics collection. 261 3.1 Internal Interfaces Between the CP and UP 263 To support the communication between the Control Plane and User 264 Plane, several interfaces are involved. Figure 2 illustrates the 265 internal interfaces of CU Separated BNG. 267 +-----------------------------------+ 268 | | 269 | BNG-CP | 270 | | 271 +--+--------------+--------------+--+ 272 | | | 273 1. Service | 2. Control | 3. Management| 274 Interface | Interface | Interface | 275 | | | 276 +--+--------------+--------------+--+ 277 | | 278 | BNG-UP | 279 | | 280 +-----------------------------------+ 282 Figure 2. Internal Interfaces Between the CP and UP of the BNG 284 Service Interface: The CP and UP use this interface to establish 285 tunnels with each other and transmit PPPoE and IPoE packets 286 over those tunnels. VXLAN is commonly used for such tunnels 287 as discussed in 288 [hu-nvo3-vxlan-gpe-extension-for-vbng]. 290 Control Interface: The CP uses this interface to deliver service 291 entries, and the UP uses this interface to report service 292 events to the CP. The requirements of this interface are 293 introduced in [cuspdt-rtgwg-cusp-requirements], and the 294 carrying protocol is presented in 295 [cuspdt-rtgwg-cu-separation-bng-protocol] which specifies 296 the Simple Control and User Plane Separation protocol (S- 297 CUSP). The information model of this interface is presented 298 in 299 [cuspdt-rtgwg-cu-separation-infor-model]. 301 Management Interface: The CP uses this interface to deliver 302 configurations to the UP. This interface uses NETCONF 303 [cuspdt-rtgwg-cu-separation-yang-model]. 305 4. Usage of the CU Separation BNG 307 In the CU separated BNG scenario, there are several processes when a 308 home user accesses the Internet: 310 (1) User dialup packets via PPPoE or IPoE from the BNG-UP are sent to 311 the BNG-CP through the BNG-UP's Service Interface. 313 (2) BNG-CP processes the dialup packet. Confirming the user's 314 authorization with the outside neighboring systems in the 315 management network, the BNG-CP makes the decision to permit or 316 deny the user access. 318 (3) After that, the BNG-CP tells the UP to do perform authorized 319 forwarding actions with appropriate QoS policies. 321 (4) If the user is certificated and permitted, the UP forwards the 322 traffic into the Internet with appropriate QoS policies such as 323 limited bandwidth, etc. Otherwise, the user is denied to access 324 the Internet. 326 In actual deployments, a CU separated BNG device is composed of a CP 327 and one or more UPs. The CP is usually centrally deployed and takes 328 responsibility as a user control management component managing UP's 329 resources such as the user entry and forwarding policy. The UPs are 330 distributed and act as a network edge and user policy implementation 331 component. 333 In order to fulfill a service, neighboring policy and resource 334 management systems are deployed outside the BNG. In the neighboring 335 systems, different service systems such as RADIUS/DIAMETER server, 336 DHCP server and EMS are included. If a BNG-CP is virtualized as a 337 NFV, the NFVI management system MANO is also included here. A BNG-CP 338 has connections with the outside neighboring systems to transmit 339 management traffic. 341 The deployment scenario is shown in the following figure: 343 +------------------------------------------------------------------+ 344 | Neighboring policy and resource management systems | 345 | | 346 | +-------------+ +-----------+ +---------+ +----------+ | 347 | | AAA Server| |DHCP Server| | EMS | | MANO | | 348 | +-------------+ +-----------+ +---------+ +----------+ | 349 +------------------------+-----------------------------------------+ 350 | 351 | 352 +-----------------+-----------------+ 353 | | 354 | BNG-CP | 355 | | 356 +-+-----------+------------+--------+ 357 Service| Control| Management| ||| 358 Interface| Interface| Interface| ||| 359 (VXLAN)| (CUSP)| (NETCONF)| ||| 360 | | | ||| 361 +-+-----------+------------+-+ +---------------------------+ 362 | | | | 363 | BNG-UP | | BNG-UP... | 364 | | | | 365 +-------+--------------------+ +---------------+-----------+ 366 | | 367 | | 368 +-------------+-------------+ +--------------+------------+ 369 | | | | 370 | Access Network | | Access Network | 371 | | | | 372 +-+-----------+-----------+-+ +-+---------+----------+----+ 373 | | | | | | 374 | | | | | | 375 +--+---+ +----+-+ +---+--+ +----+-+ +----+-+ +--+---+ 376 |User11| |User12| ... |User1N| |User21| |User22| ... |User2N| 377 +------+ +------+ +------+ +------+ +------+ +------+ 379 Figure 3. Deployment Example 381 5. Security Considerations 383 The Service, Control, and Management Interfaces between the CP and UP 384 might be across the general Internet or other hostile environment. 385 Thus, appropriate protections MUST be implemented to provide 386 integrity, authenticity, and secrecy of traffic over those 387 interfaces. For example, the implementation of IPSEC, DTLS, or TLS 388 as appropriate. However, such security protocols need not always be 389 used and lesser security precautions might be appropriate because, in 390 some cases, the communication between the CP and UP might be in a 391 more benign environment. 393 6. IANA Considerations 395 This document requires no IANA actions. 397 Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, DOI 401 10.17487/RFC2119, March 1997, . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 Informative References 410 [_3GPP.23.501] "System Architecture for the 5G System", 3GPP GPP TS 411 23.501 15.0.0, 2018. 413 [cuspdt-rtgwg-cu-separation-bng-deployment] Gu, R., "Deployment Model 414 of Control Plane and User Plane Separated BNG", draft- 415 cuspdt-rtgwg-cu-separation-bng-deployment, work in 416 progress, 2018. 418 [cuspdt-rtgwg-cu-separation-bng-protocol] Wang, Z., "Control-Plane 419 and User-Plane separation BNG control channel Protocol", 420 draft-cuspdt-rtgwg-cu-separation-bng-protocol, work in 421 progress, 2018. 423 [cuspdt-rtgwg-cu-separation-infor-model] Wang, Z., "Information Model 424 of Control-Plane and User- Plane separation BNG", draft- 425 cuspdt-rtgwg-cu-separation-infor-model, work in progress, 426 2018. 428 [cuspdt-rtgwg-cusp-requirements] Hu, S., "Requirements for Control 429 Plane and User Plane Separated BNG Protocol", draft-cuspdt- 430 rtgwg-cusp-requirements, work in progress, 2018. 432 [cuspdt-rtgwg-cu-separation-yang-model] Hu, F., "YANG Data Model for 433 Configuration Interface of Control-Plane and User-Plane 434 separation BNG", draft-cuspdt-rtgwg-cu-separation-yang- 435 model, work in progress, 2018. 437 [hu-nov3-vxlan-gpe-extension-for-vbng] Huang, L., "VXLAN GPE 438 Extension for Packets Exchange Between Control and User 439 Plane of vBNG", draft-hu-nvo3-vxlan-gpe-extension-for-vbrg, 440 work in progress, 2017. 442 [TR-384] Broadband Forum, "Cloud Central Office Reference 443 Architectural Framework", BBF TR-384, 2018. 445 Authors' Addresses 447 Shujun Hu 448 China Mobile 449 32 Xuanwumen West Ave, Xicheng District 450 Beijing, Beijing 100053 451 China 453 Email: hushujun@chinamobile.com 455 Fengwei Qin 456 China Mobile 457 32 Xuanwumen West Ave, Xicheng District 458 Beijing, Beijing 100053 459 China 461 Email: qinfengwei@chinamobile.com 463 Zhenqiang Li 464 China Mobile 465 32 Xuanwumen West Ave, Xicheng District 466 Beijing, Beijing 100053 467 China 469 Email: lizhenqiang@chinamobile.com 471 Tee Mong Chua 472 Singapore Telecommunications Limited 473 31 Exeter Road, #05-04 Comcentre Podium Block 474 Singapore City 239732 475 Singapore 477 Email: teemong@singtel.com 479 Victor Lopez 480 Telefonica 481 Spain 483 Email: victor.lopezalvarez@telefonica.com 484 Donald Eastlake, 3rd 485 Huawei Technologies 486 1424 Pro Shop Court 487 Davenport, FL 33896 488 USA 490 Phone: +1-508-333-2270 491 Email: d3e3e3@gmail.com 493 Zitao Wang 494 Huawei Technologies 495 101 Software Avenue, Yuhua District 496 Nanjing, Jiangsu 210012 497 China 499 Email: wangzitao@huawei.com 501 Jun Song 502 Huawei Technologies 503 101 Software Avenue, Yuhua District 504 Nanjing, Jiangsu 210012 505 China 507 Email: song.jun@huawei.com 509 Copyright, Disclaimer, and Additional IPR Provisions 511 Copyright (c) 2019 IETF Trust and the persons identified as the 512 document authors. All rights reserved. 514 This document is subject to BCP 78 and the IETF Trust's Legal 515 Provisions Relating to IETF Documents 516 (http://trustee.ietf.org/license-info) in effect on the date of 517 publication of this document. Please review these documents 518 carefully, as they describe your rights and restrictions with respect 519 to this document. Code Components extracted from this document must 520 include Simplified BSD License text as described in Section 4.e of 521 the Trust Legal Provisions and are provided without warranty as 522 described in the Simplified BSD License.