[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/