idnits 2.17.1 draft-ietf-teas-native-ip-scenarios-03.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 (April 9, 2019) is 1844 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-02 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: October 11, 2019 C. Kou 6 BUPT 7 Z. Li 8 China Mobile 9 P. Mi 10 Huawei Technologies 11 April 9, 2019 13 Scenario, Simulation and Suggestion of PCE in Native IP Network 14 draft-ietf-teas-native-ip-scenarios-03 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 October 11, 2019. 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. 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 thousands of routers that run 81 distributed protocol to exchange the reachability information between 82 them. The path for the destination network is mainly calculated and 83 controlled by the IGP/BGP protocols. These distributed protocols are 84 robust enough to support the current evolution of Internet but have 85 some difficulties when application requires the end-to-end QoS 86 performance, or in the situation that the service provider wants to 87 maximize the link utilization within their network. 89 MPLS-TE technology is one solution for finely planned network but it 90 will put heavy burden on the routers when we use it to meet the 91 dynamic QoS assurance requirements within real time traffic network. 93 SR(Segment Routing) is another solution that integrates some merits 94 of distributed protocol and the advantages of centrally control mode, 95 but it requires the underlying network, especially the provider edge 96 router to do label push and pop action in-depth, and need complex 97 mechanic for coexisting with the Non-SR network. Additionally, it 98 can only maneuver the end-to-end path for MPLS and IPv6 traffic via 99 different mechanisms. 101 This draft describes scenarios that the centrally control dynamic 102 routing (CCDR) framework can easily solve, without adding more extra 103 burden on the router. It also gives the path optimization simulation 104 results to illustrate the applicability of CCDR framework. Finally, 105 it gives some suggestions for the implementation and deployment of 106 CCDR. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 3. CCDR Scenarios. 116 The following sections describe some scenarios that the CCDR 117 framework is suitable for deployment. 119 3.1. QoS Assurance for Hybrid Cloud-based Application. 121 With the emerge of cloud computing technologies, enterprises are 122 putting more and more services on the public oriented cloud 123 environment, but keep core business within their private cloud. The 124 communication between the private and public cloud will span the WAN 125 network. The bandwidth requirements between them are variable and 126 the background traffic between these two sites changes from time to 127 time. Enterprise applications just want to exploit the network 128 capabilities to assure the end-to-end QoS performance on demand. 130 CCDR, which integrates the merits of distributed protocol and the 131 power of centrally control, is suitable for this scenario. The 132 possible solution framework is illustrated below: 134 +------------------------+ 135 | Cloud Based Application| 136 +------------------------+ 137 | 138 +-----------+ 139 | PCE | 140 +-----------+ 141 | 142 | 143 //--------------\\ 144 ///// \\\\\ 145 Private Cloud Site || Distributed |Public Cloud Site 146 | Control Network | 147 \\\\\ ///// 148 \\--------------// 150 Fig.1 Hybrid Cloud Communication Scenario 152 By default, the traffic path between the private and public cloud 153 site will be determined by the distributed control network. When 154 applications require the end-to-end QoS assurance, it can send these 155 requirements to PCE,let PCE compute one e2e path which is based on 156 the underlying network topology and the real traffic information, to 157 accommodate the application's QoS requirements. The proposed 158 solution can refer the draft [I-D.ietf-teas-pce-native-ip]. 159 Section 4 describes the detail simulation process and the result. 161 3.2. Link Utilization Maximization 163 Network topology within MAN is generally in star mode as illustrated 164 in Fig.2, with different devices connect different customer types. 165 The traffic from these customers is often in tidal pattern that the 166 links between the CR/BRAS and CR/SR will experience congestion in 167 different periods, because the subscribers under BRAS often use the 168 network at night and the dedicated line users under SR often use the 169 network during the daytime. The uplink between BRAS/SR and CR must 170 satisfy the maximum traffic volume between them respectively and this 171 causes these links often in underutilization situation. 173 +--------+ 174 | CR | 175 +----|---+ 176 | 177 --------|--------|-------| 178 | | | | 179 +--|-+ +-|- +--|-+ +-|+ 180 |BRAS| |SR| |BRAS| |SR| 181 +----+ +--+ +----+ +--+ 183 Fig.2 Star-mode Network Topology within MAN 185 If we consider to connect the BRAS/SR with local link loop (which is 186 more cheaper), and control the MAN with the CCDR framework, we can 187 exploit the tidal phenomena between BRAS/CR and SR/CR links, maximize 188 the links (which is more expensive) utilization of them . 190 +-------+ 191 ----- PCE | 192 | +-------+ 193 +----|---+ 194 | CR | 195 +----|---+ 196 | 197 --------|--------|-------| 198 | | | | 199 +--|-+ +-|- +--|-+ +-|+ 200 |BRAS-----SR| |BRAS-----SR| 201 +----+ +--+ +----+ +--+ 203 Fig.3 Link Utilization Maximization via CCDR 205 3.3. Traffic Engineering for Multi-Domain 207 Operator's networks are often comprised by different domains, 208 interconnected with each other,form very complex topology that 209 illustrated in Fig.4. Due to the traffic pattern to/from MAN and 210 IDC, the utilization of links between them are often asymmetric. It 211 is almost impossible to balance the utilization of these links via 212 the distributed protocol, but this unbalance phenomenon can be 213 overcome via the CCDR framework. 215 +---+ +---+ 216 |MAN|-----------------IDC| 217 +-|-| | +-|-+ 218 | ---------| | 219 ------|BackBone|------ 220 | ----|----| | 221 | | | 222 +-|-- | ----+ 223 |IDC|----------------|MAN| 224 +---| |---+ 226 Fig.4 Traffic Engineering for Complex Multi-Domain Topology 228 Solution for this scenario requires the gather of NetFlow 229 information, analysis the source/destination AS of them and determine 230 which pair is the main cause of the congested link. After this, the 231 operator can use the multi eBGP sessions described in 232 [I-D.ietf-teas-pce-native-ip]to schedule the traffic among different 233 domains. 235 3.4. Network Temporal Congestion Elimination. 237 In more general situation, there are often temporal congestions 238 within the service provider's network. Such congestion phenomena 239 often appear repeatedly and if the service provider has some methods 240 to mitigate it, it will certainly increase the degree of satisfaction 241 for their customers. CCDR is also suitable for such scenario in such 242 manner that the distributed protocol process most of the traffic 243 forwarding and the controller schedule some traffic out of the 244 congestion links to lower the utilization of them. Section 4 245 describes the simulation process and results about such scenario. 247 4. CCDR Simulation. 249 The following sections describe the topology, traffic matrix, end-to- 250 end path optimization and congestion elimination in CCDR applied 251 scenarios. 253 4.1. Topology Simulation 255 The network topology mainly contains nodes and links information. 256 Nodes used in simulation have two types: core node and edge node. 257 The core nodes are fully linked to each other. The edge nodes are 258 connected only with some of the core nodes. Fig.5 is a topology 259 example of 4 core nodes and 5 edge nodes. In CCDR simulation, 100 260 core nodes and 400 edge nodes are generated. 262 +----+ 263 /|Edge|\ 264 | +----+ | 265 | | 266 | | 267 +----+ +----+ +----+ 268 |Edge|----|Core|-----|Core|---------+ 269 +----+ +----+ +----+ | 270 / | \ / | | 271 +----+ | \ / | | 272 |Edge| | X | | 273 +----+ | / \ | | 274 \ | / \ | | 275 +----+ +----+ +----+ | 276 |Edge|----|Core|-----|Core| | 277 +----+ +----+ +----+ | 278 | | | 279 | +------\ +----+ 280 | ---|Edge| 281 +-----------------/ +----+ 283 Fig.5 Topology of Simulation 285 The number of links connecting one edge node to the set of core nodes 286 is randomly between 2 to 30, and the total number of links is more 287 than 20000. Each link has its congestion threshold. 289 4.2. Traffic Matrix Simulation. 291 The traffic matrix is generated based on the link capacity of 292 topology. It can result in many kinds of situations, such as 293 congestion, mild congestion and non-congestion. 295 In CCDR simulation, the dimension of the traffic matrix is 500*500. 296 About 20% links are overloaded when the Open Shortest Path First 297 (OSPF) protocol is used in the network. 299 4.3. CCDR End-to-End Path Optimization 301 The CCDR end-to-end path optimization is to find the best path which 302 is the lowest in metric value and each link of the path is far below 303 link's threshold. Based on the current state of the network, PCE 304 within CCDR framework combines the shortest path algorithm with 305 penalty theory of classical optimization and graph theory. 307 Given background traffic matrix which is unscheduled, when a set of 308 new flows comes into the network, the end-to-end path optimization 309 finds the optimal paths for them. The selected paths bring the least 310 congestion degree to the network. 312 The link utilization increment degree(UID) when the new flows are 313 added into the network is shown in Fig.6. The first graph in Fig.6 314 is the UID with OSPF and the second graph is the UID with CCDR end- 315 to-end path optimization. The average UID of the first graph is more 316 than 30%. After path optimization, the average UID is less than 5%. 317 The results show that the CCDR end-to-end path optimization has an 318 eye-catching decreasing in UID relative to the path chosen based on 319 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., and R. Mallya, 452 "PCE in Native IP Network", draft-ietf-teas-pce-native- 453 ip-02 (work in progress), October 2018. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 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 Authors' Addresses 473 Aijun Wang 474 China Telecom 475 Beiqijia Town, Changping District 476 Beijing, Beijing 102209 477 China 479 Email: wangaj.bri@chinatelecom.cn 481 Xiaohong Huang 482 Beijing University of Posts and Telecommunications 483 No.10 Xitucheng Road, Haidian District 484 Beijing 485 China 487 Email: huangxh@bupt.edu.cn 489 Caixia Kou 490 Beijing University of Posts and Telecommunications 491 No.10 Xitucheng Road, Haidian District 492 Beijing 493 China 495 Email: koucx@lsec.cc.ac.cn 497 Zhenqiang Li 498 China Mobile 499 32 Xuanwumen West Ave, Xicheng District 500 Beijing 100053 501 China 503 Email: li_zhenqiang@hotmail.com 504 Penghui Mi 505 Huawei Technologies 506 Tower C of Bldg.2, Cloud Park, No.2013 of Xuegang Road 507 Shenzhen, Bantian,Longgang District 518129 508 China 510 Email: mipenghui@huawei.com