AI-Aware Adaptive Multipath Ethernet Fabric

Layer 2 Switch Hop-by-Hop Congestion Notification with AI-Optimized Path Selection for fast and efficient ECMP packet spraying across Layer 2 links.

Technology Concept Paper

Author: Christopher Soans
Date: September 2026

Download PDF

A backward-compatible architecture for telemetry-informed Layer-2 multipathing, rapid switch-to-switch congestion notification, and fabric-wide AI optimization in large-scale AI infrastructure.

Figure 1. AI-Aware Adaptive Multipath Ethernet Fabric

1. Executive Summary

Large AI clusters generate highly synchronized, high-bandwidth traffic patterns that can expose limitations in conventional flow-hashed ECMP. A deterministic flow may remain pinned to one equal-cost path even when another path has available capacity, while fine-grained packet spraying can improve utilization but introduces ordering and congestion-management requirements.

This paper proposes an AI-aware Ethernet fabric in which packet forwarding remains local and hardware-fast, while switches exchange lightweight congestion state and an independent AI Control/Intelligence network provides summarized, fabric-wide telemetry and optimization. The design is intended to complement, rather than replace, Ethernet, ECMP, RoCEv2, emerging Ultra Ethernet Consortium (UEC) mechanisms, and endpoint-oriented congestion signaling such as CSIG.

The central design principle is: distribute conditions, not paths. The AI system does not calculate every endpoint-to-endpoint route and does not participate in individual packet forwarding decisions. Switch ASICs retain local next-hop groups and make line-rate forwarding decisions. Congestion information modifies compact path weights or path-state attributes.

2. Problem Statement

Conventional ECMP typically hashes a flow onto one of several equal-cost paths. This preserves packet ordering but can create hash collisions and uneven utilization when a small number of very large AI flows dominate the fabric. Fine-grained multipathing or packet spraying can use aggregate fabric capacity more effectively, but a switch that considers only its own immediate interfaces may select a locally uncongested path that encounters severe congestion several hops downstream.

A fully centralized controller that maintains every Layer-2/IP endpoint mapping and every possible end-to-end path would introduce unnecessary state and could become difficult to scale in fabrics containing tens of thousands of endpoints. The proposed architecture therefore separates immediate distributed reaction from broader centralized intelligence.

3. Design Objectives

• Preserve line-rate ASIC forwarding; no AI query is permitted in the per-packet forwarding path.
• Allow fine-grained multipathing for traffic whose endpoint transport can tolerate out-of-order delivery.
• Provide rapid switch-to-switch congestion notification so upstream switches can change path weighting before congestion becomes widespread.
• Use an independent AI Control/Intelligence network for fabric-wide telemetry, correlation, prediction, and longer-timescale optimization.
• Avoid a centralized database of every endpoint-to-endpoint path by distributing compact congestion and fabric-region state.
• Remain compatible with UEC, RoCEv2, ECMP, Ethernet/IP, QoS/ECN, and conventional forwarding behavior.
• Continue forwarding safely if the AI Control/Intelligence network is unavailable.
• Support incremental implementation through NOS/firmware enhancements where switch silicon already exposes suitable telemetry and programmable multipath capabilities.

4. Architectural Model

The architecture uses three cooperating control scopes while retaining a conventional high-speed data plane.

Layer	Primary Function	Timescale	Typical Action
Switch ASIC / local logic	Immediate forwarding and local congestion reaction	Fastest	Select next hop; apply local override
Switch-to-switch notification	Propagate affected path/region congestion upstream	Very fast	Reduce weight of degraded next hop
AI Control/Intelligence	Fabric-wide correlation, topology awareness, optimization	Slower control loop	Publish summarized path/region state and recommended weights
UEC / endpoint transport	Transport-level multipathing, reliability and congestion response	Transport dependent	Endpoint reaction to congestion and out-of-order delivery

5. AI-Aware Switch

An AI-aware switch remains a standards-compliant Ethernet switch. AI awareness is an additional capability that allows the switch to export telemetry, receive summarized fabric state, validate recommendations, and translate approved information into hardware-consumable multipath parameters.

