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

Zusammenfassung

• Das 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 ins Leben gerufen wurde. Es handelt sich um ein Industrie-Spezifikationskonsortium und nicht um ein herkömmliches Unternehmen oder einen Netzbetreiber.
• Der Umfang des UEC geht über eine schnellere Ethernet-Verbindung oder einen einfachen Ersatz für RoCE hinaus. Die 573-seitige Spezifikation 1.0.3 deckt die Software-, Transport-, Netzwerk-, Verbindungs- und physikalische Schicht ab, ergänzt durch Arbeiten zu Management, Speicher, Tests und Konformität.
• Ultra Ethernet Transport kombiniert mehrere Zustellungsmodi, paketbasiertes Multipathing, selektive Wiederholung, sender- und empfängergesteuerte Überlastkontrolle, ECN, optionale Pakettrunkierung, optionale lokale Wiederherstellung, optionale kreditbasierte Flusskontrolle und eine optionale Ende-zu-Ende-Transportsicherheit.
• Produkte und Demonstrationen von AMD, Broadcom, Nokia und Keysight zeigen, dass die Implementierung angelaufen ist, aber die öffentliche Konformität stützt sich noch weitgehend auf die Selbstauskunft der Anbieter, ohne ein umfassendes unabhängiges Zertifizierungsregister oder eine Bestandsaufnahme von groß angelegten Bereitstellungen.
• Die strategische Chance des UEC ergibt sich aus der installierten Ethernet-Basis und der Multi-Vendor-Lieferkette. Die Hauptrisiken sind die Komplexität der Endpunkte, die Fragmentierung durch optionale Funktionen, RAND-Patentverpflichtungen, die begrenzte Reife von Management und Tests sowie die Kluft zwischen der Veröffentlichung einer Spezifikation und der im Produktionsbetrieb nachgewiesenen Interoperabilität.

Warum KI das Netzwerk zu einem Teil des Computers gemacht hat

Das Ultra Ethernet Consortium entstand aus einem Wandel in der Wirtschaftlichkeit des Computings. In einem gewöhnlichen Unternehmensnetz muss die Fabric viele unabhängige Datenströme mit akzeptablem Durchsatz und akzeptabler Verfügbarkeit transportieren. In einem großen KI-Trainingssystem oder einem Hochleistungsrechner wird das Netz zu einem Bestandteil einer einzigen synchronisierten Berechnung. Tausende von Beschleunigern können während kollektiver Operationen Modellparameter, Gradienten oder wissenschaftliche Daten austauschen. Eine Phase kann blockiert bleiben, bis der langsamste Teilnehmer die benötigten Informationen erhalten hat.

Eine leichte Pfad-Ungleichverteilung, ein Überlastungsereignis oder ein Paketverlust können daher selbst dann teure Prozessoren untätig lassen, wenn die durchschnittliche Auslastung der Fabric zufriedenstellend erscheint.

Die Optimierungskriterien verschieben sich. Die aggregierte Bandbreite bleibt wichtig, reicht aber nicht mehr aus. Betreiber achten auch auf die Job-Abschlusszeit, die Tail-Latenz, Incast, die Wiederherstellung nach Verlust, die Verkehrsverteilung über parallele Pfade und den Zustandsaufwand, den die Endpunkte vorhalten müssen. Ein Netz, das die meisten Pakete schnell zustellt, aber einen kleinen Bruchteil verzögert, kann eine ganze kollektive Operation ausbremsen. Eine für herkömmlichen Verkehr akzeptable Wiederholungsmethode kann zu viel Zeit kosten, wenn nur ein einziges Paket in einer langen Nachricht fehlt.

Ein Fluss, der auf einen einzigen ECMP-Pfad fixiert ist, kann unterdurchschnittlich abschneiden, während an anderer Stelle in der Topologie noch Kapazität verfügbar ist.

Die Gründungsvision des UEC war, dass diese Probleme nicht durch eine einzelne Switch-Funktion oder einen einzigen Überlastalgorithmus gelöst werden können. Der Kommunikationspfad beginnt oberhalb des Netzwerks in den Softwarebibliotheken und der Anwendungssemantik. Er durchläuft Speicherregistrierung, entfernte Operationen, den Transportzustand, die Paketzustellung, die Überlastkontrolle, das IP-Routing, die Ethernet-Links, die Optik und die physikalische Signalisierung. Werden diese Schichten isoliert entworfen, kann eine lokale Optimierung den Engpass lediglich verschieben oder an anderer Stelle inkompatible Annahmen schaffen.

Die Antwort des UEC ist eine koordinierte Architektur. Sie behält Ethernet und IP bei, weil die Betreiber sie bereits kennen und eine riesige industrielle Lieferkette für Switches, Optiken, Kabel, Netzwerkbetriebssysteme, Telemetrie und Management existiert. Sie ersetzt oder erweitert die Teile, die das Konsortium für große KI- und HPC-Lasten als ungeeignet ansieht. Das Ergebnis ist nicht „gewöhnliches Ethernet mit neuem Logo“. Es ist der Versuch, ein vertrautes Netz mit einem spezialisierten Transport zu versehen, dessen Verhalten von der Software-API bis zum Pro-Lane-Durchsatz definiert ist.

Diese Unterscheidung erklärt die Bedeutung des UEC für die digitale Infrastruktur. Das Projekt besitzt weder Beschleuniger noch Fabriken, Rechenzentren oder Cloud-Regionen. Es definiert die Verträge, die seine Mitglieder und andere Implementierer in Netzwerkkarten, Switching-ASICs, Systeme, Treiber, Bibliotheken und Testgeräte einbauen können. Sein Einfluss wird erst dann real, wenn diese unabhängigen Produkte unter Ausfall-, Überlastungs-, Upgrade- und Multi-Vendor-Bedingungen korrekt Datenverkehr austauschen.

Was das UEC ist – und was es nicht ist

Ultra Ethernet Consortium ist der öffentliche Name eines formellen Projekts, dessen juristische Reihe als Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series bezeichnet wird. Diese Reihenstruktur bettet das Projekt in die Joint Development Foundation und damit in die Linux Foundation-Familie ein. Sie bietet den Teilnehmern einen bereits bestehenden Rahmen für Mitgliedschaft, Governance, geistiges Eigentum, Finanzierung und Außenbeziehungen, ohne dass eine eigenständige neue Gesellschaft gegründet werden muss.

Diese Struktur ist wichtig, denn das UEC wird oft ungenau als Unternehmen, Allianz oder Normungsgremium beschrieben. Es ist keine Handelsgesellschaft mit Aktionären, Kapital, Bewertung oder separaten hinterlegten Abschlüssen. Es verkauft keine Ethernet-Produkte, betreibt kein öffentliches Netz und besitzt nicht die von seinen Mitgliedern beworbene Hardware. Es handelt sich um ein Spezifikationsentwicklungskonsortium mit einem Rechts- und IP-Rahmen. Seine öffentlichen Dokumente sind dazu bestimmt, zu Implementierungsverträgen zwischen mehreren Unternehmen zu werden.

Das UEC ist auch nicht synonym mit Ultra Ethernet Transport. UET ist die Transportarchitektur im Kern der Spezifikation. Die Arbeiten des Konsortiums sind weiter gefasst: Software-Mapping auf libfabric, Nachrichten- und Paketsemantik, Netzwerkannahmen, Optionen der Sicherungsschicht, physikalische Anforderungen, Management, Ausrichtung am Speicher, Leistung und Debugging, Konformität und Tests. Das Projekt auf „ein neues RDMA-Protokoll“ zu reduzieren, würde genau die übergreifende Ambition verschleiern, die es gleichzeitig vielversprechend und anspruchsvoll macht.

Das UEC ist auch nicht die IEEE 802.3-Arbeitsgruppe. IEEE 802.3 entwickelt die wesentlichen Ethernet-MAC- und Phy-Normen nach einem eigenen formellen Verfahren. Das UEC ist von diesem Ökosystem abhängig und pflegt eine Verbindung zu ihm, ohne es zu ersetzen. Die gleiche Abgrenzung gilt für die IETF-Mechanismen, die UET zugrunde liegen, insbesondere IPv4, IPv6 und Explicit Congestion Notification; für das OpenFabrics-Ökosystem, das libfabric pflegt; und für Organisationen, die im Bereich Speicher, offene Hardware und Beschleunigerverbindungen tätig sind.

Die Projektwebsite hat eine Formulierung verwendet, die auf den Status einer internationalen Normungsorganisation hindeutet. Die sicherste und am besten belegte Beschreibung ist die einer internationalen Spezifikationsentwicklungsorganisation unter dem Dach der JDF. Es gibt keinen Beleg dafür, dass es der Internationalen Organisation für Normung angehört, dass seine Dokumente ISO-Normen sind oder eine ISO-Nummer tragen. Diese Nuance ist nicht kosmetisch: Sie hilft zu verstehen, woher die Autorität des Projekts stammt, wie die Teilnahme funktioniert und welche rechtlichen Verpflichtungen auf Implementierer zukommen können.

