idnits 2.17.1 draft-wang-teas-ccdr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 9 characters 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Intended status: Information Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (October 24, 2017) is 2369 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 150, but not defined == Unused Reference: 'RFC4655' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-teas-pce-control-function' is defined on line 486, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 -- No information found for draft-ietf-teas-pce-control-function - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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: Information Track October 24, 2017 13 Expires: April 23, 2018 15 CCDR Scenario, Simulation and Suggestion 16 draft-wang-teas-ccdr-02.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 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, and it may not be 26 published except as an Internet-Draft. 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, except to publish it 31 as an RFC and to translate it into languages other than English. 33 it for publication as an RFC or to translate it into languages other 34 than English. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as 44 reference material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 This Internet-Draft will expire on April 23, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. 65 Abstract 67 This document describes the scenarios, simulation and suggestions 68 for the "Centrally Control Dynamic Routing (CCDR)" architecture, 69 which integrates the merit of traditional distributed protocols 70 (IGP/BGP), and the power of centrally control technologies (PCE/SDN) 71 to provide one feasible traffic engineering solution in various 72 complex scenarios for the service provider. 74 Traditional MPLS-TE solution is mainly used in static network 75 planning scenario and is difficult to meet the QoS assurance 76 requirements in real-time traffic network. With the emerge of SDN 77 concept and related technologies, it is possible to simplify the 78 complexity of distributed control protocol, utilize the global view 79 of network condition, give more efficient solution for traffic 80 engineering in various complex scenarios. 82 Table of Contents 84 1. Introduction ................................................ 3 85 2. Conventions used in this document............................ 4 86 3. CCDR Scenarios. ............................................. 4 87 3.1. Qos Assurance for Hybrid Cloud-based Application........ 4 88 3.2. Increase link utilization based on tidal phenomena...... 5 89 3.3. Traffic engineering for IDC/MAN asymmetric link......... 6 90 3.4. Network temporal congestion elimination. ............... 6 91 4. CCDR Simulation. ............................................ 7 92 4.1. Topology Simulation..................................... 7 93 4.2. Traffic Matrix Simulation............................... 7 94 4.3. CCDR End-to-End Path Optimization ...................... 8 95 4.4. Network temporal congestion elimination ................ 9 97 5. CCDR Deployment Consideration............................... 10 98 6. Security Considerations..................................... 10 99 7. IANA Considerations ........................................ 10 100 8. Conclusions ................................................ 10 101 9. References ................................................. 10 102 9.1. Normative References................................... 10 103 9.2. Informative References................................. 11 104 10. Contributors: ............................................. 12 105 11. Acknowledgments ........................................... 12 107 1. Introduction 109 Internet network is composed mainly tens of thousands of routers that 110 run distributed protocol to exchange the reachability information 111 between them. The path for the destination network is mainly 112 calculated and controlled by the traditional IGP protocols. These 113 distributed protocols are robust enough to support the current 114 evolution of Internet but has some difficulties when the application 115 requires the end-to-end QoS performance, or the service provider 116 wants to maximize the links utilization within their network. 118 MPLS-TE technology is one perfect solution for the finely planned 119 network but it will put heavy burden on the router when we use it to 120 solve the dynamic QoS assurance requirements within real time traffic 121 network. 123 SR(Segment Routing) is another prominent solution that integrates 124 some merits of traditional distributed protocol and the advantages of 125 centrally control mode, but it requires the underlying network, 126 especially the provider edge router to do label push and pop action 127 in-depth, and need some complex solutions for co-exist with the Non- 128 SR network. Finally, it can only maneuver the end-to-end path for 129 MPLS and IPv6 traffic via different mechanisms. 131 The advantage of MPLS is mainly for traffic isolation, such as the 132 L2/L3 VPN service deployments, but most of the current application 133 requirements are only for high performances end-to-end QoS assurance. 134 Without the help of centrally control architecture, the service 135 provider almost can't make such SLA guarantees upon the real time 136 traffic situation. 138 This draft gives some scenarios that the centrally control dynamic 139 routing (CCDR) architecture can easily solve, without adding more 140 extra burdening on the router. It also gives the PCE algorithm 141 results under the similar topology, traffic pattern and network size 142 to illustrate the applicability of CCDR architecture. Finally, it 143 gives some suggestions for the implementation and deployment of CCDR. 145 2. Conventions used in this document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3. CCDR Scenarios. 153 The following sections describe some scenarios that the CCDR 154 architecture is suitable for deployment. 156 3.1. Qos Assurance for Hybrid Cloud-based Application. 158 With the emerge of cloud computing technologies, enterprises are 159 putting more and more services on the public oriented service 160 infrastructure, but keep still some core services within their 161 network. The bandwidth requirements between the private cloud and 162 the public cloud are occasionally and the background traffic between 163 these two sites varied from time to time. Enterprise cloud 164 applications just want to invoke the network capabilities to make 165 the end-to-end QoS assurance on demand. Otherwise, the traffic 166 should be controlled by the distributed protocol. 168 CCDR, which integrates the merits of distributed protocol and the 169 power of centrally control, is suitable for this scenario. The 170 possible solution architecture is illustrated below: 172 +------------------------+ 173 | Cloud Based Application| 174 +------------------------+ 175 | 176 +-----------+ 177 | PCE | 178 +-----------+ 179 | 180 | 181 //--------------\\ 182 ///// \\\\\ 183 Private Cloud Site || Distributed |Public Cloud Site 184 | Control Network | 185 \\\\\ ///// 186 \\--------------// 188 Fig.1 Hybrid Cloud Communication Scenario 190 By default, the traffic path between the private cloud site and 191 public cloud site will be determined by the distributed control 192 network. When some applications require the end-to-end QoS assurance, 193 it can send these requirements to PCE, let PCE compute one e2e path 194 which is based on the underlying network topology and the real 195 traffic information, to accommodate the application's bandwidth 196 requirements. The proposed solution can refer the draft [draft-wang- 197 teas-pce-native-ip]. Section 4 describes the detail simulation 198 process and the results. 200 3.2. Increase link utilization based on tidal phenomena. 202 Currently, the network topology within MAN is generally in star mode 203 as illustrated in Fig.2, with the different devices connect 204 different customer types. The traffic pattern of these customers 205 demonstrates some tidal phenomena that the links between the CR/BRAS 206 and CR/SR will experience congestion in different periods because 207 the subscribers under BRAS often use the network at night and the 208 dedicated line users under SR often use the network during the 209 daytime. The uplink between BRAS/SR and CR must satisfy the maximum 210 traffic pattern between them and this causes the links 211 underutilization. 213 +--------+ 214 | CR | 215 +----|---+ 216 | 217 --------|--------|-------| 218 | | | | 219 +--|-+ +-|- +--|-+ +-|+ 220 |BRAS| |SR| |BRAS| |SR| 221 +----+ +--+ +----+ +--+ 223 Fig.2 STAR-style network topology within MAN 225 If we can consider link the BRAS/SR with local loop, and control the 226 MAN with the CCDR architecture, we can exploit the tidal phenomena 227 between BRAS/CR and SR/CR links, increase the efficiency of them. 229 +-------+ 230 ----- PCE | 231 | +-------+ 232 +----|---+ 233 | CR | 234 +----|---+ 235 | 236 --------|--------|-------| 237 | | | | 238 +--|-+ +-|- +--|-+ +-|+ 239 |BRAS-----SR| |BRAS-----SR| 240 +----+ +--+ +----+ +--+ 242 Fig.3 Increase the link utilization via CCDR 244 3.3. Traffic engineering for IDC/MAN asymmetric link 246 The operator's networks are often comprised by tens of different 247 domains, interconnected with each other, form very complex topology 248 that illustrated in Fig.4. Due to the traffic pattern to/from MAN 249 and IDC, the links between them are often in asymmetric style. It is 250 almost impossible to balance the utilization of these links via the 251 distributed protocol, but this unbalance phenomenon can be overcome 252 via the CCDR architecture. 254 +---+ +---+ 255 |MAN|-----------------IDC| 256 +-|-| | +-|-+ 257 | ---------| | 258 ------|BackBone|------ 259 | ----|----| | 260 | | | 261 +-|-- | ----+ 262 |IDC|----------------|MAN| 263 +---| |---+ 265 Fig.4 TE within Complex Multi-Domain topology 267 3.4. Network temporal congestion elimination. 269 In more general situation, there are often temporal congestion 270 periods within part of the service provider's network. Such 271 congestion phenomena will appear repeatedly and if the service 272 provider has some methods to mitigate it, it will certainly increase 273 the satisfaction degree of their customer. CCDR is also suitable for 274 such scenario that the traditional distributed protocol will process 275 most of the traffic forwarding and the controller will schedule some 276 traffic out of the congestion links to lower the utilization of them. 277 Section 4 describes the simulation process and results about such 278 scenario. 280 4. CCDR Simulation. 282 The following sections describe the topology, traffic matrix, end- 283 to-end path optimization and congestion elimination in CCDR 284 simulation. 286 4.1. Topology Simulation. 288 The network topology mainly contains nodes and links information. 289 Nodes used in simulation have two types: core nodes and edge nodes. 290 The core nodes are fully linked to each other. The edge nodes are 291 connected only with some of the core nodes. Fig.5 is a topology 292 example of 4 core nodes and 5 edge nodes. In CCDR simulation, 100 293 core nodes and 400 edge nodes are generated. 295 +----+ 296 /|Edge|\ 297 | +----+ | 298 | | 299 | | 300 +----+ +----+ +----+ 301 |Edge|----|Core|-----|Core|---------+ 302 +----+ +----+ +----+ | 303 / | \ / | | 304 +----+ | \ / | | 305 |Edge| | X | | 306 +----+ | / \ | | 307 \ | / \ | | 308 +----+ +----+ +----+ | 309 |Edge|----|Core|-----|Core| | 310 +----+ +----+ +----+ | 311 | | | 312 | +------\ +----+ 313 | ---|Edge| 314 +-----------------/ +----+ 316 Fig.5 Topology of simulation 318 The number of links connecting one edge node to the set of core 319 nodes is randomly between 2 to 30, and the total number of links is 320 more than 20000. Each link has its congestion threshold. 322 4.2. Traffic Matrix Simulation. 324 The traffic matrix is generated based on the link capacity of 325 topology. It can result in many kinds of situations, such as 326 congestion, mild congestion and non-congestion. 328 In CCDR simulation, the traffic matrix is 500*500. About 20% links 329 are overloaded when the Open Shortest Path First (OSPF) protocol is 330 used in the network. 332 4.3. CCDR End-to-End Path Optimization 334 The CCDR end-to-end path optimization is to find the best end-to-end 335 path which is the lowest in metric value and each link of the path 336 is far below link's threshold. Based on the current state of the 337 network, PCE within CCDR architecture combines the shortest path 338 algorithm with penalty theory of classical optimization and graph 339 theory. 341 Given background traffic matrix which is unscheduled, when a set of 342 new flows comes into the network, the end-to-end path optimization 343 finds the optimal paths for them. The selected paths bring the least 344 congestion degree to the network. 346 The link utilization increment degree(UID) when the new flows are 347 added into the network is shown in Fig.6. The first graph in Fig.6 348 is the UID with OSPF and the second graph is the UID with CCDR end- 349 to-end path optimization. The average UID of graph one is more than 350 30%. After path optimization, the average UID is less than 5%. The 351 results show that the CCDR end-to-end path optimization has an eye- 352 catching decreasing in UID relative to the path chosen based on OSPF. 354 +-----------------------------------------------------------+ 355 | * * * *| 356 60| * * * * * *| 357 |* * ** * * * * * ** * * * * **| 358 |* * ** * * ** *** ** * * ** * * * ** * * *** **| 359 |* * * ** * ** ** *** *** ** **** ** *** **** ** *** **| 360 40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **| 361 UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********| 362 |*** ******* ** **** *********** *********** ***************| 363 |******************* *********** *********** ***************| 364 20|******************* ***************************************| 365 |******************* ***************************************| 366 |***********************************************************| 367 |***********************************************************| 368 0+-----------------------------------------------------------+ 369 0 100 200 300 400 500 600 700 800 900 1000 370 +-----------------------------------------------------------+ 371 | | 372 60| | 373 | | 374 | | 375 | | 376 40| | 378 UID(%)| | 379 | | 380 | | 381 20| | 382 | *| 383 | * *| 384 | * * * * * ** * *| 385 0+-----------------------------------------------------------+ 386 0 100 200 300 400 500 600 700 800 900 1000 387 Flow Number 388 Fig.6 Simulation result with congestion elimination 390 4.4. Network temporal congestion elimination 392 Different degree of network congestion is simulated. The congestion 393 degree (CD) is defined as the link utilization beyond its threshold. 395 The CCDR congestion elimination performance is shown in Fig.7. The 396 first graph is the congestion degree before the process of 397 congestion elimination. The average CD of all congested links is 398 more than 10%. The second graph shown in Fig.7 is the congestion 399 degree after congestion elimination process. It shows only 12 links 400 among totally 20000 links exceed the threshold, and all the 401 congestion degree is less than 3%. Thus, after schedule of the 402 traffic in congestion paths, the degree of network congestion is 403 greatly eliminated and the network utilization is in balance. 405 Before congestion elimination 406 +-----------------------------------------------------------+ 407 | * ** * ** ** *| 408 20| * * **** * ** ** *| 409 |* * ** * ** ** **** * ***** *********| 410 |* * * * * **** ****** * ** *** **********************| 411 15|* * * ** * ** **** ********* *****************************| 412 |* * ****** ******* ********* *****************************| 413 CD(%) |* ********* ******* ***************************************| 414 10|* ********* ***********************************************| 415 |*********** ***********************************************| 416 |***********************************************************| 417 5|***********************************************************| 418 |***********************************************************| 419 |***********************************************************| 420 0+-----------------------------------------------------------+ 421 0 0.5 1 1.5 2 423 After congestion elimination 424 +-----------------------------------------------------------+ 425 | | 426 20| | 427 | | 428 | | 429 15| | 430 | | 431 CD(%) | | 432 10| | 433 | | 434 | | 435 5 | | 436 | | 437 | * ** * * * ** * ** * | 438 0 +-----------------------------------------------------------+ 439 0 0.5 1 1.5 2 440 Link Number(*10000) 441 Fig.7 Simulation result with congestion elimination 443 5. CCDR Deployment Consideration. 445 With the above CCDR scenarios and simulation results, we can know it 446 is necessary and feasible to find one general solution to cope with 447 various complex situations for the most complex optimal path 448 computation in centrally manner based on the underlay network 449 topology and the real time traffic. 451 [draft-wang-teas-native-ip] gives the principle solution for above 452 scenarios, such thoughts can be extended to cover requirements that 453 are more concretes in future. 455 6. Security Considerations 457 TBD 459 7. IANA Considerations 461 TBD 463 8. Conclusions 465 TBD 467 9. References 469 9.1. Normative References 471 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 473 Computation Element (PCE)-Based Architecture", RFC 474 4655, August 2006,. 476 [RFC5440]Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 478 Computation Element (PCE) Communication Protocol 480 (PCEP)", RFC 5440, March 2009, 482 . 484 9.2. Informative References 486 [I-D.draft-ietf-teas-pce-control-function] 488 A. Farrel, Q.Zhao et al. "An Architecture for use of PCE and PCEP in 489 a Network with Central Control" 491 https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central- 492 control/ September, 2016 494 [I-D. draft-ietf-teas-pcecc-use-cases] 496 Quintin Zhao, Robin Li, Boris Khasanov et al. "The Use Cases for 497 Using PCE as the Central Controller(PCECC) of LSPs 499 https://tools.ietf.org/html/draft-ietf-teas-pcecc-use-cases-00 501 March,2017 503 [I-D. draft-wang-teas-pce-native-ip] 505 A.Wang, Quintin Zhao, Boris Khasanov, Penghui Mi,Raghavendra Mallya, 506 Shaofu Peng "PCE in Native IP Network" 508 https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03 March 509 13, 2017 511 [I-D. draft-wang-pcep-extension for native IP] 512 Aijun Wang, Boris Khasanov et al. "PCEP Extension for Native IP 513 Network" https://datatracker.ietf.org/doc/draft-wang-pce-extension- 514 native-ip/ 516 10. Contributors: 518 Tingting Yuan 519 Beijing University of Posts and Telecommunications 520 yuantingting@bupt.edu.cn 522 Qiong Sun 523 sunqiong.bri@chinatelecom.cn 525 Xiaoyan Wei 526 China Telecom Shanghai Company 527 weixiaoyan@189.cn 529 Dingyuan Hu 530 Beijing University of Posts and Telecommunications 531 hdy@bupt.edu.cn 533 11. Acknowledgments 535 TBD 537 Authors' Addresses 539 Aijun Wang 540 China Telecom 541 Beiqijia Town, Changping District 542 Beijing,China 544 Email: wangaj.bri@chinatelecom.cn 546 Xiaohong Huang 547 Beijing University of Posts and Telecommunications 548 No.10 Xitucheng Road, Haidian District 549 Beijing,China 551 EMail: huangxh@bupt.edu.cn 552 Caixia Kou 553 Beijing University of Posts and Telecommunications 554 No.10 Xitucheng Road, Haidian District 555 Beijing,China 556 koucx@lsec.cc.ac.cn 558 Lu Huang 559 China Mobile 560 32 Xuanwumen West Ave, Xicheng District 561 Beijing 100053 562 China 563 Email: hlisname@yahoo.com 565 Penghui Mi 566 Tencent 567 Tencent Building, Kejizhongyi Avenue, 568 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 570 Email kevinmi@tencent.com