• Local telemetry: interface utilization, queue depth, buffer pressure, latency indicators, drops, ECN/congestion events, errors, and link state.
• Congestion-notification engine: generates and consumes lightweight upstream switch notifications.
• AI Control/Intelligence agent: exchanges summarized telemetry and optimization information over the independent control network.
• Policy-validation boundary: verifies topology, reachability, loop prevention, security constraints, supported hardware ranges, and administrative policy before programming the ASIC.
• Adaptive path engine: maintains weighted next-hop groups or equivalent hardware objects.
• Standards fallback: retains UEC/local mechanisms where available and conventional ECMP/Ethernet behavior otherwise.

The AI system advises and optimizes; deterministic networking mechanisms validate and forward.

6. Fast Switch-to-Switch Congestion Notification

When a downstream switch detects congestion, it should not require a round trip through the centralized intelligence system before upstream forwarding changes. The detecting switch generates a compact notification toward switches feeding the affected direction or destination region.

Example: SW1 can forward toward a destination region through either SW2-SW5-SW8 or SW3-SW6-SW9. If SW5 detects severe congestion on SW5-SW8, SW5 immediately reduces its own use of that resource where alternatives exist and notifies SW2. SW2 adjusts the relevant hardware path state and can propagate a summarized notification to SW1. SW1 only needs to know that its next hop through SW2 toward the affected region is degraded; it does not need a complete map of SW5, SW8, or every endpoint behind them.

6.1 Suggested Notification Semantics

• Affected direction, path class, or compact fabric-region identifier.
• Congestion severity or bounded congestion metric.
• Traffic class/queue where relevant.
• Reporting switch or link identifier for correlation.
• Sequence number and/or freshness timer.
• Optional decay/recovery indication.

The exact wire format should preferably use an existing standards mechanism where one is suitable. If no suitable UEC or Ethernet mechanism provides switch-to-switch upstream path-state propagation, the concept can be implemented as a standards-oriented extension rather than tied to a proprietary protocol.

7. AI Control/Intelligence Network

The independent AI Control/Intelligence network provides a broader view without becoming a centralized packet-forwarding engine. It receives telemetry from participating switches and maintains a topology-centric representation of the fabric.

Instead of storing every possible source-to-destination path, the controller can maintain physical/logical adjacencies and summarized conditions such as: SW5-SW8 = high congestion; SW6-SW9 = normal; fabric region R27 = degraded in the direction of SW8.

• Correlate congestion observed by multiple switches.
• Identify shared downstream bottlenecks that are invisible from an ingress switch's local interfaces.
• Distinguish transient bursts from persistent hotspots.
• Recommend bounded path weights or path-state changes.
• Distribute relevant congestion summaries to switches that have not yet encountered the congested segment.
• Use historical patterns and workload information to anticipate recurring congestion.
• Maintain control visibility even when the production AI data fabric itself is congested.

8. Distribute Conditions, Not Paths

Scalability depends on avoiding endpoint-centric control. A fabric with tens of thousands of endpoints can have an enormous number of possible source/destination/path combinations. The controller therefore distributes compact network conditions rather than complete per-flow routes.

For example, the controller may advertise that fabric region R27 is degraded or that a specific directional segment has elevated congestion. Each switch combines that information with its own existing forwarding state to determine which local next-hop groups are affected.

This preserves distributed forwarding and limits control-plane state while still giving ingress switches information about congestion several hops downstream.

9. Weighted Multipath and Stability

Congestion should generally modify path preference rather than cause binary route removal. Abruptly moving all traffic away from one path can simply create congestion elsewhere and produce oscillation.

Condition	Path via SW2	Path via SW3
Normal	50%	50%
Moderate congestion via SW2	35%	65%
Heavy congestion via SW2	10%	90%
Recovery period	25-40%	75-60%
Stable recovery	50%	50%

Implementations should use bounded weights, hysteresis, hold-down/decay timers, freshness checks, and rate limits. Local congestion information may temporarily override an older controller recommendation.

10. Relationship to UEC, CSIG, RoCEv2 and ECMP