Das UEC muss daher nach seiner tatsächlichen Rolle beurteilt werden. Es koordiniert Wettbewerber und Betreiber um ein gemeinsames technisches Design. Es veröffentlicht Spezifikationen, verwaltet Arbeitsgruppen und Patentanmeldungen, entwickelt Konformitätsdokumente und pflegt Beziehungen zu benachbarten Organisationen. Doch keine Ankündigung allein macht ein Produkt interoperabel oder erzwingt die Marktakzeptanz.

Die Gründungskoalition aus neun Organisationen

Das Konsortium wurde am 19. Juli 2023 von neun Organisationen angekündigt, die auf unterschiedlichen Ebenen der KI- und HPC-Lieferkette angesiedelt sind: AMD, Arista Networks, Broadcom, Cisco, Eviden, damals mit Atos verbunden, Hewlett Packard Enterprise, Intel, Meta und Microsoft. Diese Vielfalt war von Anfang an ein strategischer Vorteil. Ein Transport, der ausschließlich von Switch-Anbietern konzipiert würde, liefe Gefahr, Anwendungs- und Endpunkt-Anforderungen zu vernachlässigen. Eine von Beschleunigerherstellern dominierte Architektur könnte eng auf ein einziges Ökosystem optimiert sein.

Ein ausschließlich von Cloud-Anbietern getriebenes Projekt würde möglicherweise nicht über das nötige Silizium-, Optik- und System-Know-how verfügen, um eine Architektur in Produkte umzusetzen.

AMD brachte Prozessoren, Beschleuniger und Endpunkt-Vernetzung ein. Arista und Cisco brachten großmaßstäbliches Ethernet-Switching und Betriebserfahrung mit. Broadcom steuerte Switching-ASICs, Netzwerkkarten und Hochgeschwindigkeits-SerDes bei. HPE und Eviden brachten HPC-Systeme und die Geschichte spezialisierter Verbindungen ein. Intel steuerte Prozessoren, Ethernet und Software bei. Meta und Microsoft vertraten Hyperscale-Betreiber, die direkt an einer besseren Auslastung großer KI-Cluster und einer geringeren Abhängigkeit von einem einzigen integrierten Anbieter interessiert sind.

Die Koalition vereinte auch konkurrierende Geschäftsinteressen. Ihre Mitglieder verkaufen Netzwerkkarten, ASICs, Systeme, Cloud-Kapazität, Optiken, Software und Support. Einige halten Patentportfolios, die für die Implementierung möglicherweise wesentlich sind. Einige profitieren von einer breiten Multi-Vendor-Norm, während sie gleichzeitig proprietäre Differenzierungsfunktionen monetarisieren können. Das Konsortium beseitigt den Wettbewerb also nicht.

Es schafft einen Raum, in dem Wettbewerber sich auf minimale Schnittstellen einigen, sich aber weiterhin durch Implementierungsqualität, Leistung, Integration und kommerzielle Bedingungen unterscheiden.

Die Slingshot-Verbindung von HPE liefert ein nützliches Beispiel für technische Herkunft. Slingshot ist eine Ethernet-kompatible HPC-Fabric mit adaptiven Routing-Funktionen und Überlastmanagement. Mit HPE verbundene Aussagen deuteten darauf hin, dass eine „HPC Ethernet“-Spezifikation zum UEC beigetragen wurde, und schätzten, dass ein Großteil von UET auf Slingshot-Transportideen beruht. Der genaue Prozentsatz wurde nicht unabhängig überprüft und sollte nicht als Konsortialbilanz dargestellt werden. Der breitere Punkt ist solide belegt: Das UEC hat nicht bei null angefangen.

Es schöpfte aus Produktionserfahrungen in HPC, Cloud, RDMA und Ethernet.

Diese Mischung aus Vorgängersystemen erklärt auch, warum das Wort „offen“ präzise definiert werden muss. Die ratifizierte Spezifikation ist öffentlich herunterladbar, und die Architektur zielt auf Multi-Vendor-Implementierungen. Aber das Projekt ist auch ein Ort, an dem Mitglieder vorhandenes Wissen, Patente und Produkt-Roadmaps einbringen. Die Offenheit des Dokuments beseitigt nicht die wirtschaftlichen und rechtlichen Bedingungen, die an die Technologie geknüpft sind.

Eine Rechtsreihe, die für die Zusammenarbeit unter Wettbewerbern ausgelegt ist

Das Modell der Joint Development Foundation verleiht dem UEC einen formalen Rahmen, ohne es zu einer herkömmlichen Betriebsgesellschaft zu machen. Das Projekt verfügt über eine eigene Identität, einen Tätigkeitsbereich, Mitgliedschaftskategorien, ein Steering Committee, Arbeitsgruppen und IP-Verpflichtungen. Die JDF-Hülle stellt die rechtliche und gemeinnützige Infrastruktur bereit und kann Vermögenswerte und Vereinbarungen des Projekts halten. Dieses Modell senkt die Kosten für die Gründung eines Konsortiums und bietet Wettbewerbern einen anerkannten Prozess für die Zusammenarbeit.

Das Steering Committee leitet das Projekt. Zu seinen dokumentierten Aufgaben gehören die Koordination der Arbeitsgruppen, die Genehmigung neuer Mitglieder, die Verwaltung von Vermögenswerten und Finanzen, die Ernennung oder Abberufung des Vorsitzenden, die Fortschrittsüberwachung sowie die Kontrolle über Veröffentlichungen und Marken des Projekts. Der Konsens wird bevorzugt. Falls dies scheitert, sieht die Satzung eine qualifizierte Dreiviertelmehrheit unter den anwesenheitsberechtigten Teilnehmern vor. Schriftliche Einsprüche können beim Vorsitzenden eingelegt werden.

Der erste Vorsitzende war Brad Booth von Meta. Die aktuelle Spezifikation 1.0.3 führt J Metz von AMD als Vorsitzenden, Barry Davis von HPE als stellvertretenden Vorsitzenden, Hugh Holbrook von Arista als Vorsitzenden des Technical Advisory Committee und Puneet Agarwal von Marvell als stellvertretenden TAC-Vorsitzenden auf. Paul Congdon wird als Herausgeber der Spezifikation genannt. Das Dokument benennt auch Leiter und Autoren für die Bereiche Physik, Verbindung, Transport und Software. Die Tagesordnung des Gipfels 2026 erwähnt weitere operative Leiter.

Diese Gipfelrollen ersetzen nicht notwendigerweise die formellen Titel der Spezifikation; die öffentlichen Dokumente liefern kein vollständiges aktuelles Organigramm.

Die Satzung erkennt drei Kategorien an: Steering, General und Contributor. Steering-Mitglieder wirken an der Governance mit und entsenden in der Regel einen Vertreter in das Steering Committee. General-Mitglieder können in allen technischen Gruppen arbeiten, haben aber keinen Sitz im Komitee. Contributor-Mitglieder beteiligen sich an ausgewählten Gruppen und haben kein Stimmrecht bei Supermajoritätsentscheidungen. Die öffentliche Mitgliedschaftsseite bewirbt die Stufen General und Contributor mit Jahresgebühren von 20.000 bzw. 5.000 US-Dollar zuzüglich der Linux Foundation-Mitgliedschaft.

Sie erklärt weder den Aufnahmeprozess noch die aktuelle Gebühr für die Steering-Stufe klar.

Dieser formale Machtunterschied ist wichtig. Eine breite Mitgliederbasis kann Fachwissen und Implementierungsreichweite bieten, aber die Governance ist nicht gleich verteilt. Große Unternehmen, die in der Lage sind, Steering-Positionen zu besetzen, Ingenieure für mehrere Gruppen abzustellen und Patent- und Produktprogramme zu unterhalten, haben praktisch mehr Einfluss als kleine Contributor-Mitglieder. Nichtmitglieder können die endgültige Spezifikation herunterladen, sehen aber nicht den gesamten Entwurfsprozess und nehmen nicht gleichberechtigt teil.

Interne Informationen gelten nicht als gewöhnliche Geschäftsgeheimnisse, aber die Mitglieder dürfen Entwürfe nicht ohne Genehmigung des zuständigen Komitees veröffentlichen. Diese Regel erleichtert die Diskussion unter Wettbewerbern, ohne dem Markt zu früh Richtungssignale zu geben. Sie verhindert auch, dass externe Beobachter verworfene Vorschläge, Abstimmungen, vorläufige Implementierungsbedenken oder die Verhandlungen erfahren, die zu optionalen Funktionen geführt haben. Die endgültige Spezifikation ist offen; der Weg dorthin ist es nur teilweise.

Vom Start mit vier Arbeitsgruppen zur 573-seitigen Spezifikation

