Internet-Draft Automatic Network Congestion Relief July 2026
Zhao, et al. Expires 7 January 2027 [Page]
Workgroup:
anima
Internet-Draft:
draft-zhao-anima-automatic-congestion-relief-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Zhao, Ed.
China Unicom
S. Zhang
China Unicom
M. Han
China Unicom

Automatic Network Congestion Relief

Abstract

This document describes an automatic network congestion relief mechanism for congestion caused by sudden capacity reduction, such as fiber failures. The mechanism uses traffic modeling, real-time congestion monitoring, policy generation, policy propagation, traffic regulation, and policy reversion to redistribute selected traffic from a congested plane to a lightly loaded paired plane. The objective is to reduce manual intervention, shorten congestion mitigation time, and improve network resilience during failure conditions.

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 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 7 January 2027.

▲

Table of Contents

1. Introduction

Fiber failures and other transport-layer faults may suddenly reduce the available capacity of an inter-domain or inter-plane link group. When the remaining capacity is insufficient for the current traffic load, congestion may occur on the affected plane. In current operational practice, operators often need to inspect traffic conditions, identify high-impact flows or prefixes, and manually adjust routing policies to relieve congestion. This process may take a long time and may not meet the response-time requirements of large-scale carrier networks.

This document introduces an automatic congestion relief mechanism based on traffic analysis and dynamic policy regulation. The mechanism is intended to identify the traffic that contributes most to congestion, calculate the amount of traffic that should be redistributed, generate a limited-scope routing adjustment policy, propagate the policy to the relevant device or peer, and withdraw the policy after the failed capacity is restored.

The mechanism described in this document focuses on the congestion relief procedure itself. It is not intended to define a new general-purpose network automation framework. Instead, it describes a closed-loop technical approach that can be used as an operational practice for improving network resilience in scenarios where link capacity is reduced and congestion needs to be mitigated quickly.

2. Automatic Network Congestion Relief

2.1. Mechanism Overview

The automatic network congestion relief mechanism is a device-assisted closed-loop process. It is triggered when the available capacity of a link or link group decreases and the utilization of the remaining capacity exceeds a predefined congestion threshold. The mechanism identifies traffic that can be moved, generates routing-priority adjustment policies, propagates these policies to the relevant routing peers or paired devices, monitors the result of the adjustment, and gradually removes the policies after the failure is recovered.

The mechanism consists of three major functions:

  • Congestion detection and traffic analysis.

  • Policy generation and traffic regulation.

  • Policy reversion and stability control.

The following figure shows the logical relationship among the functions.

   +-+-+-+-+-+-+-+-+-+-+       +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Traffic Modeling  |------>| Traffic Monitoring  |---->| Intelligent Policy Generation |
   +-+-+-+-+-+-+-+-+-+-+       +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                    |
                                                                    |
                               +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               |   Policy Reversion  |<----|      Policy Regulation      |
                               +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Mechanism Framework Description

Congestion detection and traffic analysis provide the basis for identifying high-impact traffic and determining whether a link or link group has entered a congestion state. Policy generation and traffic regulation calculate the required relief volume, select candidate prefixes or flows, generate a temporary routing adjustment policy, and propagate the policy to guide selected traffic to a paired plane. Policy reversion and stability control monitor the adjustment result, avoid traffic oscillation, and remove the temporary policy after the failed capacity is restored.

2.2. Congestion Detection and Traffic Analysis

Congestion detection and traffic analysis are used to understand the current traffic distribution, detect capacity reduction, and identify the traffic that contributes most to congestion. This part of the mechanism provides the input for later policy generation.

2.2.1. Functional Inputs

The congestion relief mechanism relies on the following inputs:

  • Traffic statistics collected from the forwarding plane, including high-volume flows and traffic distribution.

  • BGP RIB-out information used to correlate traffic with routing prefixes and outgoing paths.

  • Link bandwidth and utilization information obtained through BGP-LS or other telemetry mechanisms.

  • Interface statistics collected at a second-level interval.

  • Operator-defined congestion thresholds and recovery thresholds.

  • Information about paired planes or alternative paths that can receive redistributed traffic.