The proposal is intentionally complementary. UEC is expected to provide transport and fabric capabilities suited to high-performance Ethernet, including support for sophisticated multipathing and congestion handling. Endpoint-oriented congestion signaling, including mechanisms such as CSIG in applicable deployments, can inform source/destination transport behavior. The proposed switch-to-switch mechanism addresses a different question: how should an upstream switch alter its own path distribution when a downstream portion of the fabric becomes congested?

For UEC-capable endpoint pairs, the fabric may permit finer-grained multipathing because the endpoint transport is designed to tolerate the associated delivery behavior. For RoCEv2 or other ordering-sensitive traffic, the same intelligence can improve flow-level path selection while preserving path affinity. Conventional traffic can continue to use standard ECMP and Ethernet/IP behavior.

10.1 IEEE 802.1Qau QCN as an Architectural Precedent

IEEE 802.1Qau Quantized Congestion Notification (QCN) is relevant as an architectural precedent because it demonstrates that a Layer-2 switch can detect queue congestion and generate explicit congestion feedback. In QCN terminology, a congested switch acts as a Congestion Point (CP) and sends feedback toward a Reaction Point (RP) associated with the source, allowing the source to adjust its transmission behavior.

The proposed architecture uses a related congestion-detection principle but changes the consumer and purpose of the notification. Rather than sending congestion information solely to a source reaction point, the proposed switch-to-switch mechanism communicates the affected path condition hop-by-hop upstream, toward the traffic source, through the relevant switches in the forwarding path.

For example, if traffic flows Source -> SW1 -> SW2 -> SW5 -> SW8 -> Destination and SW5 detects congestion in the direction of SW8, SW5 can notify SW2. SW2 immediately adjusts the appropriate local ASIC multipath weight and, where the condition is relevant to traffic arriving from SW1, propagates a summarized notification to SW1. SW1 does not need a complete map of SW5, SW8, or every endpoint behind them; it only needs to know that its next hop through SW2 toward the affected destination or fabric region is degraded.

This makes the proposed mechanism fabric-oriented rather than source-rate-oriented. QCN primarily addresses congestion by causing a source reaction point to alter its offered load. The proposed mechanism primarily addresses path imbalance by allowing upstream switches to steer subsequent eligible traffic toward alternative paths with available capacity. Endpoint congestion control remains necessary when alternate paths are also congested or when the offered load must be reduced.

The QCN precedent also suggests that congestion information can be quantified rather than treated as a binary condition. A bounded congestion-severity value can be mapped to proportional path-weight changes, with hysteresis and decay controls preventing oscillation. The proposed mechanism should not be described as QCN itself; QCN has defined IEEE semantics and a source reaction model. Instead, QCN is a useful standards precedent for Layer-2 congestion detection and explicit feedback.

Aspect	IEEE 802.1Qau QCN	Proposed Switch-to-Switch Mechanism
Detection	Congestion detected at a Layer-2 switch/queue	Congestion detected at a Layer-2 switch/path or queue
Feedback target	Source Reaction Point	Relevant upstream switch, propagated hop-by-hop as needed
Primary reaction	Source transmission-rate adjustment	Hardware multipath/path-weight adjustment
Primary purpose	Congestion control	Congestion-aware path steering and avoidance
Scope	Layer-2 congestion domain	Layer-2 fabric mechanism, supplemented by AI Control/Intelligence telemetry

11. Failure and Degraded-Mode Operation

• AI Control/Intelligence unavailable: switches retain safe validated state for a bounded period, rely on local telemetry and supported UEC mechanisms, and fall back to standard ECMP/routing behavior.
• Congestion notification unavailable: forwarding continues using controller summaries and local congestion mechanisms.
• Controller recommendation conflicts with fresh local congestion: local protection takes temporary precedence.
• Link failure: existing deterministic hardware/routing failure handling remains authoritative; AI is not required for convergence.
• Legacy neighbor or endpoint: use standards-compatible forwarding without AI-specific assumptions.

12. Security and Control Safeguards