Die erste öffentliche Struktur von 2023 basierte auf vier Arbeitsgruppen: Software, Transport, Verbindung und Physik. Diese Abfolge spiegelte den End-to-End-Anspruch des Projekts wider. Die Mitgliedschaft öffnete sich nicht wie eine uneingeschränkte öffentliche Mailingliste. Über 200 Organisationen hatten Interesse bekundet, und das Konsortium staffelte die Aufnahme, während es eine Schulung zu Prozessen und Kartellregeln vorschrieb. Diese Vorsicht war verständlich, da die Teilnehmer auf mehreren Märkten direkte Wettbewerber sind und gemeinsame Produkt- und Protokollanforderungen diskutieren.

Im Dezember 2023 gab das UEC an, rund 40 Unternehmen und über 300 Personen zu umfassen. Es hatte ein Technical Advisory Committee eingerichtet und seine Struktur auf acht Gruppen erweitert. Das TAC sollte die architektonische Kohärenz sicherstellen: Ein Transport durfte kein Switch-Verhalten, Signalisierungsverfahren oder eine API voraussetzen, die nicht von einer anderen Gruppe akzeptiert worden war. Im März 2024 meldete das Konsortium 55 Unternehmen und über 750 aktive Teilnehmer und veröffentlichte eine viel klarere Darstellung seiner geplanten Architektur.

Dieses März-Update stellte die Hauptideen vor, die später in die normative Spezifikation eingingen: libfabric als softwareorientierte API, Paketverteilung, flexible Reihenfolge, mehrere Zustellmodi, sender- und empfängerseitige Überlastkontrolle, ECN, Pakettrunkierung, Link Layer Retry, optionale kreditbasierte Flusskontrolle, Transportsicherheit und zukünftige kollektive Operationen im Netz. Es bestätigte auch, dass UET auf vorhandenen Ethernet-Switches laufen kann, wobei angereicherte Geräte zusätzliche Leistung bieten können.

Parallel dazu wuchs die institutionelle Reichweite. Das UEC meldete im Juli 2024 1.193 aktive Teilnehmer und im August 97 Mitgliedsorganisationen. Es handelt sich um datierte Zahlen, deren Definitionen nicht vollständig öffentlich sind. Sie dürfen nicht einfach mit späteren Ankündigungen addiert werden. 2025 gab das UEC den Zugang von 27 neuen Unternehmen an, aber Abgänge, Fusionen und sich überlappende Bezugszeiträume verhindern, daraus eine exakte aktuelle Gesamtzahl abzuleiten. Die Website weist selbst darauf hin, dass nicht alle Mitglieder angezeigt werden.

Die Version 1.0 der Ultra Ethernet Specification wurde am 11. Juni 2025 veröffentlicht. Von diesem Zeitpunkt an war das UEC nicht mehr nur eine Roadmap, sondern eine öffentliche Implementierungsreferenz. Version 1.0.1, veröffentlicht im September, korrigierte den Quellalgorithmus der empfängerkreditbasierten Überlastkontrolle sowie redaktionelle Probleme. Version 1.0.2 erschien im Januar 2026 und korrigierte Überlastalgorithmen, doch zwei offizielle Dokumente weichen zwischen dem 21. und 28. Januar voneinander ab. Diese Inkonsistenz sollte bewahrt und nicht stillschweigend aufgelöst werden.

Die am 16. Juli 2026 veröffentlichte Version 1.0.3 ist zum Recherchezeitpunkt die aktuelle Referenz. Sie umfasst 573 Seiten und fügt eine 200-Gbit/s-pro-Lane-Signalisierung sowie eine boolesche Aushandlungsfähigkeit hinzu. Die Versionshinweise benennen auch zwingende Korrekturen in Bezug auf Paketzustellung, Überlastkredite, Link Layer Retry und geordnete Kontrollsätze der physikalischen Schicht sowie Klarstellungen zu Transportsicherheit, atomaren Operationen und trunkierten Paketen.

Die Unterscheidung zwischen zwingender Korrektur und redaktioneller Klarstellung ist wesentlich: Einige Änderungen verändern das konforme Verhalten und machen daher eine Wartung der Implementierungen erforderlich.

Der Member Summit 2026 in Denver markierte einen zweiten Übergang. Sein Programm drehte sich um Bereitstellung, Produktisierung, Konformität, Management, Leistung, Debugging, Speicherintegration und Tests zwischen Switches und Endpunkten. Das Architekturdokument existiert; die Glaubwürdigkeit des Projekts hängt nun stärker davon ab, ob die Implementierer in der Lage sind, den Stack über Organisationsgrenzen hinweg zu bauen, zu qualifizieren, zu betreiben und upzugraden.

Eine Architektur über fünf funktionale Schichten

Die aktuelle Spezifikation verteilt Ultra Ethernet auf die Software-, Transport-, Netzwerk-, Verbindungs- und physikalische Schicht. Diese Aufteilung ist nützlich, aber der Wert des Projekts liegt in den Annahmen, die diese Schichten verbinden.

An der Spitze interagieren KI-Frameworks, MPI, SHMEM und kollektive Bibliotheken über OpenFabrics Interfaces, insbesondere libfabric. Die UET Semantic Services Sublayer übersetzt Anwendungsoperationen in Transporttransaktionen. Die Packet Delivery Sublayer entscheidet über Segmentierung, Reihenfolge, Bestätigungen und Wiederherstellung. Die Überlastkontrolle steuert die in die Fabric eingespeiste Datenmenge und deren Verteilung auf Pfade. Die optionale Transportsicherheit schützt den Punkt-zu-Punkt-Austausch. IPv4 oder IPv6 übernimmt die Netzwerkweiterleitung.

Ethernet stellt die Verbindung mit Trunkierung, Link Layer Retry, kreditbasierter Flusskontrolle und optionaler Funktionsaushandlung bereit. Die physikalische Schicht spezifiziert Statistiken und Signalisierung mit 100 oder 200 Gbit/s pro Lane.

Diese Struktur bewahrt wesentliche Elemente des bestehenden Netzwerks. Das UEC definiert keinen Ersatz für IP-Routing. Es erwartet von Switches, dass sie herkömmliches ECMP und ECN bereitstellen. Ein Großteil der Intelligenz verbleibt in den Fabric-Endpunkten, die Entropie handhaben, den Transportzustand halten, Daten platzieren und auf Überlastsignale reagieren. Angereicherte Switches können Funktionen hinzufügen, aber das Modell zwingt nicht dazu, die gesamte Fabric auszutauschen, bevor UET transportiert wird.

Dies schafft einen Migrationsvorteil und ein Klassifizierungsproblem. Ein Deployment kann UET-Endpunkte auf herkömmlichem Ethernet mit ECMP und ECN nutzen. Ein anderes kann Trunkierung, Link-Wiederherstellung, Credits pro virtuellem Kanal, fortschrittliche Telemetrie und künftige In-Network-Operationen hinzufügen. Beide können als Ultra Ethernet bezeichnet werden, obwohl sie sich in Leistung, Wiederherstellungsverhalten und betrieblicher Komplexität erheblich unterscheiden.

Der Fünf-Schichten-Ansatz macht es auch schwieriger, Fehler einzugrenzen. Ein schlechtes Ergebnis kann vom Anwendungs-Mapping, der Zustandsmaschine des Endpunkts, den Überlastparametern, der Warteschlangenkonfiguration, dem DSCP-Mapping, der Optik, der Firmware oder dem Sicherheitssystem herrühren. Pakete durchzuleiten genügt nicht. Das System muss die erwartete Semantik und Leistung im großen Maßstab, bei Mischverkehr, während Ausfällen und bei Versionswechseln aufrechterhalten.

Der Softwarevertrag: libfabric statt einer proprietären Anwendungs-API

Das UEC wählt libfabric 2.0 als referenzielle Nord-API für konforme Endpunkte. Diese Entscheidung bindet das Projekt an ein bestehendes Software-Ökosystem aus HPC und fortschrittlichen Netzwerken, anstatt von jedem Framework die Einführung einer neuen proprietären Schnittstelle zu verlangen. Libfabric repräsentiert bereits Fabrics, Domänen, Endpunkte, Completion Queues, Event Queues, Adressvektoren, Speicherregionen, Nachrichten, Remote Memory Operations und atomare Operationen. Das UEC mapped und beschränkt diese Konzepte, damit Anbieter die Aufrufe in UET-Verhalten übersetzen können.

Der strategische Wert liegt in der Kontinuität oberhalb des Transports. MPI, SHMEM und Beschleunigerkommunikationsbibliotheken können vertraute Abstraktionen beibehalten, auch wenn der zugrunde liegende Anbieter wechselt. Prinzipiell kann eine Anwendung eine Operation anfordern, ohne zu wissen, welche Netzwerkkartenmarke die Zustellung übernimmt oder welches Silizium die Pakete vermittelt. Dies ist einer der Hauptmechanismen, durch die ein gemeinsamer Transport echte Anbieterwahl schaffen könnte.

