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 gegründet wurde. Es ist ein Branchenspezifikationskonsortium, kein herkömmliches Unternehmen oder Netzbetreiber.
  • Der Geltungsbereich des UEC ist weiter als eine schnellere Ethernet-Verbindung oder ein Ersatz für RoCE. Seine 573-seitige Spezifikation Version 1.0.3 umfasst Software-, Transport-, Netzwerk-, Sicherungs- und physikalische Schichten, ergänzt durch Management-, Speicher-, Test- und Compliance-Arbeiten rund um den Kernstapel.
  • Der Ultra Ethernet Transport kombiniert mehrere Zustellmodi, paketbasiertes Multipathing, selektive Neuübertragung, sender- und empfängergesteuerte Überlastkontrolle, ECN, optionales Packet Trimming, optionalen Link Layer Retry, optionale Credit-Based Flow Control und optionale Ende-zu-Ende-Transportsicherheit.
  • Produkte und Demonstrationen von AMD, Broadcom, Nokia und Keysight zeigen, dass die Implementierung begonnen hat, aber die öffentliche Compliance beruht hauptsächlich auf Selbstauskünften der Implementierer, und es wurde noch kein umfassendes unabhängiges Zertifizierungsregister oder eine groß angelegte Bestandsaufnahme der Bereitstellungen veröffentlicht.
  • Die strategische Chance des UEC liegt in der installierten Basis und der Multi-Vendor-Lieferkette von Ethernet. Die Hauptrisiken sind Endpunktkomplexität, Fragmentierung durch optionale Funktionen, RAND-Patentverpflichtungen, unausgereiftes Management und Testing sowie die Lücke zwischen der Veröffentlichung einer Spezifikation und der nachgewiesenen Interoperabilität im Produktionsbetrieb.

Warum KI das Netzwerk zu einem Teil des Computers gemacht hat

Das Ultra Ethernet Consortium entstand aus einem Wandel in der Ökonomie des Rechnens. In einem gewöhnlichen Unternehmensnetzwerk wird von der Fabric erwartet, dass sie viele unabhängige Datenströme mit akzeptablem Durchsatz und akzeptabler Verfügbarkeit befördert. In einem großen KI-Trainingssystem oder einer Hochleistungsrechnermaschine wird das Netzwerk Teil einer synchronisierten Berechnung. Tausende von Beschleunigern können Modellparameter, Gradienten oder wissenschaftliche Daten in kollektiven Operationen austauschen. Eine Phase kann nicht voranschreiten, bevor der langsamste Teilnehmer die notwendigen Informationen erhalten hat.

Schon ein geringes Ungleichgewicht der Pfade, Überlast oder Paketverlust kann daher teure Prozessoren warten lassen, selbst wenn die durchschnittliche Auslastung der Fabric gesund erscheint.

Das verändert, worauf die Betreiber optimieren. Die Gesamtbandbreite ist zwar weiterhin wichtig, aber sie allein reicht nicht aus. Sie achten auch auf die Auftragsabschlusszeit, die Tail-Latenz, Incast, die Wiederherstellung nach Verlusten, die Verteilung des Datenverkehrs auf parallele Pfade und die Menge an Zustandsinformationen, die Endpunkte vorhalten müssen. Ein Netzwerk, das die meisten Pakete schnell zustellt, aber einen kleinen Teil verzögert, kann eine gesamte kollektive Operation blockieren.

Eine Neuübertragungsmethode, die für herkömmlichen Verkehr akzeptabel ist, kann zu viel Zeit verschwenden, wenn eine lange Nachricht ein einziges Paket verliert. Ein auf einen gleichberechtigten Pfad fixierter Fluss kann schlechte Leistung zeigen, während anderswo in der Topologie Kapazität verfügbar bleibt.

Die Gründungsprämisse des UEC war, dass diese Probleme nicht durch ein neues Switch-Feature oder einen überarbeiteten Überlastalgorithmus gelöst werden können. Der Kommunikationspfad beginnt oberhalb des Netzwerks, in Softwarebibliotheken und Anwendungssemantiken. Er führt über Speicherregistrierung, Remote-Operationen, Transportstatus, Paketzustellung, Überlastkontrolle, IP-Weiterleitung, Ethernet-Verbindungen, Optiken und physikalische Signalgebung. Wenn diese Schichten unabhängig voneinander entworfen werden, kann eine Optimierung an einer Stelle lediglich den Engpass verschieben oder inkompatible Annahmen anderswo erzeugen.

Die Antwort des UEC ist eine koordinierte Architektur. Es behält Ethernet und IP bei, weil die Betreiber sie bereits verstehen und weil eine enorme Lieferkette rund um Switches, Optiken, Kabel, Netzwerkbetriebssysteme, Telemetrie und Management existiert. Es ändert oder erweitert die Teile, die nach Ansicht des Konsortiums schlecht auf große KI- und HPC-Workloads abgestimmt sind. Das Ergebnis ist nicht „gewöhnliches Ethernet mit einem neuen Logo“. Es ist der Versuch, ein vertrautes Netzwerk einen spezialisierten Transport tragen zu lassen, dessen Verhalten von der Software-API bis hinunter zur Lane-Rate definiert ist.

Dieser Unterschied erklärt, warum UEC für die digitale Infrastruktur von Bedeutung ist. Das Projekt besitzt weder Beschleuniger, Fabriken, Rechenzentren noch Cloud-Regionen. Es definiert die Verträge, die Mitgliedsunternehmen und andere Implementierer in NICs, Switch-ASICs, Systeme, Treiber, Bibliotheken und Testgeräte einbringen können. Sein Einfluss wird sich erst dann realisieren, wenn diese unabhängigen Produkte unter den Bedingungen von Ausfällen, Überlast, Upgrades und gemischten Anbietern fehlerfrei Daten austauschen.

Was UEC ist – und was es nicht ist

Ultra Ethernet Consortium ist der öffentliche Name eines formellen Projekts, dessen rechtliche Reihe Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series heißt. Die Reihenstruktur ordnet das Projekt der Joint Development Foundation und der weiteren Linux Foundation-Familie zu. Sie gibt den Teilnehmern einen bereits bestehenden rechtlichen Rahmen für Mitgliedschaft, Governance, geistiges Eigentum, Finanzierung und externe Beziehungen, ohne dass sie eine neue eigenständige Kapitalgesellschaft gründen müssen.

Diese Struktur ist wichtig, weil UEC oft ungenau als Unternehmen, Allianz oder Normungsgremium beschrieben wird. Es ist kein kommerzielles Unternehmen mit Aktionären, Eigenkapital, einer Bewertung oder unabhängig geprüften Abschlüssen. Es verkauft keine Ethernet-Produkte, betreibt kein öffentliches Netzwerk und besitzt nicht die von seinen Mitgliedern beworbene Hardware. Es ist ein Spezifikationsentwicklungskonsortium mit einem rechtlichen und geistigen Eigentumsrahmen. Seine öffentlichen Dokumente sollen als Implementierungsverträge über mehrere Unternehmen hinweg dienen.

UEC ist auch nicht identisch mit Ultra Ethernet Transport. UET ist die Transportarchitektur im Zentrum der Spezifikation. Die Arbeit des Konsortiums ist breiter. Sie umfasst die Software-Abbildung auf libfabric, Paket- und Nachrichtensemantik, Netzwerkannahmen, Verbindungsschichtoptionen, Anforderungen der physikalischen Schicht, Management, Speicherausrichtung, Leistungs- und Debugging, Compliance und Testing. Das Projekt auf „ein neues RDMA-Protokoll“ zu reduzieren, verbirgt das schichtenübergreifende Design, das es ambitioniert und schwierig macht.

UEC ist auch nicht die IEEE 802.3 Working Group. IEEE 802.3 entwickelt durch seinen eigenen formellen Prozess grundlegende Ethernet-MAC- und physikalische Schichtstandards. UEC stützt sich auf dieses Ökosystem und unterhält eine Liaison, ersetzt es aber nicht. Die gleiche Grenze gilt für die IETF-Mechanismen unterhalb von UET, einschließlich IPv4, IPv6 und Explicit Congestion Notification, für das OpenFabrics-Ökosystem, das libfabric pflegt, und für Organisationen, die an Speicher, offener Hardware und Beschleuniger-Interconnects arbeiten.

Die Website des Projekts hat Formulierungen verwendet, die auf den Status einer internationalen Normungsorganisation hindeuten. Die sicherere und besser belegte Beschreibung lautet, dass UEC eine internationale Spezifikationsentwicklungsorganisation unter dem JDF-Rahmenwerk ist. Es gibt keine Belege dafür, dass es Teil der Internationalen Organisation für Normung ist, dass seine Dokumente ISO-Normen sind oder dass es eine ISO-Normnummer besitzt. Die Unterscheidung ist mehr als terminologisch.

Sie identifiziert, woher Autorität kommt, wie Teilnahme funktioniert und mit welchen rechtlichen Verpflichtungen Implementierer konfrontiert sein können.