These inputs are used together to determine whether congestion exists, how much traffic needs to be moved, which traffic can be selected, and where the selected traffic can be redirected.

2.2.2. Traffic Modeling

Traffic modeling is used to identify the traffic that has the largest impact on the monitored link or plane. The forwarding chip of the device performs real-time traffic sorting using full-flow data and identifies the Top N traffic flows.

The intelligent component subscribes to BGP RIB-out information and correlates traffic statistics with routing prefixes and outgoing paths. This correlation allows the device to determine which prefixes are responsible for large traffic volumes and whether these prefixes can be adjusted through routing policy.

The traffic model can include the following information:

  • Traffic volume of each high-impact flow or prefix.

  • Corresponding routing prefix and outgoing path.

  • Historical traffic pattern of the flow or prefix.

  • Flow rate and traffic burst characteristics.

  • Packet length distribution.

  • Proportion of TCP and UDP traffic.

  • Proportion of fragmented packets.

  • Proportion of SYN packets.

The purpose of traffic modeling is not only to identify large flows, but also to provide a basis for controlled policy generation. For example, if several prefixes together can reduce the load of the affected plane below the congestion threshold, only those prefixes need to be adjusted. This avoids unnecessary routing changes and limits the impact of the mitigation action.

2.2.3. Congestion Detection

Congestion detection determines whether the monitored link or link group has entered a congestion state. The device obtains inter-domain link bandwidth and utilization information through BGP-LS extensions or other equivalent telemetry mechanisms. The device also collects local interface statistics at a second-level interval.

When the utilization of the affected link or link group exceeds the configured congestion threshold, the device reports a congestion event and triggers policy generation.

The detection function uses the following information when determining the congestion state:

  • Available capacity before and after a failure

  • Current traffic load on the affected plane

  • Current traffic load on the paired plane

  • Congestion threshold configured by the operator

  • Recovery threshold configured by the operator

  • Duration of threshold violation

  • Remaining capacity of the paired plane

To avoid unnecessary policy oscillation, the device uses dampening mechanisms such as hold-down timers, hysteresis thresholds, or minimum observation windows. A policy generation action is not triggered by a short-lived traffic spike unless the spike persists for a configured period.

2.2.3.1. BGP-LS Utilized Bandwidth TLV

The device uses the Utilized Bandwidth information to describe inter-domain BGP Egress Peer Engineering (EPE) link bandwidth and bandwidth utilization.

The BGP-LS Utilized Bandwidth TLV reuses the Maximum Link Bandwidth TLV (Type 1089) [RFC5305]. This TLV is used to describe the bandwidth and bandwidth utilization of inter-domain BGP EPE links.

The format of the BGP-LS Utilized Bandwidth TLV is as follows.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Type            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Utilized Bandwidth                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 2: BGP-LS Utilized Bandwidth KEY TLV
Figure 2: BGP-LS Utilized Bandwidth KEY TLV

2.3. Policy Generation and Traffic Regulation

Policy generation and traffic regulation are the core functions of the congestion relief mechanism. After congestion is detected, the device calculates the amount of traffic that needs to be redistributed, selects candidate prefixes or flows, generates a temporary routing adjustment policy, and propagates the policy so that selected traffic is redirected from the affected plane to the paired plane.

2.3.1. Relief Traffic Calculation

The device compares the current load of the affected plane with the remaining available capacity and the configured congestion threshold. The difference between the current load and the acceptable load is used as the target amount of traffic that needs to be redistributed.

The calculation can be expressed conceptually as follows:

Target relief traffic = Current traffic on affected plane - Acceptable traffic after capacity reduction

The acceptable traffic is determined by the remaining capacity of the affected plane and the operator-defined congestion threshold. For example, if a link group loses part of its capacity after a fiber failure, the mechanism calculates how much traffic needs to be moved away so that the utilization of the remaining capacity falls below the congestion threshold.