Die Abstraktion garantiert keine gleichwertigen Implementierungen. Anbieter können unterschiedliche Injektionsgrößen, Scatter-Gather-Grenzen, Endpunktanzahlen, atomare Operationen, Speicherregistrierungstechniken, Completion-Verhalten, Hardwarebeschleunigungen und Sicherheitsfunktionen bieten. Eine für dieselbe API kompilierte Bibliothek kann daher auf unterschiedliche Kapazitäts- oder Leistungsgrenzen stoßen. Softwareeinkauf und -qualifikation erfordern mehr als ein Häkchen bei „libfabric unterstützt“.

Die Softwareschicht trägt auch die Semantik von Jobs und Berechtigung. KI- und HPC-Systeme führen häufig viele Jobs auf einer gemeinsam genutzten Infrastruktur aus, jeden mit eigenen Prozessen, Speicherregionen und Sicherheitsgrenzen. Die Spezifikation muss festlegen, welcher Endpunkt zu welchem Job gehört, welche Puffer zugänglich sind, wie eine entfernte Operation gepaart wird und wie Abschluss- oder Fehlerinformationen an die Software zurückgelangen. Diese Entscheidungen bestimmen, ob das schnelle Netzwerk für Scheduler, Laufzeitumgebung und Anwendung wirklich nutzbar ist und nicht nur in einem Paket-Benchmark beeindruckt.

Das Projekt ist vom OpenFabrics-Ökosystem abhängig, da es libfabric nicht besitzt. Diese Beziehung veranschaulicht ein allgemeineres Merkmal: Die UEC-Architektur setzt sich aus Komponenten zusammen, die an anderer Stelle verwaltet werden. Das UEC kann definieren, wie sein Transport auf libfabric abgebildet wird, muss sich jedoch mit den Maintainern und Nutzern der API abstimmen. Vergleichbare Abhängigkeiten bestehen zu IEEE Ethernet, IETF-Mechanismen, Speicherorganisationen und den Betriebssystemen der Anbieter.

Fabric-Endpunkte und Lastprofile

Ein Fabric Endpoint, kurz FEP, ist der logische Punkt, an dem UET terminiert. Er verbindet eine Betriebssysteminstanz mit einer oder mehreren isolierten Fabrics und kann einen User-Space-Provider, einen Kernel-Treiber, einen Transport auf einer Netzwerkkarte oder einem Beschleuniger, ein Speicherregistrierungssystem, einen Sicherheitskontext, Completion Queues, Adressvektoren und den für Zustellung und Überlastkontrolle erforderlichen Zustand umfassen.

Dieses endpunktzentrierte Design ermöglicht es, dass Switches hauptsächlich erkennbare Ethernet- und IP-Geräte bleiben. Der FEP wählt Entropiewerte, hält Paket- und Überlastzustand, platziert Daten im erlaubten Speicher und interpretiert Bestätigungen, Trunkierung und andere Rückmeldungen. Dies kann die Abhängigkeit von proprietärer Routing-Intelligenz im Switch verringern. Es konzentriert die Komplexität auch im Silizium der Netzwerkkarte, ihrer Firmware, den Treibern und der Software.

Das UEC definiert drei Implementierungsprofile: AI Base, AI Full und HPC. Es sind nicht drei verschiedene Netzwerke, sondern Sätze zwingender Funktionen. AI Base zielt auf gängige KI-Kommunikation mit geringeren Kosten und weniger Zustand. AI Full fügt unter anderem aufschiebbare Sendeoperationen, exaktes Matching und bestimmte atomare Lese- oder Vergleichsoperationen hinzu. Das HPC-Profil übernimmt die meisten AI-Full-Fähigkeiten, schließt aufschiebbares Senden aus und legt stärkeren Wert auf Reihenfolge, kleine Nachrichten und HPC-Semantik.

Das Profilsystem soll vermeiden, dass jedes Produkt den maximalen Satz implementieren muss. Es erkennt an, dass eine KI-Karte mit hohem Volumen den kollektiven Austausch bevorzugen könnte, während ein HPC-Endpunkt eine stärkere Ordnung und mehr atomare Operationen erfordern könnte. Die Profile beseitigen jedoch nicht die Optionen. Ein Produkt kann innerhalb eines Profils optionale Funktionen implementieren, und zwei Produkte mit demselben Label können sich dennoch in Sicherheit, Link-Verbesserungen, Kapazität und Leistung unterscheiden.

Die Terminologie ist bereits ein Warnsignal. Die maßgebliche Spezifikation 1.0.3 verwendet AI Base, AI Full und HPC. Ein Konformitätsdokument von 2025 verwendet AI Base, AI Extended und HPC. Die solideste Interpretation ist, dass „AI Full“ die aktuelle Bezeichnung ist und das Konformitätsdokument veraltet oder inkonsistent ist. Solange das Testpaket nicht korrigiert ist, müssen Anbieter und Käufer die Spezifikationsversion und das genaue Vokabular hinter jeder Behauptung ermitteln.

Vom Anwendungszweck zur Paketzustellung

In UET transportiert die Semantic Services Sublayer die Anwendungsabsicht. Sie definiert Nachrichtenidentität, Pufferadressierung, Operationen mit oder ohne Tag, Remote Memory Access, atomare Operationen, Completion-Verhalten, Job-Identifikatoren, Pufferberechtigung, Antworten und Fehler. Die Packet Delivery Sublayer legt dann fest, wie diese Absicht zu Paketen wird und wie diese den anderen Endpunkt erreichen.

Für zuverlässige Modi etablieren die Endpunkte Packet Delivery Contexts (PDCs). Ein PDC enthält insbesondere Sequenznummern, Bestätigungen, Duplikaterkennung, den Ordnungsmodus, Überlastinformationen, den Zustand der Rückrichtung und die Verkehrsklasse. Ein PDC entspricht einem Zustellmodus und einer Verkehrsklasse, und zwischen denselben FEPs können mehrere PDCs bestehen.

Diese Menge an Zustand ist nicht nebensächlich. Große Cluster können eine sehr große Zahl von Kommunikationsbeziehungen erzeugen. Verlangt jede davon einen umfangreichen Zielzustand, werden Speicher und Suchaufwand zum limitierenden Faktor. Das UEC zwingt daher nicht alle Operationen in ein einziges Verbindungsmodell. Es definiert vier Dienste mit unterschiedlichen Verträgen.

Reliable Unordered Delivery, kurz RUD, garantiert eine genau-einmalige Zustellung an die Semantikschicht, während es eine ungeordnete Ankunft zulässt. Es unterstützt die paketbasierte Verteilung über mehrere Pfade, selektive Wiederholung, Duplikatbeseitigung und direkte Datenplatzierung. Da das Ziel Daten gemäß ihren Offsets platzieren kann, anstatt auf einen Transport-Wiederherstellungspuffer zu warten, kann eine lange kollektive Operation mehrere Pfade nutzen, ohne alle Pakete hinter einer einzigen fehlenden Einheit zu blockieren.

Reliable Ordered Delivery, kurz ROD, garantiert eine genau-einmalige Zustellung in Reihenfolge. Es nutzt einen einzigen Pfad und einen Entropiewert, verwirft Pakete außerhalb der Reihenfolge und setzt auf Go-Back-N-Wiederholung ab der ersten fehlenden Nummer. Dieses Modell wirkt weniger fortschrittlich als RUD, bewahrt aber die Semantik, die für Operationen mit strikter Ordnung erforderlich ist. Das UEC behandelt Reihenfolge als Anwendungsanforderung und nicht als Kostenfaktor, der allen Übertragungen auferlegt wird.

Reliable Unordered Delivery for Idempotent Operations, kurz RUDI, geht einen anderen Kompromiss ein. Es stellt mindestens einmal zu und erlaubt Duplikate, was den üblichen Sequenz- und Bestätigungszustand am Ziel reduziert. Es kann für bestimmte Remote-Memory-Verschiebungen geeignet sein, denen eine separate Barriere folgt. Es wird gefährlich, wenn es falsch angewendet wird: Die Paketschicht erkennt nicht, ob eine Operation idempotent ist. Die Software muss das wissen. RUDI für eine nicht idempotente Operation zu verwenden, kann den Anwendungszustand ungültig machen.

Unreliable Unordered Delivery, kurz UUD, stellt Best-Effort-Datagramme ohne übliche Zuverlässigkeits- oder Ordnungsgarantien bereit. Es gehört zum selben semantischen Rahmen, übernimmt aber nicht dieselben Anforderungen an die Überlastkontrolle wie RUD und ROD. Anwendungen müssen vermeiden, kontrollierten Verkehr zu beeinträchtigen, wenn UUD dieselben Warteschlangen oder Klassen teilt.

Diese vier Modi offenbaren eine zentrale Philosophie: Das Netzwerk muss mehrere Mechanismen bereitstellen, damit die Software die Transportkosten mit der Operationssemantik in Einklang bringen kann. Der Nutzen ist Effizienz. Der Preis ist eine größere Implementierungs- und Testfläche mit mehr möglichen inkompatiblen Kombinationen.

