idnits 2.17.1 draft-ietf-teas-native-ip-scenarios-06.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 (July 1, 2019) is 1733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3209' is defined on line 473, 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: January 2, 2020 C. Kou 6 BUPT 7 Z. Li 8 China Mobile 9 P. Mi 10 Huawei Technologies 11 July 1, 2019 13 Scenarios and Simulation Results of PCE in Native IP Network 14 draft-ietf-teas-native-ip-scenarios-06 16 Abstract 18 This document describes the scenarios and simulation results for PCE 19 in native IP network, which integrates the merit of distributed 20 protocols (IGP/BGP), and the power of centrally control technologies 21 (PCE/SDN) to provide one feasible traffic engineering solution in 22 various complex scenarios for the service provider. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 2, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. CCDR Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. QoS Assurance for Hybrid Cloud-based Application. . . . . 3 61 2.2. Link Utilization Maximization . . . . . . . . . . . . . . 4 62 2.3. Traffic Engineering for Multi-Domain . . . . . . . . . . 5 63 2.4. Network Temporal Congestion Elimination. . . . . . . . . 6 64 3. CCDR Simulation. . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Topology Simulation . . . . . . . . . . . . . . . . . . . 6 66 3.2. Traffic Matrix Simulation. . . . . . . . . . . . . . . . 7 67 3.3. CCDR End-to-End Path Optimization . . . . . . . . . . . . 7 68 3.4. Network Temporal Congestion Elimination . . . . . . . . . 9 69 4. CCDR Deployment Consideration. . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Service provider network is composed thousands of routers that run 82 distributed protocol to exchange the reachability information between 83 them. The path for the destination network is mainly calculated and 84 controlled by the IGP/BGP protocols. These distributed protocols are 85 robust enough to support the current evolution of Internet but have 86 some difficulties when application requires the end-to-end QoS 87 performance, or in the situation that the service provider wants to 88 maximize the link utilization within their network. 90 MPLS-TE technology [RFC3209]is one solution for finely planned 91 network but it will put heavy burden on the routers when we use it to 92 meet the dynamic QoS assurance requirements within real time traffic 93 network. 95 SR(Segment Routing) [RFC8402] is another solution that integrates 96 some merits of distributed protocol and the advantages of centrally 97 control mode, but it requires the underlying network, especially the 98 provider edge router to do label push and pop action in-depth, and 99 need complex mechanic for coexisting with the Non-SR network. 100 Additionally, it can only maneuver the end-to-end path for MPLS and 101 IPv6 traffic via different mechanisms. 103 DetNet[RFC8578] describes use cases for diverse industries that have 104 a common need for "deterministic flows", which can provide guaranteed 105 bandwidth, bounded latency, and other properties germane to the 106 transport of time-sensitive data. The use cases focus mainly on the 107 industrial critical applications within one centrally controlled 108 network and are out of scope of this draft. 110 This draft describes scenarios that the centrally control dynamic 111 routing (CCDR) framework can easily solve, without the change of the 112 data plane behaviour on the router. It also gives the path 113 optimization simulation results to illustrate the applicability of 114 CCDR framework. 116 2. CCDR Scenarios. 118 The following sections describe some scenarios that the CCDR 119 framework is suitable for deployment. 121 2.1. QoS Assurance for Hybrid Cloud-based Application. 123 With the emerge of cloud computing technologies, enterprises are 124 putting more and more services on the public oriented cloud 125 environment, but keep core business within their private cloud. The 126 communication between the private and public cloud sites will span 127 the WAN network. The bandwidth requirements between them are 128 variable and the background traffic between these two sites changes 129 from time to time. Enterprise applications just want to exploit the 130 network capabilities to assure the end-to-end QoS performance on 131 demand. 133 CCDR, which integrates the merits of distributed protocol and the 134 power of centrally control, is suitable for this scenario. The 135 possible solution framework is illustrated below: 137 +------------------------+ 138 | Cloud Based Application| 139 +------------------------+ 140 | 141 +-----------+ 142 | PCE | 143 +-----------+ 144 | 145 | 146 //--------------\\ 147 ///// \\\\\ 148 Private Cloud Site || Distributed |Public Cloud Site 149 | Control Network | 150 \\\\\ ///// 151 \\--------------// 153 Fig.1 Hybrid Cloud Communication Scenario 155 By default, the traffic path between the private and public cloud 156 site will be determined by the distributed control network. When 157 applications require the end-to-end QoS assurance, it can send these 158 requirements to PCE,let PCE compute one e2e path which is based on 159 the underlying network topology and the real traffic information, to 160 accommodate the application's QoS requirements. The proposed 161 solution can refer the draft [I-D.ietf-teas-pce-native-ip]. 162 Section 4 describes the detail simulation process and the result. 164 2.2. Link Utilization Maximization 166 Network topology within MAN is generally in star mode as illustrated 167 in Fig.2, with different devices connect different customer types. 168 The traffic from these customers is often in tidal pattern that the 169 links between the CR/BRAS and CR/SR will experience congestion in 170 different periods, because the subscribers under BRAS often use the 171 network at night and the dedicated line users under SR often use the 172 network during the daytime. The uplink between BRAS/SR and CR must 173 satisfy the maximum traffic volume between them respectively and this 174 causes these links often in underutilization situation. 176 +--------+ 177 | CR | 178 +----|---+ 179 | 180 --------|--------|-------| 181 | | | | 182 +--|-+ +-|- +--|-+ +-|+ 183 |BRAS| |SR| |BRAS| |SR| 184 +----+ +--+ +----+ +--+ 186 Fig.2 Star-mode Network Topology within MAN 188 If we consider to connect the BRAS/SR with local link loop (which is 189 more cheaper), and control the MAN with the CCDR framework, we can 190 exploit the tidal phenomena between BRAS/CR and SR/CR links, maximize 191 the links (which is more expensive) utilization of them . 193 +-------+ 194 ----- PCE | 195 | +-------+ 196 +----|---+ 197 | CR | 198 +----|---+ 199 | 200 --------|--------|-------| 201 | | | | 202 +--|-+ +-|- +--|-+ +-|+ 203 |BRAS-----SR| |BRAS-----SR| 204 +----+ +--+ +----+ +--+ 206 Fig.3 Link Utilization Maximization via CCDR 208 2.3. Traffic Engineering for Multi-Domain 210 Operator's networks are often comprised by different domains, 211 interconnected with each other,form very complex topology that 212 illustrated in Fig.4. Due to the traffic pattern to/from MAN and 213 IDC, the utilization of links between them are often asymmetric. It 214 is almost impossible to balance the utilization of these links via 215 the distributed protocol, but this unbalance phenomenon can be 216 overcome via the CCDR framework. 218 +---+ +---+ 219 |MAN|-----------------IDC| 220 +-|-| | +-|-+ 221 | ---------| | 222 ------|BackBone|------ 223 | ----|----| | 224 | | | 225 +-|-- | ----+ 226 |IDC|----------------|MAN| 227 +---| |---+ 229 Fig.4 Traffic Engineering for Complex Multi-Domain Topology 231 Solution for this scenario requires the gather of NetFlow 232 information, analysis the source/destination AS of them and determine 233 which pair is the main cause of the congested link. After this, the 234 operator can use the multi eBGP sessions described in 235 [I-D.ietf-teas-pce-native-ip]to schedule the traffic among different 236 domains. 238 2.4. Network Temporal Congestion Elimination. 240 In more general situation, there are often temporal congestions 241 within the service provider's network. Such congestion phenomena 242 often appear repeatedly and if the service provider has some methods 243 to mitigate it, it will certainly increase the degree of satisfaction 244 for their customers. CCDR is also suitable for such scenario in such 245 manner that the distributed protocol process most of the traffic 246 forwarding and the controller schedule some traffic out of the 247 congestion links to lower the utilization of them. Section 4 248 describes the simulation process and results about such scenario. 250 3. CCDR Simulation. 252 The following sections describe the topology, traffic matrix, end-to- 253 end path optimization and congestion elimination in CCDR applied 254 scenarios. 256 3.1. Topology Simulation 258 The network topology mainly contains nodes and links information. 259 Nodes used in simulation have two types: core node and edge node. 260 The core nodes are fully linked to each other. The edge nodes are 261 connected only with some of the core nodes. Fig.5 is a topology 262 example of 4 core nodes and 5 edge nodes. In CCDR simulation, 100 263 core nodes and 400 edge nodes are generated. 265 +----+ 266 /|Edge|\ 267 | +----+ | 268 | | 269 | | 270 +----+ +----+ +----+ 271 |Edge|----|Core|-----|Core|---------+ 272 +----+ +----+ +----+ | 273 / | \ / | | 274 +----+ | \ / | | 275 |Edge| | X | | 276 +----+ | / \ | | 277 \ | / \ | | 278 +----+ +----+ +----+ | 279 |Edge|----|Core|-----|Core| | 280 +----+ +----+ +----+ | 281 | | | 282 | +------\ +----+ 283 | ---|Edge| 284 +-----------------/ +----+ 286 Fig.5 Topology of Simulation 288 The number of links connecting one edge node to the set of core nodes 289 is randomly between 2 to 30, and the total number of links is more 290 than 20000. Each link has its congestion threshold. 292 3.2. Traffic Matrix Simulation. 294 The traffic matrix is generated based on the link capacity of 295 topology. It can result in many kinds of situations, such as 296 congestion, mild congestion and non-congestion. 298 In CCDR simulation, the dimension of the traffic matrix is 500*500. 299 About 20% links are overloaded when the Open Shortest Path First 300 (OSPF) protocol is used in the network. 302 3.3. CCDR End-to-End Path Optimization 304 The CCDR end-to-end path optimization is to find the best path which 305 is the lowest in metric value and each link of the path is far below 306 link's threshold. Based on the current state of the network, PCE 307 within CCDR framework combines the shortest path algorithm with 308 penalty theory of classical optimization and graph theory. 310 Given background traffic matrix which is unscheduled, when a set of 311 new flows comes into the network, the end-to-end path optimization 312 finds the optimal paths for them. The selected paths bring the least 313 congestion degree to the network. 315 The link utilization increment degree(UID) when the new flows are 316 added into the network is shown in Fig.6. The first graph in Fig.6 317 is the UID with OSPF and the second graph is the UID with CCDR end- 318 to-end path optimization. The average UID of the first graph is more 319 than 30%. After path optimization, the average UID is less than 5%. 320 The results show that the CCDR end-to-end path optimization has an 321 eye-catching decreasing in UID relative to the path chosen based on 322 OSPF. 324 +-----------------------------------------------------------+ 325 | * * * *| 326 60| * * * * * *| 327 |* * ** * * * * * ** * * * * **| 328 |* * ** * * ** *** ** * * ** * * * ** * * *** **| 329 |* * * ** * ** ** *** *** ** **** ** *** **** ** *** **| 330 40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **| 331 UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********| 332 |*** ******* ** **** *********** *********** ***************| 333 |******************* *********** *********** ***************| 334 20|******************* ***************************************| 335 |******************* ***************************************| 336 |***********************************************************| 337 |***********************************************************| 338 0+-----------------------------------------------------------+ 339 0 100 200 300 400 500 600 700 800 900 1000 340 +-----------------------------------------------------------+ 341 | | 342 60| | 343 | | 344 | | 345 | | 346 40| | 347 UID(%)| | 348 | | 349 | | 350 20| | 351 | *| 352 | * *| 353 | * * * * * ** * *| 354 0+-----------------------------------------------------------+ 355 0 100 200 300 400 500 600 700 800 900 1000 356 Flow Number 357 Fig.6 Simulation Result with Congestion Elimination 359 3.4. Network Temporal Congestion Elimination 361 Different degree of network congestions are simulated. The 362 congestion degree (CD) is defined as the link utilization beyond its 363 threshold. 365 The CCDR congestion elimination performance is shown in Fig.7. The 366 first graph is the congestion degree before the process of congestion 367 elimination. The average CD of all congested links is more than 10%. 368 The second graph shown in Fig.7 is the congestion degree after 369 congestion elimination process. It shows only 12 links among totally 370 20000 links exceed the threshold, and all the congestion degree is 371 less than 3%. Thus, after scheduling of the traffic in congestion 372 paths, the degree of network congestion is greatly eliminated and the 373 network utilization is in balance. 375 Before congestion elimination 376 +-----------------------------------------------------------+ 377 | * ** * ** ** *| 378 20| * * **** * ** ** *| 379 |* * ** * ** ** **** * ***** *********| 380 |* * * * * **** ****** * ** *** **********************| 381 15|* * * ** * ** **** ********* *****************************| 382 |* * ****** ******* ********* *****************************| 383 CD(%) |* ********* ******* ***************************************| 384 10|* ********* ***********************************************| 385 |*********** ***********************************************| 386 |***********************************************************| 387 5|***********************************************************| 388 |***********************************************************| 389 |***********************************************************| 390 0+-----------------------------------------------------------+ 391 0 0.5 1 1.5 2 393 After congestion elimination 394 +-----------------------------------------------------------+ 395 | | 396 20| | 397 | | 398 | | 399 15| | 400 | | 401 CD(%) | | 402 10| | 403 | | 404 | | 405 5 | | 406 | | 407 | * ** * * * ** * ** * | 408 0 +-----------------------------------------------------------+ 409 0 0.5 1 1.5 2 410 Link Number(*10000) 411 Fig.7 Simulation Result with Congestion Elimination 413 4. CCDR Deployment Consideration. 415 With the above CCDR scenarios and simulation results, we can know it 416 is necessary and feasible to find one general solution to cope with 417 various complex situations for the complex optimal path computation 418 in centrally manner based on the underlay network topology and the 419 real time traffic. 421 [I-D.ietf-teas-pce-native-ip] gives the solution for above scenarios, 422 such thoughts can be extended to cover requirements in other 423 situations in future. 425 5. Security Considerations 427 This document considers mainly the integration of distributed 428 protocol and the central control capability of PCE/SDN. It certainly 429 can ease the management of network in various traffic-engineering 430 scenarios described in this document, but the central control manner 431 also bring the new point that may be easily attacked. Solutions for 432 CCDR scenarios should keep these in mind and consider more for the 433 protection of PCE/SDN controller and their communication with the 434 underlay devices, as that described in document [RFC5440] and 435 [RFC8253] 437 6. IANA Considerations 439 This document does not require any IANA actions. 441 7. Contributors 443 Lu Huang contributes to the content of this draft. 445 8. Acknowledgement 447 The author would like to thank Deborah Brungard, Adrian Farrel, 448 Huaimo Chen, Vishnu Beeram and Lou Berger for their supports and 449 comments on this draft. 451 9. References 453 9.1. Normative References 455 [I-D.ietf-teas-pce-native-ip] 456 Wang, A., Zhao, Q., Khasanov, B., Chen, H., and R. Mallya, 457 "PCE in Native IP Network", draft-ietf-teas-pce-native- 458 ip-03 (work in progress), April 2019. 460 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 461 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 462 DOI 10.17487/RFC5440, March 2009, 463 . 465 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 466 "PCEPS: Usage of TLS to Provide a Secure Transport for the 467 Path Computation Element Communication Protocol (PCEP)", 468 RFC 8253, DOI 10.17487/RFC8253, October 2017, 469 . 471 9.2. Informative References 473 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 474 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 475 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 476 . 478 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 479 Decraene, B., Litkowski, S., and R. Shakir, "Segment 480 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 481 July 2018, . 483 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 484 RFC 8578, DOI 10.17487/RFC8578, May 2019, 485 . 487 Authors' Addresses 489 Aijun Wang 490 China Telecom 491 Beiqijia Town, Changping District 492 Beijing, Beijing 102209 493 China 495 Email: wangaj.bri@chinatelecom.cn 497 Xiaohong Huang 498 Beijing University of Posts and Telecommunications 499 No.10 Xitucheng Road, Haidian District 500 Beijing 501 China 503 Email: huangxh@bupt.edu.cn 504 Caixia Kou 505 Beijing University of Posts and Telecommunications 506 No.10 Xitucheng Road, Haidian District 507 Beijing 508 China 510 Email: koucx@lsec.cc.ac.cn 512 Zhenqiang Li 513 China Mobile 514 32 Xuanwumen West Ave, Xicheng District 515 Beijing 100053 516 China 518 Email: li_zhenqiang@hotmail.com 520 Penghui Mi 521 Huawei Technologies 522 Tower C of Bldg.2, Cloud Park, No.2013 of Xuegang Road 523 Shenzhen, Bantian,Longgang District 518129 524 China 526 Email: mipenghui@huawei.com