idnits 2.17.1 draft-wang-teas-ccdr-05.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 (January 25, 2018) is 2282 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- 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 TEAS Working Group A.Wang 2 Internet Draft China Telecom 3 Xiaohong Huang 4 BUPT 5 Caixia Kou 6 BUPT 7 Lu Huang 8 China Mobile 9 Penghui Mi 10 Tencent Company 12 Intended status: Experimental Track January 25, 2018 13 Expires: July 24, 2018 15 CCDR Scenario, Simulation and Suggestion 16 draft-wang-teas-ccdr-05.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 24, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. 47 Abstract 49 This document describes the scenarios, simulation and suggestions 50 for the "Centrally Control Dynamic Routing (CCDR)" architecture, 51 which integrates the merit of traditional distributed protocols 52 (IGP/BGP), and the power of centrally control technologies (PCE/SDN) 53 to provide one feasible traffic engineering solution in various 54 complex scenarios for the service provider. 56 Traditional MPLS-TE solution is mainly used in static network 57 planning scenario and is difficult to meet the QoS assurance 58 requirements in real-time traffic network. With the emerge of SDN 59 concept and related technologies, it is possible to simplify the 60 complexity of distributed control protocol, utilize the global view 61 of network condition, give more efficient solution for traffic 62 engineering in various complex scenarios. 64 Table of Contents 66 1. Introduction ................................................ 2 67 2. CCDR Scenarios. ............................................. 3 68 2.1. Qos Assurance for Hybrid Cloud-based Application........ 3 69 2.2. Increase link utilization based on tidal phenomena...... 4 70 2.3. Traffic engineering for IDC/MAN asymmetric link......... 5 71 2.4. Network temporal congestion elimination. ............... 6 72 3. CCDR Simulation. ............................................ 6 73 3.1. Topology Simulation..................................... 6 74 3.2. Traffic Matrix Simulation............................... 7 75 3.3. CCDR End-to-End Path Optimization ...................... 7 76 3.4. Network temporal congestion elimination ................ 8 77 4. CCDR Deployment Consideration................................ 9 78 5. Security Considerations..................................... 10 79 6. IANA Considerations ........................................ 10 80 7. Conclusions ................................................ 10 81 8. References ................................................. 10 82 8.1. Normative References................................... 10 83 8.2. Informative References................................. 10 84 9. Contributors: .............................................. 11 85 10. Acknowledgments ........................................... 11 87 1. Introduction 89 Internet network is composed mainly tens of thousands of routers that 90 run distributed protocol to exchange the reachability information 91 between them. The path for the destination network is mainly 92 calculated and controlled by the traditional IGP protocols. These 93 distributed protocols are robust enough to support the current 94 evolution of Internet but has some difficulties when the application 95 requires the end-to-end QoS performance, or the service provider 96 wants to maximize the links utilization within their network. 98 MPLS-TE technology is one perfect solution for the finely planned 99 network but it will put heavy burden on the router when we use it to 100 solve the dynamic QoS assurance requirements within real time traffic 101 network. 103 SR(Segment Routing) is another prominent solution that integrates 104 some merits of traditional distributed protocol and the advantages of 105 centrally control mode, but it requires the underlying network, 106 especially the provider edge router to do label push and pop action 107 in-depth, and need some complex solutions for co-exist with the Non- 108 SR network. Finally, it can only maneuver the end-to-end path for 109 MPLS and IPv6 traffic via different mechanisms. 111 The advantage of MPLS is mainly for traffic isolation, such as the 112 L2/L3 VPN service deployments, but most of the current application 113 requirements are only for high performances end-to-end QoS assurance. 114 Without the help of centrally control architecture, the service 115 provider almost can't make such SLA guarantees upon the real time 116 traffic situation. 118 This draft gives some scenarios that the centrally control dynamic 119 routing (CCDR) architecture can easily solve, without adding more 120 extra burdening on the router. It also gives the PCE algorithm 121 results under the similar topology, traffic pattern and network size 122 to illustrate the applicability of CCDR architecture. Finally, it 123 gives some suggestions for the implementation and deployment of CCDR. 125 2. CCDR Scenarios. 127 The following sections describe some scenarios that the CCDR 128 architecture is suitable for deployment. 130 2.1. Qos Assurance for Hybrid Cloud-based Application. 132 With the emerge of cloud computing technologies, enterprises are 133 putting more and more services on the public oriented service 134 infrastructure, but keep still some core services within their 135 network. The bandwidth requirements between the private cloud and 136 the public cloud are occasionally and the background traffic between 137 these two sites varied from time to time. Enterprise cloud 138 applications just want to invoke the network capabilities to make 139 the end-to-end QoS assurance on demand. Otherwise, the traffic 140 should be controlled by the distributed protocol. 142 CCDR, which integrates the merits of distributed protocol and the 143 power of centrally control, is suitable for this scenario. The 144 possible solution architecture is illustrated below: 146 +------------------------+ 147 | Cloud Based Application| 148 +------------------------+ 149 | 150 +-----------+ 151 | PCE | 152 +-----------+ 153 | 154 | 155 //--------------\\ 156 ///// \\\\\ 157 Private Cloud Site || Distributed |Public Cloud Site 158 | Control Network | 159 \\\\\ ///// 160 \\--------------// 162 Fig.1 Hybrid Cloud Communication Scenario 164 By default, the traffic path between the private cloud site and 165 public cloud site will be determined by the distributed control 166 network. When some applications require the end-to-end QoS assurance, 167 it can send these requirements to PCE, let PCE compute one e2e path 168 which is based on the underlying network topology and the real 169 traffic information, to accommodate the application's bandwidth 170 requirements. The proposed solution can refer the draft [draft-wang- 171 teas-pce-native-ip]. Section 4 describes the detail simulation 172 process and the results. 174 2.2. Increase link utilization based on tidal phenomena. 176 Currently, the network topology within MAN is generally in star mode 177 as illustrated in Fig.2, with the different devices connect 178 different customer types. The traffic pattern of these customers 179 demonstrates some tidal phenomena that the links between the CR/BRAS 180 and CR/SR will experience congestion in different periods because 181 the subscribers under BRAS often use the network at night and the 182 dedicated line users under SR often use the network during the 183 daytime. The uplink between BRAS/SR and CR must satisfy the maximum 184 traffic pattern between them and this causes the links 185 underutilization. 187 +--------+ 188 | CR | 189 +----|---+ 190 | 191 --------|--------|-------| 192 | | | | 193 +--|-+ +-|- +--|-+ +-|+ 194 |BRAS| |SR| |BRAS| |SR| 195 +----+ +--+ +----+ +--+ 197 Fig.2 STAR-style network topology within MAN 199 If we can consider link the BRAS/SR with local loop, and control the 200 MAN with the CCDR architecture, we can exploit the tidal phenomena 201 between BRAS/CR and SR/CR links, increase the efficiency of them. 203 +-------+ 204 ----- PCE | 205 | +-------+ 206 +----|---+ 207 | CR | 208 +----|---+ 209 | 210 --------|--------|-------| 211 | | | | 212 +--|-+ +-|- +--|-+ +-|+ 213 |BRAS-----SR| |BRAS-----SR| 214 +----+ +--+ +----+ +--+ 216 Fig.3 Increase the link utilization via CCDR 218 2.3. Traffic engineering for IDC/MAN asymmetric link 220 The operator's networks are often comprised by tens of different 221 domains, interconnected with each other, form very complex topology 222 that illustrated in Fig.4. Due to the traffic pattern to/from MAN 223 and IDC, the links between them are often in asymmetric style. It is 224 almost impossible to balance the utilization of these links via the 225 distributed protocol, but this unbalance phenomenon can be overcome 226 via the CCDR architecture. 228 +---+ +---+ 229 |MAN|-----------------IDC| 230 +-|-| | +-|-+ 231 | ---------| | 232 ------|BackBone|------ 233 | ----|----| | 234 | | | 235 +-|-- | ----+ 236 |IDC|----------------|MAN| 237 +---| |---+ 239 Fig.4 TE within Complex Multi-Domain topology 241 2.4. Network temporal congestion elimination. 243 In more general situation, there are often temporal congestion 244 periods within part of the service provider's network. Such 245 congestion phenomena will appear repeatedly and if the service 246 provider has some methods to mitigate it, it will certainly increase 247 the satisfaction degree of their customer. CCDR is also suitable for 248 such scenario that the traditional distributed protocol will process 249 most of the traffic forwarding and the controller will schedule some 250 traffic out of the congestion links to lower the utilization of them. 251 Section 4 describes the simulation process and results about such 252 scenario. 254 3. CCDR Simulation. 256 The following sections describe the topology, traffic matrix, end- 257 to-end path optimization and congestion elimination in CCDR 258 simulation. 260 3.1. Topology Simulation. 262 The network topology mainly contains nodes and links information. 263 Nodes used in simulation have two types: core nodes and edge nodes. 264 The core nodes are fully linked to each other. The edge nodes are 265 connected only with some of the core nodes. Fig.5 is a topology 266 example of 4 core nodes and 5 edge nodes. In CCDR simulation, 100 267 core nodes and 400 edge nodes are generated. 269 +----+ 270 /|Edge|\ 271 | +----+ | 272 | | 273 | | 274 +----+ +----+ +----+ 275 |Edge|----|Core|-----|Core|---------+ 276 +----+ +----+ +----+ | 277 / | \ / | | 278 +----+ | \ / | | 279 |Edge| | X | | 280 +----+ | / \ | | 281 \ | / \ | | 282 +----+ +----+ +----+ | 283 |Edge|----|Core|-----|Core| | 284 +----+ +----+ +----+ | 285 | | | 286 | +------\ +----+ 287 | ---|Edge| 288 +-----------------/ +----+ 290 Fig.5 Topology of simulation 292 The number of links connecting one edge node to the set of core 293 nodes is randomly between 2 to 30, and the total number of links is 294 more than 20000. Each link has its congestion threshold. 296 3.2. Traffic Matrix Simulation. 298 The traffic matrix is generated based on the link capacity of 299 topology. It can result in many kinds of situations, such as 300 congestion, mild congestion and non-congestion. 302 In CCDR simulation, the traffic matrix is 500*500. About 20% links 303 are overloaded when the Open Shortest Path First (OSPF) protocol is 304 used in the network. 306 3.3. CCDR End-to-End Path Optimization 308 The CCDR end-to-end path optimization is to find the best end-to-end 309 path which is the lowest in metric value and each link of the path 310 is far below link's threshold. Based on the current state of the 311 network, PCE within CCDR architecture combines the shortest path 312 algorithm with penalty theory of classical optimization and graph 313 theory. 315 Given background traffic matrix which is unscheduled, when a set of 316 new flows comes into the network, the end-to-end path optimization 317 finds the optimal paths for them. The selected paths bring the least 318 congestion degree to the network. 320 The link utilization increment degree(UID) when the new flows are 321 added into the network is shown in Fig.6. The first graph in Fig.6 322 is the UID with OSPF and the second graph is the UID with CCDR end- 323 to-end path optimization. The average UID of graph one is more than 324 30%. After path optimization, the average UID is less than 5%. The 325 results show that the CCDR end-to-end path optimization has an eye- 326 catching decreasing in UID relative to the path chosen based on OSPF. 328 +-----------------------------------------------------------+ 329 | * * * *| 330 60| * * * * * *| 331 |* * ** * * * * * ** * * * * **| 332 |* * ** * * ** *** ** * * ** * * * ** * * *** **| 333 |* * * ** * ** ** *** *** ** **** ** *** **** ** *** **| 334 40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **| 335 UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********| 336 |*** ******* ** **** *********** *********** ***************| 337 |******************* *********** *********** ***************| 338 20|******************* ***************************************| 339 |******************* ***************************************| 340 |***********************************************************| 341 |***********************************************************| 342 0+-----------------------------------------------------------+ 343 0 100 200 300 400 500 600 700 800 900 1000 344 +-----------------------------------------------------------+ 345 | | 346 60| | 347 | | 348 | | 349 | | 350 40| | 351 UID(%)| | 352 | | 353 | | 354 20| | 355 | *| 356 | * *| 357 | * * * * * ** * *| 358 0+-----------------------------------------------------------+ 359 0 100 200 300 400 500 600 700 800 900 1000 360 Flow Number 361 Fig.6 Simulation result with congestion elimination 363 3.4. Network temporal congestion elimination 365 Different degree of network congestion is simulated. The congestion 366 degree (CD) is defined as the link utilization beyond its threshold. 368 The CCDR congestion elimination performance is shown in Fig.7. The 369 first graph is the congestion degree before the process of 370 congestion elimination. The average CD of all congested links is 371 more than 10%. The second graph shown in Fig.7 is the congestion 372 degree after congestion elimination process. It shows only 12 links 373 among totally 20000 links exceed the threshold, and all the 374 congestion degree is less than 3%. Thus, after schedule of the 375 traffic in congestion paths, the degree of network congestion is 376 greatly eliminated and the network utilization is in balance. 378 Before congestion elimination 379 +-----------------------------------------------------------+ 380 | * ** * ** ** *| 381 20| * * **** * ** ** *| 382 |* * ** * ** ** **** * ***** *********| 383 |* * * * * **** ****** * ** *** **********************| 384 15|* * * ** * ** **** ********* *****************************| 385 |* * ****** ******* ********* *****************************| 386 CD(%) |* ********* ******* ***************************************| 387 10|* ********* ***********************************************| 388 |*********** ***********************************************| 389 |***********************************************************| 390 5|***********************************************************| 391 |***********************************************************| 392 |***********************************************************| 393 0+-----------------------------------------------------------+ 394 0 0.5 1 1.5 2 396 After congestion elimination 397 +-----------------------------------------------------------+ 398 | | 399 20| | 400 | | 401 | | 402 15| | 403 | | 404 CD(%) | | 405 10| | 406 | | 407 | | 408 5 | | 409 | | 410 | * ** * * * ** * ** * | 411 0 +-----------------------------------------------------------+ 412 0 0.5 1 1.5 2 413 Link Number(*10000) 414 Fig.7 Simulation result with congestion elimination 416 4. CCDR Deployment Consideration. 418 With the above CCDR scenarios and simulation results, we can know it 419 is necessary and feasible to find one general solution to cope with 420 various complex situations for the most complex optimal path 421 computation in centrally manner based on the underlay network 422 topology and the real time traffic. 424 [draft-wang-teas-native-ip] gives the principle solution for above 425 scenarios, such thoughts can be extended to cover requirements that 426 are more concretes in future. 428 5. Security Considerations 430 TBD 432 6. IANA Considerations 434 TBD 436 7. Conclusions 438 TBD 440 8. References 442 8.1. Normative References 444 [RFC5440]Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 446 Computation Element (PCE) Communication Protocol 448 (PCEP)", RFC 5440, March 2009, 450 . 452 [RFC8283] A.Farrel, Q.Zhao et al.," An Architecture for Use of PCE 453 and the PCE Communication Protocol (PCEP) in a Network with Central 454 Control", [RFC8283], December 2017 456 8.2. Informative References 458 [I-D. draft-ietf-teas-pcecc-use-cases] 460 Quintin Zhao, Robin Li, Boris Khasanov et al. "The Use Cases for 461 Using PCE as the Central Controller(PCECC) of LSPs 463 https://tools.ietf.org/html/draft-ietf-teas-pcecc-use-cases-00 465 March,2017 467 [I-D. draft-wang-teas-pce-native-ip] 469 A.Wang, Quintin Zhao, Boris Khasanov, Penghui Mi,Raghavendra Mallya, 470 Shaofu Peng "PCE in Native IP Network" 472 https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03 March 473 13, 2017 475 [I-D. draft-wang-pcep-extension for native IP] 477 Aijun Wang, Boris Khasanov et al. "PCEP Extension for Native IP 478 Network" https://datatracker.ietf.org/doc/draft-wang-pce-extension- 479 native-ip/ 481 9. Contributors: 483 Tingting Yuan 484 Beijing University of Posts and Telecommunications 485 yuantingting@bupt.edu.cn 487 Qiong Sun 488 sunqiong.bri@chinatelecom.cn 490 Xiaoyan Wei 491 China Telecom Shanghai Company 492 weixiaoyan@189.cn 494 Dingyuan Hu 495 Beijing University of Posts and Telecommunications 496 hdy@bupt.edu.cn 498 10. Acknowledgments 500 TBD 502 Authors' Addresses 504 Aijun Wang 505 China Telecom 506 Beiqijia Town, Changping District 507 Beijing,China 509 Email: wangaj.bri@chinatelecom.cn 511 Xiaohong Huang 512 Beijing University of Posts and Telecommunications 513 No.10 Xitucheng Road, Haidian District 514 Beijing,China 516 EMail: huangxh@bupt.edu.cn 518 Caixia Kou 519 Beijing University of Posts and Telecommunications 520 No.10 Xitucheng Road, Haidian District 521 Beijing,China 522 koucx@lsec.cc.ac.cn 524 Lu Huang 525 China Mobile 526 32 Xuanwumen West Ave, Xicheng District 527 Beijing 100053 528 China 529 Email: hlisname@yahoo.com 531 Penghui Mi 532 Tencent 533 Tencent Building, Kejizhongyi Avenue, 534 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 536 Email kevinmi@tencent.com