Pakete verteilen: die ganze Fabric nutzen statt einen glücklichen Pfad

Herkömmliches ECMP fixiert oft einen gesamten Fluss durch Hashing auf eine einzige Route. In einer großen Clos-Fabric entsteht eine Lotterie: Mehrere schwere Flüsse können auf denselben Links zusammentreffen, während an anderer Stelle gleichwertige Kapazität frei bleibt. Eine lange KI-Übertragung kann während ihrer gesamten Dauer durch diese unglückliche Wahl begrenzt sein.

UET verändert die Entropie auf Paketebene. Der Sender kann Dutzende oder Hunderte Werte nutzen, was den vorhandenen ECMP-Mechanismen die Möglichkeit gibt, Pakete über mehrere Pfade zu verteilen. Die Packet Delivery Sublayer stellt die Sequenz bereit, die Congestion Management Sublayer wählt Entropie oder Pfad, die Switches wenden ihr normales Hashing an, und die Rückmeldung zeigt dem Sender, welche Werte überlastet erscheinen.

Diese Verteilung ist nur praktikabel, weil die anderen Komponenten sie unterstützen. Pakete können ungeordnet ankommen. RUD kann Daten direkt platzieren, anstatt auf eine vollständige Wiederherstellung der Reihenfolge zu warten. Selektive Wiederholung stellt nur das Fehlende wieder her. Überlastsignale reduzieren die Nutzung schwieriger Pfade. Es handelt sich also nicht um einen einfachen Balancing-Trick, sondern um ein Transportmodell, das um Pfadvielfalt herum gebaut ist.

Das UEC verlangt nicht, dass jeder Switch einen proprietären adaptiven Routing-Algorithmus ausführt. Basisimplementierungen können eine pseudo-zufällige oder rotierende Auswahl auf Standard-ECMP verwenden. Fortgeschrittenere Endpunkte können ECN, Latenz oder Trunkierung mit bestimmten Entropiewerten verknüpfen und problematische Pfade meiden. Anbieterspezifisches adaptives Routing kann mit UET koexistieren, ist aber nicht die einzige Quelle für Pfadbewusstsein.

Das Versprechen ist eine bessere Auslastung und eine geringere Tail-Latenz. Die offene Frage ist, wie konsistent verschiedene Endpunkte die Rückmeldung interpretieren und wie die Verteilung mit Puffern, Unordnung, Ausfällen und Mischverkehr interagiert. Ein Algorithmus, der in einem homogenen Labor effektiv ist, kann sich in einer großen Fabric aus mehreren Switch-Generationen anders verhalten. Unabhängige, Multi-Vendor-Belege bleiben begrenzt.

Drei Überlastmechanismen für drei verschiedene Engpässe

Das UEC definiert keinen universellen Algorithmus. Es unterscheidet Überlast im Netzwerkkern, Incast am Empfänger und Puffergrenzen des Endpunkts.

Network-signal Congestion Control, kurz NSCC, ist quellgesteuert. Der Sender hält ein Congestion Window, schätzt die in-Flight-Bytes und passt dieses Fenster anhand von Bestätigungen, NACKs, Timeouts, Latenz und Netzsignalen wie ECN an. Es koordiniert das Fenster mit dem paketbasierten Multipathing. Das UEC argumentiert, dass ein Fenster auf natürliche Weise aufhört, Daten zuzulassen, wenn Pakete das Netz nicht mehr verlassen, während ein rein ratenbasierter Controller eine ausbleibende Rückmeldung falsch interpretieren kann.

Dies ist das architektonische Argument des Konsortiums, nicht ein unabhängiger Beleg, dass jede NSCC-Implementierung DCQCN oder andere RoCE-Überlastkontrollen übertrifft. Die Ergebnisse hängen von Algorithmen-Details, Switch-Markierung, Topologie, Verkehr und Parametern ab. „Nutzt NSCC“ ist daher keine ausreichende Leistungsbehauptung.

Receiver-credit Congestion Control, kurz RCCC, zielt auf Incast. Wenn viele Quellen gleichzeitig an ein Ziel senden, kann der letzte Link zum Engpass werden, während der Kern nicht überlastet ist. Der Empfänger verfolgt die Nachfrage, verteilt Credits, taktet die aggregierte Ankunft und passt das implizite Fenster jeder Quelle entsprechend der Konkurrenz an. RCCC kann mit NSCC zusammenarbeiten, da Empfängerüberlast und Kernüberlast verschieden sind.

Transport Flow Control, kurz TFC, verwendet ebenfalls Credits, jedoch für Punkt-zu-Punkt-Dienste mit kleinen Puffern und geringer Verlusttoleranz. Sein Ziel ist es, direktes Überlaufen zu verhindern. Es kann mit oder ohne Multipath eingesetzt werden. Alle Kreditmechanismen in einen Topf zu werfen, würde die unterschiedlichen Fehlerdomänen verschleiern, die sie kontrollieren.

Die Spezifikation erwartet ECN in der gesamten Fabric und legt betriebliche Annahmen zugrunde, insbesondere die Markierung am Ausgang und nicht nur am Eingang. Die Endpunkte interpretieren ECN zusammen mit Bestätigungen, Latenz und Trunkierung. Eine konsistente Konfiguration aller Switches ist daher unerlässlich. Ein Transport kann korrekt implementiert sein und in einer fehlkonfigurierten Fabric dennoch schlechte Ergebnisse liefern.

Die Wartungshistorie zeigt die Schwierigkeit. Version 1.0.1 korrigierte den RCCC-Quellalgorithmus. 1.0.2 korrigierte Fälle der Überlastbehandlung. 1.0.3 korrigierte Wechselwirkungen zwischen Credits und Link Layer Retry. Diese Korrekturen sind für eine lebende Spezifikation normal, belegen aber auch, dass Credits, Wiederholungen und Pfade subtil interagieren. Betreiber werden Versionsdisziplin und Regressionstests aufrechterhalten müssen, nicht nur anfängliche Konformität.

Pakettrunkierung und präzise Wiederherstellung nach Verlust

Trunkierung verändert, was ein fähiger Switch tut, wenn er nicht ein ganzes Paket halten kann. Statt den Rahmen ohne Information zu verwerfen, entfernt er die Nutzlast ganz oder teilweise, behält genug Header und Metadaten, um das Paket zu identifizieren, markiert es als trunkiert und sendet diese reduzierte Benachrichtigung an den Empfänger. Dieser kann dann dem Sender genau mitteilen, welche Daten fehlen.

Diese Information ist reichhaltiger als eine ECN-Markierung. ECN zeigt an, dass eine Überlast aufgetreten ist; Trunkierung identifiziert ein Paket, dessen Nutzlast nicht überlebt hat. Zusammen mit RUD und selektiver Wiederholung kann sie die Wiederherstellung beschleunigen, ohne auf einen Timeout zu warten oder eine lange Sequenz wegen eines einzigen Verlusts erneut zu senden.

Die Switching-Funktion ist optional, aber konforme Endpunkte müssen trunkierte Pakete gemäß den anwendbaren Anforderungen empfangen und interpretieren. Diese Asymmetrie ermöglicht den Einsatz auf herkömmlichen Switches und gibt angereicherten Fabrics zugleich ein präziseres Feedback. Sie schafft auch ein Upgrade-Problem. Ein teilweise modernisiertes Netz muss die Trunkierung möglicherweise auf Pfade, Profile oder Topologien beschränken, damit alle Empfänger sie verstehen.

Das UEC definiert außerdem differenzierte Klassen für Anfragen, Kontrollpakete, Wiederholungen und trunkierten Verkehr. Betreiber müssen DSCP-Werte, Warteschlangen von Switches und Endpunkten sowie Prioritätsstufen konsistent abbilden. Die Spezifikation stellt kein universelles System zur Verwaltung dieser Zuordnung bereit. Ein Fehler kann Kontrollverkehr aushungern, das Überlastfeedback verfälschen oder Wiederherstellungspakete mit den Flüssen konkurrieren lassen, die sie reparieren sollen.

Die Trunkierung veranschaulicht die globale Herausforderung des Projekts. Das Protokoll kann das On-Wire-Verhalten definieren, aber das Ergebnis hängt von Warteschlangen, Abschlusslogik, Telemetrie, Konfiguration und Fehlerbehandlung ab. Interoperabilität ist eine Systemeigenschaft, nicht nur ein Paketformat.

Link-Wiederherstellung, Credits und Funktionsaushandlung

Link Layer Retry, kurz LLR, versucht, eine Beschädigung auf einer physikalischen Verbindung zu beheben, bevor der Ende-zu-Ende-Transport reagiert. Ein Peer erkennt eine Sequenzunterbrechung oder einen beschädigten Rahmen, sendet ein Link-NACK und veranlasst das erneute Lesen des Rahmens aus einem lokalen Puffer. Ist die Wiederherstellung schnell erfolgreich, kann der Transport eine längere Neutransmission vermeiden.

