Automatic Network Congestion Relief

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.

Mechanism Framework Description | Traffic Monitoring |---->| Intelligent Policy Generation | +-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Policy Reversion |<----| Policy Regulation | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]> 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.

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.

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.

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.

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.

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) . 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.

BGP-LS Utilized Bandwidth KEY TLV

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.

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: 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.

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.

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.

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.

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.

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.

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.

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.

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.