The calculation also considers the capacity of the paired plane. The generated policy does not move more traffic than the paired plane can safely receive.

2.3.2. Candidate Prefix Selection

The device uses the Top N traffic model to identify high-impact flows or prefixes. Candidate traffic is selected based on traffic volume, prefix-to-path correlation, traffic stability, and whether the traffic can be redirected through routing-priority adjustment.

The selection logic uses the following information:

  • Top N traffic ranking.

  • Mapping between traffic and routing prefixes.

  • BGP RIB-out information.

  • Current outgoing path of the selected prefix.

  • Historical stability of the traffic.

  • Expected relief volume after adjustment.

  • Remaining capacity of the paired plane.

The objective is to select a small number of high-impact prefixes or flows that can provide sufficient congestion relief. This prevents unnecessary adjustment of low-impact traffic and reduces the risk of disturbing existing routing policies.

2.3.3. Adjustment Policy Generation

After candidate traffic is selected, the device generates a temporary routing-priority adjustment policy. Since the routing prefixes sent to one network domain through RIB-out may be the same, the device can adjust routing attributes after identifying the Top N routing prefixes to be moved. The policy lowers the priority of selected prefixes on the affected plane and guides traffic to the paired plane.

The generated policy is limited to selected prefixes, neighbors, or paths. It does not change unrelated routing policies or affect traffic that does not need to be moved.

The generated policy includes the following information:

  • Selected prefixes or traffic identifiers.

  • Affected neighbor or peer.

  • Affected plane or link group.

  • Target paired plane or alternative path.

  • Routing attributes to be adjusted.

  • Expected traffic relief volume.

  • Policy lifetime or re-evaluation interval.

  • Rollback condition.

The device does not simply move traffic blindly. It uses the traffic model and monitored utilization data to determine which traffic is moved, how much traffic is moved, and where the selected traffic is redirected.

2.3.4. Policy Propagation and Traffic Regulation

After the adjustment policy is generated, the device propagates the policy through the BGP RPD protocol or another policy distribution mechanism. The purpose of policy propagation is to deliver the temporary routing-priority adjustment to the relevant peer or paired device so that selected traffic can be redirected from the affected plane to the lightly loaded plane.

The policy propagation function provides the following capabilities:

  • The policy is applied only to selected prefixes, neighbors, or paths.

  • The policy preserves existing routing policies that are not related to the congestion relief action.

  • The policy includes enough information for the receiving device to validate and apply the adjustment.

  • The receiving device can reject the policy if it conflicts with local policy or capacity constraints.

  • The originating device monitors the effect of the policy after it is applied.

After policy propagation, the device continues to monitor the utilization of both the affected plane and the paired plane. If the affected plane is still congested, the device can generate an additional limited-scope adjustment. If the paired plane approaches its own congestion threshold, the device stops further traffic movement or revises the policy.

The end-to-end process is designed to complete within seconds in order to alleviate congestion quickly. The exact convergence time depends on implementation, network scale, policy distribution delay, and routing convergence behavior.

2.4. Policy Reversion and Stability Control

Policy reversion and stability control ensure that the congestion relief mechanism remains controlled during and after the adjustment. This part of the mechanism monitors the effect of policy enforcement, prevents routing or traffic oscillation, and gradually removes temporary policies after the failed capacity is restored.

2.4.1. Closed-loop Monitoring

After the policy is applied, the device monitors the traffic distribution on both the affected plane and the paired plane. The monitoring result is used to determine whether the adjustment has achieved the expected relief effect.

Closed-loop monitoring tracks the following information:

  • Utilization of the affected plane after policy enforcement.

  • Utilization of the paired plane after receiving redistributed traffic.

  • Actual traffic relief volume.

  • Difference between expected and actual relief effect.

  • New congestion events caused by traffic redistribution.

  • Stability of the recovered link or link group.