Der potenzielle Wert steigt mit dem Pro-Lane-Durchsatz und der Portdichte. Gelegentliche optische oder elektrische Fehler könnten sonst eine unverhältnismäßige Verzögerung in einem synchronisierten Job verursachen. LLR fügt jedoch Sequenzstatus, Wiederholungspuffer, Kontrollnachrichten, Verwerfungsfenster und neue Fehlermodi hinzu. Es muss auch mit Credit-Updates und Resets koexistieren. Version 1.0.3 korrigierte mehrere Grenzfälle, darunter eine Race Condition zwischen CBFC- und LLR-Informationen.

Credit-Based Flow Control, kurz CBFC, arbeitet auf Link-Ebene pro virtuellem Kanal. Es zeigt dem Sender die verbleibende Empfangskapazität an und kann eine feinere Steuerung als Priority-Pause bieten. Das UEC stellt es als Mittel dar, ein kontrolliertes verlustfreies Verhalten zu schaffen, ohne dass alle UET-Deployments global lossless sein müssen. CBFC ist optional, und UET muss auf Best-Effort-Netzen funktionieren.

CBFC ist kein anderer Name für Priority Flow Control. Die Mechanismen unterscheiden sich in Signalisierung und Granularität, auch wenn beide ein Überlaufen verhindern wollen. CBFC erfordert dennoch eine konsistente Konfiguration und die korrekte Zustellung seiner eigenen Kontrollrahmen. Lokale Credits können mit Ende-zu-Ende-Fenstern und Empfänger-Credits interagieren und mehrere verschachtelte Regelschleifen erzeugen.

Das UEC verwendet eine LLDP-basierte Aushandlung, um optionale Funktionen zu erkennen und zu verhindern, dass eine Seite eine Fähigkeit aktiviert, die der Nachbar nicht besitzt. Die Aushandlung muss Profile, virtuelle Kanäle, DSCP- und Prioritätszuordnungen, Resets, Upgrades und teilweise Kombinationen berücksichtigen. Version 1.0.3 fügte eine boolesche Aushandlungsfähigkeit hinzu und unterstrich die Bedeutung einer expliziten Einigung auf jedem Link.

Diese Optionen schaffen einen Pfad vom Basis-Ethernet zu einer angereicherten Fabric, aber auch eine Matrix, die Marketingsprache verschleiern kann. Ein Switch kann UET korrekt transportieren ohne Trunkierung, LLR oder CBFC. Ein anderer kann sie nur in bestimmten Versionen oder Port-Modi unterstützen. Eine glaubwürdige Bereitstellungsdokumentation muss daher den genauen Funktionsumfang beschreiben, nicht nur den Konsortialnamen nennen.

Physikalische Signalisierung mit 100 und 200 Gigabit pro Lane

Die physikalische Schicht verankert das UEC in der Hardware-Roadmap. Die ursprüngliche 1.0-Arbeit konzentrierte sich auf 100 Gbit/s pro Lane. Version 1.0.3 fügte 200 Gbit/s pro Lane hinzu. Diese Entwicklung bringt die Spezifikation mit einer neuen Generation dichterer Verbindungen in Einklang, beweist aber nicht, dass alle UEC-Produkte diese Rate sofort unterstützen.

Die PHY-Arbeiten decken auch Fehlerkorrekturstatistiken, Raten korrigierbarer und nicht korrigierbarer Codeworte, geordnete Kontrollsätze, Link-Quality-Reporting und die Interaktion zwischen physikalischen Fehlern und LLR ab. Diese Details sind wichtig, weil Wiederherstellungsentscheidungen davon abhängen, was die unteren Schichten beobachten und melden können.

Bei höheren Raten wird die Grenze zwischen Optiken, SerDes, FEC, lokaler Wiederherstellung und Transport-Neutransmission wirtschaftlich bedeutsam. Eine stärkere FEC kann Restfehler auf Kosten von Latenz und Energie reduzieren. LLR kann eine lokale Beschädigung schneller beheben, erfordert jedoch Puffer und Zustand. Ende-zu-Ende-Wiederherstellung ist im Netz einfacher, kann aber mehr Zeit verschwenden. Das UEC versucht, die Zusammenarbeit zwischen diesen Schichten zu definieren, anstatt jeden Anbieter allein optimieren zu lassen.

Die Hinzufügung von 200G-Lanes zeigt auch, dass das Ziel in Bewegung ist. 1.0-Implementierer müssen die Kompatibilität wahren und gleichzeitig neue physikalische Fähigkeiten vorbereiten. Testgeräte, Firmware und Managementsysteme müssen unterscheiden, was auf jedem Port unterstützt wird. Käufer sollten die Lane-Rate nicht aus einer allgemeinen UEC-Behauptung ableiten.

Optionale Ende-zu-Ende-Transportsicherheit

Die Transport Security Sublayer, kurz TSS, bietet optionalen Schutz zwischen Endpunkten. Ihr Bedrohungsmodell setzt keine vertrauenswürdigen Switches voraus. Sie kann Vertraulichkeit, Integrität, Replay-Schutz, Job-Isolation, sichere Domänen, Gruppenschlüssel, Schlüsselrotation und Integration mit Hardware-Vertrauensankern bieten.

Das Design verwendet sichere Domänen, deren Mitglieder einen kryptographischen Kontext teilen. Identifikatoren, Assoziationsnummern, Epochen, sichere Quellidentitäten und Ableitungsmechanismen sollen eine Skalierung über eine unabhängige Sitzung für jedes Endpunktpaar hinaus ermöglichen. Dies ist nötig, wenn sich Beschleunigerbestände und Job-Zugehörigkeiten schnell ändern.

Das Protokoll ist nur ein Teil des Sicherheitssystems. Ein Betreiber muss Schlüsselbehörden, Zertifikate oder andere Vertrauensanker, Job-Mitgliedschaft, Verteilung und Widerruf, Epochenwechsel, Endpunkt-Wiederherstellung, Hardware-Kryptographie und Telemetrie verwalten. Ein Netz kann einem Profil entsprechen, ohne jede TSS-Funktion zu aktivieren. „UEC-konform“ bedeutet daher nicht automatisch verschlüsselt.

Der optionale Charakter spiegelt unterschiedliche Einsatzannahmen wider. Eine dedizierte, physisch kontrollierte Fabric kann Leistung priorisieren und sich auf Umgebungskontrollen stützen. Eine Multi-Tenant-Cloud kann starke Isolation und kryptographischen Schutz erfordern. Profile und Beschaffungsprozess müssen diesen Unterschied sichtbar machen.

Das schwerwiegendste Risiko sind nicht nur die Verschlüsselungskosten. Es betrifft Ausfälle im großen Lebenszyklus: veraltete Mitgliedschaft, verspäteter Widerruf, inkonsistente Epochen, Wiederherstellung nach Ausfall oder die Unfähigkeit zu beweisen, welcher Job auf welchen Speicher zugreifen darf. Diese Probleme verknüpfen die Transportsicherheit mit Orchestrierungs- und Identitätssystemen außerhalb des Spezifikationskerns.

Was „UEC-konform“ heute bedeutet

Das UEC hat mit der Version 1.0 begonnen, Konformitätsdokumente zu veröffentlichen, aber das öffentliche System stellt noch kein ausgereiftes unabhängiges Zertifizierungsregime dar. Das verfügbare Paket ist hauptsächlich für die Selbstauskunft der Implementierer ausgelegt. Matrizen verknüpfen Anforderungen mit Profilen, und Prüfstandempfehlungen beschreiben Endpunkt- und Switch-Konfigurationen. Es wurde kein vollständiges öffentliches Register identifiziert, in dem eine unabhängige Stelle Erfolge und Misserfolge von Produkten festhält, die einem umfassenden UEC-Programm unterzogen wurden.

Die Unterscheidung ist wesentlich, denn mehrere Arten von Behauptungen kursieren. Ein Produkt kann um in Entwicklung befindliche UEC-Funktionen herum entworfen worden sein. Es kann bestimmtes On-Wire-Verhalten implementieren. Es kann ein Profil oder einen Teil eines Profils in einer bestimmten Softwareversion unterstützen. Ein Anbieter kann vollständige Konformität beanspruchen. Ein Labor kann UET-Verkehr durch einen Switch erzeugen. Keine dieser Aussagen ist automatisch gleichbedeutend mit einer unabhängigen, Multi-Vendor- und Ende-zu-Ende-Zertifizierung.

Die Prüfstandempfehlungen sind nützlich, aber bewusst begrenzt. Sie liefern Topologien und Best-Practice-Prüfungen, aber keine vollständige Systemqualifikation. Sie schließen die allgemeine Interoperabilität, Leistung, Stress, Skalierung und den API-Lebenszyklus aus oder decken sie nicht vollständig ab. Sie belegen nicht das Verhalten bei UET/RoCE-Mischverkehr, während teilweiser Upgrades, wiederholter Ausfälle, in großen Schlüsseldomänen oder bei den ambitioniertesten Endpunktzahlen.

