idnits 2.17.1 draft-ietf-teas-native-ip-scenarios-02.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 (October 21, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-01 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: Experimental X. Huang 5 Expires: April 24, 2019 C. Kou 6 BUPT 7 Z. Li 8 China Mobile 9 P. Mi 10 Huawei Technologies 11 October 21, 2018 13 Scenario, Simulation and Suggestion of PCE in Native IP Network 14 draft-ietf-teas-native-ip-scenarios-02 16 Abstract 18 This document describes the scenarios, simulation and suggestions for 19 PCE 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 April 24, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. CCDR Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Qos Assurance for Hybrid Cloud-based Application. . . . . 3 62 3.2. Link Utilization Maximization . . . . . . . . . . . . . . 4 63 3.3. Traffic Engineering for Multi-Domain . . . . . . . . . . 5 64 3.4. Network temporal congestion elimination. . . . . . . . . 6 65 4. CCDR Simulation. . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Topology Simulation . . . . . . . . . . . . . . . . . . . 6 67 4.2. Traffic Matrix Simulation. . . . . . . . . . . . . . . . 7 68 4.3. CCDR End-to-End Path Optimization . . . . . . . . . . . . 7 69 4.4. Network Temporal Congestion Elimination . . . . . . . . . 9 70 5. CCDR Deployment Consideration. . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 75 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 Service provider network is composed mainly thousands of routers that 81 run distributed protocol to exchange the reachability information 82 between them. The path for the destination network is mainly 83 calculated and controlled by the IGP/BGP protocols. These 84 distributed protocols are robust enough to support the current 85 evolution of Internet but have some difficulties when application 86 requires the end-to-end QoS performance, or in the situation that the 87 service provider wants to maximize the links utilization within their 88 network. 90 MPLS-TE technology is one solution for finely planned network but it 91 will put heavy burden on the routers when we use it to meet the 92 dynamic QoS assurance requirements within real time traffic network. 94 SR(Segment Routing) is another solution that integrates some merits 95 of distributed protocol and the advantages of centrally control mode, 96 but it requires the underlying network, especially the provider edge 97 router to do label push and pop action in-depth, and need complex 98 mechanics for co-exist with the Non-SR network. Aditionally, it can 99 only maneuver the end-to-end path for MPLS and IPv6 traffic via 100 different mechanisms. 102 This draft describes scenarios that the centrally control dynamic 103 routing (CCDR) framework can easily solve, without adding more extra 104 burdening on the router. It also gives the path optimization 105 simulation results to illustrate the applicability of CCDR framework. 106 Finally, it gives some suggestions for the implementation and 107 deployment of CCDR. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 3. CCDR Scenarios. 117 The following sections describe some scenarios that the CCDR 118 framework is suitable for deployment. 120 3.1. Qos Assurance for Hybrid Cloud-based Application. 122 With the emerge of cloud computing technologies, enterprises are 123 putting more and more services on the public oriented cloud 124 environment, but keep core business within their private cloud. The 125 communication between the private and public cloud will span the WAN 126 network. The bandwidth requirements between them are variable and 127 the background traffic between these two sites changes from time to 128 time. Enterprise applications just want to exploit the network 129 capabilities to assure the end-to-end QoS performance on demand. 131 CCDR, which integrates the merits of distributed protocol and the 132 power of centrally control, is suitable for this scenario. The 133 possible solution framework is illustrated below: 135 +------------------------+ 136 | Cloud Based Application| 137 +------------------------+ 138 | 139 +-----------+ 140 | PCE | 141 +-----------+ 142 | 143 | 144 //--------------\\ 145 ///// \\\\\ 146 Private Cloud Site || Distributed |Public Cloud Site 147 | Control Network | 148 \\\\\ ///// 149 \\--------------// 151 Fig.1 Hybrid Cloud Communication Scenario 153 By default, the traffic path between the private and public cloud 154 site will be determined by the distributed control network. When 155 applications require the end-to-end QoS assurance, it can send these 156 requirements to PCE, let PCE compute one e2e path which is based on 157 the underlying network topology and the real traffic information, to 158 accommodate the application's QoS requirements. The proposed 159 solution can refer the draft [I-D.ietf-teas-pce-native-ip]. 160 Section 4 describes the detail simulation process and the result. 162 3.2. Link Utilization Maximization 164 Network topology within MAN is generally in star mode as illustrated 165 in Fig.2, with different devices connect different customer types. 166 The traffic from these customers is often in tidal pattern that the 167 links between the CR/BRAS and CR/SR will experience congestion in 168 different periods, because the subscribers under BRAS often use the 169 network at night and the dedicated line users under SR often use the 170 network during the daytime. The uplink between BRAS/SR and CR must 171 satisfy the maximum traffic volume between them respectively and this 172 causes these links often in underutilization situation. 174 +--------+ 175 | CR | 176 +----|---+ 177 | 178 --------|--------|-------| 179 | | | | 180 +--|-+ +-|- +--|-+ +-|+ 181 |BRAS| |SR| |BRAS| |SR| 182 +----+ +--+ +----+ +--+ 184 Fig.2 Star-mode Network Topology within MAN 186 If we consider to connect the BRAS/SR with local link loop (which is 187 more cheaper), and control the MAN with the CCDR framework, we can 188 exploit the tidal phenomena between BRAS/CR and SR/CR links, maximize 189 the links (which is more expensive) utilization of them . 191 +-------+ 192 ----- PCE | 193 | +-------+ 194 +----|---+ 195 | CR | 196 +----|---+ 197 | 198 --------|--------|-------| 199 | | | | 200 +--|-+ +-|- +--|-+ +-|+ 201 |BRAS-----SR| |BRAS-----SR| 202 +----+ +--+ +----+ +--+ 204 Fig.3 Link Utilization Maximization via CCDR 206 3.3. Traffic Engineering for Multi-Domain 208 Operator's networks are often comprised by different domains, 209 interconnected with each other, form very complex topology that 210 illustrated in Fig.4. Due to the traffic pattern to/from MAN and 211 IDC, the utilization of links between them are often in asymmetric. 212 It is almost impossible to balance the utilization of these links via 213 the distributed protocol, but this unbalance phenomenon can be 214 overcome via the CCDR framework. 216 +---+ +---+ 217 |MAN|-----------------IDC| 218 +-|-| | +-|-+ 219 | ---------| | 220 ------|BackBone|------ 221 | ----|----| | 222 | | | 223 +-|-- | ----+ 224 |IDC|----------------|MAN| 225 +---| |---+ 227 Fig.4 Traffic Engineering for Complex Multi-Domain Topology 229 Solution for this scenario requires the gather of NetFlow 230 information, analysis the source/destination AS of them and determine 231 which pair is the main cause of the congested link. After this, the 232 operator can use the multi eBGP sessions described in 233 [I-D.ietf-teas-pce-native-ip]to schedule the traffic among different 234 domains. 236 3.4. Network temporal congestion elimination. 238 In more general situation, there are often temporal congestions 239 within the service provider's network. Such congestion phenomena 240 often appear repeatedly and if the service provider has some methods 241 to mitigate it, it will certainly increase the degree of satisfaction 242 for their customers. CCDR is also suitable for such scenario in such 243 manner that the distributed protocol process most of the traffic 244 forwarding and the controller schedule some traffic out of the 245 congestion links to lower the utilization of them. Section 4 246 describes the simulation process and results about such scenario. 248 4. CCDR Simulation. 250 The following sections describe the topology, traffic matrix, end-to- 251 end path optimization and congestion elimination in CCDR applied 252 scenarios. 254 4.1. Topology Simulation 256 The network topology mainly contains nodes and links information. 257 Nodes used in simulation have two types: core node and edge node. 258 The core nodes are fully linked to each other. The edge nodes are 259 connected only with some of the core nodes. Fig.5 is a topology 260 example of 4 core nodes and 5 edge nodes. In CCDR simulation, 100 261 core nodes and 400 edge nodes are generated. 263 +----+ 264 /|Edge|\ 265 | +----+ | 266 | | 267 | | 268 +----+ +----+ +----+ 269 |Edge|----|Core|-----|Core|---------+ 270 +----+ +----+ +----+ | 271 / | \ / | | 272 +----+ | \ / | | 273 |Edge| | X | | 274 +----+ | / \ | | 275 \ | / \ | | 276 +----+ +----+ +----+ | 277 |Edge|----|Core|-----|Core| | 278 +----+ +----+ +----+ | 279 | | | 280 | +------\ +----+ 281 | ---|Edge| 282 +-----------------/ +----+ 284 Fig.5 Topology of Simulation 286 The number of links connecting one edge node to the set of core nodes 287 is randomly between 2 to 30, and the total number of links is more 288 than 20000. Each link has its congestion threshold. 290 4.2. Traffic Matrix Simulation. 292 The traffic matrix is generated based on the link capacity of 293 topology. It can result in many kinds of situations, such as 294 congestion, mild congestion and non-congestion. 296 In CCDR simulation, the dimension of the traffic matrix is 500*500. 297 About 20% links are overloaded when the Open Shortest Path First 298 (OSPF) protocol is used in the network. 300 4.3. CCDR End-to-End Path Optimization 302 The CCDR end-to-end path optimization is to find the best path which 303 is the lowest in metric value and each link of the path is far below 304 link's threshold. Based on the current state of the network, PCE 305 within CCDR framework combines the shortest path algorithm with 306 penalty theory of classical optimization and graph theory. 308 Given background traffic matrix which is unscheduled, when a set of 309 new flows comes into the network, the end-to-end path optimization 310 finds the optimal paths for them. The selected paths bring the least 311 congestion degree to the network. 313 The link utilization increment degree(UID) when the new flows are 314 added into the network is shown in Fig.6. The first graph in Fig.6 315 is the UID with OSPF and the second graph is the UID with CCDR end- 316 to-end path optimization. The average UID of graph one is more than 317 30%. After path optimization, the average UID is less than 5%. The 318 results show that the CCDR end-to-end path optimization has an eye- 319 catching decreasing in UID relative to the path chosen based on OSPF. 321 +-----------------------------------------------------------+ 322 | * * * *| 323 60| * * * * * *| 324 |* * ** * * * * * ** * * * * **| 325 |* * ** * * ** *** ** * * ** * * * ** * * *** **| 326 |* * * ** * ** ** *** *** ** **** ** *** **** ** *** **| 327 40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **| 328 UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********| 329 |*** ******* ** **** *********** *********** ***************| 330 |******************* *********** *********** ***************| 331 20|******************* ***************************************| 332 |******************* ***************************************| 333 |***********************************************************| 334 |***********************************************************| 335 0+-----------------------------------------------------------+ 336 0 100 200 300 400 500 600 700 800 900 1000 337 +-----------------------------------------------------------+ 338 | | 339 60| | 340 | | 341 | | 342 | | 343 40| | 344 UID(%)| | 345 | | 346 | | 347 20| | 348 | *| 349 | * *| 350 | * * * * * ** * *| 351 0+-----------------------------------------------------------+ 352 0 100 200 300 400 500 600 700 800 900 1000 353 Flow Number 354 Fig.6 Simulation Result with Congestion Elimination 356 4.4. Network Temporal Congestion Elimination 358 Different degree of network congestions are simulated. The 359 congestion degree (CD) is defined as the link utilization beyond its 360 threshold. 362 The CCDR congestion elimination performance is shown in Fig.7. The 363 first graph is the congestion degree before the process of congestion 364 elimination. The average CD of all congested links is more than 10%. 365 The second graph shown in Fig.7 is the congestion degree after 366 congestion elimination process. It shows only 12 links among totally 367 20000 links exceed the threshold, and all the congestion degree is 368 less than 3%. Thus, after scheduling of the traffic in congestion 369 paths, the degree of network congestion is greatly eliminated and the 370 network utilization is in balance. 372 Before congestion elimination 373 +-----------------------------------------------------------+ 374 | * ** * ** ** *| 375 20| * * **** * ** ** *| 376 |* * ** * ** ** **** * ***** *********| 377 |* * * * * **** ****** * ** *** **********************| 378 15|* * * ** * ** **** ********* *****************************| 379 |* * ****** ******* ********* *****************************| 380 CD(%) |* ********* ******* ***************************************| 381 10|* ********* ***********************************************| 382 |*********** ***********************************************| 383 |***********************************************************| 384 5|***********************************************************| 385 |***********************************************************| 386 |***********************************************************| 387 0+-----------------------------------------------------------+ 388 0 0.5 1 1.5 2 390 After congestion elimination 391 +-----------------------------------------------------------+ 392 | | 393 20| | 394 | | 395 | | 396 15| | 397 | | 398 CD(%) | | 399 10| | 400 | | 401 | | 402 5 | | 403 | | 404 | * ** * * * ** * ** * | 405 0 +-----------------------------------------------------------+ 406 0 0.5 1 1.5 2 407 Link Number(*10000) 408 Fig.7 Simulation Result with Congestion Elimination 410 5. CCDR Deployment Consideration. 412 With the above CCDR scenarios and simulation results, we can know it 413 is necessary and feasible to find one general solution to cope with 414 various complex situations for the complex optimal path computation 415 in centrally manner based on the underlay network topology and the 416 real time traffic. 418 [I-D.ietf-teas-pce-native-ip] gives the solution for above scenarios, 419 such thoughts can be extended to cover requirements in other 420 situations in future. 422 6. Security Considerations 424 This document considers mainly the integration of distributed 425 protocol and the central control capability of PCE/SDN. It certainly 426 can ease the management of network in various traffic-engineering 427 scenarios described in this document, but the central control manner 428 also bring the new point that may be easily attacked. Solutions for 429 CCDR scenarios should keep these in mind and consider more for the 430 protection of PCE/SDN controller and their communication with the 431 underlay devices, as that described in document [RFC5440] and 432 [RFC8253] 434 7. IANA Considerations 436 This document does not require any IANA actions. 438 8. Contributors 440 Lu Huang contributes to the content of this draft. 442 9. Acknowledgement 444 The author would like to thank Deborah Brungard, Adrian Farrel, 445 Huaimo Chen, Vishnu Beeram and Lou Berger for their supports and 446 comments on this draft. 448 10. Normative References 450 [I-D.ietf-teas-pce-native-ip] 451 Wang, A., Zhao, Q., Khasanov, B., Chen, H., Mi, P., 452 Mallya, R., and S. Peng, "PCE in Native IP Network", 453 draft-ietf-teas-pce-native-ip-01 (work in progress), June 454 2018. 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, 459 . 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 Authors' Addresses 474 Aijun Wang 475 China Telecom 476 Beiqijia Town, Changping District 477 Beijing, Beijing 102209 478 China 480 Email: wangaj.bri@chinatelecom.cn 482 Xiaohong Huang 483 Beijing University of Posts and Telecommunications 484 No.10 Xitucheng Road, Haidian District 485 Beijing 486 China 488 Email: huangxh@bupt.edu.cn 490 Caixia Kou 491 Beijing University of Posts and Telecommunications 492 No.10 Xitucheng Road, Haidian District 493 Beijing 494 China 496 Email: koucx@lsec.cc.ac.cn 498 Zhenqiang Li 499 China Mobile 500 32 Xuanwumen West Ave, Xicheng District 501 Beijing 100053 502 China 504 Email: li_zhenqiang@hotmail.com 505 Penghui Mi 506 Huawei Technologies 507 Tower C of Bldg.2, Cloud Park, No.2013 of Xuegang Road 508 Shenzhen, Bantian,Longgang District 518129 509 China 511 Email: mipenghui@huawei.com