Open Standards for AI Networking: How UEC, UALink, and OCP Shape Buyer Choice

Key takeaways

• Preserve purchasing choice: Compare scale-up, scale-out, and management standards before locking in a rack design.

• Lower integration risk: Ask for test evidence on the exact configuration you plan to deploy.

• Weigh contribution over membership: Cornelis joined Ultra Ethernet Consortium (UEC) in 2023 and contributes to work in libfabric, Ultra Ethernet Transport (UET) reference software, and link-layer mechanisms.

Why interoperability decides who controls the next purchase

Open standards matter for a practical reason: they help determine who controls the next purchase. A proprietary fabric can bind the network roadmap and software stack to one vendor and may limit accelerator choice. Each expansion can carry that dependency forward.

There is a quiet irony in modern AI infrastructure. Accelerator choices are growing, but the network connecting them can remain the most proprietary part of the rack. At Cornelis, we believe the fabric should be open and standards-based.

AI systems are becoming more mixed. Clusters now separate training from inference and prefill from decode, add CPUs for reasoning models, and mix CPUs, GPUs, and XPUs. Scale-up and scale-out often run on different network interfaces. Open standards let each part change on its own schedule.

Open standards let each part of this system of systems evolve, and they should widen the buyer's choice. Open standards alone do not guarantee interoperability. Buyers still need evidence that the chosen adapters, switches, software, and accelerators work together in the configuration they plan to deploy.

The risk is an untested fabric, not an open standard

A specification defines interfaces and expected behavior. It does not prove that every product implementing it will interoperate with every other product. That depends on the implementation, software, firmware, and configuration. Standards can also treat the same feature differently. UEC lists link-level retry (LLR) and credit-based flow control (CBFC) as optional. The OCP ESUN base specification requires switches to support both, and makes them optional on hosts.

For infrastructure teams, the distinction matters at purchase time.

• Ask which specification versions each component supports.

• Ask which combinations have been tested, and what software or configuration the deployment requires.

• A support matrix or test report for the intended system is more useful than a general claim of openness.

Three standards efforts address different parts of the AI fabric

Scale-out networking connects systems across a cluster. Scale-up networking connects accelerators within a system or pod. UEC, Ultra Accelerator Link (UALink), and OCP work on different parts of this ecosystem. Their standards and workstreams are related, but they are not interchangeable.

Ultra Ethernet Consortium (UEC): technical alignment

The Ultra Ethernet Consortium (UEC) is defining an open, Ethernet-based communications architecture for AI and high-performance computing (HPC). Cornelis joined the consortium in November 2023.

Our experience is relevant to the problems UEC is addressing. Cornelis builds interconnects for tightly coupled computing, and that Omni-Path heritage applies to problems UEC is addressing. A 2025 whitepaper from Intersect360, sponsored by UEC, makes a related point. Experience with advanced HPC interconnects brings useful expertise to Ultra Ethernet.

Cornelis participation goes beyond membership.

• Software: The UEC Software Working Group selected libfabric as the primary API for Ultra Ethernet. Cornelis adopted libfabric years ago, replacing its Verbs and PSM layers. Cornelis also worked on the uet-libfabric reference provider.

• Link-layer alignment, where UEC's optional enhancements — Link Layer Retry (LLR), Credit-Based Flow Control (CBFC), and Link Negotiation — map directly onto Cornelis' data-path and flow-control expertise.

The technical payoff is concrete: Ultra Ethernet Transport (UET) supports ordered and unordered delivery and multipath packet spraying. It defines three profiles: AI Base, AI Full, and HPC. In-network collectives and transport security are optional. UET does not require changes to the Ethernet network layer. These capabilities can be accomplished without abandoning Ethernet's operational ecosystem.

UALink: open accelerator scale-up

If UEC addresses scale-out, UALink targets scale-up: the low-latency link fabric that connects accelerators within a pod. UALink is intended to provide an open option alongside proprietary accelerator links such as NVIDIA‘s NVLink. The cited UALink materials describe support for up to 1,024 accelerators per pod and 200 Gb/s lanes.

The specification also describes in-network collectives (INC), AuthTags-based security (hardware-based authentication), link-level retry, and strict ordering. We participate in UALink as an implementer and a Contributor member.

Cornelis intends to support UALink features including INC primitives, UALinkSec with AuthTags, Strict Ordering Mode, low-latency forward error correction (FEC), and Link-Level Retry.  That distinction is important to buyers. Membership, contribution, productsupport, and interoperability testing are different things. Ask which one a vendor is claiming.

OCP ESUN: Ethernet-based scale-up and open management

UEC and UALink focus on transport standards. The Open Compute Project (OCP) also provides a place for work on the surrounding infrastructure, including management and rack-scale hardware. Its Ethernet for Scale-Up Networking (ESUN) workstream was launched at the OCP Global Summit in October 2025.

The ESUN specification describes an Ethernet-based scale-up approach with a compact, four-byte extension header. The header carries class of service, congestion marking, a flow label, hop limit, and user-defined bits. The specification also covers priority-based flow control (PFC), credit-based flow control (CBFC), LLR, and ESUN-aware forwarding.

The work extends beyond wire protocols. We built a libsai implementation of the Switch Abstraction Interface (SAI), including a UALink fabric extension, and use of the same SAI code path in emulation. OpenBMC, Redfish, and OCP ORv3 rack packaging are also part of the described management and hardware approach.

Openness at the protocol layer and openness in the management model are different things. Buyers should evaluate both.

Build choice into the fabric

Active Compute Fabric™ is an open architecture for scale-up and scale-out networking with programmable compute built into the fabric. It is designed around UEC specifications for scale-out and UALink and ESUN for scale-up.

• Scale-out: the Cornelis SuperNIC is designed to support Omni-Path, Ultra Ethernet, and Remote Direct Memory Access (RDMA) over Converged Ethernet v2 (RoCEv2). Multipath Reliable Connection (MRC) and standard Ethernet on one port, with protocol choice by workload. Its primary AI transport is designed for UEC conformance.

• Scale-up:  Cornelis will build scale-up products on UALink and ESUN.

This approach is meant to let customers evaluate multiple standards and protocols without betting the cluster on one vendor stack or one standards roadmap. Product support and interoperability still depend on the specific configuration.

What the public record shows

Cornelis’ UEC commitment has a public starting point: the November 2023 membership announcement linked above. Membership is evidence of participation, not proof of product conformance or interoperability. The stronger case for commitment is the technical work described across software, transport, and link-layer efforts.

What to verify before choosing an AI fabric

• Workload: Which communication patterns and scaling needs matter to the applications you plan to run?

• Standards and versions: Which specification and version does each component support?

• Complete configuration: Which accelerators, adapters, switches, software, and firmware have been tested together?

• Feature placement: Which capabilities run at the endpoint, and which require support across links or switches?

• Software path: Which APIs, providers, drivers, and versions are supported today?

• Operations: Which management, monitoring, and troubleshooting interfaces are available?

• Evidence type: Is each claim based on a specification, product capability, test result, customer deployment, or roadmap?

• Expansion path: What documented options exist for adding or changing components later?

The goal is to choose a fabric your team can evaluate, operate, and extend. A list of standards alone is not enough.

Bring your architecture questions to OCP 2026

At OCP 2026, stop by booth #E36 with your workload and target configuration. Ask for a standards-to-product map, supported software and firmware versions, and test evidence for the components you plan to deploy.

Interoperability beats lock-in when it gives buyers real options. The destination may be shared, but the starting architecture still matters.

Even if you can’t attend OCP, you can always talk to a Cornelis fabric architect about your AI networking fabric requirements.