Ultra Ethernet Consortium: Ethernet für KI im großen Maßstab neu aufbauen

Zusammenfassung

• Ultra Ethernet Consortium ist ein Projekt der Joint Development Foundation, das am 19. Juli 2023 von AMD, Arista Networks, Broadcom, Cisco, Eviden/Atos, Hewlett Packard Enterprise, Intel, Meta und Microsoft gestartet wurde. Es ist ein industrielles Konsortium zur Entwicklung von Spezifikationen und kein herkömmliches Unternehmen oder Netzbetreiber.
• Der Umfang geht weit über eine schnellere Ethernet-Verbindung oder die Ablösung von RoCE hinaus. Die Spezifikation 1.0.3 mit 573 Seiten deckt Software, Transport, Netzwerk, Link- und Physical-Layer sowie Arbeiten zu Management, Storage, Test und Konformität ab.
• Ultra Ethernet Transport kombiniert mehrere Auslieferungsmodi, paketbasiertes Multipath, selektive Wiederholung, Staukontrolle vom Sender und Empfänger, ECN, optionales Packet Trimming, optionales lokales Retry, optionale Credit-basierte Flusskontrolle und optionale End-to-End-Transport-Sicherheit.
• Produkte und Demonstrationen von AMD, Broadcom, Nokia und Keysight zeigen, dass die Implementierung begonnen hat, aber die öffentliche Konformität stützt sich im Wesentlichen auf Selbstauskunft der Implementierer; ein vollständiges öffentliches Register unabhängiger Zertifizierung oder ein vollständiges Verzeichnis großskaliger Deployments wurde nicht veröffentlicht.
• UECs strategische Chance ergibt sich aus der vorhandenen Ethernet-Installation und einer mehranbieter-basierten Lieferkette. Die wesentlichen Risiken sind Endpoint-Komplexität, Fragmentierung durch optionale Funktionen, RAND-Patentverpflichtungen, die Unreife von Management und Testung sowie der Abstand zwischen der Veröffentlichung einer Spezifikation und der Verifikation der Interoperabilität im Produktionsbetrieb.

Warum KI das Netzwerk zum Teil des Rechners machte

Ultra Ethernet Consortium entstand vor dem Hintergrund eines Wandels in der Rechenökonomie. In einem gewöhnlichen Unternehmensnetzwerk soll die Infrastruktur viele unabhängige Flows mit einem akzeptablen Niveau an Kapazität und Verfügbarkeit transportieren. In einem großen KI-Trainingssystem oder in einem Hochleistungsrechner bildet das Netzwerk hingegen Teil einer einzigen, zeitlich eng gekoppelten Berechnungskette. Tausende Beschleuniger können Parameter, Gradienten oder wissenschaftliche Daten über kollektive Operationen austauschen. Eine Phase kann nicht fortschreiten, bis der langsamste Teilnehmer die benötigten Daten erhalten hat.

Daher kann eine geringe Pfadabweichung, ein kurzfristiger Stau oder der Verlust eines Pakets teure Beschleuniger ungenutzt lassen, obwohl die mittlere Netzwerkauslastung gesund erscheint.

Das ändert, was Betreiber optimieren müssen. Die aggregierte Bandbreite bleibt wichtig, reicht aber nicht. Auch die Arbeitszeit bis zum Abschluss von Jobs, die Warteschlanglatenz, Incast, Verlustwiederherstellung, die Verteilung von Verkehr über parallele Pfade und die Menge an Zustand, die Endpunkte halten müssen, sind entscheidend. Ein Netzwerk, das die große Mehrzahl der Pakete schnell liefert, aber einen kleinen Teil verzögert, kann einen gesamten kollektiv ausgeführten Job anhalten.

Ein Wiederholungsverfahren, das für gewöhnlichen Verkehr ausreichend ist, kann zu viel Zeit verlieren, wenn bei einer langen Nachricht auch nur ein einzelnes Paket verloren geht. Ein Flow, der auf einem einzigen Pfad gleicher Kosten bleibt, kann unter der Kapazitätsreserve anderer Topologieabschnitte deutlich unter den Erwartungen bleiben.

Die Kernthese von UEC war, dass diese Probleme nicht durch eine einzelne neue Switch-Funktion oder einen isolierten Staualgorithmus gelöst werden können. Die Kommunikationskette beginnt oberhalb des Netzes in den Softwarebibliotheken und der Semantik der Anwendungen. Sie verläuft über den Speicher-Workflow, Remote-Operationen, Transportzustand, Paketzustellung, Staukontrolle, IP-Weiterleitung, Ethernet-Links, Optik und physische Signalisierung. Werden diese Schichten separat entworfen, kann eine Optimierung in einem Bereich nur den Engpass verschieben oder in einem anderen Bereich zu unvereinbaren Annahmen führen.

UECs Ansatz ist eine koordinierte Architektur. Sie behält Ethernet und IP bei, weil Betreiber sie bereits kennen und weil es eine erhebliche industrielle Lieferkette für Switches, Optik, Kabel, Netzwerkbetriebssysteme, Telemetrie und Management-Werkzeuge gibt. Gleichzeitig verändert oder erweitert das Konsortium die Teile, die für große KI- und HPC-Lasten nicht ausreichend angepasst sind. Das Ergebnis ist nicht „normales Ethernet mit anderem Logo“. Es ist der Versuch, ein bekanntes Netz mit einem spezialisierten Mechanismus auszustatten, dessen Verhalten von der Software-API bis zur Signalisierungsgeschwindigkeit jeder Lane definiert wird.

Diese Unterscheidung erklärt die Bedeutung von UEC für die digitale Infrastruktur. Das Projekt besitzt keine Beschleuniger, Fertigung, Rechenzentren oder Cloud-Regionen. Es liefert Verträge, die Mitgliedsfirmen und andere Implementierer in NICs, Switching-ASICs, Systemen, Treibern, Bibliotheken und Testsystemen übernehmen können. Die Wirkung entfaltet sich erst, wenn unabhängige Produkte Fehler, Stau, Updates und gemischte Lieferantenkonstellationen gemeinsam korrekt verarbeiten.

Was UEC ist und was es nicht ist

Ultra Ethernet Consortium ist der öffentliche Name eines formellen Projekts, dessen rechtliche Serie als Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series geführt wird. Die Struktur ordnet UEC in die Joint Development Foundation und in die weitere Linux Foundation-Familie ein. Sie gibt den Teilnehmern einen bestehenden Rechtsrahmen für Mitgliedschaft, Governance, geistiges Eigentum, Finanzierung und externe Beziehungen, ohne die Gründung einer eigenen, neuen juristischen Gesellschaft zu erzwingen.

Die Struktur ist wichtig, weil UEC häufig als Unternehmen, Allianz oder Standardisierungsgremium beschrieben wird. Es ist kein kommerzielles Unternehmen mit Anteilseignern, eigenem Kapital, Bewertung oder unabhängig aufgestellten Zahlen. Es verkauft weder Ethernet-Produkte noch betreibt es ein öffentliches Netz und besitzt nicht die Hardware, die seine Mitglieder bewerben. Es ist ein Spezifikationsentwicklungs-Konsortium mit einem Rechts- und IP-Rahmen. Die öffentlichen Dokumente zielen auf Implementierungsverträge zwischen mehreren Unternehmen ab.

UEC ist auch nicht gleichbedeutend mit Ultra Ethernet Transport. UET ist die Transportarchitektur im Zentrum der Spezifikation, aber die Arbeit des Konsortiums ist breiter. Sie umfasst das Mapping von Software auf libfabric, die Semantik von Nachrichten und Paketen, Netzannahmen, Link-Optionen, physische Anforderungen, Management, Abstimmung mit Storage, Leistungsanalyse und Debugging, Konformität und Tests. UEC auf „neues RDMA-Protokoll“ zu reduzieren, verschleiert das Querschnittsdesign, das es besonders ambitioniert und anspruchsvoll macht.

UEC ist nicht die IEEE 802.3-Arbeitsgruppe. IEEE 802.3 entwickelt die fundamentalen Ethernet-Standards auf MAC- und Physical-Layer über einen eigenen formalen Prozess. UEC baut auf diesem Ökosystem auf und hält eine Integrationsbeziehung, ersetzt es aber nicht. Dasselbe gilt für die von IETF genutzten Mechanismen, darunter IPv4, IPv6 und Explicit Congestion Notification; für das von UET genutzte OpenFabrics-Ökosystem mit libfabric; und für die Organisationen, die im Bereich Storage, offene Hardware und Beschleunigerinterkonnektivität arbeiten.

