idnits 2.17.1 draft-hu-lsr-network-automatic-optimization-00.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 : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 37 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 date (July 2, 2018) is 2096 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) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Hu 3 Internet-Draft G. Yan 4 Intended status: Standards Track J. Yao 5 Expires: January 3, 2019 Huawei Technologies 6 July 2, 2018 8 Network Automatic Optimization Based on Dynamic Adjustment of IGP 9 Metrics 10 draft-hu-lsr-network-automatic-optimization-00 12 Abstract 14 The centralized traffic engineering technology adopts centralized 15 calculation, PCE/SDN performs centralized calculation based on the 16 collected link-status and TE information collected by BGP-LS/IGP, so 17 that the traffic in the network is optimized to the optimization 18 goal. 20 The distributed traffic engineering technology uses IGP to calculate 21 the shortest path. Each node in the network calculates the next hop 22 to a destination address based on the same algorithm and network 23 topology. Each algorithm can calculate a shortest path tree in the 24 entire network, which can reduce the amount of calculation, so that 25 the hard convergence time of TE can be close to the convergence time 26 of IGP. 28 The distributed computing and management methods can not co-ordinate 29 management of network bandwidth resources. As a result, network 30 bandwidth resources can not be planned in an integrated manner, 31 bandwidth resources are wasted, and even tunnels cannot be 32 established. This document attempts to discuss a automatic network 33 optimization function of the distributed traffic engineering 34 technology by the method of dynamically adjusting the link Metric. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on January 3, 2019. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 77 2. Automatic Network Optimization Method . . . . . . . . . . . . 3 78 3. Optimization Rules . . . . . . . . . . . . . . . . . . . . . 5 79 3.1. Threshold Regulation . . . . . . . . . . . . . . . . . . 5 80 3.2. Optimization Rules . . . . . . . . . . . . . . . . . . . 5 81 4. Controller Adjustment Scenario . . . . . . . . . . . . . . . 6 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 8.2. Informative References . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 The concept of IGP Metric defined in [RFC1195] for ISIS, and defined 93 in [RFC2328] and [RFC5340] for OSPF, indicating the cost of using 94 this router link. 96 Segment Routing (SR) described in [I-D.ietf-spring-segment-routing] 97 leverages the source routing paradigm. Segment Routing can be 98 directly applied to the MPLS architecture with no change on the 99 forwarding plane [I-D.ietf-spring-segment-routing-mpls] and applied 100 to the IPv6 architecture with a new type of routing header called the 101 SR header (SRH) [I-D.ietf-6man-segment-routing-header]. Segment 102 Routing uses the IGP protocol as the control protocol. The 103 distributed traffic engineering technology has unique advantages in 104 solving the problem of SRv6's label stack depth, in rapid convergence 105 and self-healing. 107 The distributed traffic engineering technology adopts the distributed 108 route calculation method. However, because the IGP calculates the 109 shortest path based on the SPF algorithm and the metric of the link 110 is constant, it is possible that a certain segment of the optimal 111 path of multiple services is the same segment of the link. In a 112 multi-service scenario, it is easy to cause congestion on some 113 network links while the bandwidth resources on other links are idle. 114 The resources of the entire network cannot be fully utilized. 116 This document proposes a method for automatic optimization when 117 traffic flow is congested by dynamically adjusting the link metric. 119 Section 2 describes the implementation of automatic network 120 optimization in distributed traffic engineering technology. 121 Section 3 defines the thresholds and optimization rules of automatic 122 network optimization. In Section 4, based on the dynamic adjustment 123 of link metric technology, the network optimization method for 124 controller weak control management is introduced. 126 2. Automatic Network Optimization Method 128 The distributed traffic engineering technology is based on the IGP 129 protocol. Each node uses the SPF algorithm to calculate the shortest 130 path to the destination node based on the entire network topology. 131 Each link calculates the shortest path based on the same metric for 132 all services. As the services in the network increase, some links in 133 the network may be seriously congested, but some links are still 134 underutilized. This causes a waste of network resources. 136 Consider a method that, when a link is congested, dynamically adjusts 137 the metric of the link so that traffic of a part of the service can 138 be switched to other paths for transmission, thereby reducing the 139 load of the congested link. Through the adjustment of metrics of 140 different links in the network, different priority services calculate 141 different shortest paths based on different metrics of the same link 142 in the same network, thereby avoiding network congestion on certain 143 links and increasing Utilization of network resources. 145 The automatic network optimization method divides the metric of the 146 link according to the SLA type into multiple types corresponding to 147 the SLA type (For example divided into Bandwidth Metric, Latency 148 Metric...etc.), Each type of Metric is divided into several metrics 149 with different priorities. In the initial case, each type of metric 150 is defined as the priority of user static planning, and the values of 151 the priority metrics are the same. When traffic is forwarded, the 152 services carried on the network are first mapped to different types 153 of different priority metrics according to the SLA type and the 154 service priority. When the network device calculates the forwarding 155 path of the service, the shortest path is calculated using the mapped 156 metric of the service as a metric, and the service is forwarded 157 according to the calculated shortest path. 159 +-----+ Metric:10 +-----+ Metric:10 +-----+ Metric:10 +-----+ 160 | RTA |------------------| RTB |------------------| RTC |------------------| RTD | 161 +-----+ +-----+ +-----+ +-----+ 162 | | 163 |Metric:10 |Metric:10 164 | | 165 | | 166 +-----+ Metric:10 +-----+ 167 | RTE |------------------| RTF | 168 +-----+ +-----+ 170 Figure 1. Network Topology 172 Assume that there are four types of services of the same type and 173 different priorities: service 1, service 2, service 3, service 4 174 (decrease of priority), Business traffic needs to be transmitted from 175 device RTA to RTD. The four services are mapped to different types 176 of different priority metrics according to the SLA type and service 177 priorities. In this example, four services are mapped to BW Metric 178 1, BW Metric 2, BW Metric 3, and BW Metric 4 according to the SLA 179 type and priority. In the initial case, the four metrics 180 corresponding to the same link have the same value. According to the 181 distributed traffic engineering technology, all four service traffics 182 are forwarded according to the shortest path calculated by the SPF 183 algorithm (RTA->RTB->RTC->RTD). If the RTB->RTC link is congested, 184 the device RTB identifies the attributes of all services forwarded on 185 the link RTB->RTC and starts network optimization from the lowest 186 priority service. Specifically, the value of the BW Metric 4 mapped 187 by the low-priority service 4 may be dynamically incrementally 188 adjusted, for example, to 1000. At this time, the shortest path for 189 the device RTB to calculate the service 4 to the device RTC according 190 to the SPF algorithm is changed to: RTB->RTE->RTF->RTC. The traffic 191 of service 4 is forwarded from the link RTB->RTE->RTF->RTC, thereby 192 reducing the congestion of the link RTB->RTC. 194 3. Optimization Rules 196 In order to prevent frequent traffic switching between the primary 197 path and backup path, the network status may oscillate for a long 198 period of time and cannot converge. Taking the topology of Figure 1 199 as an example, this paper presents a threshold regulation method and 200 some optimization rules. 202 3.1. Threshold Regulation 204 In order to prevent network oscillation caused by frequent adjustment 205 of Metric, we SHOULD set a threshold for network bandwidth 206 utilization and maintenance time. 208 The bandwidth occupancy rate is set two thresholds respectively: 209 Overlimit threshold V1 and recovery threshold V2. 211 To prevent network turbulence, we also SHOULD set two time thresholds 212 : Overtime maintenance time T1 and recovery maintenance time T2. 214 Overlimit threshold V1 and recovery threshold V2 can be set according 215 to the actual situation of the network. For example, the Overlimit 216 threshold V1 is set to 80%, and the recovery threshold V2 is set to 217 20%, which prevents congestion and idle of network links. The 218 overtime maintenance time T1 and the recovery maintenance time T2 are 219 configured according to the actual situation of the network, which 220 can be set to the same value, and can be different by the network 221 planner. 223 3.2. Optimization Rules 225 According to the threshold defined in Section 3.1, the following 226 conditions may be encountered in the process of network optimization: 228 1. The device RTB determines that the link traffic of RTB->RTC is 229 congested, the bandwidth occupancy rate is higher than the threshold 230 V1, and the congestion maintenance time exceeds the threshold time 231 T1. The RTB adjusts the value of the BW Metric 4 mapped by the 232 service 4 (for example, adjusting to 1000, Adjusting the Metric to a 233 large enough value to switch traffic directly to the backup path) 234 from the lowest priority service 4 by identifying the priority order 235 of service traffic of the current link until the RTA->RTB link 236 Bandwidth usage starts to fall. 238 2. If service 4 has been adjusted to the backup path 239 (RTA->RTB->RTE->RTF->RTC->RTB), but the bandwidth usage of the A->B 240 link is still higher than the overrun threshold V1, and has 241 experienced another Maintain time T1, RTB again recognizes the 242 priority order of the service traffic of the RTB->RTC link, and 243 continues to dynamically adjust the value of the BW Metric 3 mapped 244 by the second-lowest-priority service 3 until the bandwidth occupancy 245 rate is lower than the overrun threshold V1. 247 3. If the BW Metric 3 value corresponding to the next-low-priority 248 service 3 is incrementally adjusted, the bandwidth occupancy rate of 249 the link RTB->RTC is lower than the restoration threshold V2, and 250 after the maintenance time T2, the next-low-priority service 3 is 251 established. The corresponding metric returns to its initial value. 253 4. If the BW Metric 3 value corresponding to the next lower priority 254 service 3 is adjusted, the bandwidth occupancy rate of the backup 255 path RTB->RTE->RTF->RTC exceeds the threshold V1 and maintains the 256 time T1. Then, the BW Metric 3 corresponding to the next lower 257 priority service 3 is restored to the initial value, and an alarm is 258 printed, indicating that all the links are on the verge of overreach 259 and need to be expanded. 261 5. If the Metric value of a business is adjusted, it is found that 262 the traffic has not been switched to the backup path according to the 263 intended purpose. It shows that there is no backup path in the link, 264 the Metric value is restored to the initial value, and the service is 265 waiver to adjust the business and continue to adjust the Metric value 266 of the next business. 268 6. If the RTB finds that the service that has been tuned to the 269 backup path goes back to the RTB->RTC link after experiencing a 270 period of time, then RTB no longer adjusts the service, and keeps the 271 service forwarded on the RTB->RTC link. This situation is usually 272 caused because the backup path is also congested and the network 273 optimization method is performed on the backup path. 275 4. Controller Adjustment Scenario 277 Based on the distributed network optimization method for automatic 278 adjustment of metrics of different services, the network itself has a 279 certain ability of automatic optimization. However, If multiple 280 services are high-priority services and have the same priority, 281 services with the same priority are mapped to the same priority 282 metric. With the above-mentioned automatic adjustment method, 283 dynamic network optimization cannot be achieved. This situation 284 requires the help of the controller. The controller only needs to 285 intervene if the network itself cannot be adjusted. 287 +----------------------+ 288 | Controller | 289 +----------------------+ 290 / \ 291 / \ Request intervention 292 Adjust services priority / \ 293 / \ 294 / \ 295 +-----+ Metric:10 +-----+ Metric:10 +-----+ Metric:10 +-----+ 296 | RTA |------------------| RTB |------------------| RTC |------------------| RTD | 297 +-----+ +-----+ +-----+ +-----+ 298 | | 299 | Metric:10 | Metric:10 300 | | 301 | | 302 +-----+ Metric:10 +-----+ 303 | RTE |------------------| RTF | 304 +-----+ +-----+ 306 Figure 2. Controller Weak Control Management Network Optimization Method 308 Assume that there are four types of services of the same type and 309 different priorities: Service 1, Service 2, Service 3, and Service 4 310 (the same priority). Traffic needs to be transmitted from the device 311 RTA to the RTD. If the link RTB->RTC is congested, the device RTB 312 recognizes that the four services have the same priority and cannot 313 use the methods in Section 3 to dynamically adjust the network 314 traffic. This scenario follows the following controller adjustment 315 scenario: 317 1. RTB distinguishes congestion and initiates the network 318 optimization; 320 2. The RTB obtains the priority of all services that congest the 321 link RTB->RTC, and determines that the priorities are the same; 323 3. RTB requests intervention from the controller to adjust 324 preference of the services; 326 4. The controller adjusts preference of the services and delivers it 327 to the ingress node; 329 5. RTB enables the distributed network optimization method again. 331 5. IANA Considerations 333 TBD. 335 6. Security Considerations 337 TBD. 339 7. Acknowledgements 341 The authors of this document would like to thank Zhenbin Li, Jie 342 Dong, Gang Yan and Peng Wu for their comments and review of this 343 document. 345 8. References 347 8.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 8.2. Informative References 356 [I-D.ietf-6man-segment-routing-header] 357 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 358 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 359 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 360 progress), June 2018. 362 [I-D.ietf-spring-segment-routing] 363 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 364 Litkowski, S., and R. Shakir, "Segment Routing 365 Architecture", draft-ietf-spring-segment-routing-15 (work 366 in progress), January 2018. 368 [I-D.ietf-spring-segment-routing-mpls] 369 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 370 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 371 data plane", draft-ietf-spring-segment-routing-mpls-14 372 (work in progress), June 2018. 374 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 375 dual environments", RFC 1195, DOI 10.17487/RFC1195, 376 December 1990, . 378 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 379 DOI 10.17487/RFC2328, April 1998, 380 . 382 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 383 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 384 . 386 Authors' Addresses 388 Zhibo Hu 389 Huawei Technologies 390 Huawei Bld., No.156 Beiqing Rd. 391 Beijing 100095 392 China 394 Email: huzhibo@huawei.com 396 Gang Yan 397 Huawei Technologies 398 Huawei Bld., No.156 Beiqing Rd. 399 Beijing 100095 400 China 402 Email: yangang@huawei.com 404 Junda Yao 405 Huawei Technologies 406 Huawei Bld., No.156 Beiqing Rd. 407 Beijing 100095 408 China 410 Email: yaojunda@huawei.com