Die Inkonsistenz zwischen AI Full und AI Extended zeigt auch, warum Konformität streng versioniert sein muss. Ein Käufer muss fragen, welche Spezifikation, welcher Korrekturstand, welches Profil, welche optionalen Funktionen, welche Link-Modi und welche Sicherheitsfunktionen abgedeckt sind. Er muss auch wissen, ob der Nachweis aus einem internen Test, einer bilateralen Demonstration, einer Konsortialveranstaltung oder einem unabhängigen Labor stammt.

Der nächste glaubwürdige Schritt wäre ein Satz öffentlicher Tests, die an exakte Versionen gebunden sind, Multi-Vendor-Plugfests, unabhängig administrierte Ergebnisse einschließlich Fehlschlägen und ein Register, das Endpunkte, Switches, Software und vollständige Systeme unterscheidet. Bis dahin muss „UEC-konform“ der Beginn der Prüfung sein, nicht ihr Ende.

Ein offenes Dokument mit RAND-Patentverpflichtungen

Die Spezifikation 1.0.3 ist öffentlich herunterladbar und wird unter der Creative Commons Attribution-NoDerivatives 4.0-Lizenz vertrieben. Diese Lizenz erlaubt die Weiterverbreitung mit Namensnennung, aber nicht die Weitergabe modifizierter Versionen. Vor allem sind Urheberrechtszugang und Patentzugang zwei getrennte Fragen.

Die Arbeitsgruppensatzungen verwenden üblicherweise ein traditionelles Modell auf der Grundlage fairer, angemessener und nichtdiskriminierender Patentlizenzen (RAND). RAND bedeutet nicht notwendigerweise kostenlos. Der Begriff garantiert keinen Einheitspreis, beseitigt keine Verhandlungen und verhindert keine Streitigkeiten über Gültigkeit, Wesentlichkeit, Geographie oder defensive Bedingungen. Die kommerzielle Position hängt von jedem deklarierten Patent, der Verpflichtung des Mitglieds und etwaigen bilateralen Lizenzen ab.

Das UEC führt ein öffentliches Register über Erklärungen zu Necessary Claims. Zum Recherchezeitpunkt waren Erklärungen unter anderem von Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google und Marvell sichtbar, einschließlich Einreichungen im Zusammenhang mit künftigen 1.1-Arbeiten. Das Register erhöht die Transparenz, indem es signalisiert, dass Implementierer möglicherweise das geistige Eigentum prüfen müssen, bevor sie ein Produkt bauen oder verkaufen.

Das Konsortium stellt nicht fest, ob ein deklariertes Patent gültig, wirklich wesentlich, verletzt oder zu einem bestimmten Preis verfügbar ist. Es veröffentlicht auch keine gemeinsame Lizenz. Kleinere Implementierer können daher Rechts- und Transaktionskosten tragen, die große Mitglieder leichter absorbieren. Eine öffentliche Spezifikation kann dennoch zu einem konzentrierten Markt führen, wenn Patentklärung, Siliziumkosten und Tests hoch sind.

Der IP-Rahmen beeinflusst auch die Governance-Anreize. Unternehmen bringen Technologie ein, um den Markt für ihre Produkte zu erweitern und ihre bestehenden Fähigkeiten im gemeinsamen Design vertreten zu sehen. Patentanmeldungen verringern Überraschungen nur, wenn sie frühzeitig und hinreichend klar sind. Sie beseitigen nicht das Risiko, dass Lizenzen nach der Übernahme der Architektur zu einer Barriere werden.

Die ehrliche Beschreibung lautet daher „offen veröffentlichte Multi-Vendor-Spezifikation mit RAND-Patentverpflichtungen“ und nicht „universell lizenzgebührenfrei“. Käufer benötigen sowohl das technische Profil als auch einen Lizenzpfad.

Die erste Welle von Produkten und Tests

Implementierungsbelege wurden rund um Version 1.0 sichtbar, entsprechen jedoch unterschiedlichen Reifegraden.

AMD stellte seine Pollara 400 AI-Karte im April 2025 zur Verfügung und beschrieb sie als rund um in Entwicklung befindliche UEC-Fähigkeiten konzipiert. Pollara ist eine wichtige programmierbare Plattform, die zeigt, dass der Transport kommerzielle Hardware erreicht hat. Die Formulierung bleibt entscheidend: Für sich entwickelnde UEC-Funktionen ausgelegt zu sein, ist nicht gleichbedeutend mit einer unabhängigen Zertifizierung aller finalen 1.0.3-Anforderungen.

Broadcom kündigte Tomahawk 6 im Juni 2025 als 102,4-Tbit/s-Switching-ASIC mit Funktionen an, die auf UEC-Fabrics abgestimmt sind. Im Oktober kündigte es die Thor Ultra 800G-Karte an und beanspruchte vollständige Konformität der UEC-Funktionen. Dies ist eine bedeutende Anbieterbehauptung, aber öffentliche Belege machen sie nicht zu einem unabhängigen Konsortialzertifikat. Produkt-Sampling, Software-Reife und das genaue Profil müssen unterschieden werden.

Nokia und Keysight kündigten im Oktober 2025 eine Ende-zu-Ende-Demonstration von UET-Verkehr über die Nokia-Switch-Familien 7220 und 7250 mit 800 Gigabit Ethernet an. Keysight lieferte Verkehrserzeugung und -validierung. Der Test zeigt, dass UET kommerzielle Systeme durchlaufen kann und dass Testwerkzeuge entstehen. Er beweist kein vollständiges Multi-Vendor-Endpunktprofil, keinen Produktionsmaßstab und keine unabhängige Zertifizierung aller Optionen.

Weitere Mitglieder haben UEC-bezogene Switches, Systeme, Software oder Testpläne beschrieben, und der Gipfel 2026 räumte der Produktisierung breiten Raum ein. Die verfügbaren Elemente stützen die Vorstellung eines Übergangs zur Implementierung. Sie erlauben es nicht, die genaue Zahl ausgelieferter UET-Karten, zertifizierter Switches, bereitgestellter Cloud-Regionen oder vollständiger Fabrics zu ermitteln.

Die beste Lesart dieser Welle ist die einer Beweiskette. Eine Spezifikation ermöglicht das Design. Silizium- und Kartenankündigungen zeigen Investitionen. Verkehrsdemonstrationen zeigen einen Teil der Interoperabilität. Matrizen ordnen Anforderungen. Betreiber-Bereitstellungsberichte würden den operativen Wert zeigen. Unabhängige Plugfests und Produktionsergebnisse würden die breitere Glaubwürdigkeit liefern, die noch fehlt.

RoCE, InfiniBand, Slingshot und UALink

Das UEC betritt einen Markt mit ausgereiften Technologien und angrenzenden Systemen. Sein strategisches Argument ist nicht, dass Ethernet nie RDMA getragen hätte oder dass spezialisierte Fabrics nicht funktionieren. Es besagt, dass Umfang und Synchronisierung aktueller KI-Lasten eine neue, durchgängige Ethernet-Architektur rechtfertigen, mit mehr Flexibilität bei Zustellung, Pfadnutzung und Überlast.

RoCEv2 ist der direkte Vorgänger und eine weit verbreitete Technologie. Es transportiert RDMA über routbares Ethernet und verfügt über umfangreiche Anwendungs- und Produktunterstützung. Das UEC kritisiert gängige Deployments für die Fixierung eines gesamten Flusses auf einen Pfad, Go-Back-N-Wiederholung, Empfänger-Wiederherstellung der Reihenfolge, die schwierige Abstimmung von DCQCN, die Abhängigkeit von Priority Flow Control in vielen Architekturen und das Verhalten unter Incast oder kollektiven Bursts. Dies sind die technischen Positionen des UEC, kein Beleg dafür, dass alle RoCE-Netze mittelmäßig sind.

Der Vergleich entwickelt sich weiter. Anbieter können programmierbaren Karten adaptives Routing, Paketverteilung, bessere Überlastkontrollen oder andere UEC-Ideen hinzufügen und gleichzeitig RoCE-Kompatibilität bewahren. AMDs Kommunikation rund um Pollara stellt RoCEv2 und UEC RDMA bereits als zwei Optionen auf programmierbarer Hardware dar. UEC kann also als vollständiger Transport mit RoCE konkurrieren und gleichzeitig dessen Entwicklung beeinflussen.