Das Projekt benutzte anfangs eine Formulierung, die wie eine internationale Standardisierungsorganisation klang. Die abgesicherte Formulierung ist, dass UEC eine internationale Spezifikationsentwicklungsorganisation unter dem JDF-Rahmen ist. Es gibt keine Hinweise darauf, dass es Teil der International Organization for Standardization ist, dass seine Dokumente ISO-Normen sind oder eine ISO-Nummer besitzen. Der Unterschied ist nicht nur semantisch; er legt fest, woher die Autorität kommt, wie die Teilnahme funktioniert und welche rechtlichen Verpflichtungen Implementierer tragen können.

UEC sollte anhand seiner tatsächlichen Funktion bewertet werden. Es koordiniert Wettbewerber und Betreiber um ein gemeinsames technisches Design, veröffentlicht Spezifikationen, verwaltet Arbeitsgruppen und Patentverpflichtungen, erstellt Konformitätsmaterialien und pflegt Beziehungen zu angrrenzenden Organisationen. Es kann weder ein Produkt interoperabel machen noch den Markt durch bloße Erklärung zur Architektur verpflichten.

Die Gründungsgemeinschaft der neun Unternehmen

Das Konsortium wurde am 19. Juli 2023 durch neun Organisationen vorgestellt, die in verschiedenen Stufen der KI- und HPC-Lieferkette vertreten sind: AMD, Arista Networks, Broadcom, Cisco, Eviden — damals mit Atos verbunden —, Hewlett Packard Enterprise, Intel, Meta und Microsoft. Diese Breite war von Beginn an ein strategischer Vorteil. Ein Transport, der nur von Switch-Herstellern entworfen würde, könnte Beschränkungen von Anwendungen und Endpunkten übersehen. Ein Design, das nur von Beschleunigeranbietern geleitet wird, könnte sich um ein einziges Hardwareökosystem herum optimieren.

Ein reines Cloud-Projekt könnte die notwendige Erfahrung in Silizium, Optik und Systemintegration fehlen, um eine Architektur in marktreife Produkte zu überführen.

AMD trug Prozessoren, Beschleuniger und Endpoint-Networking bei. Arista und Cisco brachten Ethernet-Switching in großer Skalierung und operative Erfahrung ein. Broadcom brachte Switch-Silizium, NICs und schnelle SerDes bei. HPE und Eviden lieferten HPC-Systeme und langjährige Erfahrung mit spezialisierten Interkonnektivitäten. Intel brachte Prozessoren, Ethernet und Software bei. Meta und Microsoft repräsentierten Hyperscaler-Betreiber mit direkten Anreizen, die Auslastung großer KI-Cluster zu verbessern und die Abhängigkeit von einem integrierten Großlieferanten zu reduzieren.

Die Koalition vereint auch harte Konkurrenzinteressen. Mitglieder verkaufen NICs, Switch-ASICs, Systeme, Cloud-Kapazität, Optik, Software und Support. Einige verfügen über Patentportfolios, die für die Umsetzung der Spezifikation relevant sein können. Manche profitieren von einem breiten, multi-vendor-Standard, während andere zugleich Vorteile aus differenzierten proprietären Funktionen ziehen. Das Konsortium beseitigt Wettbewerb nicht; es schafft einen Rahmen, in dem Rivalen minimale Schnittstellen vereinbaren und weiterhin um Implementierungsqualität, Leistung, Integration und kommerzielle Konditionen konkurrieren.

Slingshot von HPE liefert ein gutes Beispiel für technische Abstammung. Es ist eine kommerzielle HPC-Fabric auf Ethernet-Basis mit adaptivem Routing und Stau-Management. In HPE-bezogenen Berichten wurde angegeben, dass eine Spezifikation „HPC Ethernet“ an UEC geliefert wurde und dass ein signifikanter Teil von UET auf Transportideen aus Slingshot basiert. Der genaue Anteil wurde nicht unabhängig verifiziert und darf nicht als offizielle Buchhaltung des Konsortiums verstanden werden.

Weitgehend belegbar ist hingegen: UEC begann nicht auf einem weißen Blatt, sondern griff Produktionswissen aus HPC-, Cloud-Networking-, RDMA- und Ethernet-Umgebungen auf.

Diese Verbindung von Vorläufersystemen zeigt, warum der Begriff „offen“ präzise zu verwenden ist. Die öffentlichemte Spezifikation ist öffentlich herunterladbar und die Architektur ist für Implementierung durch mehrere Anbieter vorgesehen. Gleichwohl ist das Projekt auch ein Ort, an dem Mitglieder bestehendes Wissen, Patente und Produkt-Roadmaps einbringen. Die Offenheit des Dokuments beseitigt nicht automatisch ökonomische oder rechtliche Rahmenbedingungen der Technologie.

Eine Rechtsstruktur, die Zusammenarbeit zwischen Wettbewerbern ermöglicht

Das Modell der Joint Development Foundation gibt UEC eine formale Struktur, ohne es in ein operatives Standardunternehmen zu verwandeln. Das Projekt verfügt über Namen, Scope, Mitgliedsklassen, Steering Committee, Arbeitsgruppen und IP-Verpflichtungen. Die Dachstruktur der JDF stellt gemeinnützige Corporate-Infrastruktur bereit und kann Assets und Vereinbarungen halten. Das senkt den Aufwand für den Aufbau eines Konsortiums und bietet Wettbewerbern einen anerkannten Prozess zur Zusammenarbeit.

Das Steering Committee führt die Projektsteuerung. Die dokumentierten Aufgaben umfassen die Koordination der Arbeitsgruppen, die Aufnahme von Mitgliedern, die Verwaltung von Assets und Finanzen, die Auswahl oder den Austausch der Vorsitzenden, Fortschrittskontrolle sowie die Steuerung öffentlicher Kommunikation und Marken. Vorrang hat der Konsens. Schlägt er fehl, ist eine Drei-Viertel-Mehrheit der wahlberechtigten, teilnahmeberechtigten Teilnehmer vorgesehen. Schriftliche Berufungen können an den Vorsitz gerichtet werden.

Brad Booth von Meta war der ursprüngliche Vorsitzende. Spezifikation 1.0.3 benennt J Metz von AMD als Vorsitzenden, Barry Davis von HPE als Vizevorsitzenden, Hugh Holbrook von Arista als Vorsitzenden des Technical Advisory Committee und Puneet Agarwal von Marvell als Vizevorsitzenden des TAC. Paul Congdon ist als Spezifikationseditor aufgeführt. Das Dokument nennt zudem Verantwortliche und Autoren der physischen, Link-, Transport- und Software-Arbeiten. Die Agenda des 2026 Summit nennt weitere operative Verantwortliche.

Diese Rollen ersetzen nicht zwingend die formalen Titel aus Spezifikation und öffentlichem Material und bieten keinen vollständigen, aktuellen Organigrammplan.

Die Charta enthält drei Mitgliedsklassen: Steering, General und Contributor. Steering-Mitglieder wirken in der Governance mit und benennen oft Vertreter für das Steering Committee. General-Mitglieder können in allen Technikgruppen arbeiten, nehmen aber nicht am Committee teil. Contributor-Mitglieder wirken in ausgewählten Gruppen mit und haben bei Supermehrheiten kein Stimmrecht. Die aktuelle öffentliche Seite bepreist die Stufen General und Contributor mit 20.000 beziehungsweise 5.000 US-Dollar jährlich zuzüglich Linux Foundation-Mitgliedschaft. Der Weg zur Aufnahme und der aktuelle Preis für Steering werden dort nicht klar erklärt.

Die formale Machtverteilung ist relevant. Eine breite Mitgliedschaft kann Wissen und Implementierungsreichweite einbringen, aber Governance verteilt sich nicht automatisch gleichmäßig. Große Unternehmen, die Steering-Sitze besetzen, viele Ingenieure mehreren Gruppen zuordnen können und Programme für Patente und Produkte vorhalten, haben praktisch größeren Einfluss als kleinere Contributor-Mitglieder. Nichtmitglieder können die finale Spezifikation laden, nicht aber den kompletten Entwurfsprozess oder eine gleichberechtigte Teilnahme mitbekommen.

Die internen Projektinformationen werden nicht wie allgemeine vertrauliche Unternehmensdaten behandelt, aber Mitglieder dürfen Entwürfe erst veröffentlichen, wenn das jeweilige Committee zugestimmt hat. Das ermöglicht Wettbewerbsdiskussionen mit unfertigen Ideen ohne vorzeitige Marktsignale. Es bedeutet zugleich, dass Externe keinen Blick auf abgelehnte Vorschläge, Abstimmungsregister, Zwischenbedenken bei der Implementierung oder Verhandlungen über optionale Funktionen haben. Die finale Spezifikation ist offen; der Weg bis dorthin ist nur teilweise sichtbar.

Von vier Arbeitsgruppen zu einer 573-seitigen Spezifikation