UEC sollte daher nach der Rolle beurteilt werden, die es tatsächlich ausübt. Es koordiniert Wettbewerber und Betreiber rund um ein gemeinsames technisches Design. Es veröffentlicht Spezifikationen. Es verwaltet Arbeitsgruppen und erklärte Patentverpflichtungen. Es entwickelt Compliance-Materialien und Beziehungen zu angrenzenden Organisationen. Es kann nicht allein durch Erklärung ein Produkt interoperabel machen oder einen Markt dazu bringen, seine Architektur zu übernehmen.

Die neunköpfige Gründungskoalition

Das Konsortium wurde am 19. Juli 2023 von neun Organisationen angekündigt, die auf verschiedenen Ebenen der KI- und HPC-Lieferkette positioniert sind: AMD, Arista Networks, Broadcom, Cisco, Eviden, damals mit Atos verbunden, Hewlett Packard Enterprise, Intel, Meta und Microsoft. Diese Breite war von Anfang an ein strategischer Vorteil. Ein Transport, der nur von Switch-Anbietern entwickelt wird, könnte Anwendungs- und Endpunktbeschränkungen vernachlässigen. Ein Design, das nur von Beschleunigeranbietern geleitet wird, könnte eng auf ein Hardware-Ökosystem optimiert sein.

Ein reines Cloud-Projekt könnte das Silizium-, Optik- und System-Know-how vermissen lassen, das nötig ist, um eine Architektur in Produkte umzusetzen.

AMD brachte Prozessoren, Beschleuniger und Endpunktvernetzung ein. Arista und Cisco brachten umfangreiche Ethernet-Switching- und Betriebserfahrung ein. Broadcom steuerte Switch-Silizium, NICs und Hochgeschwindigkeits-SerDes bei. HPE und Eviden brachten HPC-Systeme und Erfahrung mit spezialisierten Interconnects ein. Intel brachte Prozessoren, Ethernet und Software-Know-how ein. Meta und Microsoft repräsentierten Hyperscale-Betreiber mit einem direkten Anreiz, die Auslastung großer KI-Cluster zu erhöhen und die Abhängigkeit von einem einzelnen integrierten Anbieter zu verringern.

Die Koalition enthielt auch konkurrierende kommerzielle Interessen. Die Mitglieder verkaufen NICs, Switch-ASICs, Systeme, Cloud-Kapazität, Optiken, Software und Support. Einige verfügen über Patentportfolios, die für die Implementierung notwendig sein könnten. Einige profitieren von einem breiten Multi-Vendor-Standard, während andere auch von differenzierten proprietären Funktionen profitieren können. Das Konsortium beseitigt also nicht den Wettbewerb.

Es schafft ein Forum, in dem Wettbewerber sich auf Mindestschnittstellen einigen, während sie weiterhin in puncto Implementierungsqualität, Leistung, Integration und kommerziellen Bedingungen konkurrieren.

HPEs Slingshot-Interconnect liefert ein nützliches Beispiel für eine technische Abstammung. Slingshot ist eine Ethernet-kompatible HPC-Fabric mit adaptivem Routing und Überlastmanagement-Funktionen. Kommentare aus dem HPE-Umfeld haben angegeben, dass eine HPC-Ethernet-Spezifikation an UEC beigesteuert wurde und haben geschätzt, dass ein großer Teil von UET von Slingshot-Transportideen abgeleitet ist. Der genaue Prozentsatz ist unabhängig nicht überprüft und sollte nicht als Konsortialbuchhaltung betrachtet werden. Der allgemeine Punkt ist gut belegt: UEC begann nicht auf einem leeren Blatt.

Es stützte sich auf Produktionserfahrung in HPC, Cloud-Netzwerken, RDMA und Ethernet.

Diese Mischung aus Vorgängersystemen ist ein Grund, warum das Wort „offen“ Präzision benötigt. Die ratifizierte Spezifikation von UEC ist öffentlich herunterladbar. Die Architektur ist zur Implementierung durch mehrere Anbieter vorgesehen. 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 oder rechtlichen Bedingungen rund um die Technologie.

Eine Rechtsreihe, die für die Zusammenarbeit von Wettbewerbern gebaut wurde

Das Modell der Joint Development Foundation gibt UEC eine formelle Hülle, ohne es zu einem konventionellen operativen Unternehmen zu machen. Das Projekt hat seinen eigenen Namen, Umfang, Mitgliedschaftsklassen, ein Steering Committee, Arbeitsgruppen und Verpflichtungen bezüglich geistigen Eigentums. Der JDF-Dachverband liefert die korporative und gemeinnützige Infrastruktur und kann Projektvermögen und -vereinbarungen halten. Dies senkt die Kosten der Konsortialgründung und gibt Wettbewerbern einen anerkannten Prozess für die Zusammenarbeit.

Das Steering Committee leitet das Projekt. Seine dokumentierten Aufgaben umfassen die Koordination der Arbeitsgruppen, die Genehmigung von Mitgliedern, die Verwaltung von Vermögenswerten und Finanzen, die Auswahl oder Ablösung des Vorsitzes, die Fortschrittsüberwachung und die Kontrolle der öffentlichen Bekanntgabe und der Projektmarken. Konsens wird bevorzugt. Kommt kein Konsens zustande, sieht die Satzung einen Mechanismus mit einer Dreiviertel-Supermajorität unter den anspruchsberechtigten Teilnehmern vor, die die Anwesenheitsanforderungen erfüllen. Schriftliche Einwände können an den Vorsitz gerichtet werden.

Der ursprüngliche Vorsitzende war Brad Booth von Meta. Die aktuelle 1.0.3-Spezifikation listet J Metz von AMD als Vorsitzenden, Barry Davis von HPE als stellvertretenden Vorsitzenden, Hugh Holbrook von Arista als Vorsitzenden des Technischen Beratungsgremiums (TAC) und Puneet Agarwal von Marvell als stellvertretenden TAC-Vorsitzenden. Paul Congdon ist als Spezifikationsredakteur gelistet. Das Dokument identifiziert auch Leiter und Autoren für die physikalische, Verbindungs-, Transport- und Softwarearbeit. Eine Gipfelagenda 2026 nennt zusätzliche operative Leiter.

Diese Gipfelrollen ersetzen nicht notwendigerweise die formellen Titel in der Spezifikation; öffentliches Material liefert kein vollständiges aktuelles Organigramm.

In der Satzung erscheinen drei Mitgliedschaftsklassen: Steering, General und Contributor. Steering-Mitglieder nehmen an der Governance teil und benennen in der Regel Vertreter für das Steering Committee. General-Mitglieder können in allen technischen Gruppen arbeiten, haben aber keinen Sitz im Steering Committee. Contributor-Mitglieder beteiligen sich an ausgewählten Gruppen und besitzen kein Supermajoritätsstimmrecht. Die aktuelle öffentliche Mitgliederseite bewirbt die Ebenen General und Contributor mit jährlichen Projektpreisen von 20.000 US-Dollar beziehungsweise 5.000 US-Dollar, zuzüglich der Linux Foundation-Mitgliedschaft.

Sie erklärt nicht klar den Zulassungsweg oder den aktuellen Preis für den Steering-Status.

Der Unterschied in der formalen Macht ist wichtig. Eine breite Mitgliedschaft kann Expertise und Implementierungsreichweite bieten, aber die Governance ist nicht gleichmäßig verteilt. Große Unternehmen, die in der Lage sind, Steering-Positionen zu halten, Ingenieure in vielen Gruppen beizusteuern und Patent- und Produktprogramme zu unterhalten, haben mehr praktischen Einfluss als kleinere Contributor-Mitglieder. Nichtmitglieder können die endgültige Spezifikation herunterladen, aber nicht den gesamten Entwurfsprozess einsehen oder gleichberechtigt teilnehmen.

Interne Projektinformationen werden nicht wie gewöhnliche vertrauliche Unternehmensdaten behandelt, dennoch ist es den Mitgliedern untersagt, Entwurfsmaterial offenzulegen, bis das zuständige Komitee die Veröffentlichung genehmigt. Diese Regelung kann Wettbewerbern helfen, unfertige Ideen ohne vorzeitige Marktsignale zu diskutieren. Sie bedeutet auch, dass Außenstehende abgelehnte Vorschläge, Abstimmungsprotokolle, zwischenzeitliche Implementierungsbedenken oder die Verhandlungen, die optionale Funktionen hervorbrachten, nicht einsehen können. Die endgültige Spezifikation ist offen; der Weg dorthin ist nur teilweise sichtbar.

Von einem Start mit vier Gruppen zu einer 573-seitigen Spezifikation

Die erste öffentliche Struktur des UEC im Jahr 2023 konzentrierte sich auf vier Arbeitsgruppen: Software, Transport, Verbindung und Physik. Die Reihenfolge spiegelte den End-to-End-Anspruch des Projekts wider. Die Mitgliedschaft wurde nicht als uneingeschränkte öffentliche Mailingliste eröffnet. Mehr als 200 Organisationen hatten Interesse bekundet, und das Konsortium führte das Onboarding schrittweise durch, wobei es Prozess- und Kartellrechtsorientierung verlangte. Diese Vorsicht war verständlich, da die Teilnehmer in mehreren Märkten direkt konkurrieren und gemeinsame Produkt- und Protokollanforderungen diskutieren würden.

