Ultra Ethernet Moves Inside the AI Node
The Ultra Ethernet Consortium released version 1.1 of its specification on October 12, extending its work beyond scale-out cluster networking and into scale-up networks. These short-range fabrics connect accelerators such as GPUs inside a node, often through a single switch tier—or without a switch at all.
The consortium was established in 2023 to adapt Ethernet to the growing requirements of artificial intelligence and high-performance computing. Its 1.0 specification, published in June 2025, defined a transport protocol, congestion-control mechanisms, and a modern approach to remote direct memory access (RDMA).
Version 1.1 expands that foundation with:
A Unified Local profile for short-range accelerator interconnects.
A Unified Forwarding Header (UFH) and optional idle reduction to lower packet overhead.
In-network collectives (INC) that let switches perform reduction operations such as allreduce for groups of endpoints.
Congestion Signaling (CSIG) to carry congestion measurements from a bottleneck switch toward the sender.
Programmable Congestion Management (PCM) for loading congestion-control and load-balancing programs onto endpoints.
Extensions that map Ultra Ethernet transport into the RDMA verbs programming interface.
“A big new focus of UEC 1.1 is extending support to scale-up networks,” Tom Emmons, Chair of the UEC Technical Advisory Committee, told Network World.
Why Packet Overhead Matters at Scale-Up Speeds
Scale-out networks connect nodes across a cluster. Scale-up networks instead carry traffic among accelerators within a node, where small messages and very high packet rates make every byte of overhead significant.
According to the specification details reported by Network World, a standard Ethernet frame carrying IPv4 and UDP data has 66 bytes of overhead before a transport header or payload is added. UEC 1.1 addresses this through three related mechanisms.
Unified Local Profile
The Unified Local profile provides a simplified transport for local networks. Requests traveling in one direction can also carry acknowledgment information for traffic in the other direction, potentially reducing protocol state and the number of separate acknowledgment packets.
The profile is intended for a lossless fabric using priority flow control (PFC) or credit-based flow control (CBFC).
Unified Forwarding Header
The optional UFH replaces the separate IP header and places addressing information in the existing 12-byte Ethernet MAC header. It can coexist on a link with standard Ethernet frames. By comparison, a standard IPv4 header occupies 20 bytes.
Reduced Idle Time
An optional idle-reduction feature shortens the required spacing between frames. The reported minimum spacing changes from an average of 84 bytes to a constant 80 bytes.
The UEC is working with the Open Compute Project to bring these scale-up technologies into a future version of the Ethernet for Scale-up Networking specification.
More Context and More Control for Congestion
Congestion develops when multiple senders target the same link and switch queues begin filling. The sender needs both a signal indicating the problem and an algorithm that determines how transmission should change.
A conventional explicit congestion notification mark supplies one bit of information: it indicates that a queue somewhere along the path is filling, but does not identify the location or quantify the condition. A second limitation is that the reaction algorithm may be fixed in the network interface card, making it difficult to adapt as AI workloads evolve.
UEC 1.1 introduces two mechanisms aimed at those constraints:
CSIG adds a 4-byte or 8-byte packet tag that switches along the path can update with congestion information.
PCM allows congestion-control and load-balancing algorithms to run as programs loaded onto an endpoint rather than remaining permanently fixed in the NIC.
Together, these additions are intended to provide endpoints with more useful feedback and make traffic-management behavior more adaptable.
Operational Readiness Is a Multi-Vendor Inventory Problem
A specification release does not mean every deployed switch, network adapter, accelerator node, or firmware image supports every feature. Operators evaluating Ultra Ethernet 1.1 therefore need to separate several questions:
Which assets have hardware capable of the relevant functions?
Which firmware or software release enables each capability?
Which features are optional, and which combinations have been validated together?
Where are PFC or CBFC configurations required for the Unified Local profile?
Can a mixed-vendor path provide consistent behavior from endpoint to endpoint?
Which configuration changes were made during testing, and can they be reversed safely?
This is especially important for features involving both endpoints and switches. CSIG depends on packet handling along the path, while PCM changes how endpoints react to the information they receive. In-network collectives also place new functions in the switching layer. Readiness must therefore be evaluated across the fabric, not by checking one device in isolation.
Where ConnectMyAssets Fits
ConnectMyAssets provides an on-prem, vendor-agnostic system for managing the operational records behind a multi-vendor fabric transition. It does not add Ultra Ethernet support to hardware; it helps infrastructure teams establish which assets, software states, and configurations are actually deployed.
The Dynamic CMDB can maintain an asset-level inventory of switches, adapters, nodes, models, operating systems, and firmware, giving teams a foundation for recording Ultra Ethernet capability and validation status.
Backup & History preserves configuration versions and supports one-click rollback, which is useful when testing changes to flow control, queues, or other fabric settings.
The Compliance Engine can check approved configuration requirements and retain evidence for internal controls or frameworks such as NIS2, ISO 27001, PCI, CISA, and NIST.
Per-asset CVE Tracking keeps vulnerability findings associated with the infrastructure participating in the AI fabric. This is separate from protocol capability, but remains essential when deciding whether a firmware release is operationally acceptable.
End-of-Life Tracking highlights equipment approaching the end of vendor support, helping teams distinguish assets that may receive future capabilities from those likely to require replacement.
Automation & ZTP can support controlled, repeatable deployment workflows after configurations and firmware combinations have been validated.
Topology provides the path context needed to assess whether an accelerator-to-accelerator flow crosses devices with different capabilities or software states.
For Ultra Ethernet planning, the practical objective is a traceable readiness record: hardware capability, installed firmware, enabled configuration, validation result, topology role, and rollback point for every participating asset.
What Network Teams Should Track Next
As implementations emerge, infrastructure teams should build a capability register rather than relying on a simple “UEC-ready” label. At minimum, track:
Support for the Unified Local profile, UFH, idle reduction, INC, CSIG, and PCM separately.
The firmware or software version associated with each supported feature.
Required endpoint, switch, and flow-control dependencies.
Validation results for each multi-vendor combination.
Configuration baselines before and after fabric tests.
Security findings and end-of-support dates for participating assets.
Ultra Ethernet 1.1 broadens Ethernet’s role in AI infrastructure, but the operational challenge will be proving that every component in a real fabric is aligned. Accurate asset data, configuration history, and topology-aware validation will be as important as the specification itself.
Source: Network World