Die erste öffentliche Struktur von UEC im Jahr 2023 konzentrierte sich auf vier Arbeitsgruppen: Software, Transport, Link und Physical-Layer. Die Reihenfolge spiegelte den End-to-End-Ambitionsanspruch des Projekts. Die Mitgliedschaft wurde nicht sofort als uneingeschränkte öffentliche Liste geöffnet. Über 200 Organisationen zeigten Interesse, und das Konsortium staffelte den Einstieg, während es Schulungen zu Prozessen und Kartellrecht verlangte. Die Vorsicht war nachvollziehbar, weil Teilnehmer in mehreren Märkten direkt konkurrieren und gemeinsame Produkt- und Protokollanforderungen diskutieren würden.

Im Dezember 2023 meldete UEC rund 40 Unternehmen und über 300 Einzelpersonen. Es war ein Technical Advisory Committee entstanden und die Struktur auf acht Arbeitsgruppen erweitert. Ziel des TAC war es, architektonische Konsistenz zu sichern: Ein Transportdesign durfte kein Verhalten von Switch, Signalisierungsmethode oder API voraussetzen, das eine andere Gruppe nicht vereinbart hätte. Im März 2024 berichtete das Konsortium von 55 Unternehmen und über 750 aktiven Teilnehmern und veröffentlichte eine deutlich klarere Darstellung der vorgesehenen Architektur.

Das Update im März brachte zentrale Ideen, die später in der normativen Spezifikation erschienen: libfabric als softwareorientierte API, Packet Spraying, flexible Ordnung, mehrere Zustellmodi, Staukontrolle am Sender und Empfänger, ECN, Packet Trimming, Link Layer Retry, optionale Credit-basierte Flusskontrolle, Transport-Sicherheit und künftige kollektive Operationen im Netz. Es hob auch hervor, dass UET über bestehende Ethernet-Switches funktionieren kann, während verbesserte Switches zusätzliche Leistung liefern können.

Die institutionelle Reichweite wuchs mit der technischen Arbeit. UEC meldete im Juli 2024 1.193 aktive Teilnehmer und im August 97 Mitgliedsorganisationen. Diese Zahlen stammen aus dem Konsortium selbst und basieren auf nicht vollständig öffentlichen Definitionen. Sie dürfen nicht mechanisch mit späteren Ankündigungen addiert werden. Im Jahr 2025 erklärte UEC, dass 27 weitere Unternehmen beigetreten seien; Ausschlüsse, Fusionen und überlappende Zeiträume verhindern jedoch eine exakte Gesamtsumme für den aktuellen Stand. Die Website gibt nicht alle Mitglieder offen an.

Die Ultra Ethernet Specification 1.0 wurde am 11. Juni 2025 veröffentlicht und markierte den Übergang von der reinen Roadmap zu einer öffentlichen Implementierungsreferenz. Die Version 1.0.1 folgte im September und korrigierte den Ursprung des Receiver-Credit-Staukontrollalgorithmus sowie redaktionelle Probleme. Version 1.0.2 kam im Januar 2026 und korrigierte Stauverwaltungsalgorithmen, obwohl offizielle Dokumente uneinheitlich zwischen dem 21. und 28. Januar datieren. Diese Inkonsistenz muss sichtbar bleiben statt aufgelöst zu werden.

Version 1.0.3 vom 16. Juli 2026 ist in diesem Untersuchungsstand die aktuelle Referenz. Sie hat 573 Seiten und integriert 200 Gb/s-Signalisierung pro Lane sowie eine boolesche Verhandlungsfähigkeit. Versionshinweise benennen zusätzliche Pflichtkorrekturen zu Paketzustellung, Congestion Credits, Link Layer Retry und Ordered Sets im Physical-Layer sowie Klarstellungen zu Transport-Sicherheit, atomaren Operationen und getrimmten Paketen. Der Unterschied zwischen Pflichtkorrekturen und redaktionellen Klarstellungen ist zentral: Einige Änderungen betreffen das Verhalten und damit die Bewahrheiterhaltung von Implementierungen.

Der Member Summit 2026 in Denver zeigte eine zweite Phase. Die Agenda fokussierte auf Deployment, Produktisierung, Konformität, Management, Leistung, Debugging, Integration mit Storage sowie Tests von Switches und Endpunkten. Die zentrale Architektur liegt vor; die Glaubwürdigkeit hängt nun stärker davon ab, dass Implementierer den Stack organisationsübergreifend aufbauen, qualifizieren, betreiben und aktuell halten können.

Eine auf fünf Funktionsschichten verteilte Architektur

Die aktuelle Spezifikation teilt Ultra Ethernet in Software, Transport, Netzwerk, Link und Physical-Layer. Die Untergliederung ist nützlich, der Wert des Projekts liegt aber in den Annahmen, die diese Ebenen verbinden.

Oben interagieren KI-Frameworks, MPI, SHMEM und kollektive Operationsbibliotheken über OpenFabrics Interfaces, insbesondere libfabric. Die UET Semantic Services Sublayer überträgt Anwendungsvorgänge in Transporttransaktionen. Die Packet Delivery Sublayer entscheidet, wie Nachrichten in Pakete zerlegt, geordnet, bestätigt und wiederhergestellt werden. Die Staukontrolle regelt, wie viele Daten in die Fabric eintreten und wie Verkehr auf Pfade verteilt wird. Die optionale Transport-Sicherheit schützt Endpunkt-zu-Endpunkt-Verkehren. IPv4 oder IPv6 stellt das standardisierte Netzwerk-Forwarding bereit.

Ethernet liefert den Link mit Packet Trimming, Link Layer Retry, Credit-Based Flow Control und Verhandlung optionaler Funktionen. Der Physical-Layer definiert Statistiken sowie Signalisierungsanforderungen bei 100 oder 200 Gb/s pro Lane.

Die Struktur bewahrt wichtige Teile der bestehenden Netzlandschaft. UEC definiert keinen Ersatz für IP-Routing. Es erwartet konventionelles ECMP mit kostengleichen Pfaden und ECN-fähigen kompatiblen Switches. Ein erheblicher Teil der Intelligenz bleibt in den Fabric Endpoints, die Entropiewerte handhaben, Transportzustand verfolgen, Daten platzieren und auf Stausignale reagieren. Verbesserte Switches können zusätzliche Funktionen bereitstellen, aber das Design verlangt nicht den Austausch der gesamten Fabric, bevor UET-Verkehr läuft.

Das schafft sowohl ein Migrationsplus als auch eine Klassifikationsherausforderung. Ein Deployment kann UET-Endpunkte über konventionelles Ethernet mit ECMP und ECN nutzen. Ein anderes Deployment kann Trimming, Link Retry, Credits pro virtuellem Kanal, umfangreichere Telemetrie und künftig In-Network-Operationen hinzufügen. Beide Varianten können als Ultra Ethernet gelten, obwohl ihre Leistungs-, Wiederherstellungs- und Betriebsaufwandsprofile deutlich auseinanderklaffen.

Der fünfschichtige Ansatz erschwert zudem Fehlersuche. Ein schlechtes Ergebnis kann aus dem Anwendungs-Mapping, dem Endpunkt-Zustandsautomaten, den Stauparametern, der Switch-Queue-Konfiguration, DSCP-Mapping, Optik, Firmware oder dem Sicherheitssystem kommen. Es genügt nicht, Pakete durchzureichen. Das System muss die vorgesehene Semantik und Leistung im Produktionsmaßstab mit gemischtem Verkehr, Ausfällen und Versionenänderungen halten.

Der Software-Vertrag: libfabric statt proprietärer Anwendungs-APIs

UEC wählt libfabric 2.0 als referenzierte northbound API für konforme Endpunkte. Diese Entscheidung bindet das Projekt in ein bestehendes HPC- und Netzwerksoftware-Ökosystem ein, statt jeden Framework dazu zu zwingen, eine neue proprietäre Schnittstelle zu übernehmen. Libfabric bildet bereits Fabrics, Domains, Endpoints, Completion Queues, Event Queues, Address Vectors, Memory Regions, Messaging, Remote-Memory- und Atomic-Operationen ab. UEC mapt diese Konzepte ab und begrenzt sie, sodass Anbieter die Aufrufe in UET-Verhalten übersetzen können.

Der strategische Wert ist die Semantik über dem Transport hinweg. MPI, SHMEM und Beschleuniger-Kommunikationsbibliotheken können vertraute Abstraktionen nutzen, während der darunterliegende Anbieter wechselt. Grundsätzlich kann eine Anwendung einen Auftrag stellen, ohne zu wissen, welche NIC die Zustellung implementiert oder welches Switch-Silizium Pakete weiterleitet. Das ist ein zentrales Mittel, mit dem ein gemeinsamer Transport Auswahlmöglichkeiten zwischen Lieferanten ermöglichen soll.

