idnits 2.17.1 draft-ietf-teas-native-ip-scenarios-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 26, 2018) is 2131 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 128, but not defined == Unused Reference: 'I-D.ietf-teas-pcecc-use-cases' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC8283' is defined on line 472, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-00 == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-01 Summary: 0 errors (**), 0 flaws (~~), 8 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: Experimental X. Huang 5 Expires: December 28, 2018 C. Kou 6 BUPT 7 Z. Li 8 China Mobile 9 L. Huang 10 P. Mi 11 Huawei Technologies 12 June 26, 2018 14 CCDR Scenario, Simulation and Suggestion 15 draft-ietf-teas-native-ip-scenarios-01 17 Abstract 19 This document describes the scenarios, simulation and suggestions for 20 the "Centrally Control Dynamic Routing (CCDR)" architecture, which 21 integrates the merit of traditional distributed protocols (IGP/BGP), 22 and the power of centrally control technologies (PCE/SDN) to provide 23 one feasible traffic engineering solution in various complex 24 scenarios for the service provider. 26 Traditional MPLS-TE solution is mainly used in static network 27 planning scenario and is difficult to meet the QoS assurance 28 requirements in real-time traffic network. With the emerge of SDN 29 concept and related technologies, it is possible to simplify the 30 complexity of distributed control protocol, utilize the global view 31 of network condition, give more efficient solution for traffic 32 engineering in various complex scenarios. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 28, 2018. 50 Copyright Notice 52 Copyright (c) 2018 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. Conventions used in this document . . . . . . . . . . . . . . 3 69 3. CCDR Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Qos Assurance for Hybrid Cloud-based Application. . . . . 3 71 3.2. Increase link utilization based on tidal phenomena. . . . 4 72 3.3. Traffic engineering for IDC/MAN asymmetric link . . . . . 5 73 3.4. Network temporal congestion elimination. . . . . . . . . 6 74 4. CCDR Simulation. . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. Topology Simulation . . . . . . . . . . . . . . . . . . . 6 76 4.2. Traffic Matrix Simulation. . . . . . . . . . . . . . . . 7 77 4.3. CCDR End-to-End Path Optimization . . . . . . . . . . . . 7 78 4.4. Network temporal congestion elimination . . . . . . . . . 9 79 5. CCDR Deployment Consideration. . . . . . . . . . . . . . . . 10 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 Internet network is composed mainly tens of thousands of routers that 88 run distributed protocol to exchange the reachability information 89 between them. The path for the destination network is mainly 90 calculated and controlled by the traditional IGP protocols. These 91 distributed protocols are robust enough to support the current 92 evolution of Internet but has some difficulties when the application 93 requires the end-to-end QoS performance, or the service provider 94 wants to maximize the links utilization within their network. 96 MPLS-TE technology is one perfect solution for the finely planned 97 network but it will put heavy burden on the router when we use it to 98 solve the dynamic QoS assurance requirements within real time traffic 99 network. 101 SR(Segment Routing) is another prominent solution that integrates 102 some merits of traditional distributed protocol and the advantages of 103 centrally control mode, but it requires the underlying network, 104 especially the provider edge router to do label push and pop action 105 in-depth, and need some complex solutions for co-exist with the Non- 106 SR network. Finally, it can only maneuver the end-to-end path for 107 MPLS and IPv6 traffic via different mechanisms. 109 The advantage of MPLS is mainly for traffic isolation, such as the 110 L2/L3 VPN service deployments, but most of the current application 111 requirements are only for high performances end-to-end QoS assurance. 112 Without the help of centrally control architecture, the service 113 provider almost can't make such SLA guarantees upon the real time 114 traffic situation. 116 This draft gives some scenarios that the centrally control dynamic 117 routing (CCDR) architecture can easily solve, without adding more 118 extra burdening on the router. It also gives the PCE algorithm 119 results under the similar topology, traffic pattern and network size 120 to illustrate the applicability of CCDR architecture. Finally, it 121 gives some suggestions for the implementation and deployment of CCDR. 123 2. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. CCDR Scenarios. 131 The following sections describe some scenarios that the CCDR 132 architecture is suitable for deployment. 134 3.1. Qos Assurance for Hybrid Cloud-based Application. 136 With the emerge of cloud computing technologies, enterprises are 137 putting more and more services on the public oriented service 138 infrastructure, but keep still some core services within their 139 network. The bandwidth requirements between the private cloud and 140 the public cloud are occasionally and the background traffic between 141 these two sites varied from time to time. Enterprise cloud 142 applications just want to invoke the network capabilities to make the 143 end-to-end QoS assurance on demand. Otherwise, the traffic should be 144 controlled by the distributed protocol. 146 CCDR, which integrates the merits of distributed protocol and the 147 power of centrally control, is suitable for this scenario. The 148 possible solution architecture is illustrated below: 150 +------------------------+ 151 | Cloud Based Application| 152 +------------------------+ 153 | 154 +-----------+ 155 | PCE | 156 +-----------+ 157 | 158 | 159 //--------------\\ 160 ///// \\\\\ 161 Private Cloud Site || Distributed |Public Cloud Site 162 | Control Network | 163 \\\\\ ///// 164 \\--------------// 166 Fig.1 Hybrid Cloud Communication Scenario 168 By default, the traffic path between the private cloud site and 169 public cloud site will be determined by the distributed control 170 network. When some applications require the end-to-end QoS 171 assurance, it can send these requirements to PCE, let PCE compute one 172 e2e path which is based on the underlying network topology and the 173 real traffic information, to accommodate the application's QoS 174 requirements. The proposed solution can refer the draft 175 [I-D.ietf-teas-pce-native-ip]. Section 4 describes the detail 176 simulation process and the results. 178 3.2. Increase link utilization based on tidal phenomena. 180 Currently, the network topology within MAN is generally in star mode 181 as illustrated in Fig.2, with the different devices connect different 182 customer types. The traffic pattern of these customers demonstrates 183 some tidal phenomena that the links between the CR/BRAS and CR/SR 184 will experience congestion in different periods because the 185 subscribers under BRAS often use the network at night and the 186 dedicated line users under SR often use the network during the 187 daytime. The uplink between BRAS/SR and CR must satisfy the maximum 188 traffic pattern between them and this causes the links 189 underutilization. 191 +--------+ 192 | CR | 193 +----|---+ 194 | 195 --------|--------|-------| 196 | | | | 197 +--|-+ +-|- +--|-+ +-|+ 198 |BRAS| |SR| |BRAS| |SR| 199 +----+ +--+ +----+ +--+ 201 Fig.2 STAR-style network topology within MAN 203 If we can consider link the BRAS/SR with local loop, and control the 204 MAN with the CCDR architecture, we can exploit the tidal phenomena 205 between BRAS/CR and SR/CR links, increase the efficiency of them. 207 +-------+ 208 ----- PCE | 209 | +-------+ 210 +----|---+ 211 | CR | 212 +----|---+ 213 | 214 --------|--------|-------| 215 | | | | 216 +--|-+ +-|- +--|-+ +-|+ 217 |BRAS-----SR| |BRAS-----SR| 218 +----+ +--+ +----+ +--+ 220 Fig.3 Increase the link utilization via CCDR 222 3.3. Traffic engineering for IDC/MAN asymmetric link 224 The operator's networks are often comprised by tens of different 225 domains, interconnected with each other, form very complex topology 226 that illustrated in Fig.4. Due to the traffic pattern to/from MAN 227 and IDC, the links between them are often in asymmetric style. It is 228 almost impossible to balance the utilization of these links via the 229 distributed protocol, but this unbalance phenomenon can be overcome 230 via the CCDR architecture. 232 +---+ +---+ 233 |MAN|-----------------IDC| 234 +-|-| | +-|-+ 235 | ---------| | 236 ------|BackBone|------ 237 | ----|----| | 238 | | | 239 +-|-- | ----+ 240 |IDC|----------------|MAN| 241 +---| |---+ 243 Fig.4 TE within Complex Multi-Domain topology 245 3.4. Network temporal congestion elimination. 247 In more general situation, there are often temporal congestion 248 periods within part of the service provider's network. Such 249 congestion phenomena will appear repeatedly and if the service 250 provider has some methods to mitigate it, it will certainly increase 251 the satisfaction degree of their customer. CCDR is also suitable for 252 such scenario that the traditional distributed protocol will process 253 most of the traffic forwarding and the controller will schedule some 254 traffic out of the congestion links to lower the utilization of them. 255 Section 4 describes the simulation process and results about such 256 scenario. 258 4. CCDR Simulation. 260 The following sections describe the topology, traffic matrix, end-to- 261 end path optimization and congestion elimination in CCDR simulation. 263 4.1. Topology Simulation 265 The network topology mainly contains nodes and links information. 266 Nodes used in simulation have two types: core nodes and edge nodes. 267 The core nodes are fully linked to each other. The edge nodes are 268 connected only with some of the core nodes. Fig.5 is a topology 269 example of 4 core nodes and 5 edge nodes. In CCDR simulation, 100 270 core nodes and 400 edge nodes are generated. 272 +----+ 273 /|Edge|\ 274 | +----+ | 275 | | 276 | | 277 +----+ +----+ +----+ 278 |Edge|----|Core|-----|Core|---------+ 279 +----+ +----+ +----+ | 280 / | \ / | | 281 +----+ | \ / | | 282 |Edge| | X | | 283 +----+ | / \ | | 284 \ | / \ | | 285 +----+ +----+ +----+ | 286 |Edge|----|Core|-----|Core| | 287 +----+ +----+ +----+ | 288 | | | 289 | +------\ +----+ 290 | ---|Edge| 291 +-----------------/ +----+ 293 Fig.5 Topology of simulation 295 The number of links connecting one edge node to the set of core nodes 296 is randomly between 2 to 30, and the total number of links is more 297 than 20000. Each link has its congestion threshold. 299 4.2. Traffic Matrix Simulation. 301 The traffic matrix is generated based on the link capacity of 302 topology. It can result in many kinds of situations, such as 303 congestion, mild congestion and non-congestion. 305 In CCDR simulation, the traffic matrix is 500*500. About 20% links 306 are overloaded when the Open Shortest Path First (OSPF) protocol is 307 used in the network. 309 4.3. CCDR End-to-End Path Optimization 311 The CCDR end-to-end path optimization is to find the best end-to-end 312 path which is the lowest in metric value and each link of the path is 313 far below link's threshold. Based on the current state of the 314 network, PCE within CCDR architecture combines the shortest path 315 algorithm with penalty theory of classical optimization and graph 316 theory. 318 Given background traffic matrix which is unscheduled, when a set of 319 new flows comes into the network, the end-to-end path optimization 320 finds the optimal paths for them. The selected paths bring the least 321 congestion degree to the network. 323 The link utilization increment degree(UID) when the new flows are 324 added into the network is shown in Fig.6. The first graph in Fig.6 325 is the UID with OSPF and the second graph is the UID with CCDR end- 326 to-end path optimization. The average UID of graph one is more than 327 30%. After path optimization, the average UID is less than 5%. The 328 results show that the CCDR end-to-end path optimization has an eye- 329 catching decreasing in UID relative to the path chosen based on OSPF. 331 +-----------------------------------------------------------+ 332 | * * * *| 333 60| * * * * * *| 334 |* * ** * * * * * ** * * * * **| 335 |* * ** * * ** *** ** * * ** * * * ** * * *** **| 336 |* * * ** * ** ** *** *** ** **** ** *** **** ** *** **| 337 40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **| 338 UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********| 339 |*** ******* ** **** *********** *********** ***************| 340 |******************* *********** *********** ***************| 341 20|******************* ***************************************| 342 |******************* ***************************************| 343 |***********************************************************| 344 |***********************************************************| 345 0+-----------------------------------------------------------+ 346 0 100 200 300 400 500 600 700 800 900 1000 347 +-----------------------------------------------------------+ 348 | | 349 60| | 350 | | 351 | | 352 | | 353 40| | 354 UID(%)| | 355 | | 356 | | 357 20| | 358 | *| 359 | * *| 360 | * * * * * ** * *| 361 0+-----------------------------------------------------------+ 362 0 100 200 300 400 500 600 700 800 900 1000 363 Flow Number 364 Fig.6 Simulation result with congestion elimination 366 4.4. Network temporal congestion elimination 368 Different degree of network congestion is simulated. The congestion 369 degree (CD) is defined as the link utilization beyond its threshold. 371 The CCDR congestion elimination performance is shown in Fig.7. The 372 first graph is the congestion degree before the process of congestion 373 elimination. The average CD of all congested links is more than 10%. 374 The second graph shown in Fig.7 is the congestion degree after 375 congestion elimination process. It shows only 12 links among totally 376 20000 links exceed the threshold, and all the congestion degree is 377 less than 3%. Thus, after schedule of the traffic in congestion 378 paths, the degree of network congestion is greatly eliminated and the 379 network utilization is in balance. 381 Before congestion elimination 382 +-----------------------------------------------------------+ 383 | * ** * ** ** *| 384 20| * * **** * ** ** *| 385 |* * ** * ** ** **** * ***** *********| 386 |* * * * * **** ****** * ** *** **********************| 387 15|* * * ** * ** **** ********* *****************************| 388 |* * ****** ******* ********* *****************************| 389 CD(%) |* ********* ******* ***************************************| 390 10|* ********* ***********************************************| 391 |*********** ***********************************************| 392 |***********************************************************| 393 5|***********************************************************| 394 |***********************************************************| 395 |***********************************************************| 396 0+-----------------------------------------------------------+ 397 0 0.5 1 1.5 2 399 After congestion elimination 400 +-----------------------------------------------------------+ 401 | | 402 20| | 403 | | 404 | | 405 15| | 406 | | 407 CD(%) | | 408 10| | 409 | | 410 | | 411 5 | | 412 | | 413 | * ** * * * ** * ** * | 414 0 +-----------------------------------------------------------+ 415 0 0.5 1 1.5 2 416 Link Number(*10000) 417 Fig.7 Simulation result with congestion elimination 419 5. CCDR Deployment Consideration. 421 With the above CCDR scenarios and simulation results, we can know it 422 is necessary and feasible to find one general solution to cope with 423 various complex situations for the most complex optimal path 424 computation in centrally manner based on the underlay network 425 topology and the real time traffic. 427 [I-D.ietf-teas-pce-native-ip] gives the principle solution for above 428 scenarios, such thoughts can be extended to cover requirements that 429 are more concretes in future. 431 6. Security Considerations 433 This document considers mainly the integration of traditional 434 distributed protocol and the global view of central control. It 435 certainly can ease the management of network in various traffic- 436 engineering scenarios described in this document, but the central 437 control manner may also bring the new point be easily attacked. 438 Solutions for CCDR scenarios should keep these in mind and consider 439 more for the protection of SDN controller and their communication 440 with the underlay devices, which described in document 1 and 441 [RFC8253] 443 7. IANA Considerations 445 This document does not require any IANA actions. 447 8. Normative References 449 [I-D.ietf-teas-pce-native-ip] 450 Wang, A., Zhao, Q., Khasanov, B., and K. Mi, "PCE in 451 Native IP Network", draft-ietf-teas-pce-native-ip-00 (work 452 in progress), February 2018. 454 [I-D.ietf-teas-pcecc-use-cases] 455 Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, 456 C., Communications, T., and A. Rachitskiy, "The Use Cases 457 for Using PCE as the Central Controller(PCECC) of LSPs", 458 draft-ietf-teas-pcecc-use-cases-01 (work in progress), May 459 2017. 461 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 462 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 463 DOI 10.17487/RFC5440, March 2009, 464 . 466 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 467 "PCEPS: Usage of TLS to Provide a Secure Transport for the 468 Path Computation Element Communication Protocol (PCEP)", 469 RFC 8253, DOI 10.17487/RFC8253, October 2017, 470 . 472 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 473 Architecture for Use of PCE and the PCE Communication 474 Protocol (PCEP) in a Network with Central Control", 475 RFC 8283, DOI 10.17487/RFC8283, December 2017, 476 . 478 Authors' Addresses 480 Aijun Wang 481 China Telecom 482 Beiqijia Town, Changping District 483 Beijing, Beijing 102209 484 China 486 Email: wangaj.bri@chinatelecom.cn 488 Xiaohong Huang 489 Beijing University of Posts and Telecommunications 490 No.10 Xitucheng Road, Haidian District 491 Beijing 492 China 494 Email: huangxh@bupt.edu.cn 496 Caixia Kou 497 Beijing University of Posts and Telecommunications 498 No.10 Xitucheng Road, Haidian District 499 Beijing 500 China 502 Email: koucx@lsec.cc.ac.cn 504 Zhenqiang Li 505 China Mobile 506 32 Xuanwumen West Ave, Xicheng District 507 Beijing 100053 508 China 510 Email: li_zhenqiang@hotmail.com 511 Lu Huang 512 Huawei Technologies 513 Unit 7 NO 8.XiBinHe Road,YongDingMen 514 Beijing, Dongcheng District 100077 515 China 517 Email: hlisname@yahoo.com 519 Penghui Mi 520 Huawei Technologies 521 Tower C of Bldg.2, Cloud Park, No.2013 of Xuegang Road 522 Shenzhen, Bantian,Longgang District 518129 523 China 525 Email: mipenghui@huawei.com