Bis Dezember 2023 meldete UEC rund 40 Unternehmen und mehr als 300 Einzelpersonen. Es hatte ein Technisches Beratungsgremium eingerichtet und auf acht Arbeitsgruppen erweitert. Der Zweck des TAC war die architektonische Kohärenz: Ein Transportdesign konnte kein Switch-Verhalten, eine Signalisierungsmethode oder eine API voraussetzen, die eine andere Gruppe nicht zu unterstützen bereit war. Im März 2024 meldete das Konsortium 55 Unternehmen und mehr als 750 aktive Teilnehmer und veröffentlichte eine viel klarere Beschreibung seiner beabsichtigten Architektur.

Das März-Update führte die Hauptideen ein, die später in der normativen Spezifikation erschienen: libfabric als software-seitige API, Packet Spraying, flexible Reihenfolge, mehrere Zustellmodi, sender- und empfängergesteuerte Überlastkontrolle, ECN, Packet Trimming, Link Layer Retry, optionale Credit-Based Flow Control, Transportsicherheit und zukünftige In-Network Collective Operations. Es betonte auch, dass UET über bestehende Ethernet-Switches betrieben werden kann, während verbesserte Switches zusätzliche Leistung bieten können.

Die institutionelle Reichweite wuchs zusammen mit der technischen Arbeit. UEC meldete im Juli 2024 1.193 aktive Teilnehmer und im August 97 Mitgliedsorganisationen. Dabei handelt es sich um datierte Konsortialzahlen, die auf nicht vollständig öffentlichen Definitionen beruhen. Sie sollten nicht mechanisch zu späteren Ankündigungen addiert werden. Im Jahr 2025 gab UEC an, dass 27 neue Unternehmen beigetreten seien, aber Austritte, Fusionen und überlappende Berichtszeiträume verhindern, dass diese Aussage eine exakte aktuelle Gesamtzahl begründet. Die Website selbst sagt, dass nicht alle Mitglieder angezeigt werden.

Das Konsortium veröffentlichte die Ultra Ethernet Specification 1.0 am 11. Juni 2025. Das war der Moment, in dem UEC von einer Roadmap zu einer öffentlichen Implementierungsbasislinie wurde. Version 1.0.1 folgte im September und korrigierte den Quellalgorithmus der empfänger-kreditbasierten Überlastkontrolle sowie redaktionelle Probleme. Version 1.0.2 erschien im Januar 2026 und korrigierte Überlastmanagement-Algorithmen, obwohl offizielle Dokumente uneins sind, ob das Erscheinungsdatum der 21. oder 28. Januar war. Die Inkonsistenz sollte sichtbar bleiben, anstatt stillschweigend bereinigt zu werden.

Version 1.0.3, veröffentlicht am 16. Juli 2026, ist zum Forschungsstichtag die aktuelle Referenz. Sie umfasst 573 Seiten und fügt Unterstützung für 200 Gb/s pro Lane-Signalisierung und eine boolesche Aushandlungsfähigkeit hinzu. Ihre Versionshinweise identifizieren auch erforderliche Korrekturen bei der Paketzustellung, bei Überlastguthaben, beim Link Layer Retry und bei den geordneten Sätzen der physikalischen Schicht sowie Klarstellungen zur Transportsicherheit, zu atomaren Operationen und zu getrimmten Paketen.

Die Unterscheidung zwischen erforderlichen Korrekturen und redaktionellen Klarstellungen ist wichtig: Einige Änderungen wirken sich auf das konforme Verhalten aus und damit auf die Wartung der Implementierung.

Der Mitgliedergipfel 2026 in Denver zeigte einen zweiten Übergang. Die Agenda konzentrierte sich auf Bereitstellung, Produktisierung, Compliance, Management, Leistung, Debugging, Speicherintegration und Switch- wie Endpunkttests. Das architektonische Kernstück existiert; die Glaubwürdigkeit des Projekts hängt nun zunehmend davon ab, ob Implementierer den Stapel über organisatorische Grenzen hinweg bauen, qualifizieren, betreiben und aktualisieren können.

Eine Architektur über fünf funktionale Schichten

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

Oben 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, wie Nachrichten paketiert, geordnet, bestätigt und wiederhergestellt werden. Das Überlastmanagement steuert, wie viele Daten in die Fabric gelangen und wie der Verkehr auf Pfade verteilt wird. Optionale Transportsicherheit schützt den Ende-zu-Ende-Verkehr. Standard-IPv4 oder IPv6 sorgen für die Netzwerkschichtweiterleitung.

Ethernet stellt die Verbindung bereit, mit optionalem Packet Trimming, Link Layer Retry, Credit-Based Flow Control und Feature-Aushandlung. Die physikalische Schicht definiert Statistik- und Signalisierungsanforderungen bei 100 oder 200 Gb/s pro Lane.

Diese Struktur bewahrt wichtige Teile des bestehenden Netzwerks. UEC definiert keinen Ersatz für IP-Routing. Es erwartet konventionelles Equal-Cost Multipath Forwarding und ECN-fähige Switches. Ein Großteil der Intelligenz verbleibt bei den Fabric Endpoints, die Entropie manipulieren, Transportstatus verfolgen, Daten platzieren und auf Überlastsignale reagieren. Verbesserte Switches können Funktionen hinzufügen, aber das Design verlangt nicht, dass jede Bereitstellung ihre gesamte Fabric austauscht, bevor UET-Verkehr fließen kann.

Das schafft einen Migrationsvorteil und ein Klassifikationsproblem. Eine Bereitstellung kann UET-Endpunkte über konventionelles Ethernet mit ECMP und ECN nutzen. Eine andere kann Trimming, Link Retry, virtuelle kanalbasierte Guthaben, reichhaltigere Telemetrie und später auch netzwerkinterne Operationen hinzufügen. Beide können Ultra Ethernet genannt werden, obwohl sich ihre Leistung, Wiederherstellungscharakteristik und betriebliche Komplexität erheblich unterscheiden.

Der Fünf-Schichten-Ansatz macht es auch schwieriger, Implementierungsfehler zu isolieren. Ein schlechtes Ergebnis kann von der Anwendungsabbildung, der Endpunktzustandsmaschine, den Überlastparametern, der Switch-Queue-Konfiguration, der DSCP-Zuordnung, den Optiken, der Firmware oder dem Sicherheitssystem herrühren. Pakete durchzuleiten ist nicht genug. Das System muss die beabsichtigte Semantik und Leistung unter Skalierung, gemischtem Verkehr, Fehlern und Versionsänderungen bewahren.

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

UEC wählt libfabric 2.0 als die Basis-Northbound-API für konforme Endpunkte. Diese Wahl verbindet das Projekt mit einem bestehenden HPC- und fortschrittlichen Netzwerk-Software-Ökosystem, anstatt jedes Framework zu bitten, eine neue proprietäre Schnittstelle zu übernehmen. Libfabric repräsentiert bereits Fabrics, Domänen, Endpunkte, Completion Queues, Event Queues, Adressvektoren, Speicherbereiche, Messaging, Remote-Speicheroperationen und atomare Operationen. UEC bildet diese Konzepte ab und beschränkt sie, damit Anbieter Aufrufe in UET-Verhalten übersetzen können.

Der strategische Wert ist Kontinuität oberhalb des Transports. MPI, SHMEM und Beschleuniger-Kommunikationsbibliotheken können vertraute Abstraktionen nutzen, während der darunter liegende Anbieter wechselt. Prinzipiell kann eine Anwendung eine Operation anfordern, ohne zu wissen, welche NIC des Anbieters die Paketzustellung implementiert oder welches Switch-Silizium die Pakete weiterleitet. Das ist einer der Hauptmechanismen, durch die ein gemeinsamer Transport Anbieterwahl schaffen könnte.

Die Abstraktion garantiert keine gleichwertigen Implementierungen. Anbieter können unterschiedliche Inject-Größen, Scatter-Gather-Limits, Endpunktanzahlen, atomare Operationen, Speicherregistrierungstechniken, Completion-Verhalten, Hardware-Offload und Sicherheitsfunktionen unterstützen. Eine Bibliothek, die gegen dieselbe API kompiliert, kann dennoch auf unterschiedliche Leistungs- oder Fähigkeitsgrenzen stoßen. Beschaffung und Softwarequalifikation brauchen daher mehr als ein Häkchen mit der Aufschrift „libfabric unterstützt“.

Die Softwareschicht von UEC trägt auch Job- und Autorisierungssemantiken. KI- und HPC-Systeme führen häufig viele Jobs auf gemeinsam genutzter Infrastruktur aus, jeder mit eigenen Prozessen, Speicherbereichen und Sicherheitsgrenzen. Die Spezifikation muss identifizieren, welcher Endpunkt zu welchem Job gehört, welche Puffer zugreifbar sind, wie eine entfernte Operation zugeordnet wird und wie Abschluss- oder Fehlerinformationen an die Software zurückgegeben werden. Diese Entscheidungen bestimmen, ob ein schnelles Netzwerk für den Scheduler, die Laufzeitumgebung und die Anwendung nutzbar ist und nicht nur in einem Paket-Benchmark beeindruckt.