Die Abstraktion garantiert jedoch keine gleichwertigen Implementierungen. Anbieter können unterschiedliche Inject-Größen, Scatter/Gather-Limits, Endpunktzahlen, atomare Operationen, Speicherregistrierung, Completion-Verhalten, Hardware-Offload oder Sicherheitsfunktionen unterstützen. Eine gegen dieselbe API kompilierte Bibliothek kann bei Leistung und Kapazität unterschiedliche Grenzen treffen. Die Softwareauswahl braucht deshalb mehr als ein Häkchen bei „libfabric supported“.

UEC-Software transportiert zudem Job- und Autorisierungssemantik. KI- und HPC-Systeme betreiben oft viele Jobs auf gemeinsam genutzter Infrastruktur, mit je eigenen Prozessen, Speicherregionen und Sicherheitsgrenzen. Die Spezifikation muss festlegen, welchem Endpoint welcher Job zugeordnet ist, welche Puffer nutzbar sind, wie entfernte Operationen gekoppelt werden und wie Completion- oder Fehlerinformationen an die Software zurückfließen. Diese Entscheidungen bestimmen, ob ein schnelles Netzwerk vom Scheduler, Runtime und der Anwendung wirklich nutzbar ist statt nur in einem Paket-Benchmark zu glänzen.

Das Projekt hängt vom OpenFabrics-Ökosystem ab, weil libfabric nicht proprietär ist. Die Beziehung illustriert eine generelle Charakteristik von UEC: Die Architektur wird aus Komponenten aufgebaut, die in unterschiedlichen Governance-Kontexten verwaltet werden. UEC kann festlegen, wie sein Transport auf libfabric gemappt wird, muss sich dabei aber mit Unterhaltern und Nutzern der API abstimmen. Ähnliche Abhängigkeiten bestehen bei Ethernet in IEEE, IETF-Netzmechanismen, Storage-Organisationen und den Betriebssystemen der Anbieter.

Fabric Endpoints und Lastprofile

Ein Fabric Endpoint oder FEP ist der logische Ort, an dem UET endet. Er verbindet eine Instanz des Betriebssystems mit einem oder mehreren isolierten Fabricebenen und kann einen Nutzerraumanbieter, einen Kernel-Treiber, Transport in NIC oder Beschleuniger, Speicherregistrierung, Sicherheitskontext, Completion Queues, Address Vectors und den für Paketzustellung und Staukontrolle genutzten Zustand enthalten.

Das endpointzentrierte Design ermöglicht, dass die meisten Switches weiterhin als vertraute Ethernet- und IP-Geräte erkennbar bleiben. Der FEP wählt Entropiewerte, hält Paket- und Stauzustand, platziert Daten in autorisierten Speichern und interpretiert Acks, Trimming und weitere Signale. Es kann die Notwendigkeit proprietärer Intelligenz im Switch reduzieren, verlagert aber Komplexität auf NIC-Silizium, Firmware, Treiber und Software.

UEC definiert drei Implementierungsprofile: AI Base, AI Full und HPC. Sie sind keine getrennten Netztypen, sondern Pakete mit den jeweils erforderlichen Funktionen. AI Base zielt auf häufige KI-Kommunikation mit geringerer Kosten- und Zustandslast. AI Full ergänzt Funktionen wie deferrable sends, exact matching und atomare Fetching- oder Vergleichsoperationen. Das HPC-Profil enthält den größten Teil der AI-Full-Funktionen, schließt deferrable send aus und legt stärkeren Fokus auf Reihenfolge, kurze Nachrichten und HPC-Semantik.

Die Abstraktion soll verhindern, dass jedes Produkt den Maximalumfang implementieren muss. Es erkennt an, dass eine KI-NIC mit großem Volumen primär kollektive Datenbewegung priorisieren kann, während ein HPC-Endpunkt stärkere Reihenfolgegarantien und Atomics benötigt. Die Profile beseitigen jedoch nicht die Optionstrukturen. Ein Produkt kann optionale Funktionen innerhalb eines Profils umsetzen, und zwei Produkte mit gleicher Kennzeichnung können Unterschiede bei Sicherheit, Link-Verbesserungen, Kapazität und Leistung haben.

Die Terminologie selbst ist ein Warnsignal. Die verbindliche Spezifikation 1.0.3 nutzt AI Base, AI Full und HPC. Ein separates Konformitäts-Readme von 2025 verwendet AI Base, AI Extended und HPC. Die bestgestützte Auslegung ist, dass „AI Full“ der gültige Name ist und das Konformitätsmaterial veraltet oder inkonsistent ist. Bis zur Korrektur müssen Anbieter und Käufer sowohl die Version als auch die exakt verwendete Profilsprache bei Aussagen benennen.

Von der Anwendungssicht zur Paketzustellung

Innerhalb von UET transportiert der Semantic Services Sublayer die Anwendungsvorgabe. Er definiert Nachrichtentypen, Puffernaddressierung, tagged- und untagged-Operationen, Remote-Speicherzugriff, Atomics, Completion-Verhalten, Job-IDs, Pufferautorisierung, Antworten und Fehler. Anschließend bestimmt die Packet Delivery Sublayer, wie diese Vorgaben zu Paketen werden und wie diese einen anderen Endpunkt erreichen.

Für verlässliche Modi richten Endpunkte Packet Delivery Contexts (PDC) ein. Ein PDC enthält Zustand wie Sequenznummern, Acknowledgements, Dubletten-Erkennung, Ordnungsmodus, Stausignale, Rücksendepfadstatus und Verkehrsklasse. Ein PDC ist einem Zustellmodus und einer Verkehrsklasse zugeordnet; zwischen derselben FEP-Paarung können mehrere existieren.

Dieser Zustand ist kein Nebenaspekt. Große Cluster erzeugen gewaltige Kommunikationsbeziehungen. Wenn jede Beziehung viel Zustand am Ziel benötigt, können Speicher- und Suchkosten des Endpunkts zum Limit werden. Deshalb verpflichtet UEC nicht zur Aufnahme jeder Operation in ein einziges Verbindungsmodell. Es werden vier Zustellservices mit unterschiedlichen Zuverlässigkeits- und Ordnungsverträgen definiert.

Reliable Unordered Delivery (RUD) stellt genau-einmalige Zustellung in Richtung Anwendungsemantik bereit, erlaubt jedoch Out-of-Order-Empfang. Es unterstützt paketweise verteilte Multi-Path-Auslieferung, selektive Wiederholung, Duplikatunterdrückung und direkte Datapositionierung. Da das Ziel Daten per Offset direkt ablegen kann, anstatt auf eine Transport-Reihenfolge-Pufferung zu warten, kann eine lange kollektive Operation mehrere Pfade nutzen, ohne alle Pakete hinter einem einzigen fehlenden Paket zu serialisieren.

Reliable Ordered Delivery (ROD) liefert genau-einmalige Zustellung in Reihenfolge. Es nutzt einen Pfad und einen Entropiewert, verwirft Out-of-Order-Pakete und verwendet Recovery im Go-Back-N-Verfahren ab der ersten fehlenden Sequenznummer. Es wirkt weniger ausgefeilt als RUD, bewahrt aber die für die Anwendung notwendige Semantik, wenn strikte Ordnung erforderlich ist. UEC behandelt Ordnung als Anwendungsanforderung, statt anzunehmen, dass jede Übertragung diese Kosten tragen muss.

Reliable Unordered Delivery for Idempotent Operations (RUDI) ist eine weitere Kompromisslösung. Sie liefert mindestens einmalige Zustellung und erlaubt Duplikate, reduziert damit den normalen Sequenz- und Acknowledgement-Zustand am Ziel. Sie kann nützlich sein, wenn Wiederholung den Endzustand nicht verändert, etwa bei bestimmten Speicherfernbewegungen mit anschließender Barriere. Sie ist riskant, wenn falsch eingesetzt. Die Paket-Ebene erkennt nicht automatisch, ob eine Operation idempotent ist; das Software-Design muss dies festlegen. RUDI für nicht-idempotente Vorgänge kann zu ungültigem Anwendungszustand führen.

Unreliable Unordered Delivery (UUD) bietet Datagramme im Best-Effort ohne übliche Zuverlässigkeits- oder Ordnungsgarantie. Es gehört zu demselben Semantikrahmen, unterliegt aber nicht denselben Staukontrollauflagen wie RUD und ROD. Anwendungen müssen vermeiden, UUD den kontrollierten Verkehr zu belasten, wenn beide gemeinsam Queue oder Klassen nutzen.

Diese vier Modi verdeutlichen die zentrale UEC-Philosophie: Das Netzwerk muss mehrere Mechanismen bereitstellen, mit denen Software die Transportkosten an die jeweilige Operationssemantik anpasst. Der Vorteil ist Effizienz; der Preis ist eine größere Implementations- und Testoberfläche, inklusive mehr möglicher inkompatibler Funktionskombinationen zwischen Anbieter, Anwendung und Betreiber.

