idnits 2.17.1 draft-ietf-teas-native-ip-scenarios-08.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 (August 30, 2019) is 1691 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3209' is defined on line 515, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Informational X. Huang 5 Expires: March 2, 2020 C. Kou 6 BUPT 7 Z. Li 8 China Mobile 9 P. Mi 10 Huawei Technologies 11 August 30, 2019 13 Scenarios and Simulation Results of PCE in Native IP Network 14 draft-ietf-teas-native-ip-scenarios-08 16 Abstract 18 Requirements for providing the End to End(E2E) performance assurance 19 are emerging within the service provider network. While there are 20 various technology solutions, there is no one solution which can 21 fulfill these requirements for a native IP network. One universal 22 (E2E) solution which can cover both intra-domain and inter-domain 23 scenarios is needed. 25 One feasible E2E traffic engineering solution is the use of a Path 26 Computation Elements (PCE) in a native IP network. This document 27 describes various complex scenarios and simulation results when 28 applying a PCE in a native IP network. This solution, referred to as 29 Centralized Control Dynamic Routing (CCDR), integrates the advantage 30 of using distributed protocols and the power of a centralized control 31 technology. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 2, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. CCDR Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. QoS Assurance for Hybrid Cloud-based Application. . . . . 4 71 3.2. Link Utilization Maximization . . . . . . . . . . . . . . 5 72 3.3. Traffic Engineering for Multi-Domain . . . . . . . . . . 6 73 3.4. Network Temporal Congestion Elimination. . . . . . . . . 7 74 4. CCDR Simulation. . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Topology Simulation . . . . . . . . . . . . . . . . . . . 7 76 4.2. Traffic Matrix Simulation. . . . . . . . . . . . . . . . 8 77 4.3. CCDR End-to-End Path Optimization . . . . . . . . . . . . 8 78 4.4. Network Temporal Congestion Elimination . . . . . . . . . 10 79 5. CCDR Deployment Consideration. . . . . . . . . . . . . . . . 11 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 83 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 A service provider network is composed of thousands of routers that 92 run distributed protocols to exchange the reachability information. 93 The path for the destination network is mainly calculated, and 94 controlled, by the distributed protocols. These distributed 95 protocols are robust enough to support most applications, but have 96 some difficulties supporting the complexities needed for traffic 97 engineering applications, e.g. E2E performance assurance, or 98 maximizing the link utilization within an IP network. 100 Multiprotocol Label Switching (MPLS) using Traffic Engineering (TE) 101 technology (MPLS-TE)[RFC3209]is one solution for traffic engineering 102 network but it introduces an MPLS network and related technology 103 which would be an overlay of the IP network. MPLS-TE technology is 104 often used for Label Switched Path (LSP) protection and complex path 105 set-up within a domain. 107 It has not been widely deployed for meeting E2E (especially in inter- 108 domain) dynamic performance assurance requirements for an IP network. 110 Segment Routing [RFC8402] is another solution that integrates some 111 advantages of using a distributed protocol and a centrally control 112 technology, but it requires the underlying network, especially the 113 provider edge router, to do a label push and pop action in-depth, and 114 adds complexity, when coexisting with the Non-Segment Routing 115 network. Additionally, it can only maneuver the E2E paths for MPLS 116 and IPv6 traffic via different mechanisms. 118 Deterministic Networking (DetNet)[RFC8578] is another possible 119 solution. It is primarily focused on providing bounded latency for a 120 flow and introduces additional requirements on the domain edge 121 router. The current DetNet scope is within one domain. The use 122 cases defined in this document do not require the additional 123 complexity of deterministic properties and so differ from the DetNet 124 use cases. 126 This draft describes scenarios for a native IP network that a 127 Centralized Control Dynamic Routing (CCDR) framework can easily 128 solve, without requiring a change of the data plane behaviour on the 129 router. It also provides path optimization simulation results to 130 illustrate the applicability of the CCDR framework. 132 2. Terminology 134 This document uses the following terms defined in [RFC5440]: PCE. 136 The following terms are defined in this document: 138 o BRAS: Broadband Remote Access Server 140 o CD: Congestion Degree 142 o CR: Core Router 144 o CCDR: Centralized Control Dynamic Routing 145 o E2E: End to End 147 o IDC: Internet Data Center 149 o MAN: Metro Area Network 151 o QoS: Quality of Service 153 o SR: Service Router 155 o UID: Utilization Increment Degree 157 o WAN: Wide Area Network 159 3. CCDR Scenarios. 161 The following sections describe various deployment scenarios for 162 applying the CCDR framework. 164 3.1. QoS Assurance for Hybrid Cloud-based Application. 166 With the emergence of cloud computing technologies, enterprises are 167 putting more and more services on a public oriented cloud 168 environment, but keeping core business within their private cloud. 169 The communication between the private and public cloud sites will 170 span the Wide Area Network (WAN) network. The bandwidth requirements 171 between them are variable and the background traffic between these 172 two sites varies over time. Enterprise applications require 173 assurance of the E2E Quality of Service(QoS) performance on demand 174 for variable bandwidth services. 176 CCDR, which integrates the merits of distributed protocols and the 177 power of centralized control, is suitable for this scenario. The 178 possible solution framework is illustrated below: 180 +------------------------+ 181 | Cloud Based Application| 182 +------------------------+ 183 | 184 +-----------+ 185 | PCE | 186 +-----------+ 187 | 188 | 189 //--------------\\ 190 ///// \\\\\ 191 Private Cloud Site || Distributed |Public Cloud Site 192 | Control Network | 193 \\\\\ ///// 194 \\--------------// 196 Figure 1: Hybrid Cloud Communication Scenario 198 By default, the traffic path between the private and public cloud 199 site will be determined by the distributed control network. When 200 applications require the E2E QoS assurance, it can send these 201 requirements to the PCE, and let the PCE compute one E2E path which 202 is based on the underlying network topology and the real traffic 203 information, to accommodate the application's QoS requirements. 204 Section 4 of this document describes the simulation results for this 205 use case. 207 3.2. Link Utilization Maximization 209 Network topology within a Metro Area Network (MAN) is generally in a 210 star mode as illustrated in Figure 2, with different devices 211 connected to different customer types. The traffic from these 212 customers is often in a tidal pattern, with the links between the 213 Core Router(CR)/Broadband Remote Access Server(BRAS) and CR/Service 214 Router(SR), experiencing congestion in different periods, because the 215 subscribers under BRAS, often use the network at night, and the 216 dedicated line users under SR, often use the network during the 217 daytime. The uplink between BRAS/SR and CR must satisfy the maximum 218 traffic volume between them respectively and this causes these links 219 often to be under-utilized. 221 +--------+ 222 | CR | 223 +----|---+ 224 | 225 --------|--------|-------| 226 | | | | 227 +--|-+ +-|- +--|-+ +-|+ 228 |BRAS| |SR| |BRAS| |SR| 229 +----+ +--+ +----+ +--+ 231 Figure 2: Star-mode Network Topology within MAN 233 If we consider connecting the BRAS/SR with a local link loop (which 234 is usually lower cost), and control the overall MAN topology with the 235 CCDR framework, we can exploit the tidal phenomena between the BRAS/ 236 CR and SR/CR links, maximizing the utilization of these links (which 237 are usually higher cost). 239 +-------+ 240 ----- PCE | 241 | +-------+ 242 +----|---+ 243 | CR | 244 +----|---+ 245 | 246 --------|--------|-------| 247 | | | | 248 +--|-+ +-|- +--|-+ +-|+ 249 |BRAS-----SR| |BRAS-----SR| 250 +----+ +--+ +----+ +--+ 252 Figure 3: Link Utilization Maximization via CCDR 254 3.3. Traffic Engineering for Multi-Domain 256 Service provider networks are often comprised of different domains, 257 interconnected with each other,forming a very complex topology as 258 illustrated in Figure 4. Due to the traffic pattern to/from the MAN 259 and IDC, the utilization of the links between them are often 260 asymmetric. It is almost impossible to balance the utilization of 261 these links via a distributed protocol, but this unbalance can be 262 overcome utilizing the CCDR framework. 264 +---+ +---+ 265 |MAN|-----------------IDC| 266 +-|-| | +-|-+ 267 | ---------| | 268 ------|BackBone|------ 269 | ----|----| | 270 | | | 271 +-|-- | ----+ 272 |IDC|----------------|MAN| 273 +---| |---+ 275 Figure 4: Traffic Engineering for Complex Multi-Domain Topology 277 A solution for this scenario requires the gathering of NetFlow 278 information, analysis of the source/destination AS, and determining 279 what is the main cause of the congested link. After this, the 280 operator can use the external Border Gateway Protocol(eBGP) sessions 281 to schedule the traffic among the different domains. 283 3.4. Network Temporal Congestion Elimination. 285 In more general situations, there are often temporal congestions 286 within the service provider's network. Such congestion phenomena 287 often appear repeatedly, and if the service provider has methods to 288 mitigate it, it will certainly improve their network operations 289 capabilities and increase satisfaction for their customers. CCDR is 290 also suitable for such scenarios, as the controller can schedule 291 traffic out of the congested links, lowering the utilization of them 292 during these times. Section 4 describes the simulation results of 293 this scenario. 295 4. CCDR Simulation. 297 The following sections describe the topology, traffic matrix, E2E 298 path optimization and congestion elimination in CCDR applied 299 scenarios. 301 4.1. Topology Simulation 303 The network topology mainly contains nodes and links information. 304 Nodes used in the simulation have two types: core node and edge node. 305 The core nodes are fully linked to each other. The edge nodes are 306 connected only with some of the core nodes. Figure 5 is a topology 307 example of 4 core nodes and 5 edge nodes. In this CCDR simulation, 308 100 core nodes and 400 edge nodes are generated. 310 +----+ 311 /|Edge|\ 312 | +----+ | 313 | | 314 | | 315 +----+ +----+ +----+ 316 |Edge|----|Core|-----|Core|---------+ 317 +----+ +----+ +----+ | 318 / | \ / | | 319 +----+ | \ / | | 320 |Edge| | X | | 321 +----+ | / \ | | 322 \ | / \ | | 323 +----+ +----+ +----+ | 324 |Edge|----|Core|-----|Core| | 325 +----+ +----+ +----+ | 326 | | | 327 | +------\ +----+ 328 | ---|Edge| 329 +-----------------/ +----+ 331 Figure 5: Topology of Simulation 333 The number of links connecting one edge node to the set of core nodes 334 is randomly between 2 to 30, and the total number of links is more 335 than 20000. Each link has a congestion threshold. 337 4.2. Traffic Matrix Simulation. 339 The traffic matrix is generated based on the link capacity of 340 topology. It can result in many kinds of situations, such as 341 congestion, mild congestion and non-congestion. 343 In the CCDR simulation, the dimension of the traffic matrix is 344 500*500. About 20% links are overloaded when the Open Shortest Path 345 First (OSPF) protocol is used in the network. 347 4.3. CCDR End-to-End Path Optimization 349 The CCDR E2E path optimization is to find the best path which is the 350 lowest in metric value and each link of the path is far below link's 351 threshold. Based on the current state of the network, the PCE within 352 CCDR framework combines the shortest path algorithm with a penalty 353 theory of classical optimization and graph theory. 355 Given a background traffic matrix, which is unscheduled, when a set 356 of new flows comes into the network, the E2E path optimization finds 357 the optimal paths for them. The selected paths bring the least 358 congestion degree to the network. 360 The link Utilization Increment Degree(UID), when the new flows are 361 added into the network, is shown in Figure 6. The first graph in 362 Figure 6 is the UID with OSPF and the second graph is the UID with 363 CCDR E2E path optimization. The average UID of the first graph is 364 more than 30%. After path optimization, the average UID is less than 365 5%. The results show that the CCDR E2E path optimization has an eye- 366 catching decrease in UID relative to the path chosen based on OSPF. 368 +-----------------------------------------------------------+ 369 | * * * *| 370 60| * * * * * *| 371 |* * ** * * * * * ** * * * * **| 372 |* * ** * * ** *** ** * * ** * * * ** * * *** **| 373 |* * * ** * ** ** *** *** ** **** ** *** **** ** *** **| 374 40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **| 375 UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********| 376 |*** ******* ** **** *********** *********** ***************| 377 |******************* *********** *********** ***************| 378 20|******************* ***************************************| 379 |******************* ***************************************| 380 |***********************************************************| 381 |***********************************************************| 382 0+-----------------------------------------------------------+ 383 0 100 200 300 400 500 600 700 800 900 1000 384 +-----------------------------------------------------------+ 385 | | 386 60| | 387 | | 388 | | 389 | | 390 40| | 391 UID(%)| | 392 | | 393 | | 394 20| | 395 | *| 396 | * *| 397 | * * * * * ** * *| 398 0+-----------------------------------------------------------+ 399 0 100 200 300 400 500 600 700 800 900 1000 400 Flow Number 401 Figure 6: Simulation Result with Congestion Elimination 403 4.4. Network Temporal Congestion Elimination 405 Different degrees of network congestions were simulated. The 406 Congestion Degree (CD) is defined as the link utilization beyond its 407 threshold. 409 The CCDR congestion elimination performance is shown in Figure 7. 410 The first graph is the CD distribution before the process of 411 congestion elimination. The average CD of all congested links is 412 more than 10%. The second graph shown in Figure 7 is the CD 413 distribution after using the congestion elimination process. It 414 shows only 12 links among totally 20000 links exceed the threshold, 415 and all the CD values are less than 3%. Thus, after scheduling of the 416 traffic away from the congested paths, the degree of network 417 congestion is greatly eliminated and the network utilization is in 418 balance. 420 Before congestion elimination 421 +-----------------------------------------------------------+ 422 | * ** * ** ** *| 423 20| * * **** * ** ** *| 424 |* * ** * ** ** **** * ***** *********| 425 |* * * * * **** ****** * ** *** **********************| 426 15|* * * ** * ** **** ********* *****************************| 427 |* * ****** ******* ********* *****************************| 428 CD(%) |* ********* ******* ***************************************| 429 10|* ********* ***********************************************| 430 |*********** ***********************************************| 431 |***********************************************************| 432 5|***********************************************************| 433 |***********************************************************| 434 |***********************************************************| 435 0+-----------------------------------------------------------+ 436 0 0.5 1 1.5 2 438 After congestion elimination 439 +-----------------------------------------------------------+ 440 | | 441 20| | 442 | | 443 | | 444 15| | 445 | | 446 CD(%) | | 447 10| | 448 | | 449 | | 450 5 | | 451 | | 452 | * ** * * * ** * ** * | 453 0 +-----------------------------------------------------------+ 454 0 0.5 1 1.5 2 455 Link Number(*10000) 456 Figure 7: Simulation Result with Congestion Elimination 458 5. CCDR Deployment Consideration. 460 With the above CCDR scenarios and simulation results, we demonstrate 461 it is feasible to find one general solution to cope with various 462 complex situations. Integrated use of a centralized controller for 463 the more complex optimal path computations in a native IP network 464 results in significant improvements without impacting the underlay 465 network infrastructure. A proposed solution is described in 466 draft[I-D.ietf-teas-pce-native-ip] . 468 6. Security Considerations 470 This document considers mainly the integration of distributed 471 protocols and the central control capability of a PCE. While It 472 certainly can ease the management of network in various traffic 473 engineering scenarios as described in this document, the centralized 474 control also bring a new point that may be easily attacked. 475 Solutions for CCDR scenarios need to consider protection of the 476 PCEand communication with the underlay devices. [RFC5440] and 477 [RFC8253] provide additional information. 479 7. IANA Considerations 481 This document does not require any IANA actions. 483 8. Contributors 485 Lu Huang contributed to the content of this draft. 487 9. Acknowledgement 489 The author would like to thank Deborah Brungard, Adrian Farrel, 490 Huaimo Chen, Vishnu Beeram and Lou Berger for their support and 491 comments on this draft. 493 10. References 495 10.1. Normative References 497 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 498 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 499 DOI 10.17487/RFC5440, March 2009, 500 . 502 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 503 "PCEPS: Usage of TLS to Provide a Secure Transport for the 504 Path Computation Element Communication Protocol (PCEP)", 505 RFC 8253, DOI 10.17487/RFC8253, October 2017, 506 . 508 10.2. Informative References 510 [I-D.ietf-teas-pce-native-ip] 511 Wang, A., Zhao, Q., Khasanov, B., Chen, H., and R. Mallya, 512 "PCE in Native IP Network", draft-ietf-teas-pce-native- 513 ip-03 (work in progress), April 2019. 515 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 516 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 517 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 518 . 520 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 521 Decraene, B., Litkowski, S., and R. Shakir, "Segment 522 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 523 July 2018, . 525 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 526 RFC 8578, DOI 10.17487/RFC8578, May 2019, 527 . 529 Authors' Addresses 531 Aijun Wang 532 China Telecom 533 Beiqijia Town, Changping District 534 Beijing, Beijing 102209 535 China 537 Email: wangaj3@chinatelecom.cn 539 Xiaohong Huang 540 Beijing University of Posts and Telecommunications 541 No.10 Xitucheng Road, Haidian District 542 Beijing 543 China 545 Email: huangxh@bupt.edu.cn 547 Caixia Kou 548 Beijing University of Posts and Telecommunications 549 No.10 Xitucheng Road, Haidian District 550 Beijing 551 China 553 Email: koucx@lsec.cc.ac.cn 554 Zhenqiang Li 555 China Mobile 556 32 Xuanwumen West Ave, Xicheng District 557 Beijing 100053 558 China 560 Email: li_zhenqiang@hotmail.com 562 Penghui Mi 563 Huawei Technologies 564 Tower C of Bldg.2, Cloud Park, No.2013 of Xuegang Road 565 Shenzhen, Bantian,Longgang District 518129 566 China 568 Email: mipenghui@huawei.com