Network Working Group Z. Hu Internet-Draft G. Yan Intended status: Standards Track J. Yao Expires: January 3, 2019 Huawei Technologies July 2, 2018 Network Automatic Optimization Based on Dynamic Adjustment of IGP Metrics draft-hu-lsr-network-automatic-optimization-00 Abstract The centralized traffic engineering technology adopts centralized calculation, PCE/SDN performs centralized calculation based on the collected link-status and TE information collected by BGP-LS/IGP, so that the traffic in the network is optimized to the optimization goal. The distributed traffic engineering technology uses IGP to calculate the shortest path. Each node in the network calculates the next hop to a destination address based on the same algorithm and network topology. Each algorithm can calculate a shortest path tree in the entire network, which can reduce the amount of calculation, so that the hard convergence time of TE can be close to the convergence time of IGP. The distributed computing and management methods can not co-ordinate management of network bandwidth resources. As a result, network bandwidth resources can not be planned in an integrated manner, bandwidth resources are wasted, and even tunnels cannot be established. This document attempts to discuss a automatic network optimization function of the distributed traffic engineering technology by the method of dynamically adjusting the link Metric. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute Hu, et al. Expires January 3, 2019 [Page 1] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Automatic Network Optimization Method . . . . . . . . . . . . 3 3. Optimization Rules . . . . . . . . . . . . . . . . . . . . . 5 3.1. Threshold Regulation . . . . . . . . . . . . . . . . . . 5 3.2. Optimization Rules . . . . . . . . . . . . . . . . . . . 5 4. Controller Adjustment Scenario . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The concept of IGP Metric defined in [RFC1195] for ISIS, and defined in [RFC2328] and [RFC5340] for OSPF, indicating the cost of using this router link. Hu, et al. Expires January 3, 2019 [Page 2] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 Segment Routing (SR) described in [I-D.ietf-spring-segment-routing] leverages the source routing paradigm. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane [I-D.ietf-spring-segment-routing-mpls] and applied to the IPv6 architecture with a new type of routing header called the SR header (SRH) [I-D.ietf-6man-segment-routing-header]. Segment Routing uses the IGP protocol as the control protocol. The distributed traffic engineering technology has unique advantages in solving the problem of SRv6's label stack depth, in rapid convergence and self-healing. The distributed traffic engineering technology adopts the distributed route calculation method. However, because the IGP calculates the shortest path based on the SPF algorithm and the metric of the link is constant, it is possible that a certain segment of the optimal path of multiple services is the same segment of the link. In a multi-service scenario, it is easy to cause congestion on some network links while the bandwidth resources on other links are idle. The resources of the entire network cannot be fully utilized. This document proposes a method for automatic optimization when traffic flow is congested by dynamically adjusting the link metric. Section 2 describes the implementation of automatic network optimization in distributed traffic engineering technology. Section 3 defines the thresholds and optimization rules of automatic network optimization. In Section 4, based on the dynamic adjustment of link metric technology, the network optimization method for controller weak control management is introduced. 2. Automatic Network Optimization Method The distributed traffic engineering technology is based on the IGP protocol. Each node uses the SPF algorithm to calculate the shortest path to the destination node based on the entire network topology. Each link calculates the shortest path based on the same metric for all services. As the services in the network increase, some links in the network may be seriously congested, but some links are still underutilized. This causes a waste of network resources. Consider a method that, when a link is congested, dynamically adjusts the metric of the link so that traffic of a part of the service can be switched to other paths for transmission, thereby reducing the load of the congested link. Through the adjustment of metrics of different links in the network, different priority services calculate different shortest paths based on different metrics of the same link in the same network, thereby avoiding network congestion on certain links and increasing Utilization of network resources. Hu, et al. Expires January 3, 2019 [Page 3] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 The automatic network optimization method divides the metric of the link according to the SLA type into multiple types corresponding to the SLA type (For example divided into Bandwidth Metric, Latency Metric...etc.), Each type of Metric is divided into several metrics with different priorities. In the initial case, each type of metric is defined as the priority of user static planning, and the values of the priority metrics are the same. When traffic is forwarded, the services carried on the network are first mapped to different types of different priority metrics according to the SLA type and the service priority. When the network device calculates the forwarding path of the service, the shortest path is calculated using the mapped metric of the service as a metric, and the service is forwarded according to the calculated shortest path. +-----+ Metric:10 +-----+ Metric:10 +-----+ Metric:10 +-----+ | RTA |------------------| RTB |------------------| RTC |------------------| RTD | +-----+ +-----+ +-----+ +-----+ | | |Metric:10 |Metric:10 | | | | +-----+ Metric:10 +-----+ | RTE |------------------| RTF | +-----+ +-----+ Figure 1. Network Topology Assume that there are four types of services of the same type and different priorities: service 1, service 2, service 3, service 4 (decrease of priority), Business traffic needs to be transmitted from device RTA to RTD. The four services are mapped to different types of different priority metrics according to the SLA type and service priorities. In this example, four services are mapped to BW Metric 1, BW Metric 2, BW Metric 3, and BW Metric 4 according to the SLA type and priority. In the initial case, the four metrics corresponding to the same link have the same value. According to the distributed traffic engineering technology, all four service traffics are forwarded according to the shortest path calculated by the SPF algorithm (RTA->RTB->RTC->RTD). If the RTB->RTC link is congested, the device RTB identifies the attributes of all services forwarded on the link RTB->RTC and starts network optimization from the lowest priority service. Specifically, the value of the BW Metric 4 mapped by the low-priority service 4 may be dynamically incrementally adjusted, for example, to 1000. At this time, the shortest path for the device RTB to calculate the service 4 to the device RTC according to the SPF algorithm is changed to: RTB->RTE->RTF->RTC. The traffic Hu, et al. Expires January 3, 2019 [Page 4] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 of service 4 is forwarded from the link RTB->RTE->RTF->RTC, thereby reducing the congestion of the link RTB->RTC. 3. Optimization Rules In order to prevent frequent traffic switching between the primary path and backup path, the network status may oscillate for a long period of time and cannot converge. Taking the topology of Figure 1 as an example, this paper presents a threshold regulation method and some optimization rules. 3.1. Threshold Regulation In order to prevent network oscillation caused by frequent adjustment of Metric, we SHOULD set a threshold for network bandwidth utilization and maintenance time. The bandwidth occupancy rate is set two thresholds respectively: Overlimit threshold V1 and recovery threshold V2. To prevent network turbulence, we also SHOULD set two time thresholds : Overtime maintenance time T1 and recovery maintenance time T2. Overlimit threshold V1 and recovery threshold V2 can be set according to the actual situation of the network. For example, the Overlimit threshold V1 is set to 80%, and the recovery threshold V2 is set to 20%, which prevents congestion and idle of network links. The overtime maintenance time T1 and the recovery maintenance time T2 are configured according to the actual situation of the network, which can be set to the same value, and can be different by the network planner. 3.2. Optimization Rules According to the threshold defined in Section 3.1, the following conditions may be encountered in the process of network optimization: 1. The device RTB determines that the link traffic of RTB->RTC is congested, the bandwidth occupancy rate is higher than the threshold V1, and the congestion maintenance time exceeds the threshold time T1. The RTB adjusts the value of the BW Metric 4 mapped by the service 4 (for example, adjusting to 1000, Adjusting the Metric to a large enough value to switch traffic directly to the backup path) from the lowest priority service 4 by identifying the priority order of service traffic of the current link until the RTA->RTB link Bandwidth usage starts to fall. Hu, et al. Expires January 3, 2019 [Page 5] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 2. If service 4 has been adjusted to the backup path (RTA->RTB->RTE->RTF->RTC->RTB), but the bandwidth usage of the A->B link is still higher than the overrun threshold V1, and has experienced another Maintain time T1, RTB again recognizes the priority order of the service traffic of the RTB->RTC link, and continues to dynamically adjust the value of the BW Metric 3 mapped by the second-lowest-priority service 3 until the bandwidth occupancy rate is lower than the overrun threshold V1. 3. If the BW Metric 3 value corresponding to the next-low-priority service 3 is incrementally adjusted, the bandwidth occupancy rate of the link RTB->RTC is lower than the restoration threshold V2, and after the maintenance time T2, the next-low-priority service 3 is established. The corresponding metric returns to its initial value. 4. If the BW Metric 3 value corresponding to the next lower priority service 3 is adjusted, the bandwidth occupancy rate of the backup path RTB->RTE->RTF->RTC exceeds the threshold V1 and maintains the time T1. Then, the BW Metric 3 corresponding to the next lower priority service 3 is restored to the initial value, and an alarm is printed, indicating that all the links are on the verge of overreach and need to be expanded. 5. If the Metric value of a business is adjusted, it is found that the traffic has not been switched to the backup path according to the intended purpose. It shows that there is no backup path in the link, the Metric value is restored to the initial value, and the service is waiver to adjust the business and continue to adjust the Metric value of the next business. 6. If the RTB finds that the service that has been tuned to the backup path goes back to the RTB->RTC link after experiencing a period of time, then RTB no longer adjusts the service, and keeps the service forwarded on the RTB->RTC link. This situation is usually caused because the backup path is also congested and the network optimization method is performed on the backup path. 4. Controller Adjustment Scenario Based on the distributed network optimization method for automatic adjustment of metrics of different services, the network itself has a certain ability of automatic optimization. However, If multiple services are high-priority services and have the same priority, services with the same priority are mapped to the same priority metric. With the above-mentioned automatic adjustment method, dynamic network optimization cannot be achieved. This situation requires the help of the controller. The controller only needs to intervene if the network itself cannot be adjusted. Hu, et al. Expires January 3, 2019 [Page 6] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 +----------------------+ | Controller | +----------------------+ / \ / \ Request intervention Adjust services priority / \ / \ / \ +-----+ Metric:10 +-----+ Metric:10 +-----+ Metric:10 +-----+ | RTA |------------------| RTB |------------------| RTC |------------------| RTD | +-----+ +-----+ +-----+ +-----+ | | | Metric:10 | Metric:10 | | | | +-----+ Metric:10 +-----+ | RTE |------------------| RTF | +-----+ +-----+ Figure 2. Controller Weak Control Management Network Optimization Method Assume that there are four types of services of the same type and different priorities: Service 1, Service 2, Service 3, and Service 4 (the same priority). Traffic needs to be transmitted from the device RTA to the RTD. If the link RTB->RTC is congested, the device RTB recognizes that the four services have the same priority and cannot use the methods in Section 3 to dynamically adjust the network traffic. This scenario follows the following controller adjustment scenario: 1. RTB distinguishes congestion and initiates the network optimization; 2. The RTB obtains the priority of all services that congest the link RTB->RTC, and determines that the priorities are the same; 3. RTB requests intervention from the controller to adjust preference of the services; 4. The controller adjusts preference of the services and delivers it to the ingress node; 5. RTB enables the distributed network optimization method again. Hu, et al. Expires January 3, 2019 [Page 7] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 5. IANA Considerations TBD. 6. Security Considerations TBD. 7. Acknowledgements The authors of this document would like to thank Zhenbin Li, Jie Dong, Gang Yan and Peng Wu for their comments and review of this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-14 (work in progress), June 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-14 (work in progress), June 2018. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . Hu, et al. Expires January 3, 2019 [Page 8] Internet-DraNetwork Automatic Optimization Based on Dynamic A July 2018 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . Authors' Addresses Zhibo Hu Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: huzhibo@huawei.com Gang Yan Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: yangang@huawei.com Junda Yao Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: yaojunda@huawei.com Hu, et al. Expires January 3, 2019 [Page 9]