Packet Spraying: die Fabric nutzen statt auf eine glückliche Route zu hoffen

Konventionelles ECMP mit kostengleichen Pfaden hashte typischerweise den gesamten Flow und fixiert ihn auf eine Route. In einer großen Clos-Fabric kann das zu einem Glücksspiel werden. Mehrere große Flows kollidieren auf denselben Links, obwohl äquivalente Kapazität anderswo ungenutzt bleibt. Eine große KI-Übertragung kann über die gesamte Laufzeit durch eine ungünstige Routenentscheidung limitiert werden.

UET reagiert durch paketgenaue Änderung der Entropie. Ein Sender kann Dutzende oder Hunderte von Werten nutzen, sodass bestehende ECMP-Mechanismen in Switches Pakete über viele Wege verteilen. Die Packet Delivery Sublayer liefert Sequenzinformationen; der Congestion Management Sublayer wählt Entropie oder Pfad; Switches führen ihre normale Hash-Verarbeitung aus; und Rückmeldungen zeigen dem Sender, welche Entropiewerte zu Staus führen.

Packet Spraying ist nur praktikabel, weil andere Architekturbestandteile es unterstützen. Pakete können out-of-order ankommen. RUD kann Daten direkt ohne vollständige Transport-Reihenfolgeumordnung platzieren. Selektive Wiederholung holt nur die verlorenen Teile zurück. Staurückmeldung reduziert die Nutzung überlasteter Pfade. Damit ist es kein isolierter Load-Balancing-Trick, sondern Teil eines Transportmodells um die Pfadvielfalt.

UEC verlangt nicht, dass jeder Switch einen proprietären adaptiven Routing-Algorithmus ausführt. Basisimplementierungen können Round-Robin oder pseudozufällige Entropie mit Standard-ECMP verwenden. Fortgeschrittene Endpunkte können ECN, Latenz oder Trimming an konkreten Werten koppeln und belastete Wege vermeiden. Lieferantenspezifisches adaptives Routing kann mit UET koexistieren, ist aber nicht die einzige Routing-Wissensquelle.

Die Aussicht ist bessere Fabric-Nutzung und geringere Queue-Latenz. Offen bleibt, mit welcher Kohärenz die verschiedenen Endpunkte Feedback interpretieren und wie Spraying mit Puffern, Reordering, Ausfällen und gemischtem Verkehr interagiert. Ein in einem homogenen Labor wirksamer Algorithmus kann in einer großen Fabric mit mehreren Switch-Generationen und Verkehrsklassen anders reagieren. Unabhängige, multivendor-basierte Evidenz bleibt begrenzt.

Drei Stau-Mechanismen für drei verschiedene Engpässe

UEC definiert keinen einzelnen universellen Staualgorithmus. Es unterscheidet Stau im Netzkern, Incast am Empfänger und begrenzte Endpunkt-Buffer als separate Fälle.

Network-signal Congestion Control (NSCC) wird vom Sender gesteuert. Der Sender hält ein Staufenster, schätzt die Flugdaten im Transit und passt das Fenster über Acks, negative Acks, Timeouts, Latenz und Netzsignals wie ECN an. Es koordiniert das Fenster mit multipfadiger Übertragung auf Paketebene. UEC argumentiert, dass ein Fenster den Datendurchsatz natürlich stoppt, wenn Pakete das Netz nicht verlassen, während ein reiner Rate-Controller Feedback-Abwesenheit falsch interpretieren kann.

Dies ist ein architektonisches Argument des Konsortiums und kein unabhängiger Beweis dafür, dass jede NSCC-Implementierung RoCE-DCQCN generell übertrifft. Ergebnisse hängen von den Algorithmusdetails, Switch-Signalisierung, Topologie, Verkehrsprofilen und Parameterauswahl ab. „NSCC nutzen“ ist keine ausreichende Leistungsbehauptung.

Receiver-credit Congestion Control (RCCC) zielt auf Incast. Wenn viele Quellen gleichzeitig zu einem Ziel senden, kann der letzte Link zum Engpass werden, obwohl der Netzkern nicht gestaut ist. Der Empfänger verfolgt Nachfrage und verteilt Credits auf Sender, reguliert den aggregierten Eingang und variiert effektiv das Senderfenster je Quelle je nach Wettbewerb. RCCC kann mit NSCC parallel laufen, da Empfängerüberlastung und Kernstau verschiedene Fehlerdomänen sind.

Transport Flow Control (TFC) nutzt ebenfalls Credits, dient aber punkt-zu-punkt-Diensten mit begrenzten Puffern. Ziel ist, direktes Overflow im Empfängerpuffer zu vermeiden, wenn Verlusttoleranz gering ist. Es kann mit Multipath oder ohne genutzt werden. Alle Kreditmechanismen gleichzusetzen würde die unterschiedlichen Kontrolldomänen verwischen.

UEC erwartet Explicit Congestion Notification im gesamten Fabric und enthält Betriebsannahmen zur Signalisierung, darunter Markierung beim Dequeue statt allein auf Enqueue. Endpunkte interpretieren ECN zusammen mit Acks, Latenz und Trimming. Eine konsistente Switch-Konfiguration ist deshalb zentral. Eine korrekte Transportimplementierung kann in einer falsch konfigurierten Fabric trotzdem schlechte Ergebnisse liefern.

Die Änderungshistorie zeigt die Tiefe der Aufgabe. Version 1.0.1 korrigierte den NSCC-Quellalgorithmus im Receiver-Credit-Bereich. Version 1.0.2 korrigierte Fälle der Stauverwaltung. Version 1.0.3 korrigierte Wechselwirkungen zwischen Credits und Link Layer Retry. Das sind normale Signale für eine lebendige Spezifikation, zeigen aber auch, dass Credits, Wiederholung und Pfadkontrollzustand subtil interagieren. Betreiber benötigen Versionstransparenz und Regressionsprüfungen, nicht nur initiale Konformität.

Packet Trimming und gezielte Verlustwiederherstellung

Packet Trimming verändert, was ein Switch kann, wenn er kein vollständiges Paket halten kann. Statt den Frame ohne Zusatzinformationen zu verwerfen, verwirft er einen großen Teil oder den gesamten Payload, bewahrt Kopf- und Metadaten für die Paketidentifikation, markiert ihn als trimmed und leitet eine reduzierte Benachrichtigung zum Empfänger weiter. Der Empfänger kann dem Sender präzise melden, welche Daten fehlen.

Das ist informativer als ein ECN-Marker. ECN zeigt, dass Stau auftritt; Trimming kennzeichnet ein Paket, dessen Nutzdaten nicht überlebt haben. Zusammen mit RUD und selektiver Wiederholung kann die Wiederherstellung beschleunigt werden, ohne auf Timeout zu warten oder eine lange Sequenz wegen eines einzigen Verlusts vollständig neu zu senden.

Die Switchfunktion ist optional, doch konforme Endpunkte müssen Trimmed-Pakete nach den jeweils geltenden Regeln empfangen und interpretieren. Diese Asymmetrie ermöglicht den Einsatz von UET auf konventionellen Switches und zugleich reichere Verlustinformationen in verbesserten Fabrics. Sie schafft aber ein Updateproblem. Eine teilweise modernisierte Netzumgebung kann Trimming je nach Pfad, Profil oder Topologie einschränken müssen, damit alle Empfänger ihn korrekt verarbeiten.

UEC definiert außerdem unterschiedliche Verkehrsrichtungen für Requests, Kontrollpakete, Wiederholungen und Trimmed-Traffic. Betreiber müssen DSCP-Werte, Switch-Queues, Endpunkt-Warteschlangen und Prioritätsstufen konsistent abbilden. Das Dokument liefert kein universelles Managementsystem. Eine falsche Zuordnung kann Kontrollverkehr ohne Ressourcen lassen, Staurückmeldung verzerren oder Wiederherstellungspakete gegen zu reparierende Pakete konkurrieren lassen.

Packet Trimming zeigt ein größeres Implementierungsthema. Das Protokoll kann Verhalten auf der Leitung festlegen, doch das operative Ergebnis hängt von Switch-Queues, Endpoint-Logik, Telemetrie, Konfiguration und Störungsmanagement ab. Interoperabilität ist eine Eigenschaft des Gesamtsystems, nicht nur des Paketformats.

Link-Layer-Wiederholung, Credits und Funktionsverhandlung

Link Layer Retry (LLR) versucht, Fehler auf dem physikalischen Link zu beheben, bevor die End-to-End-Transporteingriffe reagieren. Ein Peer erkennt eine Sequenzunterbrechung oder einen beschädigten Frame, sendet ein negatives Ack auf Link-Layer-Ebene und lässt den Sender den betroffenen Frame aus lokalem Puffer erneut ausgeben. Bei schneller Wiederherstellung kann Transport eine langlaufende Wiederholung über das gesamte Netz vermeiden.