Das Projekt ist vom OpenFabrics-Ökosystem abhängig, weil es libfabric nicht besitzt. Diese Beziehung veranschaulicht ein breiteres Merkmal von UEC: Die Architektur wird aus Komponenten zusammengesetzt, die an verschiedenen Orten gesteuert werden. UEC kann definieren, wie sein Transport auf libfabric abgebildet wird, muss sich jedoch mit den Maintainern und Nutzern der API abstimmen. Ähnliche Abhängigkeiten bestehen bei IEEE Ethernet, IETF-Netzwerken, Speicherorganisationen und den Betriebssystemen der Anbieter.

Fabric Endpoints und Workload-Profile

Ein Fabric Endpoint (FEP) ist der logische Ort, an dem UET terminiert. Er verbindet eine Betriebssysteminstanz mit einer oder mehreren isolierten Fabric-Ebenen und kann einen Userspace-Provider, Kernel-Treiber, NIC- oder beschleunigerseitigen Transport, ein Speicherregistrierungssystem, einen Sicherheitskontext, Completion Queues, Adressvektoren sowie den für die Paketzustellung und Überlastkontrolle verwendeten Zustand umfassen.

Dieses endpointzentrierte Design erlaubt es den meisten Switches, erkennbar Ethernet- und IP-Geräte zu bleiben. Der FEP wählt Entropiewerte, hält Paket- und Überlastzustände, platziert Daten in autorisierten Speicher und interpretiert Bestätigungen, Trimming und anderes Feedback. Das kann die Abhängigkeit von proprietärer switch-interner Routing-Intelligenz verringern. Es konzentriert auch die Komplexität in NIC-Silizium, Firmware, Treibern und Software.

UEC definiert drei Implementierungsprofile: AI Base, AI Full und HPC. Sie sind keine getrennten Netzwerktypen. Es sind Bündel, die festlegen, welche Funktionen eine Implementierung unterstützen muss. AI Base soll gängige KI-Kommunikation mit geringeren Implementierungskosten und -zuständen abdecken. AI Full fügt Funktionen wie aufschiebbare Sends, exakte Übereinstimmung und Fetch- oder Compare-artige atomare Operationen hinzu. Das HPC-Profil umfasst die meisten AI Full-Fähigkeiten, schließt aufschiebbare Sends aus und legt größeren Wert auf Reihenfolge, kurze Nachrichten und HPC-Semantik.

Das Profilsystem ist ein Versuch zu verhindern, dass jedes Produkt den maximalen Funktionsumfang implementieren muss. Es erkennt an, dass eine volumenstarke KI-NIC kollektive Datenbewegungen priorisieren kann, während ein HPC-Endpunkt strengere Ordnung und atomare Operationen benötigt. Profile beseitigen jedoch nicht die Optionalität. Ein Produkt kann optionale Funktionen innerhalb eines Profils implementieren, und zwei Produkte mit demselben Profil-Label können sich dennoch in Sicherheit, Verbindungsverbesserungen, Kapazität und Leistung unterscheiden.

Die Terminologie ist bereits ein Warnsignal. Die maßgebliche 1.0.3-Spezifikation verwendet AI Base, AI Full und HPC. Ein separates Compliance-Readme von 2025 verwendet AI Base, AI Extended und HPC. Die am besten gestützte Interpretation ist, dass „AI Full“ aktuell und das Compliance-Material veraltet oder inkonsistent ist. Bis das öffentliche Testpaket korrigiert ist, sollten Anbieter und Käufer sowohl die Spezifikationsversion als auch die genaue Profilsprache hinter einer Behauptung angeben.

Von der Anwendungsabsicht zur Paketzustellung

Innerhalb von UET trägt die Semantic Services Sublayer die Anwendungsabsicht. Sie definiert Nachrichtenidentität, Pufferadressierung, getaggte und ungetaggte Operationen, Remote-Speicherzugriff, atomare Operationen, Completion-Verhalten, Job-Identifikatoren, Pufferautorisierung, Antworten und Fehler. Die Packet Delivery Sublayer bestimmt dann, wie diese Absicht zu Paketen wird und wie diese Pakete einen anderen Endpunkt erreichen.

Für zuverlässige Modi etablieren Endpunkte Packet Delivery Contexts (PDCs). Ein PDC enthält Zustände wie Paketsequenznummern, Bestätigungen, Duplikatserkennung, Ordnungsmodus, Überlastinformationen, Rückrichtungsstatus und Verkehrsklasse. Ein PDC ist einem Zustellmodus und einer Verkehrsklasse zugeordnet, und zwischen demselben Paar von FEPs können mehrere PDCs existieren.

Dieser Zustand ist kein unbedeutendes Implementierungsdetail. Große Cluster können enorme Anzahlen von Kommunikationsbeziehungen erzeugen. Wenn jede Beziehung umfangreichen Zielzustand erfordert, können Endpunktspeicher und Lookup-Kosten limitierend werden. UEC zwingt daher nicht jede Operation in ein Verbindungsmodell. Es definiert vier Zustelldienste mit unterschiedlichen Zuverlässigkeits- und Ordnungsverträgen.

Reliable Unordered Delivery (RUD) bietet genau-einmalige Paketzustellung an die semantische Schicht und erlaubt gleichzeitig, dass Pakete außerhalb der Reihenfolge ankommen. Es unterstützt Packet Spraying auf mehrere Pfade, selektive Neuübertragung, Duplikatsunterdrückung und direkte Datenplatzierung. Da das Ziel Daten gemäß Offsets platzieren kann, anstatt auf einen Neuordnungspuffer auf Transportebene zu warten, kann eine lange kollektive Operation mehrere Pfade ausnutzen, ohne alle Pakete hinter einer fehlenden Einheit zu serialisieren.

Reliable Ordered Delivery (ROD) bietet genau-einmalige, reihenfolgegetreue Zustellung. Es verwendet einen Pfad und einen Entropiewert, verwirft Pakete außerhalb der Reihenfolge und verlässt sich auf Go-Back-N-Wiederherstellung ab der ersten fehlenden Sequenz. Das erscheint weniger raffiniert als RUD, bewahrt aber die Semantik, die für Operationen erforderlich ist, bei denen strenge Ordnung wichtig ist. UEC behandelt Ordnung als Anwendungsanforderung, anstatt anzunehmen, dass jeder Transfer dafür bezahlen sollte.

Reliable Unordered Delivery for Idempotent Operations (RUDI) geht einen anderen Kompromiss ein. Es bietet mindestens-einmalige Zustellung und erlaubt Duplikate, wodurch gewöhnliche Sequenz- und Bestätigungszustände am Ziel reduziert werden. Es kann nützlich sein, wenn das Wiederholen einer Operation das Endergebnis nicht verändert, etwa bei ausgewählten Remote-Speicherbewegungen gefolgt von einer separaten Barriere. Es ist gefährlich, wenn es falsch angewendet wird. Die Paketschicht leitet nicht ab, ob eine Operation idempotent ist; die Software muss diese Entscheidung treffen.

Die Verwendung von RUDI für eine nicht-idempotente Operation kann einen ungültigen Anwendungszustand erzeugen.

Unreliable Unordered Delivery (UUD) bietet Best-Effort-Datagramme ohne normale Zuverlässigkeits- oder Ordnungsgarantien. Es gehört zum selben semantischen Rahmen, unterliegt aber nicht denselben Überlastkontrollanforderungen wie RUD und ROD. Anwendungen müssen vermeiden, überlastkontrollierten Verkehr zu schädigen, wenn UUD Queues oder Verkehrsklassen teilt.

Die vier Modi offenbaren eine zentrale UEC-Philosophie: Das Netzwerk sollte mehrere Mechanismen anbieten, damit Software die Transportkosten an die Semantik der Operation anpassen kann. Der Vorteil ist Effizienz. Der Nachteil ist eine größere Implementierungs- und Testoberfläche mit mehr Gelegenheiten, dass Anbieter, Anwendung oder Betreiber eine inkompatible Kombination wählen.

Packet Spraying: die Fabric nutzen statt eines glücklichen Pfades

Konventionelles Equal-Cost Multipath Forwarding hasht häufig einen gesamten Fluss auf eine Route. In einer breiten Clos-Fabric kann das eine Lotterie erzeugen. Mehrere große Flüsse können auf denselben Links kollidieren, während anderswo gleichwertige Kapazität ungenutzt bleibt. Ein langer KI-Transfer kann dann während seiner gesamten Lebensdauer durch einen unglücklichen Hash begrenzt sein.

UET adressiert das, indem es die Entropie auf Paketgranularität ändert. Ein Sender kann Dutzende oder Hunderte von Entropiewerten verwenden, sodass bestehende ECMP-Mechanismen der Switches Pakete auf viele Routen verteilen können. Die Packet Delivery Sublayer liefert Sequenzinformationen; die Congestion Management Sublayer wählt Entropie oder Pfad; Switches führen ihr normales Hashing aus; und Feedback informiert den Sender, welche Entropiewerte überlastet erscheinen.