• Authenticate switch-to-switch congestion notifications and AI Control/Intelligence sessions.
• Prevent an endpoint or untrusted external network from injecting trusted fabric-state information.
• Constrain controller authority to approved parameters and ranges.
• Validate all changes locally before hardware installation.
• Use freshness, replay protection, and sequence controls for congestion state.
• Maintain forensic logs of significant path-weight changes and their triggering telemetry.
• Rate-limit control updates to protect the switch CPU/control plane.

13. Illustrative Traffic Sequence

1. SW1 sprays eligible packets across next hops SW2 and SW3 using ASIC-resident weighted multipath state.
2. SW5 detects rising queue pressure/congestion toward SW8.
3. SW5 immediately applies any safe local mitigation and sends a compact upstream congestion notification to SW2.
4. SW2 reduces the affected next-hop/path weight and propagates a summarized degraded-path indication toward SW1 where relevant.
5. SW1 shifts a larger share of subsequent eligible packets toward SW3-SW6-SW9 without consulting the AI controller per packet.
6. SW5 simultaneously exports detailed telemetry over the AI Control/Intelligence network.
7. The intelligence layer correlates the event with other fabric telemetry, identifies whether the bottleneck is local or shared, and distributes summarized state or bounded weight recommendations to other affected switches.
8. UEC/CSIG or other endpoint mechanisms independently continue transport-level congestion response where supported.
9. As congestion clears, hysteresis and decay logic gradually restore balanced path weighting.

14. Implementation and Migration Approach

The design should support incremental adoption. Existing programmable switches may be able to participate through NOS/firmware enhancements if their ASICs expose weighted ECMP or programmable next-hop groups, telemetry, suitable queue/congestion indicators, and a secure management/control interface. More advanced fine-grained packet spraying or UEC-specific behavior may require compatible silicon and endpoint NICs.

• Phase 1: telemetry collection and AI Control/Intelligence visibility with no forwarding changes.
• Phase 2: controller-recommended weighted ECMP for selected traffic classes.
• Phase 3: switch-to-switch congestion notification and local hardware adaptation.
• Phase 4: fine-grained multipathing for UEC-capable endpoint pairs.
• Phase 5: predictive optimization using workload schedules and historical congestion patterns.

15. Expected Benefits

• Better utilization of parallel Ethernet links and reduced ECMP hash imbalance.
• Faster avoidance of downstream congestion without central per-packet decisions.
• Fabric-wide awareness of bottlenecks that are not visible from an ingress switch's local interfaces.
• Reduced controller state compared with per-endpoint/per-path centralized routing.
• Independent telemetry visibility during production-fabric congestion.
• Backward compatibility and graceful degraded operation.
• Ability to combine local reaction, endpoint congestion control, and global intelligence rather than forcing one mechanism to solve every timescale.

16. Open Design Questions

• Which existing UEC/Ethernet mechanisms can carry or be extended to carry switch-to-switch upstream congestion state?
• What is the optimal compact identifier: destination region, path group, next-hop group, link/segment ID, or a combination?
• How far upstream should a congestion notification propagate before its benefit no longer justifies additional state?
• What congestion thresholds and decay algorithms minimize oscillation while reacting quickly enough for AI collective traffic?
• How should multiple simultaneous bottlenecks be summarized without expanding the control state excessively?
• Which telemetry should remain local and which should be exported to the AI Control/Intelligence system?
• What portions can be introduced through firmware/NOS upgrades on current merchant silicon?

17. Conclusion

The proposed AI-Aware Adaptive Multipath Ethernet Fabric separates high-speed forwarding from global intelligence. Switches make packet decisions locally in hardware, exchange rapid congestion state with relevant upstream switches, and use an independent AI Control/Intelligence network for broader topology-aware optimization. By distributing conditions rather than centrally managing every path, the architecture is designed to scale while preserving interoperability and autonomous fallback.

The concept is deliberately evolutionary: it can augment existing Ethernet, ECMP, RoCEv2, UEC, and endpoint congestion mechanisms while introducing AI-aware coordination only where supported.

© 2026 Christopher Soans. All rights reserved.

This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0).

Related Posts

Loading related posts...