Das potenzielle Nutzen-Spektrum wächst mit Lane-Geschwindigkeit und Portdichte. Gelegentliche optische oder elektrische Fehler können in hochsynchronisierten Jobs zu unverhältnismäßigen Verzögerungen führen. LLR fügt jedoch Sequenzzustand, Replay-Puffer, Kontrollnachrichten, Verwerfungsfenster und neue Fehlermodi hinzu. Es muss mit Credit-Anpassungen und Link-Resets koexistieren. Version 1.0.3 korrigierte mehrere Grenzfälle, einschließlich einer Race-Bedingung zwischen CBFC-Credits und LLR.

Credit-Based Flow Control (CBFC) arbeitet linkweit über virtuelle Kanäle. Es teilt dem Sender mit, wie viel Empfangskapazität noch verfügbar ist, und kann granularere Kontrolle als breit angelegte Pausierung nach Priorität ersetzen. UEC beschreibt dies als Ansatz für kontrolliert verlustarme Betriebsweise ohne die Forderung, dass jeder UET-Einsatz vollständig verlustfrei sein muss. CBFC ist optional und UET ist so konfiguriert, dass es auch über best-effort-Netzen funktioniert.

CBFC darf nicht als anderes Wort für Priority Flow Control verwendet werden. Die Mechanismen unterscheiden sich in Signalisierung und Granularität, wenngleich beide Pufferüberläufe vermeiden wollen. CBFC erfordert weiterhin konsistente Konfiguration und korrekte Lieferung eigener Kontrollframes. Lokale Credits können mit end-to-end-Fenstern und Empfänger-Credits interagieren und mehrere verschachtelte Kontrollschleifen erzeugen.

UEC setzt LLDP-basierte Verhandlung ein, um optionale Link-Funktionen zu entdecken und zu verhindern, dass eine Seite eine Funktion aktiviert, die der Nachbar nicht unterstützt. Die Verhandlung muss Profile, virtuelle Kanäle, DSCP-Zuordnung, Prioritäten, Resets, Softwareupdates und partielle Kombinationen berücksichtigen. Version 1.0.3 fügte eine boolesche Verhandlungsfähigkeit hinzu und verstärkte damit die Notwendigkeit expliziter Einigung auf Link-Ebene.

Diese Optionen schaffen einen Pfad von Basis-Ethernet hin zu verbessertem Ethernet. Sie können jedoch in der Beschaffungsprache verborgen bleiben. Ein Switch kann UET korrekt weiterleiten, ohne Trimming, LLR oder CBFC zu beherrschen. Ein anderer Switch unterstützt diese Funktionen nur in bestimmten Versionen oder Portmodi. Ein belastbarer Deploymentsnachweis muss das exakte Funktionsset benennen, nicht nur den Konsortionsnamen.

Physische Signalisierung mit 100 und 200 Gigabit pro Lane

Die Physical-Ebene verankert UEC in der Hardware-Roadmap. Die initiale 1.0-Arbeit war auf 100 Gb/s pro Lane ausgelegt. Version 1.0.3 ergänzte Unterstützung für 200 Gb/s pro Lane. Diese Änderung passt die Spezifikation an eine Generation mit höherer Dichte von Links und Systemen an; sie ist jedoch eine Dokumentkapazität, kein Beleg, dass alle UEC-Produkte diese Geschwindigkeit sofort liefern.

UECs PHY-Arbeit behandelt auch Forward Error Correction, Korrekturquoten für korrigierbare und nicht korrigierbare Codewörter, Ordered Sets, Link-Quality-Berichte sowie die Interaktion zwischen physischen Fehlern und LLR. Diese Punkte sind relevant, weil Transportwiederherstellung davon abhängt, was die unteren Ebenen beobachten und melden können.

Mit steigenden Signalraten gewinnt die Grenze zwischen Optik, SerDes, FEC, lokaler Wiederholung und Transportwiederherstellung wirtschaftliche Bedeutung. Stärkerer FEC senkt Restfehler auf Kosten von Latenz und Energie. Link Retry kann lokale Korruption schneller beheben, verlangt aber Puffer und Zustand. End-to-End-Wiederholung über das Netz ist meist einfacher, kann aber mehr Zeit verbrauchen. UEC definiert, wie diese Ebenen kooperieren, statt jede Optimierung isoliert durch jede Hardwareklasse erfolgen zu lassen.

Die Einführung von 200G-Lanes zeigt zudem, dass sich das Konsortium weiter bewegt. Implementierer von 1.0 müssen Kompatibilität erhalten und gleichzeitig neue physische Fähigkeiten planen. Testsysteme, Firmware und Management müssen unterscheiden, was jeder Port unterstützt. Käufer sollten nicht aus einer generellen UEC-Behauptung auf Lane-Geschwindigkeit schließen.

Optionale End-to-End-Transport-Sicherheit

Die Transport Security Sublayer (TSS) bietet optionale Schutzmaßnahmen von Endpunkt zu Endpunkt. Ihr Bedrohungsmodell benötigt kein Vertrauen in Switches. Sie kann Vertraulichkeit, Integrität, Replay-Schutz, Job-Isolation, sichere Domänen, Gruppenschlüssel, Schlüsselrotation und Integration in Hardware-Root-of-Trust-Bausteine bereitstellen.

Das Design nutzt sichere Domänen, deren Mitglieder kryptografischen Kontext teilen. Kennzeichner, Association-Nummern, Epochen, sichere Herkunftsidentität und Schlüsselderschichtung sollen über das einfache Session-Modell für jedes Endpunktpaar hinaus skalieren. Das ist relevant, wenn Beschleunigerpopulationen und Job-Mitgliedschaften rasch wechseln.

Das Protokoll ist nur ein Teil des Sicherheitssystems. Ein Produktionsbetrieb braucht Key Authorities, Zertifikate oder andere Vertrauenstiefe, Job-Membership-Services, Verteilung und Widerruf, Epoch-Wechsel, Endpoint-Recovery, Hardware-Kryptographie und Sicherheits-Telemetrie. Ein Netz kann auf ein Profil abgestimmt werden, ohne alle optionalen TSS-Funktionen einzuschalten. „UEC konform“ bedeutet nicht automatisch „verschlüsselt“.

Die Option zeigt verschiedene Deployment-Modelle. Eine dedizierte, physisch geschlossene Fabric kann auf Leistung setzen und auf Umgebungsabgrenzung vertrauen. Eine multi-tenant-Cloud kann starke Isolation und kryptografische Absicherung benötigen. Profile und Beschaffung müssen diese Unterschiede deutlich machen.

Das schwerwiegendste Risiko ist nicht nur kryptografischer Overhead. Es ist der großskalierte Lebenszyklusfehler: veraltete Mitgliedschaften, verzögerter Widerruf, inkonsistente Epochen, Recovery nach ausgefallenen Endpunkten oder Unfähigkeit, zu belegen, welcher Job auf welchen Speicher zugreifen darf. Diese Punkte verbinden Transport-Sicherheit mit Orchestrierungs- und Identitätssystemen außerhalb des zentralen Spezifikationskerns.

Was «UEC compliant» derzeit bedeutet

UEC begann, Konformitätsmaterial für Version 1.0 zu veröffentlichen, aber das öffentliche System ist kein ausgereiftes Regime unabhängiger Zertifizierung. Das verfügbare Paket ist primär auf Selbstdeklaration ausgelegt. Die Matrizen ordnen Anforderungen den Profilen zu; die Testbed-Guides beschreiben empfohlene Endpoint- und Switch-Setups. Es wurde keine vollständige öffentliche Basis veröffentlicht, in der eine unabhängige Instanz Produkte nach einem integrierten UEC-Gesamtsprogramm als bestanden oder fehlgeschlagen registriert.

Die Unterscheidung ist entscheidend, weil unterschiedliche Aussagen kursieren. Ein Produkt kann rund um laufende UEC-Funktionen entworfen sein. Es kann ausgewählte Wire-Funktionen implementieren. Es kann ein Profil oder einen Teil davon in einer bestimmten Version unterstützen. Ein Anbieter kann Vollständigkeit der Funktionen ausweisen. Ein Labor kann UET-Verkehr über einen Switch erzeugen. Keine dieser Aussagen ist automatisch gleichbedeutend mit unabhängiger End-to-End-, Multivendor-Zertifizierung.

Die veröffentlichten Testbed-Empfehlungen sind nützlich, aber bewusst begrenzt. Sie liefern Topologien und Good-Practice-Checks statt vollständiger Systemqualifikation. Sie decken keine vollständige Breite von Interoperabilität, Leistung, Belastung, Skalierung und Lebenszyklus von APIs ab. Ebenso wenig zeigen sie Verhalten bei gemischtem UET- und RoCE-Verkehr, wiederholten Fehlern, großen Schlüsseldomänen oder maximalen Job-Populationen.