Packet Spraying ist nur praktikabel, weil andere Teile des Designs es unterstützen. Pakete können außerhalb der Reihenfolge ankommen. RUD kann Daten direkt platzieren, anstatt auf eine vollständige Transportneuordnung zu warten. Selektive Neuübertragung kann nur das wiederherstellen, was verloren ging. Überlastfeedback kann die Nutzung problematischer Pfade reduzieren. Der Mechanismus ist daher kein eigenständiger Lastverteilungstrick. Er ist Teil eines Transportmodells, das auf Pfadvielfalt aufgebaut ist.

UEC verlangt nicht, dass jeder Switch einen proprietären adaptiven Routing-Algorithmus ausführt. Einfache Implementierungen können Round-Robin oder pseudo-zufällige Entropie über Standard-ECMP nutzen. Fortgeschrittenere Endpunkte können ECN-, Latenz- oder Trimming-Signale mit bestimmten Entropiewerten verknüpfen und Pfade meiden, die überlastet erscheinen. Anbieterspezifisches adaptives Forwarding kann mit UET koexistieren, ist aber nicht die einzige Quelle für Pfadbewusstsein.

Das Versprechen ist eine bessere Fabric-Auslastung und niedrigere Tail-Latenz. Die ungeklärte Frage ist, wie konsistent verschiedene Endpunkte Feedback interpretieren und wie Packet Spraying mit Switch-Puffern, Umordnung, Ausfällen und gemischtem Verkehr interagiert. Ein Algorithmus, der in einem homogenen Labor gut funktioniert, kann sich in einer großen Fabric mit mehreren Switch-Generationen und Verkehrsklassen anders verhalten. Unabhängige, multi-vendor-basierte Belege sind noch begrenzt.

Drei Überlastmechanismen für drei verschiedene Engpässe

UEC definiert keinen universellen Überlastalgorithmus. Es unterscheidet zwischen Überlast im Netzwerkkern, Incast beim Empfänger und begrenzter Endpunktpufferung.

Network-signal Congestion Control (NSCC) ist sendergetrieben. Der Sender verwaltet ein Überlastfenster, schätzt die unterwegs befindlichen Bytes und passt das Fenster anhand von Bestätigungen, negativen Bestätigungen, Timeouts, Latenz und Netzwerksignalen wie ECN an. Es koordiniert das Fensterverhalten mit paketbasiertem Multipathing. UEC argumentiert, dass ein Fenster natürlich die Aufnahme von Daten stoppt, wenn Pakete das Netzwerk nicht verlassen, während ein rein ratenbasierter Kontroller fehlendes Feedback falsch interpretieren kann.

Das ist die architektonische Argumentation des Konsortiums, kein unabhängiger Beweis, dass jede NSCC-Implementierung DCQCN oder andere RoCE-Überlastkontrollen übertrifft. Die Ergebnisse hängen von Algorithmusdetails, Switch-Markierung, Topologie, Verkehrsmustern und Parameterwahl ab. „Verwendet NSCC“ ist daher keine ausreichende Leistungsbehauptung.

Receiver-credit Congestion Control (RCCC) zielt auf Incast. Wenn viele Quellen gleichzeitig an ein Ziel senden, kann die letzte Verbindung zum Engpass werden, selbst wenn der Netzwerkkern nicht überlastet ist. Der Empfänger verfolgt die Nachfrage und verteilt Guthaben unter den Sendern, wobei er die aggregierte Ankunft steuert und das effektive Fenster jeder Quelle je nach Wettbewerb variiert. RCCC kann parallel zu NSCC arbeiten, weil Empfängerüberlast und Kernüberlast unterschiedliche Probleme sind.

Transport Flow Control (TFC) verwendet ebenfalls Guthaben, dient aber Punkt-zu-Punkt-Diensten mit begrenztem Puffer. Ihr Zweck ist die direkte Verhinderung eines Empfängerpufferüberlaufs, wenn die Verlusttoleranz gering ist. Sie kann mit oder ohne Multipathing eingesetzt werden. Jeden Guthabenmechanismus gleich zu behandeln, würde die unterschiedlichen Ausfalldomänen verschleiern, die jeweils kontrolliert werden sollen.

Die Spezifikation erwartet Explicit Congestion Notification in der gesamten Fabric und enthält betriebliche Annahmen über die Markierung, einschließlich Markierung beim Dequeue und nicht nur basierend auf Enqueue-Verhalten. Endpunkte interpretieren ECN zusammen mit Bestätigungen, Latenz und Trimming. Eine konsistente Konfiguration über alle Switches hinweg ist daher unerlässlich. Eine Transportimplementierung kann korrekt sein, während eine falsch konfigurierte Fabric schlechte Ergebnisse liefert.

Die Wartungshistorie demonstriert die Schwierigkeit. Version 1.0.1 korrigierte den RCCC-Quellalgorithmus. Version 1.0.2 korrigierte Fälle des Überlastmanagements. Version 1.0.3 korrigierte Interaktionen mit Guthaben und Link Layer Retry. Dies sind normale Anzeichen einer lebenden Spezifikation, aber sie zeigen auch, dass Guthaben, Neuübertragung und Pfadkontrollzustände auf subtile Weise interagieren können. Betreiber werden Versionsdisziplin und Regressionstests benötigen, nicht nur Ersttagskonformität.

Packet Trimming und präzise Verlustwiederherstellung

Packet Trimming ändert, was ein fähiger Switch tut, wenn er ein ganzes Paket nicht bewahren kann. Anstatt den Rahmen ohne weitere Informationen zu verwerfen, entfernt der Switch den größten Teil oder die gesamte Nutzlast, bewahrt genügend Kopf- und Metadaten, um das Paket zu identifizieren, markiert es als getrimmt und leitet die verkürzte Benachrichtigung an den Empfänger weiter. Der Empfänger kann dann die spezifischen fehlenden Daten an den Sender melden.

Das ist informativer als eine ECN-Markierung. ECN sagt, dass Überlast aufgetreten ist; Trimming identifiziert ein Paket, dessen Nutzlast nicht überlebt hat. In Kombination mit RUD und selektiver Neuübertragung kann das die Wiederherstellung beschleunigen, ohne auf einen Timeout warten oder eine große Sequenz nach einem Verlust neu übertragen zu müssen.

Das Switch-Feature ist optional, aber konforme Endpunkte müssen getrimmte Pakete gemäß den zutreffenden Anforderungen empfangen und interpretieren. Diese Asymmetrie unterstützt die Bereitstellung über konventionelle Switches, während verbesserte Fabrics reichhaltigere Verlustinformationen liefern können. Sie schafft auch ein Upgrade-Problem. Ein teilweise verbessertes Netzwerk muss Trimming möglicherweise nach Pfad, Profil oder Topologie beschränken, damit jeder empfangende Endpunkt korrekt damit umgeht.

UEC definiert auch differenzierte Verkehrsklassen für Anfragen, Kontrollpakete, Neuübertragungen und getrimmten Verkehr. Betreiber müssen DSCP-Werte, Switch-Queues, Endpunkt-Queues und Prioritätsstufen konsistent zuordnen. Die Spezifikation stellt kein universelles Managementsystem für diese Zuordnung bereit. Eine Fehlanpassung kann Kontrollverkehr aushungern, Überlastfeedback verzerren oder Wiederherstellungspakete mit dem Verkehr konkurrieren lassen, den sie reparieren sollen.

Packet Trimming veranschaulicht die breitere Implementierungsherausforderung des Projekts. Das Protokoll kann das Leitungsverhalten definieren, aber das Betriebsergebnis hängt von Switch-Queueing, Endpunktlogik, Telemetrie, Konfiguration und Fehlerbehandlung ab. Interoperabilität ist daher eine Systemeigenschaft und keine Paketformateigenschaft.

Link-Wiederherstellung, Guthaben und Feature-Aushandlung

Link Layer Retry (LLR) versucht, Korruption auf einer physischen Verbindung wiederherzustellen, bevor der Ende-zu-Ende-Transport reagiert. Ein Peer erkennt eine Sequenzlücke oder einen korrupten Rahmen, sendet eine negative Bestätigung auf Verbindungsebene und veranlasst den Sender, den betroffenen Rahmen aus einem lokalen Puffer erneut zu senden. Wenn die Wiederherstellung schnell gelingt, kann der Transport eine längere Ende-zu-Ende-Neuübertragung vermeiden.

Der potenzielle Wert steigt, wenn die Lane-Raten und Portdichten zunehmen. Gelegentliche optische oder elektrische Fehler können sonst unverhältnismäßige Verzögerungen in einem eng synchronisierten Job verursachen. Doch LLR fügt Sequenzzustand, Wiederholungspuffer, Kontrollnachrichten, Verwerffenster und neue Ausfallmodi hinzu. Es muss auch mit Guthabenaktualisierungen und Link-Resets koexistieren. Version 1.0.3 korrigierte mehrere Grenzfälle, darunter eine Race-Condition mit CBFC-Guthabeninformationen und LLR.

Credit-Based Flow Control (CBFC) arbeitet pro virtuellem Kanal auf Verbindungsebene. Sie teilt einem Sender mit, wie viel Empfangskapazität verbleibt, und kann eine feinere Steuerung bieten als breites Priority Pausing. UEC präsentiert sie als einen Weg, kontrolliertes verlustfreies Verhalten zu unterstützen, ohne dass jede UET-Bereitstellung global verlustfrei sein muss. CBFC ist optional, und UET ist für den Betrieb über Best-Effort-Netzwerke ausgelegt.

