Internet DRAFT - draft-hu-lsr-network-automatic-optimization
draft-hu-lsr-network-automatic-optimization
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,
<https://www.rfc-editor.org/info/rfc2119>.
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, <https://www.rfc-editor.org/info/rfc1195>.
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,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
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]