Die Inkonsistenz zwischen AI Full und AI Extended zeigt zusätzlich, warum versionierte Konformität entscheidend ist. Ein Käufer muss fragen, welche Spezifikation, welche Korrekturobjektstufe, welches Profil, welche optionalen Modi und welche Sicherheitsfunktionen eine Aussage abdeckt. Die Antwort sollte ausweisen, ob die Evidenz aus internen Tests, bilateraler Demonstration, Konsortiumsveranstaltung oder unabhängigem Labor stammt.

Ein plausibler nächster Schritt wäre öffentliche Testdefinitionen zu exakten Versionen, multivendor-basierte Plugfests und verwaltete Resultate inklusive negativer Ergebnisse sowie ein Register, das Endpoints, Switches, Software und Gesamtsysteme unterscheidet. Bis dahin ist «UEC compliant» eher eine Ausgangsfrage als eine vollständige Garantie.

Ein offenes Dokument mit RAND-Patentverpflichtungen

Die Ultra Ethernet Specification 1.0.3 ist öffentlich herunterladbar und unter Creative Commons Attribution-NoDerivatives 4.0 verfügbar. Die Lizenz erlaubt Weiterverbreitung mit Namensnennung, verbietet jedoch modifizierte Fassungen. Wichtiger ist: Urheberrechtlicher Zugang und Patentzugang sind getrennte Themen.

Die dokumentierten Charta-Muster der Arbeitsgruppen folgen im Allgemeinen einem klassischen Spezifikationsentwicklungsmodell mit lizenzierten Patenten zu fairen und nicht-diskriminierenden Bedingungen. RAND bedeutet nicht automatisch Royalty-free. Es garantiert keinen universellen Preis, verhindert keine Verhandlungen und schließt keine Streitfragen zu Gültigkeit, Essenzialität, regionaler Geltung oder defensiven Bedingungen aus. Die kommerzielle Position hängt von jedem deklarierten Patent, dem Engagement des Mitglieds und eventuell bilateral vereinbarten Lizenzen ab.

UEC führt ein öffentliches Register für Necessary-Claims. Im Untersuchungsstand waren dort Deklarationen u. a. zu Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google und Marvell sichtbar, einschließlich Angaben zu möglichen Arbeiten für 1.1. Das Register erhöht Transparenz, weil Implementierer vor dem Bau oder Vertrieb prüfen müssen, welche Eigentumsrechte bestehen.

Das Konsortium erklärt ausdrücklich, nicht zu beurteilen, ob ein Patent gültig, tatsächlich essentiell, verletzt oder zu einem konkreten Preis verfügbar ist. Es veröffentlicht auch keine gemeinsame Lizenz. Kleine Implementierer können dadurch rechtliche und transaktionale Kosten tragen, die große Mitglieder leichter abfedern. Eine frei verfügbare Spezifikation kann dennoch zu einem wirtschaftlich konzentrierten Ökosystem führen, wenn Patentbereinigung, Siliziumkosten und Testaufwand hoch bleiben.

Der IP-Rahmen formt auch Governance-Inzente. Unternehmen stellen Technologie teils ein, um einen breiten Markt für ihre Produkte zu schaffen, teils um sicherzustellen, dass vorhandene Fähigkeiten in ein gemeinsames Design eingehen. Patentdeklara-tionen verhindern nur Überraschungen, wenn sie früh genug und eindeutig sind. Sie beseitigen nicht die Möglichkeit, dass Lizenzkosten erst nach breiter Adaption zur Hürde werden.

Die präzise Beschreibung ist „offen veröffentlicht, multipartnerfähig und mit RAND-Verpflichtungen“, nicht „universell lizenzkostenfrei“. Beschaffungsteams brauchen sowohl das technische Profil als auch den Lizenzpfad.

Erste Produkt- und Testwelle

Die Implementierungsevidenz wurde mit Veröffentlichung von 1.0 sichtbar, die Beispiele liegen aber in unterschiedlichen Reifestufen.

AMD machte seine IA Pollara 400 im April 2025 kommerziell verfügbar und beschrieb sie als auf sich entwickelnde UEC-Funktionen ausgelegt. Pollara ist eine programmierbare Endpoint-Plattform und ein wichtiges Signal, dass der Transport in kommerzielle Hardware gelangte. Die Formulierung ist relevant: „für wachsende Funktionen entworfen“ entspricht nicht der Aussage einer unabhängigen Zertifizierung gegen alle Endanforderungen von 1.0.3.

Broadcom kündigte im Juni 2025 Tomahawk 6 als 102,4-Terabit-Switching-ASIC an und ergänzte im Oktober die NIC Thor Ultra 800G. Dabei wurde vollständige UEC-Funktionskonformität behauptet. Es ist eine bedeutende Herstelleraussage, aber öffentliche Evidenz macht daraus keine unabhängige Konsortiumszertifizierung. Stichprobenrate, Software-Reife und exakte Profilunterstützung müssen getrennt bewertet werden.

Nokia und Keysight kündigten im Oktober 2025 eine End-to-End-Demonstration von UET-Verkehr über Nokia 7220- und 7250-Familien mit 800-Gigabit-Ethernet an. Keysight lieferte Traffic-Generierung und Validierung. Der Test zeigt, dass UET auf kommerziellen Systemen transportiert werden kann und sich Test-Ökosysteme entwickeln. Er bildet jedoch kein vollständiges Profil unabhängigem Multivendor-Endpunkt-Einsatz, Produktionsskalierung oder umfassender Konsortiumszertifizierung ab.

Weitere Mitglieder beschrieben NICs, Systeme, Software oder Testpläne für UEC, und die Summit 2026 betonte Produktisierung. Die Evidenz stützt den Übergang in Richtung Implementierung. Sie erlaubt noch keinen genauen Zählung von UET-NICs in Volumen, zertifizierten Switches, ausgerollten Cloud-Regionen oder vollständigen Fabrics.

Die sinnvollste Lesart der Welle ist eine Beweiskette: Öffentliche Spezifikation ermöglicht Design. Silizium- und NIC-Ankündigungen zeigen Investitionen. Verkehrsdemos zeigen Teilinteroperabilität. Konformitätsmatrizen ordnen Anforderungen. Erprobungsberichte von Betreibern würden den operativen Nutzen belegen. Unabhängige Plugfests und Produktionsnachweise würden die breitere Glaubwürdigkeit liefern.

RoCE, InfiniBand, Slingshot und UALink

UEC tritt in einen Markt mit reifen Alternativen und angrenzenden Technologien. Das strategische Argument ist nicht, dass Ethernet nie RDMA transportiert hat oder dass spezialisierte Fabrics nicht funktionieren. Es ist, dass KI-Lasten heute so skaliert und synchronisiert sind, dass eine neue end-to-end-Ethernet-Architektur mit flexibler Zustellung, Pfadnutzung und Staukontrolle sinnvoll ist.

RoCEv2 ist der direkte Vorläufer und eine bedeutende bestehende Technologie. Sie trägt RDMA-Verkehr über geroutetes Ethernet und hat breite Anwendungs- und Produktstützung. UEC kritisiert typische RoCE-Deployments wegen fester Flow-Routing-Entscheidungen, Go-Back-N-Wiederholungen, Reorder im Empfänger, schwieriger DCQCN-Ausrichtung, Abhängigkeit von Priority Flow Control in vielen Designs und eingeschränkter Incast- oder Kollektivspitzenbewältigung. Es sind UEC-Positionen, keine Belege dafür, dass alle RoCE-Netze schlecht performen.

Der Vergleich bleibt dynamisch. Anbieter können adaptives Routing, Packet Spraying, bessere Staualgorithmen oder Funktionen ähnlich UEC in programmierbare NICs integrieren und RoCE kompatibel halten. AMDs Kommunikation zu Pollara etwa zeigt RoCEv2 und UEC RDMA als Optionen in derselben programmierbaren Hardware. UEC kann mit RoCE als kompletten Transport konkurrieren und zugleich die Weiterentwicklung künftiger RoCE-Produkte beeinflussen.

InfiniBand ist die Hauptalternative als spezialisierte Fabric. Sie bietet ein integriertes RDMA-Ökosystem mit langjähriger Erfahrung bei Stau, Zuverlässigkeit und Management. Die Arbeit 2.0 der InfiniBand Trade Association enthält physische XDR-Unterstützung bis 200 Gb/s pro Lane und aktualisierte Telemetrie. UECs zentrale Differenzierung besteht nicht darin zu behaupten, InfiniBand sei unterlegen, sondern darin, KI- und HPC-Verhalten über die breitere Ethernet-Kette mit Standard-IP-Routing und mehr Lieferantenwahl zu erreichen.