CBFC sollte nicht als ein anderer Name für Priority Flow Control behandelt werden. Die Mechanismen unterscheiden sich in Signalisierung und Granularität, auch wenn beide Pufferüberlauf verhindern wollen. CBFC erfordert dennoch eine konsistente Konfiguration und die korrekte Zustellung ihrer eigenen Kontrollrahmen. Lokale Guthaben können auch mit Ende-zu-Ende-Fenstern und Empfängerguthaben interagieren, wodurch mehrere verschachtelte Kontrollschleifen entstehen.

UEC verwendet LLDP-basierte Aushandlung, um optionale Verbindungsfunktionen zu entdecken und zu verhindern, dass eine Seite eine Fähigkeit aktiviert, die ihr Nachbar nicht unterstützt. Die Aushandlung muss Profile, virtuelle Kanäle, DSCP- und Prioritätszuordnung, Resets, Software-Upgrades und partielle Feature-Kombinationen berücksichtigen. Version 1.0.3 fügte eine boolesche Aushandlungsfähigkeit hinzu und unterstrich damit die Bedeutung expliziter Einigung auf jeder Verbindung.

Diese Optionen bieten einen Weg von einfachem zu verbessertem Ethernet. Sie erzeugen aber auch eine Matrix, die Beschaffungssprache verschleiern kann. Ein Switch kann UET perfekt weiterleiten, aber Trimming, LLR oder CBFC vermissen lassen. Ein anderer kann die Funktionen nur in bestimmten Softwareversionen oder Portmodi unterstützen. Eine glaubwürdige Einsatzbilanz benötigt den exakten Funktionsumfang, nicht einfach den Konsortialnamen.

Physikalische Signalisierung mit 100 und 200 Gigabit pro Lane

Die physikalische Schicht verankert UEC in der Hardware-Roadmap. Die anfängliche 1.0-Arbeit wurde um 100-Gb/s-pro-Lane-Signalisierung herum geschrieben. Version 1.0.3 fügte Unterstützung für 200 Gb/s pro Lane hinzu. Diese Änderung bringt die Spezifikation in Einklang mit einer Generation höherer Link- und Systemdichten, aber es handelt sich um eine Spezifikationsfähigkeit, nicht um den Beweis, dass alle UEC-Produkte diese Rate sofort unterstützen.

Die PHY-Arbeit von UEC behandelt auch Vorwärtsfehlerkorrekturstatistiken, Verhältnisse korrigierter und nicht korrigierbarer Codewörter, geordnete Kontrollsätze, Verbindungsqualitätsberichte und die Interaktion zwischen physikalischen Fehlern und LLR. Diese Details sind wichtig, weil die Wiederherstellungsentscheidungen des Transports davon abhängen, was niedrigere Schichten beobachten und melden können.

Bei höheren Signalisierungsraten wird die Grenze zwischen Optiken, SerDes, FEC, Link Retry und Transportwiederherstellung wirtschaftlich bedeutsam. Stärkere FEC kann Restfehler auf Kosten von Latenz und Leistung reduzieren. Link Retry kann lokale Korruption schneller wiederherstellen, benötigt aber Puffer und Zustand. Ende-zu-Ende-Neuübertragung ist netzwerkweit einfacher, kann aber mehr Zeit verschwenden. UEC versucht zu definieren, wie diese Schichten zusammenarbeiten, anstatt jedem Anbieter zu erlauben, isoliert zu optimieren.

Die Hinzufügung von 200G-Lanes veranschaulicht auch das bewegliche Ziel des Konsortiums. Implementierer von Version 1.0 müssen Kompatibilität wahren, während sie neue physikalische Fähigkeiten planen. Testgeräte, Firmware und Managementsysteme müssen unterscheiden, was an jedem Port unterstützt wird. Käufer sollten die Lane-Rate nicht aus einer generischen UEC-Behauptung ableiten.

Optionale Ende-zu-Ende-Transportsicherheit

Die Transport Security Sublayer (TSS) bietet optionalen Ende-zu-Ende-Schutz. Ihr Bedrohungsmodell verlangt nicht, dass Switches vertrauenswürdig sind. Sie kann Vertraulichkeit, Integrität, Wiederholschutz, Job-Isolation, sichere Domänen, Gruppenschlüssel, Schlüsselrotation und Integration mit Hardware-Vertrauensankern liefern.

Das Design verwendet sichere Domänen, deren Mitglieder einen kryptografischen Kontext teilen. Identifikatoren, Assoziationsnummern, Epochen, sichere Quellidentität und Schlüsselableitung sollen skalieren, ohne für jedes Endpunktpaar eine unabhängige Sitzung aufzubauen. Das ist notwendig, wenn sich Beschleunigerpopulationen und Job-Mitgliedschaften schnell ändern.

Das Protokoll ist nur ein Teil des Sicherheitssystems. Ein Produktionsbetreiber muss Schlüsselautoritäten, Zertifikate oder andere Vertrauensanker, Job-Mitgliedschaftsdienste, Verteilung und Widerruf, Epochenübergänge, Endpunktwiederherstellung, Hardwarekryptografie und Sicherheitstelemetrie betreiben. Das Netzwerk kann einem Profil entsprechen, ohne jede optionale TSS-Funktion zu aktivieren. „UEC-konform“ bedeutet nicht automatisch verschlüsselt.

Die Optionalität der Sicherheit spiegelt unterschiedliche Bereitstellungsannahmen wider. Eine dedizierte, physisch kontrollierte Fabric kann Leistung priorisieren und sich auf Umgebungskontrollen verlassen. Eine Multi-Tenant-Cloud kann starke Isolation und kryptografischen Schutz erfordern. Das Profil- und Beschaffungssystem muss diesen Unterschied sichtbar machen.

Das schwerwiegendste Risiko ist nicht bloß der Verschlüsselungs-Overhead. Es ist das Lebenszyklusversagen im großen Maßstab: veraltete Mitgliedschaften, verzögerter Widerruf, inkonsistente Epochen, Wiederherstellung nach einem ausgefallenen Endpunkt oder die Unfähigkeit nachzuweisen, welcher Job auf welchen Speicher zugreifen darf. Diese Probleme verbinden die Transportsicherheit mit Orchestrierungs- und Identitätssystemen außerhalb der Kernspezifikation.

Was „UEC-konform“ derzeit bedeutet

UEC begann mit der Veröffentlichung von Compliance-Materialien mit Version 1.0, aber das öffentliche System ist kein ausgereiftes unabhängiges Zertifizierungsregime. Das verfügbare Paket ist hauptsächlich für die Selbstauskunft der Implementierer konzipiert. Matrizen ordnen Spezifikationsanforderungen Profilen zu, und Testbettanleitungen beschreiben empfohlene Endpunkt- und Switch-Konfigurationen. Es wurde keine umfassende öffentliche Datenbank identifiziert, in der eine unabhängige Autorität Produkte erfasst, die ein vollständiges UEC-Programm bestanden oder nicht bestanden haben.

Die Unterscheidung ist wesentlich, weil mehrere unterschiedliche Behauptungen im Markt kursieren. Ein Produkt kann um sich entwickelnde UEC-Funktionen herum entworfen sein. Es kann ausgewählte Leitungsfunktionen implementieren. Es kann ein Profil oder Teile eines Profils in einer bestimmten Softwareversion unterstützen. Ein Anbieter kann erklären, dass es vollständig funktionskonform ist. Ein Testlabor kann UET-Verkehr durch einen Switch erzeugen. Keine dieser Aussagen ist automatisch gleichbedeutend mit einer unabhängigen, multi-vendor-basierten Ende-zu-Ende-Zertifizierung.

Die öffentlichen Testbettempfehlungen sind nützlich, aber bewusst begrenzt. Sie bieten Best-Practice-Topologien und Prüfungen, jedoch keine vollständige Systemqualifikation. Die Materialien schließen umfassendere Interoperabilitäts-, Leistungs-, Stress-, Skalierungs- und API-Lebenszyklustests aus oder decken diese nicht vollständig ab. Sie beweisen kein Verhalten bei gemischtem UET- und RoCE-Verkehr, partiellen Upgrades, wiederholten Fehlern, großen Schlüsseldomänen oder den ambitioniertesten Endpunktzahlen des Konsortiums.

Die Profilnamen-Inkonsistenz zwischen AI Full und AI Extended veranschaulicht weiter, warum Compliance disziplinierte Versionierung braucht. Ein Käufer sollte fragen, welche Spezifikation, Korrekturstufe, welches Profil, welche optionalen Funktionen, Verbindungsmodi und Sicherheitsfunktionen eine Behauptung abdeckt. Die Antwort sollte angeben, ob die Evidenz aus internen Tests, einer bilateralen Demonstration, einer Konsortialveranstaltung oder einem unabhängigen Labor stammt.