InfiniBand ist die führende spezialisierte Alternative. Es bietet ein integriertes Ökosystem aus RDMA, Überlastkontrolle, Link-Zuverlässigkeit und Management mit langer HPC-Erfahrung. Die 2.0-Arbeiten der InfiniBand Trade Association umfassen 200-Gbit/s-XDR-Lanes und aktualisierte Telemetrie. Die stärkste Differenzierung des UEC ist nicht die Behauptung, InfiniBand fehle es an Leistung, sondern der Versuch, KI/HPC-Verhalten über die Ethernet-Lieferkette, standardmäßiges IP-Routing und eine breitere Anbieterauswahl zu erreichen.

HPE Slingshot nimmt eine Zwischenposition ein. Diese Ethernet-kompatible HPC-Fabric mit adaptivem Routing und Überlastmanagement hat wichtige Vorarbeiten für UET geliefert. Sie demonstriert, dass spezialisiertes Verhalten auf Ethernet aufgebaut werden kann, und verdeutlicht zugleich den Unterschied zwischen einer kontrollierten kommerziellen Plattform und einer Industrie-Spezifikation.

UALink ist im Allgemeinen komplementär. Seine öffentliche 200G-Spezifikation zielt auf latenzarme Scale-up-Konnektivität zwischen Beschleunigern in einem Pod und beschreibt bis zu 1.024 Beschleuniger. UEC 1.0 ist hauptsächlich eine Scale-out-Fabric zwischen Knoten über Switches. Ein Rechenzentrum kann einen Scale-up-Link innerhalb eines Pods und UEC zwischen Pods oder Knoten nutzen. Künftige UEC-Arbeiten zu optimiertem Scale-up und In-Network-kollektiven Operationen können die Grenzen verschieben und entweder Konvergenz oder Wettbewerb erzeugen.

NVIDIA Spectrum-X und proprietäre Fabrics veranschaulichen einen anderen Kompromiss: Ein integrierter Stack kann Hardware, Software und Support schnell optimieren, erhöht aber die Abhängigkeit von einem Ökosystem. UEC tauscht einen Teil dieser Integration gegen das Versprechen gemeinsamer Schnittstellen und Wahlfreiheit. Der Wert des Kompromisses wird von Leistung, Support, Patenten, Interoperabilität und Gesamtkosten abhängen, nicht von Offenheit als bloßem Schlagwort.

Das betriebliche Problem geht über das Protokoll hinaus

Eine 573-seitige Spezifikation kann viele Anforderungen definieren, aber eine Produktions-Fabric braucht noch ein Betriebsmodell. Version 1.0 lässt erhebliche Management-Arbeiten rund um das normative Dokument offen. Betreiber müssen Profile, Verkehrsklassen, ECN-Schwellen, Entropiemengen, Link-Optionen, Schlüssel, Firmware, Telemetrie und Fehlerrichtlinien konsistent konfigurieren.

Mischverkehr erschwert die Aufgabe zusätzlich. Eine Fabric kann UET, RoCE, TCP, Storage, Management und geordnete oder ungeordnete UET-Dienste transportieren. Warteschlangenzuordnung und Fairness werden nicht allein durch die Korrektheit jedes Protokolls gelöst. Eine Überlastkontrolle kann isoliert gut funktionieren und sich gegenüber einem anderen Controller mit anderen Signalen schlecht verhalten.

Die Komplexität der Endpunkte ist ein weiteres strukturelles Risiko. UET platziert dort Multipath, direkte Datenplatzierung, selektive Wiederholung, mehrere Modi, fenster- und kreditbasierte Steuerung, Empfang trunkierter Pakete, Sicherheit und viel Zustand. Dies kann die Siliziumfläche, die Firmwaregröße, den Verifikationsaufwand, den Energieverbrauch und die Zahl zu diagnostizierender Fehler erhöhen. Die Endpunktintelligenz ermöglicht eine breite Anbieterkette, macht aber auch die Komponente komplex, die in jedem Server steckt.

Optionale Funktionen schaffen sowohl Differenzierung als auch Fragmentierung. Ein Anbieter kann AI Base für herkömmliches ECMP und ECN optimieren. Ein anderer kann AI Full, TSS, Trunkierung, LLR und CBFC unterstützen. Beide sind Teil desselben Ökosystems, ohne dieselbe Leistung oder Sicherheit zu garantieren. Konformitätsmatrizen müssen zu betrieblichen Fähigkeitsmatrizen werden.

Die Versionswartung wird kontinuierlich sein. Die Korrekturen 1.0.1 bis 1.0.3 betrafen Überlast, Credits, Wiederherstellung und Pakete. Ein großer Cluster kann mehrere Firmware-Versionen von Karten, Switch-Software und Testwerkzeugen enthalten. Eine Schicht ohne Abstimmung mit den anderen upzugraden, kann querschnittliche Race Conditions offenlegen, die das Konsortium gerade vermeiden will.

Externe Allianzen sind daher zentral. OCP verbindet den Transport mit offener Hardware und Systemen. OFA und libfabric verbinden die Anwendungen. IEEE 802.3 bringt den formellen Ethernet-Prozess ein. SNIA und NVM Express bringen Storage und Management. IETF-Mechanismen liefern IP, ECN und andere Grundlagen. Diese Organisationen haben unterschiedliche Prozesse und Zeitpläne; die Verbindung reduziert Doppelarbeit, garantiert aber keine gleichzeitige Übernahme.

Der letzte Test ist die funktionierende Infrastruktur. Ein Dokument kann Verhalten definieren, ein Anbieter ein Produkt ankündigen und ein Konsortium einen Gipfel veranstalten. Nichts ersetzt einen Cluster, in dem unabhängige Endpunkte und Switches echte Jobs unter Überlast, Ausfall und Upgrade abschließen, mit Betreibern, die das Ergebnis erklären können.

Aktuelle Relevanz: vom dokumentarischen Sieg zur Implementierungsglaubwürdigkeit

Im Juli 2026 hatte das UEC mehrere zum Start unsichere Ziele erreicht. Es hatte eine breite Koalition gebildet, eine integrierte Fünf-Schichten-Architektur geschaffen, eine vollständige 1.0-Spezifikation veröffentlicht, ihre Wartung sichergestellt, 200G-Lanes hinzugefügt, Patentanmeldungen offengelegt und Produkt- und Testankündigungen ausgelöst. Das Projekt ist aktiv, und seine Agenda hat sich klar in Richtung Implementierung verschoben.

Dieser Fortschritt macht die Unsicherheiten bedeutsamer. Kein einziges Register veröffentlicht die aktuelle Mitgliederzahl und die Zusammensetzung des Steering Committee. Die Mitgliedschaftsseiten und die Satzung beschreiben den Zugang unterschiedlich. Die formelle TAC-Leitung ist nicht vollständig mit den Gipfelrollen abgestimmt. Das 1.0.2-Datum weicht zwischen offiziellen Dokumenten ab. Das Konformitätspaket verwendet eine veraltete Profil-Terminologie. Keines dieser Probleme zerstört die Architektur, aber jedes signalisiert die Qualität der Dokumentenkontrolle in einem Projekt, in dem exakte Versionen zählen.

Die größten Lücken betreffen die Akzeptanz. Das UEC veröffentlicht weder eine Bereitstellungsübersicht noch ein unabhängiges Produktregister, einen eigenständigen Haushalt oder geprüfte Abschlüsse. Kein öffentlicher Nachweis belegt ein vollständig interoperables 1.0-Netz in dem angestrebten Maximalmaßstab. Demonstrationen und Anbieterbehauptungen sind nützlich, aber interessengeleitet. Neutrale Vergleiche mit RoCE, InfiniBand und integrierten Ethernet-Plattformen bleiben begrenzt.

Die Chance bleibt beträchtlich. Ethernet ist der gemeinsame Nenner in Rechenzentren, und der KI-Markt kann neue Generationen von Karten, Switches, Optiken und Software tragen. Betreiber haben starke Anreize, einseitige Abhängigkeit zu vermeiden und die Beschleunigerauslastung zu verbessern. Ein gemeinsamer Stack könnte diese Anreize in Beschaffungshebel verwandeln.

Das Risiko ist, dass „Ultra Ethernet“ zu einem Dach für inkompatible Teilmengen wird. Funktioniert der Basistransfer, aber Profile, Überlastkontrolle, Sicherheit und Management laufen auseinander, kann sich die Marke schneller verbreiten als die Interoperabilität. Sind RAND-Lizenzen teuer oder unsicher, kann die Zahl der Anbieter schrumpfen. Absorbiert RoCE die attraktivsten Ideen, ohne den Transport zu wechseln, kann UEC den Markt beeinflussen, ohne das dominierende Label zu werden.

Die entscheidende Frage ist nicht mehr, ob das Konsortium eine ausgefeilte Spezifikation veröffentlichen kann. Das hat es getan. Sie lautet, ob unabhängige Organisationen dieselben Verträge implementieren, die nötigen Lizenzen erhalten, die Fabric im großen Maßstab betreiben und die Kompatibilität während der Weiterentwicklung bewahren können. UEC wird nur insoweit Infrastruktur, wie seine Behauptungen dem Code in Produktion standhalten.