HPE Slingshot steht dazwischen. Es ist eine kommerzielle HPC-Fabric, Ethernet-kompatibel mit adaptivem Routing und Staukontrolle, und lieferte wichtige technische Vorläufer für UET. Es zeigt, dass spezialisierte Fähigkeiten auf Ethernet aufgebaut werden können, aber auch den Unterschied zwischen einer kontrollierten Plattform und einer industrieweiten Spezifikation.

UALink ist eher ergänzend als direkter Ersatz. Die aktuelle 200G-öffentliche Spezifikation adressiert Low-Latency-Scale-up-Konnektivität zwischen Beschleunigern innerhalb eines Pods und beschreibt bis zu 1.024 Beschleuniger. UEC 1.0 ist primär eine Scale-out-Fabric zwischen Knoten über Switches. Ein Rechenzentrum kann eine Scale-up-Verbindung im Pod und UEC zwischen Pods oder Knoten einsetzen. Künftige UEC-Arbeiten zu optimiertem Scale-up-Transport und In-Network-Kollektiven könnten die Grenze annähern oder Wettbewerb erzeugen.

NVIDIA Spectrum-X und proprietäre Beschleunigerfabrics liefern weitere Vergleichsmaßstäbe. Ein eng integrierter Stack kann Hardware, Software und Support schnell aufeinander abstimmen, erhöht aber Ökosystemabhängigkeit. UEC ersetzt einen Teil dieser Integration durch die Verheißung gemeinsamer Schnittstellen und Lieferantenwahl. Ob sich dieser Austausch rechnet, hängt von Leistung, Support, Patenten und operativer Gesamtökonomie ab, nicht von „offen“ als abstrakter Marke.

Das operative Problem ist größer als das Protokoll

Eine 573-seitige Spezifikation kann viele Anforderungen definieren, aber eine Produktionsfabric braucht weiterhin ein Betriebsmodell. UEC 1.0 lässt wesentliche Betriebsfelder um den normativen Kern herum offen. Betreiber müssen Profile, Verkehrsarten, ECN-Schwellen, Entropiesets, optionale Linkfunktionen, Schlüssel, Firmware, Telemetrie und Störungsregeln konsistent über Endpunkte und Switches konfigurieren.

Gemischter Verkehr verschärft das Problem. Eine Fabric kann UET, RoCE, TCP, Storage, Management und geordnete oder ungeordnete UET-Dienste transportieren. Die Queue-Zuordnung und Fairness zwischen Klassen werden nicht dadurch gelöst, dass jedes Protokoll korrekt implementiert ist. Ein Staualgorithmus kann isoliert funktionieren und im Wettbewerb mit einem zweiten Controller mit anderem Feedbackbild schlecht abschneiden.

Endpoint-Komplexität bleibt ein strukturelles Risiko. UET verlagert Multipath, direktes Platzieren, selektive Wiederholung, mehrere Zustellmodi, Fenster- und Credit-Kontrolle, Trimming, Sicherheit und beträchtlichen Zustand in den FEP. Das kann die Komplexität in der NIC steigern, das Firmware-Volumen erhöhen, den Verifikationsaufwand, den Energiebedarf und die Zahl zu diagnostizierenden Fehlerfälle. Endpoint-Intelligenz ermöglicht Multi-vendor-Kette, verankert aber Schwierigkeit in der je Maschine zugehörigen Komponente.

Optionale Funktionen schaffen Differenzierung und zugleich Fragmentierung. Ein Anbieter kann mit AI Base auf ECMP und Standard-ECN optimieren. Ein anderer kann AI Full, TSS, Trimming, LLR und CBFC unterstützen. Beide sind Teil des UEC-Ökosystems, aber Operatoren können nicht dieselbe Semantik, Leistung oder Sicherheit unterstellen. Konformitätsmatrizen müssen zu operativen Fähigkeitsmatrizen werden.

Versionswartung wird dauerhaft sein. Korrekturen von 1.0.1 bis 1.0.3 betrafen Stau, Credits, Retry und Paketverhalten. Große Cluster können mehrere NIC-Firmware-Versionen, Switch-Releases und Testwerkzeuge enthalten. Eine Lagen-Update ohne Koordination kann genau die übergreifende Fehlerkette freilegen, die das Konsortium zu vermeiden versucht.

Die externen Allianzen von UEC sind deswegen zentral und nicht nur repräsentativ. Open Compute Project verknüpft den Transport mit offenen Systemen und Hardware. OpenFabrics Alliance und die libfabric-Community verknüpfen Anwendungen. IEEE 802.3 liefert die formelle Ethernet-Arbeit. SNIA und NVM Express bringen Storage- und Managementanforderungen. IETF-Technologien liefern IP, ECN und verwandte Mechanismen. Diese Organisationen haben unterschiedliche Entscheidungsprozesse und Roadmaps; Liaison reduziert Doppelarbeit, garantiert aber keine synchronisierte Einführung.

Der letzte operative Prüfstein ist der Betrieb im Feld. Ein Dokument kann Verhalten vorgeben, ein Anbieter ein Produkt ankündigen und ein Konsortium eine Summit organisieren. Keines davon ersetzt einen Cluster, in dem unabhängige Endpunkte und Switches reale Jobs unter Stau, Ausfall und Updates vollständig abschließen und die Betreiber erklären können, was passiert ist.

Aktuelle Relevanz: Von der Spezifikationssieg zur Implementierungsglaubwürdigkeit

Im Juli 2026 hatte UEC mehrere Punkte erreicht, die bei der Vorstellung unklar waren. Es entstand eine breite Koalition, eine integrierte Fünf-Schichten-Architektur, eine vollständige 1.0-Spezifikation, fortlaufende Korrekturreleases, die Veröffentlichung von 200G pro Lane, die Bekanntgabe von Patentrechten und Produkt- sowie Testankündigungen. Das Projekt ist aktiv, und die Agenda ist klar in Richtung Implementierung gewandert.

Diese Fortschritte machen die verbleibenden Unsicherheiten wichtiger, nicht weniger. Die exakte aktuelle Mitgliederschaft und der Steering-Roster sind nicht in einem einzelnen autoritativen Register veröffentlicht. Öffentliche Mitgliedsseiten und Charta beschreiben den Zugang nicht identisch. Die formale TAC-Ausrichtung ist mit den Rollen aus der Summit nicht vollständig aufgelöst. Die Datumsangabe von 1.0.2 ist zwischen offiziellen Dokumenten widersprüchlich. Das Konformitätspaket nutzt teils veraltete Profilterminologie.

Kein Problem widerlegt die Architektur; jedes allein signalisiert aber etwas über Dokument- und Transparenzkontrolle in einem Projekt, in dem präzise Versionierung entscheidend ist.

Die gravierendsten Lücken betreffen die Adoption. UEC veröffentlicht kein Deployment-Census, keine vollständige Liste unabhängig verifizierter Produkte, kein eigenes Budget und keine auditierten Abschlüsse. Es gibt keine öffentliche Evidenz für eine UEC-1.0-fähige vollständig interoperable Netzwerkumgebung auf den maximalen Zielskalen des Konsortiums. Demonstrationen und Herstellerbehauptungen sind wertvoll, stammen aber meist von Interessengruppen mit eigenem kommerziellem Interesse. Neutrale Vergleiche mit aktuellem RoCE, InfiniBand und integrierten Ethernet-Plattformen bleiben begrenzt.

Die Chance bleibt groß. Ethernet ist der gemeinsame Nenner von Rechenzentren und der KI-Infrastrukturmarkt ist groß genug, um neue Generationen von NICs, Switches, Optik und Software zu tragen. Betreiber haben starke Anreize, Einzellanbieterabhängigkeit zu vermeiden und die Auslastung von Beschleunigern zu verbessern. Ein gemeinsamer Stack kann diese Anreize in reale Verhandlungsmacht umsetzen.

Das Risiko ist, dass „Ultra Ethernet“ zu einem Dachbegriff für inkompatible Untergruppen wird. Wenn Basistransport funktioniert, die Profile, die Stau- und Sicherheitssteuerung sowie das Management aber auseinanderlaufen, kann die Marke schneller wachsen als die Interoperabilität. Wenn RAND-Lizenzen teuer oder unklar bleiben, kann sich der Lieferantenkreis verengen. Wenn RoCE die attraktivsten Ideen übernimmt, ohne einen neuen Transport vollständig zu benötigen, kann UEC den Markt beeinflussen, ohne zur dominanten Marke zu werden.

Die entscheidende Frage ist nicht mehr, ob das Konsortium eine komplexe Spezifikation veröffentlichen kann – das hat es bereits getan. Entscheidend ist, ob unabhängige Organisationen dieselben Verträge umsetzen, notwendige Technologie lizenzieren, Fabrics im Maßstab betreiben und Kompatibilität während der Spezifikationsentwicklung erhalten können. UEC wird erst dann zu echter Infrastruktur, wenn diese Aussagen den Betrieb überstehen.