idnits 2.17.1 draft-cuspdt-rtgwg-cusp-requirements-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 1985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.cuspdt-rtgwg-cu-separation-bng-deployment' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'I-D.cuspdt-rtgwg-cu-separation-infor-model' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-cuspdt-rtgwg-cu-separation-bng-deployment-00 == Outdated reference: A later version (-03) exists of draft-cuspdt-rtgwg-cu-separation-infor-model-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg S. Hu 3 Internet-Draft China Mobile 4 Intended status: Informational V. Lopez 5 Expires: April 25, 2019 Telefonica 6 F. Qin 7 Z. Li 8 China Mobile 9 T. Chua 10 Singapore Telecommunications Limited 11 Donald. Eastlake 12 M. Wang 13 J. Song 14 Huawei 15 October 22, 2018 17 Requirements for Control Plane and User Plane Separated BNG Protocol 18 draft-cuspdt-rtgwg-cusp-requirements-03 20 Abstract 22 This document introduces the Control Plane and User Plane separated 23 BNG (Broadband Network Gateway) architecture and defines a set of 24 associated terminology. It also specifies a set of protocol 25 requirements for communication between the BNG-CP and the BNG-UPs in 26 the Control Plane and User Plane Separated BNG. 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 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 25, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 3 64 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. CU Separated BNG Model . . . . . . . . . . . . . . . . . . . 3 66 3.1. Internal interfaces between the CP and UP . . . . . . . . 5 67 4. The usage of CU separation BNG protocol . . . . . . . . . . . 6 68 5. Control Plane and User Plane Separation Protocol Requirements 7 69 5.1. Transmit information tables . . . . . . . . . . . . . . . 7 70 5.2. Message Priority . . . . . . . . . . . . . . . . . . . . 7 71 5.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.4. Support for Secure Communication . . . . . . . . . . . . 8 73 5.5. Version negotiation . . . . . . . . . . . . . . . . . . . 8 74 5.6. Capability Exchange . . . . . . . . . . . . . . . . . . . 9 75 5.7. CP primary/backup capability . . . . . . . . . . . . . . 9 76 5.8. Event Notification . . . . . . . . . . . . . . . . . . . 9 77 5.9. Query Statistics . . . . . . . . . . . . . . . . . . . . 10 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 A Broadband Network Gateway (BNG) is an Ethernet-centric IP edge 88 router and the aggregation point for user traffic. To provide 89 centralized session management, flexible address allocation, high 90 scalability for subscriber management capacity, and cost-efficient 91 redundancy, the CU separated BNG is introduced [TR-384]. The CU 92 separated Service Control Plane could be virtualized and centralized; 93 it is responsible for user access authentication and sending 94 forwarding entries to user planes. The routing control and 95 forwarding plane, i.e. BNG user plane (local), could be distributed 96 across the infrastructure. 98 This document introduces the Control Plane and User Plane separated 99 BNG architecture and modeling. This document also defines the 100 protocol requirements for Control Plane and User Plane Separated BNG 101 (CUSP). 103 2. Concept and Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 2.1. Terminology 113 BNG: Broadband Network Gateway. A broadband remote access server 114 (BRAS, B-RAS or BBRAS) that routes traffic to and from broadband 115 remote access devices such as digital subscriber line access 116 multiplexers (DSLAM) on an Internet service provider's (ISP) network. 117 BRAS can also be referred to as a Broadband Network Gateway (BNG). 119 CP: Control Plane. The CP is a user control management component 120 which manages UP's resources such as the user entry and user's QoS 121 policy. 123 CUSP: Control Plane and User Plane Separated BNG Protocol. 125 UP: User Plane. UP is a network edge and user policy implementation 126 component. The traditional router's Control Plane and forwarding 127 plane are both preserved on BNG devices in the form of a user plane. 129 3. CU Separated BNG Model 131 Figure 1 shows the architecture of CU separated BNG 132 +------------------------------------------------------------------+ 133 | Neighboring policy and resource management systems | 134 | | 135 | +-------------+ +-----------+ +---------+ +----------+ | 136 | |Radius Server| |DHCP Server| | EMS | | MANO | | 137 | +-------------+ +-----------+ +---------+ +----------+ | 138 +------------------------------------------------------------------+ 140 +------------------------------------------------------------------+ 141 | CU-separated BNG system | 142 | +--------------------------------------------------------------+ | 143 | | +----------+ +----------+ +------++------++-----------+ | | 144 | | | Address | |Subscriber| |Radius||PPPoE/|| UP | | | 145 | | |management| |management| | ||IPoE ||management | | | 146 | | +----------+ +----------+ +------++------++-----------+ | | 147 | | CP | | 148 | +--------------------------------------------------------------+ | 149 | | 150 | | 151 | | 152 | +---------------------------+ +--------------------------+ | 153 | | +------------------+ | | +------------------+ | | 154 | | | Routing control | | | | Routing control | | | 155 | | +------------------+ | ... | +------------------+ | | 156 | | +------------------+ | | +------------------+ | | 157 | | |Forwarding engine | | | |Forwarding engine | | | 158 | | +------------------+ UP | | +------------------+ UP| | 159 | +---------------------------+ +--------------------------+ | 160 +------------------------------------------------------------------+ 161 Figure 1. Architecture of CU Separated BNG 163 Briefly, a CU separated BNG is made up of a Control Plane (CP) and a 164 set of User Planes (UPs) [TR-384], [I-D.cuspdt-rtgwg-cu-separation- 165 bng-deployment]. The Control Plane is a user control management 166 component which manages UP's resources such as the user entry and 167 user's Quality of Service (QoS) policy, for example, the access 168 bandwidth and priority management. This Control Plane could be 169 virtualized and centralized. The functional modules inside the BNG 170 Service Control Plane can be implemented as Virutl Network Functions 171 (VNFs) and hosted in a Network Function Virtualization Infrastructure 172 (NFVI). The User Plane Management module in the BNG control plane 173 centrally manages the distributed BNG user planes (e.g. load 174 balancing), as well as the setup, deletion, update, and maintenance 175 of channels between control planes and user planes [TR-384], [I- 176 D.cuspdt-rtgwg-cu-separation-bng-deployment]. The User Plane (UP) is 177 a network edge and user policy implementation component. It can 178 support the forwarding plane functions on traditional BNG devices, 179 such as traffic forwarding, QoS, and traffic statistics collection, 180 and it can also support the control plane functions on traditional 181 BNG devices, such as routing, multicast, etc [TR-384], [I-D.cuspdt- 182 rtgwg-cu-separation-bng-deployment]. 184 3.1. Internal interfaces between the CP and UP 186 To support communication between the Control Plane and User Plane, 187 several interfaces are involved. Figure 2 illustrates the three 188 internal interfaces of CU Separated BNG. 190 +----------------------------------+ 191 | | 192 | BNG-CP | 193 | | 194 +--+--------------+--------------+-+ 195 | | | 196 1.Service | 2.Control | 3.Management| 197 Interface | Interface | Interface | 198 | | | 199 +--+--------------+--------------+-+ 200 | | 201 | BNG-UP | 202 | | 203 +----------------------------------+ 205 Figure 2. Interfaces between the BNG-CP and the BNG-UP 207 Service interface: The CP and UP use this interface to establish 208 VXLAN tunnels with each other and transmit PPPoE and IPoE packets 209 over the VXLAN tunnels. 211 Control interface: The CP uses this interface to deliver service 212 entries, and the UP uses this interface to report service events to 213 the CP. 215 Management interface: The CP uses this interface to deliver 216 configurations to the UP. This interface uses NETCONF. 218 The CUSP (Control plane and User plane Separated BNG protocol) 219 defines the control interface, and specifies the communication 220 between the centralized control plane and user planes. This protocol 221 should be designed to support establishing and maintaining a 222 conversation between CP and UPs, and transporting the tables that are 223 specified in [draft-cuspdt-rtgwg-cu-separation-infor-model]. 225 4. The usage of CU separation BNG protocol 227 ----------------- 228 //// \\\\ 229 //// \\\\ 230 // Cloud \\ 231 | | 232 | | 233 | | 234 | | 235 | +-----------------+ | 236 | | Control Plane | | 237 \\ | | // 238 \\\\ +------+----------+ //// 239 \\\\ | //// 240 ----+------------ 241 | Control Interface (CUSP) 242 +--------+----------+-------------+-----+ 243 | | | | 244 User's information IP address QoS: ....... 245 May Include: | CIR; : 246 User ID; | PIR; | 247 User MAC; | CBS; | 248 Access method(PPPoE, | PBS; | 249 IPoE, etc) | ...... 250 ..... | | | 251 +-------------------V--------------+ 252 | 253 +-----------+ 254 | ------- 255 | /// \\\ 256 +------+ +-------v---------+ +--------+ | | 257 | OLT | | User Plane | | Core | | Internet | 258 | +-------+ +-------+ Routing+-----+ | 259 +------+ +-----------------+ +--------+ \\\ /// 260 ------- 261 Figure 3. CU Separation BNG protocol usage 263 As shown in Figure 3, when users access the BNG network, the control 264 plane solicits user information (such as user's ID, user's MAC, 265 user's access methods, for example via PPPoE/IPoE), associates users 266 with available bandwidth which is reported by User planes, and, based 267 on the service's requirement, generates a set of tables, which may 268 include user's information, UP's IP segment, and QoS, etc. Then the 269 control plane can transmit these tables to the User planes. User 270 planes receive these tables, parse them, and then perform 271 corresponding actions. 273 5. Control Plane and User Plane Separation Protocol Requirements 275 This section specifies the requirements for the CU separation 276 protocol. 278 5.1. Transmit information tables 280 The Control Plane and User Plane Separation Protocol MUST allow the 281 CP to send tables to each User Plane device. 283 a) The current BNG service requires that the UP should support at 284 least 2000 users being accessed every second. And every user 285 requires at least 2000 bytes. To achieve high performance, the CU 286 Separation protocol SHOULD be lightweight. 288 b) CU separation protocol should support data encoded as either 289 XML or binary. It allows user information data to be read, saved, 290 and manipulated with tools specific to XML or binary. 292 c) In order to provide centralized session management, high 293 scalability for subscriber management capacity, and cost-efficient 294 redundancy, batching ability should be provided. The CU 295 Separation protocol should be able to group an ordered set of 296 commands to a UP device. Each such group of commands SHOULD be 297 sent to the UP in as few messages as practical. Furthermore, the 298 protocol MUST support the ability to specify if a command group 299 MUST have all-or-nothing semantics. 301 d) The CU Separation protocol SHOULD be able to support at least 302 hundreds of UP devices and tens of thousands of ports. For 303 example, the protocol field sizes corresponding to UP or port 304 numbers SHALL be large enough to support the minimum required 305 numbers. This requirement does not relate to the performance of 306 the system as the number of UPs or ports in the system grows. 308 5.2. Message Priority 310 The CU Separation protocol MUST provide a means to express the 311 protocol message priorities. 313 5.3. Reliability 315 Heartbeat is a periodic signal generated by hardware or software to 316 test for some aspects of normal operation or to synchronize other 317 parts of network system. 319 In the CU separation BNG, a heartbeat is sent between CP and UPs at a 320 regular interval on the order of seconds. If the CP/UP does not 321 receive a heartbeat for a time--usually a few heartbeat intervals-- 322 the CP/UP that should have sent the heartbeat is assumed to have 323 failed. 325 The CU separation protocol should support some kind of heartbeat 326 monitoring mechanism. And this mechanism should have ability to 327 distinguish whether the interruption is an actual failure. For 328 example, in some scenarios (i.e. CP/UP update, etc), the connection 329 between the UP and CP need to be interrupted. In this case, the 330 interruption should not be reported. 332 5.4. Support for Secure Communication 334 As mentioned above, CP may send some information tables to the UP 335 which may be critical to the network function (e.g, User Information, 336 IPv4/IPv6 information) and may reflect the business information (e.g, 337 QoS, service level agreements, etc). Therefore, supporting the 338 integrity of all CU Separation protocol messages and protecting 339 against man-in-the-middle attacks MUST be supported. 341 The CP Separation protocol should support security in a variety of 342 scenarios. For example, the connections between the CP and UPs could 343 be dedicated lines, VPNs within one domain, or could cross several 344 domains, that is, cross third party networks. Thus it is likely that 345 more than one security mechanism SHOULD be supported. TLS and IPsec 346 are good candidates for such mechanisms. 348 5.5. Version negotiation 350 The CU separated BNG may consist of different vendors' devices 351 implementing different versions of protocol. Threfore, the CU 352 separation protocol MUST provide some mechanisms to perform the 353 version negotiation. 355 Version negotiation is the process that the CU separated BNG's 356 Control-Plane uses to evaluate the protocol versions supported by 357 both the control-plane and the user-plane devices. Then a suitable 358 protocol version is selected for communication in CUSP. The process 359 is a "negotiation" because it requires identifying the most recent 360 protocol version that is supported by both the control-plane and the 361 user-plane devices or determining that they have no version in 362 common. 364 5.6. Capability Exchange 366 The UP Capability Report displays the device's profile, service 367 capability, and other assigned capabilities within the CU separated 368 BNG. The CU separation protocol should MUST provide some mechanism 369 to exchange the UP device's capabilities. 371 5.7. CP primary/backup capability 373 A backup CP for failure recovery is required for the CU separated BNG 374 network. And the CUSP should provide some mechanism to implement the 375 backup CP: 377 a) In some scenarios, there may be two CP devices both declaring 378 the primary CP. Thus the CUSP should support or associate with 379 some mechanisms to determine which CP is the primary device. 381 b) In the scenario of the primary CP down, the CUSP should support 382 switching between primary and backup CP. 384 5.8. Event Notification 386 The CUSP protocol SHOULD be able to asynchronously notify the CP of 387 events on the UP such as failures and changes in available resources 388 and capabilities. Some scenarios that may initiate event 389 notifications are listed below. 391 a) Sending response message: As mentioned above, the control plane 392 solicits users' information, associates them with available 393 bandwidth, and generates a set of tables based on the service's 394 requirement. Then the control plane transmits these tables to the 395 conresponding User plane. The UP should respond with an event 396 notification to inform the CP that the tables are received. 398 b) User trace: The user trace mechanism can support the Control 399 Plane tracing and monitoring the network status for users (for 400 example the real-time bandwidth, etc), to help debug the user's 401 application. Therefore, the UPs SHOULD be able to notify the CP 402 with the User trace message. 404 c) Sending statistics parameters: In CU separation BNG, the User- 405 plane will report the traffic statistics parameters to the 406 Control-plane, such as the ingress packets, ingress bytes, egress 407 packets, egress bytes, etc. These parameters can help measure the 408 BNG network performance. Available network resources can be 409 allocated basing on the statistics parameters by the BNG-CP. 410 Therefore, the UPs SHOULD be able to notify the CP with statistics 411 parameters. 413 d) Report the result of User Detect: "User Detect" message will be 414 send periodically to detect user dial-up and disconnect. The UPs 415 SHOULD be able to notify the CP with the result of User Detect. 417 5.9. Query Statistics 419 The CUSP protocol MUST provide a means for the CP to be able to query 420 statistics (performance monitoring) from the UP. 422 6. Security Considerations 424 As this is an Informational requirements document, detailed technical 425 Security Considerations are not included. However, Section 5.4 426 covers general security requirements and Section 5.7 covers backup 427 requirements relevant to some denial of service scenarios. 429 7. IANA Considerations 431 This document requires no IANA actions. 433 8. References 435 8.1. Normative References 437 [I-D.cuspdt-rtgwg-cu-separation-bng-deployment] 438 Gu, R., Hu, S., and Z. Wang, "Deployment Model of Control 439 Plane and User Plane Separation BNG", draft-cuspdt-rtgwg- 440 cu-separation-bng-deployment-00 (work in progress), 441 October 2017. 443 [I-D.cuspdt-rtgwg-cu-separation-infor-model] 444 Wang, Z., Gu, R., Lopezalvarez, V., and S. Hu, 445 "Information Model of Control-Plane and User-Plane 446 separation BNG", draft-cuspdt-rtgwg-cu-separation-infor- 447 model-00 (work in progress), February 2018. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 455 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 456 May 2017, . 458 8.2. Informative References 460 [TR-384] Broadband Forum, ""Cloud Central Office Reference 461 Architectural Framework",", BBF TR-384, January. 2018. 463 Authors' Addresses 465 Shujun Hu 466 China Mobile 467 32 Xuanwumen West Ave, Xicheng District 468 Beijing, Beijing 100053 469 China 471 Email: shujun_hu@outlook.com 473 Victor Lopez 474 Telefonica 475 Sur 3 building, 3rd floor, Ronda de la Comunicacion s/n 476 Madrid 28050 477 Spain 479 Email: victor.lopezalvarez@telefonica.com 481 Fengwei Qin 482 China Mobile 483 32 Xuanwumen West Ave, Xicheng District 484 Beijing, Beijing 100053 485 China 487 Email: qinfengwei@chinamobile.com 489 Zhenqiang Li 490 China Mobile 491 32 Xuanwumen West Ave, Xicheng District 492 Beijing, Beijing 100053 493 China 495 Email: lizhenqiang@chinamobile.com 496 Tee Mong Chua 497 Singapore Telecommunications Limited 498 31 Exeter Road, #05-04 Comcentre Podium Block 499 Singapore City 239732 500 Singapore 502 Email: teemong@singtel.com 504 Donald Eastlake, 3rd 505 Huawei 506 1424 Pro Shop Court 507 Davenport, FL 33896 508 USA 510 Email: d3e3e3@gmail.com 512 Michael Wang 513 Huawei 514 101 Software Avenue, Yuhua District 515 Nanjing, Jiangsu 210012 516 China 518 Email: wangzitao@huawei.com 520 Jun Song 521 Huawei 522 101 Software Avenue, Yuhua District 523 Nanjing, Jiangsu 210012 524 China 526 Email: song.jun@huawei.com