The Ultra Ethernet Consortium published Ultra Ethernet Specification 1.1 on October 12, 2026, adding scale-up features alongside a larger set of transport and congestion-control changes for AI and high-performance computing networks.
The revision introduces a local transport profile for accelerators, shorter headers and inter-packet gaps, in-network collective operations, more detailed congestion signals and a portable framework for programmable congestion management. The consortium lists version 1.1 as its current published specification, replacing version 1.0.3 from July.
On this page
Scale-up support moves into the specification
AI infrastructure uses two related kinds of communication. Scale-up links join accelerators that need to behave like a tightly coupled system, often within a server or rack. Scale-out networks connect more of those systems across a cluster.
Ultra Ethernet began as an Ethernet-based scale-out stack. Version 1.1 expands its scale-up work. The new Unified Local profile defines read, write and atomic operations for local accelerator endpoints, while keeping compatibility with the wider Ultra Ethernet Transport, or UET, framework.
That distinction matters because model training and distributed inference do not only move large files. They also exchange many short control and synchronization messages. Extra bytes and idle time around each small packet can become a material part of the transfer.
The consortium says version 1.1 can reduce the inter-packet gap by as many as 11 bytes. It also defines a Unified Forwarding Header that saves 20 bytes compared with a traditional IP packet while retaining IP routing and wire interoperability with conventional Ethernet.
Existing software gets a clearer migration path
Version 1.1 adds a UET Verbs mapping for the AI Base profile. The goal is to preserve familiar application semantics while moving software to Ultra Ethernet.
Two details are central to that work. More flexible memory mapping lets an implementation share memory-region resources across logical services in an application. Synchronization groups reproduce in-order responder-completion behavior used by existing Verbs-based applications.
These are specification-level compatibility mechanisms, not a promise that every current workload can move unchanged. A deployment still depends on compliant network adapters, switches, software and the profiles each product implements.
Switches can take part in collective operations
Distributed training repeatedly uses collective operations such as all-reduce, where many accelerators combine values and return the result to every participant. In a conventional implementation, endpoints first send values for reduction and then receive the broadcast result.
Ultra Ethernet 1.1 specifies In-Network Collectives, or INC, so capable switches can perform the reduction as data arrives and distribute the result. In the consortium’s example, producing a 1 GB reduced result normally makes each endpoint send 2 GB across the two phases; INC cuts that contribution to 1 GB. The consortium therefore describes an up to 2× communication speedup for that pattern. This is an architectural claim about the specified method, not an independent benchmark of shipping hardware.
The same mechanism can reduce the number of network hops for small collective operations. That is relevant to latency-sensitive synchronization, where each additional hop can delay the whole group.
Congestion data becomes more precise
Version 1.1 introduces Congestion Signaling, or CSIG. A 4- or 8-byte Layer 2 tag travels with a packet, and switches update it with information about the bottleneck encountered along the path. The receiving endpoint can learn both the magnitude and location of congestion.
The specification connects CSIG to Ultra Ethernet’s NSCC and RCCC congestion-control methods. NSCC can use reported queueing latency, while RCCC can use delay or queue-depth measurements when granting sender credits.
For operators, the same signal can provide path-level telemetry for troubleshooting. For the transport, it gives control algorithms more specific information than a general indication that congestion occurred somewhere.
Programmable congestion control is now portable by design
The new Programmable Congestion Management framework defines a common language and APIs that network-interface vendors can expose. Vendors and operators can build congestion-control or load-balancing algorithms for a workload, compile them for endpoints and move them between adapters that support the framework.
Portability remains conditional: both the network interface and the deployment have to implement PCM. The release of a specification does not establish product availability, interoperability certification or measured gains in a particular cluster.
What version 1.1 changes — and what it does not
Ultra Ethernet 1.1 is a substantial standards release, but it is not a hardware launch. It defines behaviors that implementers can build into adapters, switches and software stacks. The consortium says it is working with the Open Compute Project on bringing its scale-up work into a future ESUN specification and with IEEE on further standardizing CSIG.
For readers following AI infrastructure, the practical change is that Ultra Ethernet now addresses more of the path from a local accelerator fabric to a larger cluster. That places it closer to the communication problems faced by rack-scale systems, while preserving Ethernet routing and interoperability as design constraints.
The full Ultra Ethernet 1.1 specification and the consortium’s October 12 release explanation are public. Its specification history lists 1.1 as the current version. Sources checked October 14, 2026.
For background on the memory side of accelerator design, see our explainer on why AI chips depend on HBM.