Eine glaubwürdige nächste Stufe würde öffentliche Testdefinitionen umfassen, die an exakte Spezifikationsversionen gebunden sind, multi-vendor Plugfests, unabhängig verwaltete Ergebnisse, sowohl negative als auch erfolgreiche Resultate und ein Register, das Endpunkte, Switches, Software und vollständige Systeme unterscheidet. Bis dahin ist „UEC-konform“ eine Ausgangsfrage und keine vollständige Zusicherung.

Ein offenes Dokument mit RAND-Patentverpflichtungen

Die Ultra Ethernet Specification 1.0.3 ist öffentlich herunterladbar und wird unter der Creative Commons Attribution-NoDerivatives 4.0 Lizenz verbreitet. Dies erlaubt die Weiterverbreitung mit Namensnennung, gestattet aber nicht die Verbreitung modifizierter Versionen unter der Lizenz. Wichtiger noch: Der Zugang zum Urheberrecht und der Zugang zu Patenten sind getrennt.

Die dokumentierten Arbeitsgruppenchartas verwenden im Allgemeinen ein traditionelles Spezifikationsentwicklungsmodell mit angemessener und nichtdiskriminierender (RAND) Patentlizenzierung. RAND bedeutet nicht notwendigerweise lizenzgebührenfrei. Es garantiert keinen einheitlichen Preis, beseitigt nicht Verhandlungen und verhindert keine Streitigkeiten über Gültigkeit, Wesentlichkeit, geografischen Geltungsbereich oder defensive Bedingungen. Die tatsächliche kommerzielle Position hängt von jedem erklärten Patent, der Mitgliedsverpflichtung und etwaigen bilateralen Lizenzen ab.

UEC führt ein öffentliches Register der Erklärungen zu notwendigen Ansprüchen (Necessary Claims). Zum Stichtag waren Erklärungen von Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell und anderen sichtbar, einschließlich Einreichungen, die mit der zukünftigen 1.1-Arbeit verbunden sind. Das Register verbessert die Transparenz, indem es zeigt, dass Implementierer möglicherweise geistiges Eigentum prüfen müssen, bevor sie ein Produkt bauen oder ausliefern.

Das Konsortium stellt ausdrücklich nicht fest, ob ein erklärtes Patent gültig, tatsächlich wesentlich, verletzt oder zu einem bestimmten Preis verfügbar ist. Es veröffentlicht auch keine gemeinsame Lizenz. Kleine Implementierer können daher mit rechtlichen und Transaktionskosten konfrontiert sein, die große Mitglieder leichter tragen können. Eine öffentlich verfügbare Spezifikation kann dennoch ein kommerziell konzentriertes Implementierungsökosystem hervorbringen, wenn die Patentklärung, Siliziumkosten und Testaufwände hoch sind.

Der Rahmen des geistigen Eigentums formt auch die Governance-Anreize. Unternehmen tragen Technologie bei, teils um einen breiten Markt für ihre Produkte zu schaffen, und teils um sicherzustellen, dass ihre vorhandenen Fähigkeiten im gemeinsamen Design vertreten sind. Patentanmeldungen können Implementierer nur dann vor Überraschungen schützen, wenn sie rechtzeitig und hinreichend klar sind. Sie beseitigen nicht die Möglichkeit, dass die Lizenzierung zu einer Barriere wird, nachdem die Architektur Akzeptanz gefunden hat.

Die ehrliche Beschreibung lautet daher „öffentlich veröffentlicht und multi-vendor-fähig, mit RAND-Patentverpflichtungen“, nicht universell lizenzgebührenfrei. Beschaffungsteams benötigen sowohl das technische Profil als auch den Lizenzierungspfad.

Die erste Produkt- und Testwelle

Implementierungsbelege wurden um die 1.0-Veröffentlichung herum sichtbar, aber die Beispiele befinden sich in unterschiedlichen Reifegraden.

AMD brachte seine Pollara 400 AI-NIC im April 2025 auf den Markt und beschrieb sie als entworfen rund um sich entwickelnde UEC-Fähigkeiten. Pollara ist eine programmierbare Endpunktplattform und ein wichtiges Signal, dass der Transport in ausgelieferte Hardware übergegangen ist. Die Formulierung ist bedeutsam: Das Design für sich entwickelnde UEC-Funktionen ist nicht dasselbe wie eine unabhängige Zertifizierung gegen jede endgültige 1.0.3-Anforderung.

Broadcom kündigte Tomahawk 6 im Juni 2025 als einen 102,4-Terabit-pro-Sekunde Switch-ASIC mit für UEC-große Fabrics relevanten Funktionen an. Im Oktober kündigte es die Thor Ultra 800G NIC an und erklärte, dass das Design vollständige UEC-Funktionskonformität biete. Das ist eine bedeutende Herstellerbehauptung, aber öffentliche Belege wandeln sie nicht in ein unabhängiges Konsortialzertifikat um. Produktbemusterung, Software-Reife und die genaue Profilunterstützung sollten separat identifiziert werden.

Nokia und Keysight kündigten im Oktober 2025 eine Ende-zu-Ende-UET-Verkehrsdemonstration über die Rechenzentrums-Switch-Familien Nokia 7220 und 7250 mit 800 Gigabit Ethernet an. Keysight lieferte Verkehrserzeugung und Validierung. Der Test zeigt, dass UET-Verkehr kommerzielle Switch-Systeme durchqueren kann und dass die Unterstützung von Testgeräten wächst. Er etabliert kein vollständiges multi-vendor Endpunktprofil, keinen Produktionsmaßstab und keine unabhängige Zertifizierung jeder optionalen Funktion.

Andere Mitglieder haben UEC-fähige Switches, Systeme, Software oder Testpläne beschrieben, und der Gipfel 2026 konzentrierte sich stark auf die Produktisierung. Die Evidenz unterstützt einen Übergang in die Implementierung. Sie unterstützt noch keine exakte Zahl ausgelieferter UET-NICs, zertifizierter Switches, bereitgestellter Cloud-Regionen oder vollständiger Fabrics.

Der sinnvollste Weg, die Produktwelle zu lesen, ist als eine Kette von Belegen. Eine öffentliche Spezifikation ermöglicht Design. Silizium- und NIC-Ankündigungen zeigen Investitionen. Verkehrsdemonstrationen zeigen etwas Interoperabilität. Compliance-Matrizen ordnen Anforderungen. Einsatzberichte von Betreibern würden den betrieblichen Wert zeigen. Unabhängige Plugfests und Produktionsergebnisse würden die breitere Glaubwürdigkeit etablieren, die der aktuelle Datensatz noch vermissen lässt.

RoCE, InfiniBand, Slingshot und UALink

UEC tritt in einen Markt mit ausgereiften Alternativen und angrenzenden Technologien ein. Sein strategisches Argument ist nicht, dass Ethernet nie RDMA transportiert hat oder dass spezialisierte Fabrics nicht funktionieren. Es ist, dass das Ausmaß und die Synchronisation aktueller KI-Workloads eine neue Ende-zu-Ende-Ethernet-Architektur mit flexiblerer Zustellung, Pfadnutzung und Überlastkontrolle rechtfertigen.

RoCEv2 ist der direkte Vorgänger und eine weit verbreitete installierte Technologie. Es platziert RDMA-Verkehr auf routingfähigem Ethernet und verfügt über breite Anwendungs- und Produktunterstützung. UEC kritisiert gängige RoCE-Bereitstellungen für die Fixierung ganzer Flüsse auf einen Pfad, Go-Back-N-Wiederherstellung, Empfänger-Neuordnung, schwieriges DCQCN-Tuning, die Abhängigkeit von Priority Flow Control in vielen Designs und schwaches Verhalten bei Incast oder kollektiven Bursts. Dies sind die technischen Positionen des UEC, keine Belege dafür, dass jedes RoCE-Netzwerk schlecht abschneidet.

Der Vergleich ist zudem dynamisch. Anbieter können adaptives Routing, Packet Spraying, bessere Überlastalgorithmen oder andere UEC-ähnliche Funktionen zu programmierbaren NICs hinzufügen und dabei die RoCE-Kompatibilität erhalten. AMDs Botschaft rund um Pollara präsentiert zum Beispiel RoCEv2 und UEC RDMA als Optionen auf programmierbarer Hardware. UEC könnte daher mit RoCE als vollständigem Transport konkurrieren und gleichzeitig beeinflussen, wie sich zukünftige RoCE-Produkte entwickeln.

InfiniBand ist die hauptsächliche Alternative einer spezialisierten Fabric. Es bietet ein integriertes RDMA-, Überlast-, Verbindungszuverlässigkeits- und Management-Ökosystem mit langer HPC-Erfahrung. Die 2.0-Arbeit der InfiniBand Trade Association umfasst 200-Gb/s-pro-Lane XDR-Physikunterstützung und aktualisierte Telemetrie. Die stärkste Differenzierung des UEC ist nicht die Behauptung, dass InfiniBand keine Leistung bietet. Es ist die Möglichkeit, KI- und HPC-Verhalten über die breitere Ethernet-Lieferkette, Standard-IP-Routing und größere Multi-Vendor-Auswahl zu erreichen.