If the actual relief effect is lower than expected, the mechanism can re-evaluate the traffic model and generate an additional limited-scope adjustment. If the paired plane becomes close to congestion, the mechanism can stop further adjustment or roll back part of the policy.

2.4.2. Policy Reversion

Policy reversion removes temporary congestion relief policies after the failed capacity is restored or after the congestion condition disappears.

After the interrupted link recovers, the optimization policies are gradually withdrawn. With the revocation of the policies, network traffic progressively returns to the load-sharing state before the failure.

The policy reversion process considers the following factors:

  • Whether the recovered link has remained stable for a configured observation period.

  • Whether the affected plane has enough available capacity after recovery.

  • Whether immediate reversion may cause traffic oscillation.

  • Whether the paired plane needs to release redistributed traffic gradually.

  • Whether the original routing policy has changed during the failure period.

A gradual reversion process helps avoid traffic oscillation. The device can withdraw policies in batches according to prefix priority, traffic volume, or operator-defined order. The device continues monitoring link utilization during reversion. If congestion reappears, the reversion process is paused or rolled back.

2.4.3. Oscillation Avoidance

The congestion relief mechanism uses stability controls to prevent repeated policy generation and withdrawal. These controls are important because traffic redistribution can change utilization on both the affected plane and the paired plane.

The following mechanisms can be used to reduce oscillation risk:

  • Separate congestion trigger and recovery thresholds.

  • Hold-down timers before policy generation.

  • Minimum observation windows for congestion detection.

  • Maximum traffic volume that can be moved in one adjustment cycle.

  • Maximum number of prefixes that can be adjusted at one time.

  • Capacity verification of the paired plane before policy propagation.

  • Gradual policy withdrawal after link recovery.

  • Rollback when congestion reappears during reversion.

These controls allow the mechanism to behave as a controlled congestion relief capability rather than an unrestricted automatic routing change function.

2.4.4. Operational Guardrails

Operators configure the congestion relief mechanism with explicit guardrails. These guardrails help ensure that automatic adjustment does not introduce instability or conflict with existing routing policies.

The following operational practices are useful for deployment:

  • Configure congestion trigger and recovery thresholds separately.

  • Set a minimum duration for congestion detection before triggering policy generation.

  • Limit the maximum amount of traffic that can be moved in one adjustment cycle.

  • Limit the maximum number of prefixes or policies that can be adjusted at one time.

  • Configure paired-plane capacity checks before policy propagation.

  • Record all generated, propagated, modified, and withdrawn policies.

  • Provide an operator override function to stop automatic adjustment when necessary.

  • Support audit and troubleshooting by recording the trigger reason, selected prefixes, expected relief volume, actual relief result, and rollback time.

3. Security Considerations

The automatic congestion relief mechanism changes routing priority and can affect traffic distribution. Therefore, it requires strict security and operational controls.

Policy generation and propagation are protected by authentication and authorization mechanisms. A device does not accept congestion relief policies from an unauthenticated or unauthorized source. Policy messages are protected against tampering and replay attacks.

The mechanism supports policy validation before applying a received policy. The receiving device verifies that the policy is within the allowed scope, does not conflict with local policy, and does not exceed configured capacity or traffic-movement limits.

The mechanism provides audit logs for congestion detection, policy generation, policy propagation, policy application, and policy reversion. Operators can determine why a policy was generated, which prefixes or paths were affected, and when the policy was withdrawn.

The mechanism supports manual override and emergency stop. If an automatically generated policy causes unexpected behavior, the operator can disable the policy and restore the original routing behavior.

4. IANA Considerations

This document makes no IANA requests.

5. Normative References

[RFC5305]
Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, , <https://www.rfc-editor.org/info/rfc5305>.

Authors' Addresses

Jing Zhao (editor)
China Unicom
Beijing
China
Shuai Zhang
China Unicom
Beijing
China
Mengyao Han
China Unicom
Beijing
China