HPE Slingshot nimmt eine Zwischenposition ein. Es ist eine Ethernet-kompatible kommerzielle HPC-Fabric mit adaptivem Routing und Überlastmanagement und lieferte wichtige technische Vorläufer für UET. Es demonstriert, dass spezialisiertes Verhalten auf Ethernet aufgebaut werden kann, und zeigt gleichzeitig den Unterschied zwischen einer kontrollierten kommerziellen Plattform und einer branchenweiten Spezifikation.

UALink ist üblicherweise komplementär und kein direkter Ersatz. Seine aktuelle öffentliche 200G-Spezifikation zielt auf latenzarme Beschleuniger-zu-Beschleuniger Scale-up-Konnektivität innerhalb eines Pods und beschreibt Systeme mit bis zu 1.024 Beschleunigern. UEC 1.0 ist primär eine Scale-out-Fabric, die Knoten über Switches hinweg verbindet. Ein Rechenzentrum kann eine Scale-up-Verbindung innerhalb eines Rechen-Pods und UEC zwischen Pods oder Knoten verwenden.

Zukünftige UEC-Arbeiten zu optimiertem Scale-up-Transport und netzwerkinternen kollektiven Operationen könnten die Grenzen näher zusammenbringen und entweder Konvergenz oder Wettbewerb erzeugen.

NVIDIA Spectrum-X und proprietäre Beschleuniger-Fabrics stellen einen weiteren Vergleich dar: Ein eng integrierter Stapel 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 Anbieterwahl. Ob dieser Tausch lohnenswert ist, wird von Leistung, Support, Patentbedingungen, Interoperabilität und Gesamtbetriebskosten abhängen – nicht von Offenheit als abstraktem Etikett.

Das betriebliche Problem ist größer als das Protokoll

Eine 573-seitige Spezifikation kann viele Anforderungen definieren, aber eine Produktions-Fabric braucht dennoch ein Betriebsmodell. UEC 1.0 lässt wichtige Managementarbeiten außerhalb oder am Rande des normativen Kerndokuments. Betreiber müssen Profile, Verkehrsklassen, ECN-Schwellen, Entropiesätze, optionale Verbindungsfunktionen, Schlüssel, Firmware, Telemetrie und Fehlerrichtlinien konsistent über Endpunkte und Switches hinweg konfigurieren.

Gemischter Verkehr macht das Problem schwerer. Eine Rechenzentrums-Fabric kann UET, RoCE, TCP, Speicher, Management sowie sowohl geordnete als auch ungeordnete UET-Dienste transportieren. Die Warteschlangenzuteilung und Fairness zwischen diesen Klassen ist nicht allein dadurch gelöst, dass jedes Protokoll korrekt implementiert ist. Ein Überlastalgorithmus kann sich isoliert gut verhalten und schlecht, wenn er mit einem anderen Kontroller konkurriert, der anderes Feedback und andere Annahmen nutzt.

Die Endpunktkomplexität ist ein weiteres strukturelles Risiko. UET platziert Multipathing, direkte Datenplatzierung, selektive Neuübertragung, mehrere Zustellmodi, Fenster- und Guthabenkontrolle, Trimming-Empfang, Sicherheit und erheblichen Zustand im FEP. Das kann die NIC-Chipfläche, die Firmware-Größe, den Verifikationsaufwand, die Leistungsaufnahme und die Anzahl der zu diagnostizierenden Fehlerbedingungen erhöhen. Die Abhängigkeit des Projekts von der Endpunktintelligenz macht eine breite Lieferkette möglich, bedeutet aber auch, dass die schwierigste Implementierung in der Komponente sitzen könnte, die jeder Server kaufen muss.

Optionale Funktionen schaffen gleichzeitig Produktdifferenzierung und Fragmentierung. Ein Anbieter kann einen einfachen AI Base-Endpunkt für konventionelles ECMP und ECN optimieren. Ein anderer kann AI Full, TSS, Trimming, LLR und CBFC unterstützen. Beide können am UEC-Ökosystem teilnehmen, doch Betreiber können nicht dieselbe Semantik, Leistung oder Sicherheit voraussetzen. Compliance-Matrizen müssen zu betrieblichen Fähigkeitsmatrizen werden.

Die Versionspflege wird kontinuierlich sein. Korrekturen von 1.0.1 bis 1.0.3 betrafen Überlast, Guthaben, Retry und Paketverhalten. Ein großer Cluster kann mehrere NIC-Firmware-Versionen, Switch-Releases und Testwerkzeuge enthalten. Eine Schicht zu aktualisieren, ohne die anderen zu koordinieren, kann genau die schichtenübergreifende Race-Condition aufdecken, die das Konsortium zu vermeiden versucht.

Die externen Allianzen des UEC sind daher zentral und nicht zeremoniell. Das Open Compute Project kann den Transport mit offenen Systemen und Hardware verbinden. Die OpenFabrics Alliance und die libfabric-Community verbinden Anwendungen. IEEE 802.3 liefert formelle Ethernet-Arbeiten. SNIA und NVM Express bringen Speicher- und Managementanforderungen ein. IETF-Technologien liefern IP, ECN und verwandte Mechanismen. Diese Organisationen haben unterschiedliche Entscheidungsprozesse und Roadmaps; die Liaison reduziert Doppelarbeit, kann aber keine gleichzeitige Übernahme garantieren.

Der letzte betriebliche Test ist laufende Infrastruktur. Ein Dokument kann Verhalten spezifizieren, ein Anbieter kann ein Produkt ankündigen und ein Konsortium kann einen Gipfel organisieren. Nichts davon ersetzt einen Cluster, in dem unabhängige Endpunkte und Switches echte Aufträge unter Überlast, Ausfall und Upgrade abschließen, während die Betreiber erklären können, was passiert ist.

Aktuelle Relevanz: vom Spezifikationserfolg zur Implementierungsglaubwürdigkeit

Bis Juli 2026 hatte UEC mehrere Dinge erreicht, die beim Start unsicher waren. Es formte eine breite Koalition, produzierte eine integrierte Fünf-Schichten-Architektur, veröffentlichte eine vollständige 1.0-Spezifikation, pflegte sie durch Korrekturversionen, fügte 200G-pro-Lane-Unterstützung hinzu, legte Patentanmeldungen offen und zog Produkt- und Testankündigungen an. Das Projekt ist aktiv und seine Agenda hat sich entschlossen in Richtung Implementierung bewegt.

Dieser Fortschritt macht die nächsten Unsicherheiten wichtiger, nicht geringer. Die exakte aktuelle Mitgliedschaft und die Steering-Besetzung sind nicht in einem einzigen maßgeblichen Register veröffentlicht. Die öffentlichen Mitgliederseiten und die Satzung beschreiben den Zugang unterschiedlich. Die aktuelle formelle TAC-Führung ist nicht vollständig mit den Gipfelrollen abgeglichen. Das Erscheinungsdatum von 1.0.2 kollidiert über offizielle Dokumente hinweg. Das Compliance-Paket verwendet veraltete Profilterminologie.

Keines dieser Probleme zerstört die Architektur, aber jedes ist ein Signal über Dokumentenkontrolle und Transparenz in einem Projekt, in dem exakte Versionen zählen.

Schwerwiegendere Lücken betreffen die Adoption. UEC veröffentlicht keine Einsatzstatistik, kein unabhängig geprüftes Produktregister, keinen eigenständigen Haushaltsplan oder geprüfte Abschlüsse. Keine öffentliche Evidenz belegt ein vollständig interoperables UEC 1.0-Netzwerk in den maximalen Skalenzielen des Konsortiums. Anbieterdemonstrationen und Behauptungen sind wertvoll, aber kommerziell interessiert. Neutrale Leistungsvergleiche mit aktuellem RoCE, InfiniBand und integrierten Ethernet-Plattformen bleiben begrenzt.

Die Chance des Konsortiums ist dennoch beträchtlich. Ethernet ist der gemeinsame Nenner in Rechenzentren, und der KI-Infrastrukturmarkt ist groß genug, um neue NIC-, Switch-, Optik- und Software-Generationen zu tragen. Betreiber haben starke Anreize, Einzelanbieterabhängigkeit zu vermeiden und die Beschleunigerauslastung zu verbessern. Ein gemeinsamer Stapel könnte diese Anreize in Beschaffungshebel umwandeln.

Sein Risiko ist, dass „Ultra Ethernet“ zu einem Dach für inkompatible Funktionsuntermengen wird. Wenn die Basisweiterleitung funktioniert, aber Profile, Überlast, Sicherheit und Management auseinanderlaufen, könnte sich die Marke schneller verbreiten als die Interoperabilität. Wenn die RAND-Lizenzierung teuer oder unsicher ist, könnte sich die Anbieterzahl verengen. Wenn RoCE-Produkte die attraktivsten Ideen aufnehmen, ohne einen neuen Transport zu erfordern, könnte 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. Die Frage ist, ob unabhängige Organisationen dieselben Verträge implementieren, die notwendige Technologie lizenzieren, die Fabric in großem Maßstab betreiben und die Kompatibilität bewahren können, während sich die Spezifikation weiterentwickelt. UEC wird nur in dem Maße zur Infrastruktur, wie diese Behauptungen den Kontakt mit laufendem Code überstehen.