Zusammenfassung

  • Das Ultra Ethernet Consortium ist ein Projekt der Joint Development Foundation und wurde am 19. Juli 2023 von AMD, Arista Networks, Broadcom, Cisco, Eviden/Atos, Hewlett Packard Enterprise, Intel, Meta und Microsoft ins Leben gerufen. Es handelt sich um ein Industriekonsortium zur Spezifikationsentwicklung, nicht um ein herkömmliches Unternehmen oder einen Netzbetreiber.
  • Der Umfang von UEC geht weit über eine schnellere Ethernet-Verbindung oder einen RoCE-Ersatz hinaus. Die Spezifikation 1.0.3 umfasst 573 Seiten und deckt die Software-, Transport-, Vermittlungs-, Verbindungs- und physikalische Schicht sowie Management-, Speicher-, Test- und Compliance-Arbeiten rund um den Kernstack ab.
  • Ultra Ethernet Transport vereint mehrere Auslieferungsmodi, Paket-Multipathing, selektive Wiederholungsanforderungen, Congestion Control auf Sender- und Empfängerseite, ECN, optionales Packet Trimming, optionales Link-Layer-Retry, optionale kreditbasierte Flusskontrolle und optionale Ende-zu-Ende-Transportsicherheit.
  • Produkte und Demonstrationen von AMD, Broadcom, Nokia und Keysight deuten auf eine beginnende Implementierung hin, doch die öffentliche Compliance beruht noch weitgehend auf Selbstauskünften der Implementierer. Ein umfassendes, unabhängiges Zertifizierungsregister oder Produktionsstatistiken für großflächige Deployments liegen nicht vor.
  • Die strategische Chance von UEC liegt in der etablierten Ethernet-Basis und der Multi-Vendor-Lieferkette. Die größten Risiken sind die Komplexität der Endpunkte, Fragmentierung durch optionale Funktionen, RAND-Patentverpflichtungen, unausgereiftes Management und Testing sowie die Lücke zwischen Spezifikationsveröffentlichung und dem Nachweis produktionsreifer Interoperabilität.

Warum KI das Netzwerk zum Teil des Computers machte

Das Ultra Ethernet Consortium entstand als Antwort auf einen Wandel in der Computing-Ökonomie. In einem normalen Unternehmensnetz wird vom Fabric erwartet, eine große Anzahl unabhängiger Flows mit akzeptablem Durchsatz und Verfügbarkeit zu transportieren. In einem großen KI-Trainingssystem oder einem HPC-Rechner hingegen wird das Netzwerk Teil einer einzigen synchronen Berechnung. Tausende Beschleuniger können Modellparameter, Gradienten oder wissenschaftliche Daten in kollektiven Operationen austauschen. Der nächste Schritt kann möglicherweise erst beginnen, wenn der langsamste Teilnehmer die erforderlichen Informationen erhalten hat.

Schon ein kleines Missverhältnis zwischen den Pfaden, ein Stau oder ein einziger Paketverlust kann teure Prozessoren zum Warten zwingen, selbst wenn die durchschnittliche Auslastung des Fabrics gut erscheint.

Das verändert die Optimierungsziele der Betreiber. Die Gesamtkapazität bleibt wichtig, reicht aber nicht aus. Entscheidend sind auch die Jobabschlusszeit, die Tail-Latenz, Incast, die Wiederherstellung nach Paketverlust, die Verkehrsverteilung auf parallele Pfade und die Frage, wie viel Zustand die Endpunkte halten müssen. Ein Netz, das die meisten Pakete schnell zustellt, aber einen kleinen Teil verzögert, kann eine ganze kollektive Operation stören. Eine Wiederholungsstrategie, die für herkömmlichen Verkehr akzeptabel ist, kann viel zu langsam sein, wenn ein einzelnes Paket einer langen Nachricht verloren geht.

Ein Flow, der an einen einzigen Equal-Cost-Pfad gebunden ist, kann schlechte Leistung zeigen, während anderswo in der Topologie noch Kapazität frei wäre.

Die Gründungsprämisse von UEC war, dass sich diese Probleme nicht mit einer einzigen neuen Switch-Funktion oder einem modifizierten Congestion-Algorithmus lösen lassen. Der Kommunikationspfad beginnt oberhalb des Netzwerks – in Softwarebibliotheken und Anwendungssemantiken – und durchläuft Speicherregistrierung, entfernte Operationen, Transportzustand, Paketzustellung, Congestion Control, IP-Routing, Ethernet-Links, Optik und physikalische Signale. Werden diese Schichten isoliert voneinander entworfen, kann eine Optimierung an einer Stelle den Engpass verschieben oder inkompatible Annahmen an anderer Stelle erzeugen.

Die Antwort von UEC ist eine koordinierte Architektur. Ethernet und IP bleiben erhalten, weil die Betreiber sie kennen und weil eine riesige Lieferkette rund um Switches, Optiken, Kabel, Netzbetriebssysteme, Telemetrie und Management gewachsen ist. Gleichzeitig ändert oder erweitert das Konsortium jene Teile, die es für ungeeignet für große KI- und HPC-Lasten hält. Das Ergebnis ist kein „normales Ethernet mit neuem Logo", sondern der Versuch, ein vertrautes Netz mit einem spezialisierten Transport zu verbinden, dessen Verhalten von der Softwareschnittstelle bis zur physikalischen Datenrate durchdefiniert ist.

Das erklärt, warum UEC für die digitale Infrastruktur von Bedeutung ist. Das Projekt besitzt keine Beschleuniger, keine Fertigungsanlagen, keine Rechenzentren und keine Cloud-Regionen. Es definiert Verträge, die Mitgliedsunternehmen und andere Implementierer in NICs, Switch-ASICs, Systeme, Treiber, Bibliotheken und Testgeräte einbauen können. Seine Wirkung entfaltet sich erst, wenn diese unabhängigen Produkte bei Ausfällen, Überlast, Upgrades und gemischten Lieferanten korrekt zusammenarbeiten.

Was UEC ist – und was es nicht ist

Das Ultra Ethernet Consortium ist der öffentliche Name eines formellen Projekts, dessen vollständiger rechtlicher Name Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series lautet. Die „Series"-Struktur bettet das Projekt in die Joint Development Foundation und die breitere Linux-Foundation-Familie ein. Sie gibt den Teilnehmern einen bewährten rechtlichen Rahmen für Mitgliedschaft, Governance, geistiges Eigentum, Finanzierung und Außenbeziehungen, ohne dass sie ein neues eigenständiges Unternehmen gründen müssen.

Diese Struktur ist wichtig, weil UEC gelegentlich ungenau als Unternehmen, Allianz oder Normungsgremium bezeichnet wird. Es ist kein kommerzielles Unternehmen mit Aktionären, Kapital, Bewertung und eigenständigen Konten. Es verkauft keine Ethernet-Produkte, betreibt kein öffentliches Netz und besitzt auch nicht die Hardware, die seine Mitglieder bewerben. Es ist ein Spezifikationsentwicklungskonsortium mit einem rechtlichen Rahmen für geistiges Eigentum. Seine öffentlichen Dokumente sind dazu gedacht, Implementierungsverträge zwischen mehreren Unternehmen zu werden.

Ebenso ist UEC nicht mit Ultra Ethernet Transport gleichzusetzen. UET ist die Transportarchitektur im Kern der Spezifikation, aber die Arbeit des Konsortiums ist breiter. Sie umfasst die Abstimmung mit libfabric, Paket- und Nachrichtensemantiken, Netzwerkannahmen, Optionen der Verbindungsschicht, Anforderungen der physikalischen Schicht, Management, Speicherabstimmung, Performance- und Debugging sowie Compliance und Tests. Das Projekt auf „ein neues RDMA-Protokoll" zu reduzieren, verdeckt den schichtenübergreifenden Entwurf, der es sowohl ehrgeizig als auch schwierig macht.

UEC ist auch nicht die IEEE 802.3-Arbeitsgruppe. Letztere entwickelt die grundlegenden Ethernet-MAC- und PHY-Standards in ihrem eigenen formalen Prozess. UEC baut auf diesem System auf und pflegt eine Koordinationsbeziehung, ersetzt es aber nicht. Gleiches gilt für die IETF-Mechanismen, die UET nutzt, einschließlich IPv4, IPv6 und Explicit Congestion Notification, für das OpenFabrics-Ökosystem, das libfabric pflegt, sowie für Gremien aus den Bereichen Speicher, offene Hardware und Beschleunigerverbindungen.

Die Projektwebsite verwendete Formulierungen, die den Status einer internationalen Normungsorganisation nahelegen. Die sicherere und besser belegte Beschreibung lautet, dass UEC eine internationale Spezifikationsentwicklungsorganisation innerhalb des JDF-Rahmens ist. Es gibt keinen Beleg dafür, dass es Teil der International Organization for Standardization ist, dass seine Dokumente ISO-Standards sind oder eine ISO-Normnummer tragen. Die Unterscheidung ist nicht rein semantisch; sie bestimmt die Autorität, die Art der Teilnahme und die rechtlichen Verpflichtungen, denen Implementierer gegenüberstehen könnten.

Daher sollte UEC anhand seiner tatsächlichen Rolle bewertet werden: Es koordiniert Wettbewerber und Betreiber rund um einen gemeinsamen technischen Entwurf, veröffentlicht Spezifikationen, betreibt Arbeitsgruppen und offengelegte Patentverpflichtungen und entwickelt Compliance-Materialien sowie Beziehungen zu benachbarten Gremien. Es kann jedoch nicht allein durch Ankündigung ein Produkt interoperabel machen oder den Markt zur Übernahme seiner Architektur zwingen.

Das aus neun Unternehmen bestehende Gründungskonsortium

Das Konsortium wurde am 19. Juli 2023 von neun Organisationen angekündigt, die verschiedene Ebenen der KI- und HPC-Lieferkette besetzen: AMD, Arista Networks, Broadcom, Cisco, Eviden (damals mit Atos verbunden), Hewlett Packard Enterprise, Intel, Meta und Microsoft. Diese Vielfalt war von Anfang an strategisch. Ein Transport, der allein von Switch-Herstellern entworfen wird, könnte Anwendungs- und Endpunktbeschränkungen übersehen. Ein von Beschleunigerfirmen getriebener Entwurf könnte auf ein einzelnes Hardware-Ökosystem optimiert sein.

Ein nur von Cloud-Unternehmen geführtes Projekt könnte nicht über das nötige Silizium-, Optik- und Systemwissen verfügen, um die Architektur in Produkte umzusetzen.

AMD brachte Prozessoren, Beschleuniger und Endpunkt-Vernetzung ein. Arista und Cisco steuerten umfangreiche Ethernet-Switching- und Betriebserfahrung bei. Broadcom trug Switch-Silizium, NICs und Hochgeschwindigkeits-SerDes bei. HPE und Eviden brachten HPC-System- und Spezialverbindungs-Know-how ein. Intel lieferte Prozessoren, Ethernet und Software. Meta und Microsoft repräsentierten Hyperscale-Betreiber mit direktem Interesse, die Auslastung großer KI-Cluster zu erhöhen und die Abhängigkeit von einem einzelnen integrierten Anbieter zu verringern.

Das Konsortium umfasst auch konkurrierende Geschäftsinteressen. Die Mitglieder verkaufen NICs, Switch-Chips, Systeme, Cloud-Kapazität, Optiken, Software und Support. Einige besitzen Patentportfolios, die für eine Implementierung möglicherweise wesentlich sind. Manche profitieren von einem breiten Multi-Vendor-Standard, können aber zugleich an proprietären Differenzierungsmerkmalen verdienen. Daher schafft das Konsortium keinen Wettbewerbsausschluss, sondern ein Forum, in dem Wettbewerber minimale Schnittstellen vereinbaren und gleichzeitig um Implementierungsqualität, Leistung, Integration und kommerzielle Konditionen konkurrieren.

HPEs Slingshot ist ein nützliches Beispiel für die technische Herkunft. Dabei handelt es sich um ein kommerzielles, Ethernet-kompatibles HPC-Fabric mit adaptivem Routing und Congestion-Management. Mit HPE in Verbindung gebrachte Kommentare besagen, dass eine „HPC-Ethernet"-Spezifikation in die UEC eingebracht wurde, und schätzen, dass ein erheblicher Anteil von UET von Slingshot-Transportideen abgeleitet ist. Die genaue Prozentzahl ist unabhängig nicht bestätigt und sollte nicht als offizielle Konsortialangabe wiedergegeben werden.

Der breitere Punkt ist jedoch gut gestützt: UEC begann nicht bei null, sondern baute auf Produktionserfahrung in HPC, Cloud-Netzwerken, RDMA und Ethernet auf.

Diese Mischung aus Vorläufersystemen ist ein Grund, das Wort „offen" mit Vorsicht zu verwenden. Die verabschiedete Spezifikation ist öffentlich zum Download verfügbar, und die Architektur ist auf eine Implementierung durch mehrere Anbieter ausgelegt. Aber das Projekt ist auch ein Ort, an dem Mitglieder Vorwissen, Patente und Produkt-Roadmaps einbringen. Die Offenheit des Dokuments ändert nichts an den wirtschaftlichen und rechtlichen Bedingungen, die die Technologie umgeben.

Ein für Wettbewerbskooperation konzipierter Rechtsrahmen

Das Joint Development Foundation-Modell gibt dem UEC eine formelle Struktur, ohne es in ein klassisches Betriebsunternehmen zu verwandeln. Das Projekt hat einen Namen, einen Geltungsbereich, Mitgliedschaftskategorien, einen Steering Committee, Arbeitsgruppen und Verpflichtungen zum geistigen Eigentum. Der JDF-Dach bietet die institutionelle und gemeinnützige Struktur und kann Projektvermögen und Vereinbarungen halten. Dies senkt die Kosten für die Gründung eines Konsortiums und gibt Wettbewerbern einen anerkannten Prozess für die Zusammenarbeit.

Die Governance des Projekts liegt beim Steering Committee. Zu seinen dokumentierten Aufgaben gehören die Koordination der Arbeitsgruppen, die Aufnahme von Mitgliedern, die Verwaltung von Vermögen und Mitteln, die Auswahl oder Ablösung des Vorsitzenden, die Fortschrittsüberwachung sowie die Kontrolle über öffentliche Bekanntmachungen und Projektkennzeichen. Konsens wird bevorzugt. Ist kein Konsens möglich, sieht das Organisationsdokument einen Mechanismus mit einer Supermajorität von drei Vierteln der qualifizierten Teilnehmer vor, die die Anwesenheitsanforderungen erfüllen. Schriftliche Einwände können beim Vorsitzenden eingereicht werden.

Erster Vorsitzender war Brad Booth von Meta. Die aktuelle Spezifikation 1.0.3 nennt 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. Paul Congdon wird als Herausgeber der Spezifikation geführt. Das Dokument nennt außerdem Leiter und Autoren für die Bereiche physikalische Schicht, Verbindungsschicht, Transport und Software. Die Agenda des Gipfels 2026 listet weitere operative Verantwortliche auf.

Diese Rollen ersetzen nicht notwendigerweise die formalen Titel in der Spezifikation, und ein vollständiges, aktuelles öffentliches Organigramm liegt nicht vor.

Das Organisationsdokument sieht drei Mitgliedschaftskategorien vor: Steering, General und Contributor. Steering-Mitglieder nehmen an der Governance teil und benennen in der Regel Vertreter für den Steering Committee. General-Mitglieder können in allen technischen Gruppen mitarbeiten, haben aber keine Sitze im Committee. Contributor-Mitglieder wirken in ausgewählten Gruppen mit und besitzen kein Stimmrecht bei Supermajoritätsentscheidungen. Die öffentliche Mitgliedsseite zeigt derzeit General- und Contributor-Kategorien zu jährlichen Gebühren von 20.000 USD bzw.

5.000 USD zuzüglich einer Linux Foundation-Mitgliedschaft, erklärt aber den Aufnahmeweg oder den aktuellen Preis für die Steering-Kategorie nicht klar.

Der Unterschied in der formellen Autorität ist wichtig. Eine breite Mitgliedschaft bringt Expertise und Implementierungsreichweite, aber die Governance ist nicht gleichmäßig verteilt. Große Unternehmen, die Steering-Sitze besetzen, Ingenieure für mehrere Gruppen abstellen und Patent- sowie Produktprogramme steuern können, haben praktisch mehr Einfluss als kleinere Contributor-Mitglieder. Nichtmitglieder können die fertige Spezifikation herunterladen, sehen aber nicht den gesamten Entwurfsprozess und nehmen nicht gleichberechtigt teil.

Interne Informationen des Projekts werden nicht wie vertrauliche Unternehmensdaten behandelt, doch es ist den Mitgliedern untersagt, Entwurfsmaterialien vor der Freigabe durch das zuständige Gremium zu veröffentlichen. Das kann Wettbewerbern helfen, unfertige Ideen ohne verfrühte Marktsignale zu diskutieren. Es bedeutet jedoch auch, dass die Öffentlichkeit abgelehnte Vorschläge, Abstimmungsprotokolle, zwischenzeitliche Implementierungsbedenken oder die Verhandlungen, die zu optionalen Merkmalen führten, nicht einsehen kann. Die fertige Spezifikation ist offen; der Weg dorthin ist nur teilweise sichtbar.

Von vier Arbeitsgruppen zu einer 573-seitigen Spezifikation

Die erste öffentliche Struktur der UEC im Jahr 2023 konzentrierte sich auf vier Arbeitsgruppen: Software, Transport, Verbindung und physikalische Schicht. Die Reihenfolge spiegelte den End-to-End-Anspruch des Projekts wider. Die Mitgliedschaft wurde nicht sofort als unbegrenzte öffentliche Mailingliste geöffnet. Über 200 Organisationen bekundeten Interesse, und das Konsortium führte den Beitritt schrittweise durch, mit obligatorischen Verfahrenshinweisen und Kartellregeln. Die Vorsicht war verständlich, denn die Teilnehmer konkurrieren direkt in mehreren Märkten und würden gemeinsame Anforderungen an Produkte und Protokolle diskutieren.

Bis Dezember 2023 berichtete UEC von rund 40 Unternehmen und über 300 Einzelpersonen. Ein Technical Advisory Committee war eingerichtet und die Zahl der Arbeitsgruppen auf acht angewachsen. Aufgabe des TAC war es, die architektonische Kohärenz zu wahren: Der Transportentwurf sollte kein Verhalten voraussetzen – weder im Switch noch in der Signalisierung oder API –, das keine andere Gruppe zu unterstützen bereit war. Im März 2024 meldete das Konsortium 55 Unternehmen, über 750 aktive Teilnehmer und veröffentlichte eine wesentlich klarere Beschreibung der angestrebten Architektur.

Die März-Updates enthielten die Kernkonzepte, die später in der Standardspezifikation erschienen: libfabric als softwareorientierte API, Packet Spraying, flexible Ordnung, mehrere Auslieferungsmodi, sender- und empfängerseitige Congestion Control, ECN, Packet Trimming, Link Layer Retry, optionale kreditbasierte Flusskontrolle, Transportsicherheit und zukünftige In-Network Collective Operations. Außerdem wurde betont, dass UET über bestehende Ethernet-Switches laufen kann, während optimierte Switches zusätzliche Leistung bieten.

Parallel zur technischen Arbeit wuchs die institutionelle Beteiligung. Im Juli 2024 sprach UEC von 1.193 aktiven Teilnehmern, im August von 97 Mitgliedsorganisationen. Dies sind datierte Angaben des Konsortiums, die auf nicht vollständig öffentlichen Definitionen beruhen und daher nicht einfach mit späteren Ankündigungen kombiniert werden sollten. 2025 teilte das Konsortium mit, dass 27 weitere Unternehmen beigetreten seien, doch Austritte, Fusionen und überlappende Zeiträume verhindern eine verlässliche aktuelle Gesamtzahl. Die Website selbst weist darauf hin, dass nicht alle Mitglieder auf der Seite erscheinen.

Am 11. Juni 2025 veröffentlichte das Konsortium die Ultra Ethernet Specification 1.0. Das war der Moment, in dem UEC von einer Roadmap zu einer öffentlichen Implementierungsbasis überging. Im September folgte Version 1.0.1, die einen Quellalgorithmus im Receiver-Credit Congestion Control und redaktionelle Probleme korrigierte. Version 1.0.2 kam im Januar 2026 und korrigierte Congestion-Management-Algorithmen, wobei sich offizielle Dokumente uneins sind, ob das Veröffentlichungsdatum der 21. oder der 28. Januar war. Dieser Widerspruch sollte sichtbar bleiben und nicht ohne Hinweis bereinigt werden.

Version 1.0.3, veröffentlicht am 16. Juli 2026, ist zum Recherchezeitpunkt die aktuelle Referenz. Sie umfasst 573 Seiten und ergänzt die Unterstützung für 200 Gbit/s pro Lane sowie eine logische Aushandlungsfähigkeit. Die Release Notes nennen zwingende Korrekturen in Bezug auf Paketzustellung, Congestion Credits, Link Layer Retry und Control Ordered Sets der physikalischen Schicht sowie Klarstellungen zu Transportsicherheit, atomaren Operationen und getrimmten Paketen.

Der Unterschied zwischen zwingenden Korrekturen und redaktionellen Klarstellungen ist bedeutsam, da einige Änderungen das konforme Verhalten beeinflussen und Implementierungspflege erfordern.

Der Denver-Mitgliedergipfel 2026 markierte einen zweiten Übergang. Die Agenda konzentrierte sich auf Deployment, Produktumsetzung, Compliance, Management, Performance, Debugging, Speicherintegration und das Testen von Switches und Endpunkten. Das architektonische Grundlagendokument steht; die Glaubwürdigkeit des Projekts hängt nun stärker davon ab, ob die Implementierer den gesamten Stack bauen, qualifizieren, betreiben und über Organisationsgrenzen hinweg aktualisieren können.

Eine Architektur über fünf funktionale Schichten hinweg

Die aktuelle Ultra-Ethernet-Spezifikation unterteilt sich in die Schichten Software, Transport, Vermittlung, Verbindung und physikalische Schicht. Diese Einteilung ist nützlich, aber der Wert des Projekts liegt in den Annahmen, die diese Schichten verbinden.

Oben interagieren KI-Frameworks, MPI, SHMEM und Collective-Libraries über OpenFabrics Interfaces, insbesondere libfabric. Der UET Semantic Services Sublayer übersetzt Anwendungsoperationen in Transporttransaktionen. Der Packet Delivery Sublayer entscheidet, wie Nachrichten segmentiert, geordnet, bestätigt und wiederhergestellt werden. Das Congestion Management steuert, wie viele Daten in das Fabric gelangen und wie der Verkehr auf Pfade verteilt wird. Die optionale Transportsicherheit schützt den Verkehr von Ende zu Ende. Standard-IPv4 oder IPv6 stellt das Routing auf der Vermittlungsschicht bereit.

Ethernet liefert die Verbindung, optional mit Packet Trimming, Link Layer Retry, kreditbasierter Flusskontrolle und Merkmalsaushandlung. Die physikalische Schicht definiert Statistiken und Signalparameter bei 100 oder 200 Gbit/s pro Lane.

Diese Architektur erhält wichtige Teile des heutigen Netzwerks. UEC definiert keinen Ersatz für IP-Routing, sondern setzt auf herkömmliches ECMP und ECN-fähige Switches. Ein Großteil der Intelligenz verbleibt in den Fabric Endpoints, die Entropy-Werte ändern, Transportzustand nachverfolgen, Daten platzieren und auf Congestion-Signale reagieren. Optimierte Switches können Funktionen hinzufügen, aber das Design erzwingt keinen vollständigen Fabricaustausch, bevor UET-Verkehr fließen kann.

Das bietet einen Migrationsvorteil, schafft aber ein Klassifikationsproblem. Ein Deployment könnte UET-Endpunkte über herkömmliches Ethernet mit ECMP und ECN betreiben; ein anderes könnte Trimming, Link-Retry, kreditbasierte Flusskontrolle pro virtuellen Kanal, reichhaltigere Telemetrie und künftige In-Network-Operationen hinzufügen. Beide könnten „Ultra Ethernet" heißen, obwohl sich Leistung, Wiederherstellungsverhalten und Betriebskomplexität grundlegend unterscheiden.

Zudem erschwert der Fünf-Schichten-Ansatz die Isolierung von Implementierungsfehlern. Schlechte Leistung kann aus der Anwendungsabstimmung, der Endpunkt-Zustandsmaschine, den Congestion-Parametern, der Switch-Warteschlangenkonfiguration, der DSCP-Zuordnung, der Optik, der Firmware oder dem Sicherheitssystem stammen. Paketdurchlauf allein reicht nicht. Das System muss die beabsichtigte Semantik und Leistung unter Skalierung, Mischverkehr, Ausfällen und wechselnden Versionen aufrechterhalten.

Der Softwarevertrag: libfabric statt einer proprietären API

UEC wählt libfabric 2.0 als primäre API auf der oberen Seite für konforme Endpunkte. Diese Entscheidung bindet das Projekt an ein bestehendes Software-Ökosystem für HPC und fortschrittliche Netzwerke, anstatt von jedem Framework die Übernahme einer neuen proprietären Schnittstelle zu verlangen. libfabric repräsentiert bereits Fabrics, Domains, Endpunkte, Completion Queues, Event Queues, Address Vectors, Speicherregionen, Nachrichten, entfernte Speicheroperationen und atomare Operationen. UEC ordnet und begrenzt diese Konzepte, damit Anbieter die Aufrufe in UET-Verhalten umsetzen können.

Der strategische Wert liegt in der Kontinuität oberhalb des Transports. MPI, SHMEM und Beschleuniger-Kommunikationsbibliotheken können vertraute Abstraktionen nutzen, selbst wenn sich der darunterliegende Anbieter ändert. Prinzipiell kann eine Anwendung eine Operation anfordern, ohne zu wissen, welcher NIC-Anbieter die Zustellung ausführt oder welcher Switch-Siliziumtyp die Pakete routet. Das ist einer der wichtigsten Mechanismen, mit denen ein gemeinsamer Transport Auswahlmöglichkeiten zwischen Anbietern schaffen könnte.

Die Abstraktion garantiert keine gleichwertigen Implementierungen. Anbieter können unterschiedliche Inject-Größen, Scatter/Gather-Grenzen, Endpunktzahlen, atomare Operationen, Speicherregistrierungstechniken, Completion-Verhalten, Hardware-Offload und Sicherheitsfunktionen unterstützen. Eine Bibliothek, die auf derselben API aufbaut, kann auf unterschiedliche Leistungs- und Fähigkeitsgrenzen stoßen. Daher benötigen Beschaffung und Software-Qualifikation mehr als ein Etikett mit der Aufschrift „libfabric supported".

Die Softwareschicht trägt auch die Semantik von Aufgaben und Delegation. KI- und HPC-Systeme führen oft viele Aufgaben auf einer gemeinsamen Infrastruktur aus, jede mit eigenen Operationen, Speicherbereichen und Sicherheitsgrenzen. Die Spezifikation muss festlegen, welcher Endpunkt zu welcher Aufgabe gehört, welcher Speicher zugreifbar ist, wie eine entfernte Operation zugeordnet wird und wie Abschluss- oder Fehlerinformationen an die Software zurückgegeben werden. Diese Entscheidungen bestimmen, ob das schnelle Netzwerk für Scheduler, Laufzeitumgebung und Anwendung nutzbar ist – nicht nur als beeindruckende Zahl in einem Paket-Benchmark.

Das Projekt stützt sich auf das OpenFabrics-Ökosystem, weil es libfabric nicht selbst besitzt. Diese Beziehung veranschaulicht ein breiteres Merkmal von UEC: Die Architektur ist aus Komponenten zusammengesetzt, die an verschiedenen Orten gesteuert werden. Das Konsortium kann die Transportanpassung an libfabric spezifizieren, muss sich aber mit den Betreuern der API und ihren Nutzern abstimmen. Ähnliche Abhängigkeiten bestehen bezüglich Ethernet bei der IEEE, IP-Mechanismen bei der IETF, Speichergremien und Betriebssystemen der Anbieter.

Fabric Endpoints und Profile

Ein Fabric Endpoint (FEP) ist der logische Ort, an dem UET endet. Er verbindet eine Betriebssysteminstanz mit einer oder mehreren isolierten Fabric-Ebenen und kann einen Userspace-Provider, einen Kernel-Treiber, einen Transport innerhalb der NIC oder des Beschleunigers, ein Speicherregistrierungssystem, einen Sicherheitskontext, Completion Queues, Address Vectors sowie Zustand für Paketzustellung und Congestion Control umfassen.

Dieses Endpunkt-zentrierte Design erlaubt es den meisten Switches, als transparente Ethernet- und IP-Geräte zu fungieren. Der FEP wählt Entropy-Werte, führt Paket- und Congestion-Zustand, platziert Daten in autorisierten Speicher und interpretiert Acknowledgements, Trimming und anderes Feedback. Das kann die Abhängigkeit von proprietärer Routing-Intelligenz im Switch verringern, konzentriert aber die Komplexität in NIC-Silizium, Firmware, Treibern und Software.

UEC definiert drei Implementierungsprofile: AI Base, AI Full und HPC. Es handelt sich nicht um getrennte Netztypen, sondern um Funktionsbündel, die eine Implementierung unterstützen muss. AI Base soll gängige KI-Kommunikation mit geringeren Kosten und weniger Implementierungszustand abdecken. AI Full fügt Funktionen wie deferrable Sends, Exact Matching und atomare Fetch- oder Compare-Operationen hinzu. Das HPC-Profil umfasst die meisten AI-Full-Fähigkeiten, schließt deferrable Send jedoch aus und betont stärker Ordnung, kurze Nachrichten und HPC-Semantik.

Das Profilsystem soll verhindern, dass jedes Produkt den maximalen Merkmalssatz implementieren muss. Es erkennt an, dass eine für Breiten-KI ausgelegte NIC den Massendatenverkehr priorisieren könnte, während ein HPC-Endpunkt robustere Ordnung und atomare Operationen benötigt. Die Profile beseitigen jedoch nicht die Wahlmöglichkeiten: Ein Anbieter kann optionale Merkmale innerhalb eines Profils implementieren, und zwei Produkte mit demselben Profil können sich in Bezug auf Sicherheit, Link-Optimierungen, Kapazität und Leistung unterscheiden.

Ein Warnsignal liegt in der Terminologie selbst. Die Referenzspezifikation 1.0.3 verwendet die Bezeichnungen AI Base, AI Full und HPC. Eine separate Compliance-Readme von 2025 verwendet hingegen AI Base, AI Extended und HPC. Die bestgestützte Interpretation lautet, dass „AI Full" die aktuelle Bezeichnung ist und das Compliance-Material veraltet oder inkonsistent ist. Solange die öffentliche Test-Suite nicht bereinigt wurde, sollten Anbieter und Käufer für jede Behauptung die Spezifikationsversion und den genauen Profilnamen angeben.

Von der Anwendungsabsicht zur Paketzustellung

Innerhalb von UET trägt der Semantic Services Sublayer die Anwendungsabsicht. Er definiert Nachrichtenidentität, Pufferspeicher, tagged- und untagged-Operationen, entfernten Speicherzugriff, atomare Operationen, Completion-Verhalten, Aufgaben-IDs, Puffersicherheit sowie Antworten und Fehler. Der Packet Delivery Sublayer bestimmt dann, wie diese Absicht in Pakete umgesetzt wird und wie sie einen anderen Endpunkt erreicht.

In zuverlässigen Modi erzeugen Endpunkte Packet Delivery Contexts (PDCs). Ein PDC enthält Zustand wie Paketsequenznummern, Acknowledgements, Duplikaterkennung, Ordnungsmodus, Congestion-Informationen, Rückpfadzustand und die Verkehrsklasse. Ein PDC ist an einen Auslieferungsmodus und eine Verkehrsklasse gebunden; zwischen demselben FEP-Paar können mehrere PDCs existieren.

Dieser Zustand ist kein triviales Detail. Große Cluster können eine enorme Anzahl von Kommunikationsbeziehungen erzeugen. Wenn jede Beziehung umfangreichen Zielzustand erfordert, können Endpunktspeicher und Lookup-Kosten zur Grenze werden. Daher erzwingt UEC nicht für jede Operation ein einziges Verbindungsmodell, sondern definiert vier Auslieferungsmodi mit unterschiedlichen Verträgen für Zuverlässigkeit und Ordnung.

Reliable Unordered Delivery (RUD) stellt jedes Paket genau einmal auf der Semantikebene zu und erlaubt den Empfang außerhalb der Reihenfolge. Es unterstützt Packet Spraying über mehrere Pfade, selektive Wiederholungen, Duplikatvermeidung und direktes Daten-Platzieren. Da das Ziel die Daten gemäß Offsets platzieren kann, ohne auf einen Transport-Reorder-Buffer zu warten, kann eine lange kollektive Operation mehrere Pfade nutzen, ohne dass alle Pakete hinter einem fehlenden Paket serialisiert werden müssen.

Reliable Ordered Delivery (ROD) liefert genau einmal und in Reihenfolge. Es verwendet einen einzelnen Pfad und einen einzelnen Entropy-Wert, verwirft Pakete außerhalb der Reihenfolge und setzt auf Go-Back-N ab der ersten fehlenden Sequenz. Es erscheint weniger komplex als RUD, bewahrt aber eine Semantik, die dort notwendig ist, wo strenge Ordnung wichtig ist. UEC behandelt Ordnung als Anwendungsanforderung, nicht als Kosten, die jedem Transport aufgebürdet werden müssen.

Reliable Unordered Delivery for Idempotent Operations (RUDI) bietet einen anderen Kompromiss. Es garantiert mindestens einmalige Zustellung und erlaubt Duplikate, was den üblichen Sequenz- und Acknowledgement-Zustand beim Ziel reduziert. Das kann nützlich sein, wenn eine doppelte Operation das Endergebnis nicht verändert, etwa bei bestimmten entfernten Speicherbewegungen mit einer nachfolgenden separaten Barriere. Es ist jedoch riskant bei falscher Anwendung. Die Paketschicht schlussfolgert nicht, ob eine Operation idempotent ist; die Software muss die Entscheidung treffen.

Die Verwendung von RUDI für eine nicht-idempotente Operation kann zu einem inkorrekten Anwendungszustand führen.

Unreliable Unordered Delivery (UUD) stellt Datagramme nach bestem Bemühen ohne die üblichen Zuverlässigkeits- oder Ordnungsgarantien zu. Es befindet sich innerhalb desselben semantischen Rahmens, trägt aber nicht dieselben Congestion-Control-Anforderungen wie RUD und ROD. Anwendungen müssen vermeiden, dem kontrollierten Verkehr zu schaden, wenn UUD gemeinsame Warteschlangen oder Klassen mit ihm teilt.

Die vier Modi offenbaren eine zentrale Philosophie: Das Netzwerk soll mehrere Mechanismen anbieten, damit die Software die Transportkosten mit der Operationssemantik in Einklang bringen kann. Der Nutzen ist Effizienz, die Kosten sind eine größere Implementierungs- und Testoberfläche sowie mehr Gelegenheiten für Anbieter, Anwendungen oder Betreiber, inkompatible Kombinationen zu wählen.

Packet Spraying: Das Fabric nutzen, statt sich auf einen glücklichen Pfad zu verlassen

Herkömmliches ECMP bindet oft einen kompletten Flow an einen einzigen Pfad mittels eines Hash-Werts. In einem großen Clos-Fabric kann das zu einem Glücksspiel werden. Mehrere große Flows können auf denselben Links kollidieren, während anderswo vergleichbare Kapazität ungenutzt bleibt. Ein lang laufender KI-Transport kann über seine gesamte Lebensdauer hinweg an einen unglücklich gewählten Pfad gebunden sein.

UET adressiert dies, indem es die Entropy auf Paketebene ändert. Der Sender kann Dutzende oder Hunderte von Werten verwenden, sodass bestehende ECMP-Mechanismen in den Switches die Pakete auf viele Wege verteilen können. Der Packet Delivery Sublayer liefert die Sequenzinformation, der Congestion Management Sublayer wählt den Entropy-Wert oder Pfad, die Switches führen das gewohnte Hashing aus, und das Feedback informiert den Sender, welche Werte überlastet erscheinen.

Packet Spraying wird erst dadurch praktikabel, dass andere Teile des Designs es unterstützen. Pakete können außerhalb der Reihenfolge ankommen. RUD kann Daten direkt platzieren, ohne auf eine vollständige Neusortierung im Transport zu warten. Selektive Wiederholungen holen nur das Fehlende zurück. Congestion-Feedback reduziert die Nutzung betroffener Pfade. Der Mechanismus ist daher kein isolierter Lastausgleichstrick, sondern Teil eines Transports, der auf Pfadvielfalt ausgelegt ist.

UEC verlangt nicht, dass jeder Switch einen proprietären adaptiven Routing-Algorithmus ausführt. Einfache Implementierungen können Round-Robin oder pseudozufällige Entropy über Standard-ECMP nutzen. Fortschrittliche Endpunkte können ECN-Signale, Latenz oder Trimming bestimmten Werten zuordnen und überlastete Pfade meiden. Herstellerspezifisches adaptives Routing kann mit UET koexistieren, ist aber nicht die einzige Quelle für Pfadbewusstsein.

Das Versprechen ist eine bessere Fabric-Auslastung und geringere Tail-Latenz. Die offene Frage ist, wie konsistent verschiedene Endpunkte das Feedback interpretieren und wie Spraying mit Switch-Puffern, Neuordnung, Ausfällen und Mischverkehr interagiert. Ein Algorithmus, der in einem homogenen Labor gut funktioniert, kann sich in einem großen Fabric mit mehreren Switch-Generationen und Verkehrsklassen anders verhalten. Unabhängige Multi-Vendor-Beweise sind noch begrenzt.

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

UEC schreibt keinen einzigen universellen Congestion-Algorithmus vor, sondern unterscheidet zwischen Überlast im Netzinneren, Incast am Empfänger und begrenzten Endpunktpuffern.

Network-signal Congestion Control (NSCC) ist ein sendergesteuerter Mechanismus. Der Sender unterhält ein Congestion Window, schätzt die unterwegs befindliche Datenmenge und passt das Fenster anhand von Acknowledgements, Negative Acknowledgements, Timeouts, Latenz und Netzsignalen wie ECN an. Er koordiniert das Fensterverhalten mit dem Multi-Path-Spraying auf Paketebene. UEC argumentiert, dass ein Fenster natürlich aufhört, neue Daten einzubringen, wenn Pakete das Netz nicht verlassen können, während ein reiner ratenbasierter Controller das Fehlen von Feedback missverstehen könnte.

Dies ist die architektonische Position des Konsortiums, kein unabhängiger Beweis, dass jede NSCC-Implementierung DCQCN oder anderen RoCE-Mechanismen überlegen ist. Die Ergebnisse hängen von den Algorithmendetails, der Switch-Markierung, der Topologie, den Verkehrsmustern und den gewählten Parametern ab. „Verwendet NSCC" allein ist kein Beleg für die Leistung.

Receiver-credit Congestion Control (RCCC) zielt auf das Incast-Problem. Wenn viele Quellen gleichzeitig an ein einzelnes Ziel senden, kann die letzte Strecke zum Engpass werden, selbst wenn das Kernnetz nicht überlastet ist. Der Empfänger verfolgt die Anforderung und verteilt Credits an die Sender, wodurch die gesamte Ankunftsrate reguliert und das effektive Fenster jeder Quelle je nach Wettbewerb variiert wird. RCCC kann parallel zu NSCC betrieben werden, da Empfängerdruck und Kernüberlastung verschiedene Probleme sind.

Transport Flow Control (TFC) verwendet ebenfalls Credits, dient aber Punkt-zu-Punkt-Verbindungen mit begrenzten Puffern. Sein unmittelbares Ziel ist es, einen Empfängerpufferüberlauf zu verhindern, wenn die Verlusttoleranz gering ist. Es kann mit oder ohne Multipathing verwendet werden. Alle kreditbasierten Mechanismen als gleichartig zu behandeln, übersieht die unterschiedlichen Fehlerdomänen, die sie adressieren sollen.

Die Spezifikation erwartet den Einsatz von Explicit Congestion Notification im gesamten Fabric und macht betriebliche Annahmen über die Markierung, einschließlich einer Markierung bei der Dequeue anstelle einer reinen Abhängigkeit von der Enqueue. Endpunkte interpretieren ECN zusammen mit Acknowledgements, Latenz und Trimming. Daher wird die Konsistenz der Switch-Konfiguration entscheidend. Eine Transportimplementierung kann korrekt sein, und dennoch kann ein schlecht konfiguriertes Fabric zu schwacher Leistung führen.

Die Wartungshistorie zeigt, wie schwierig das ist. Version 1.0.1 korrigierte den Quellalgorithmus von RCCC, 1.0.2 korrigierte Congestion-Management-Fälle und 1.0.3 korrigierte Interaktionen zwischen Credits und Link Layer Retry. Dies sind normale Anzeichen einer lebenden Spezifikation, zeigen aber auch, dass Zustände von Credits, Wiederholungen und Pfadkontrolle auf subtile Weise interagieren können. Betreiber benötigen Versionsdisziplin und Regressionstests, nicht nur anfängliche Konformität.

Packet Trimming und präzise Verlustwiederherstellung

Packet Trimming ändert, was ein fähiger Switch tut, wenn er ein ganzes Paket nicht halten kann. Anstatt den Rahmen ohne zusätzliche Information zu verwerfen, entfernt er die Nutzlast ganz oder größtenteils, bewahrt genügend Header- und Metadaten, um das Paket zu identifizieren, setzt ein Trim-Mark und sendet die verkürzte Benachrichtigung in Richtung Ziel. Das Ziel kann dann den Sender über die spezifischen verlorenen Daten informieren.

Das liefert präzisere Informationen als eine ECN-Markierung. ECN sagt, dass Überlast aufgetreten ist; Trimming identifiziert ein konkretes Paket, dessen Nutzlast nicht erhalten blieb. In Kombination mit RUD und selektiver Wiederholung kann die Wiederherstellung beschleunigt werden, ohne auf einen Timeout oder eine lange Neusequenzierung wegen eines einzelnen Verlusts zu warten.

Die Switch-Funktion ist optional, aber konforme Endpunkte müssen getrimmte Pakete empfangen und interpretieren können, wenn die Anforderungen zutreffen. Diese Asymmetrie hilft, UET über normale Switches einzusetzen, während optimierte Fabrics reichhaltigere Verlustinformationen liefern können. Sie schafft jedoch auch ein Upgrade-Problem: Ein teilweise optimiertes Netz könnte Trimming je nach Pfad, Profil oder Topologie einschränken müssen, um sicherzustellen, dass jeder empfangende Endpunkt korrekt damit umgehen kann.

UEC definiert zudem unterschiedliche Verkehrsklassen für Anfragen, Steuerpakete, Wiederholungen und getrimmten Verkehr. Betreiber müssen DSCP-Werte, Switch-Warteschlangen, Endpunkt-Warteschlangen und Prioritätsebenen konsistent abbilden. Die Spezifikation liefert kein universelles Managementsystem für diese Zuordnung. Ein Fehler kann Steuerverkehr aushungern, Congestion-Feedback verzerren oder Wiederherstellungspakete mit dem Verkehr konkurrieren lassen, den sie eigentlich reparieren sollen.

Packet Trimming fasst die allgemeinere Implementierungsherausforderung zusammen. Das Protokoll kann das Verhalten auf der Leitung definieren, aber das betriebliche Ergebnis hängt von Switch-Warteschlangen, Endpunktlogik, Telemetrie, Konfiguration und Fehlerbehandlung ab. Interoperabilität ist eine Eigenschaft des gesamten Systems, nicht nur der Paketformatierung.

Link-Wiederherstellung, Credits und Merkmalsaushandlung

Link Layer Retry (LLR) versucht, einen Fehler auf einer physikalischen Verbindung zu beheben, bevor der Ende-zu-Ende-Transport reagiert. Die Gegenseite erkennt eine Sequenzlücke oder einen beschädigten Rahmen, sendet ein Link-Layer-Negative-Acknowledgement und veranlasst den Sender, den betroffenen Rahmen aus einem lokalen Puffer erneut zu übertragen. Gelingt die Wiederherstellung schnell, kann der Transport eine längere Wiederholung über den gesamten Pfad vermeiden.

Der potenzielle Wert steigt mit höheren Lane-Geschwindigkeiten und Portdichten. Ein gelegentlicher optischer oder elektrischer Fehler kann in einer stark synchronisierten Aufgabe erhebliche Verzögerung verursachen. LLR fügt jedoch Sequenzzustand, Replay-Puffer, Steuernachrichten, Drop-Fenster und neue Fehlerarten hinzu. Zudem muss es mit Credit-Updates und Link-Resets koexistieren. Version 1.0.3 korrigierte mehrere Randfälle, darunter Race-Conditions zwischen CBFC-Credits und LLR.

Credit-Based Flow Control (CBFC) arbeitet pro virtuellem Kanal auf Verbindungsebene und teilt dem Sender mit, wie viel Empfangskapazität noch verfügbar ist. Es kann eine feinere Steuerung bieten als ein breit angelegtes Priority-basiertes Pausieren. UEC stellt es als Mittel dar, ein verlustfreies Verhalten zu unterstützen, ohne dass jedes UET-Netz vollständig verlustfrei sein muss. CBFC ist optional, und UET ist so entworfen, dass es über Best-Effort-Netzen funktioniert.

CBFC sollte nicht als anderer Name für Priority Flow Control behandelt werden. Die beiden Mechanismen unterscheiden sich in Signalisierung und Granularität, obwohl beide einen Pufferüberlauf verhindern wollen. CBFC benötigt dennoch eine konsistente Konfiguration und eine korrekte Zustellung seiner Steuerrahmen. Lokale Credits können mit Ende-zu-Ende-Fenstern und Empfängercredits interagieren und so mehrere verschachtelte Regelkreise erzeugen.

UEC nutzt eine LLDP-basierte Aushandlung, um optionale Merkmale zu erkennen und zu verhindern, dass eine Seite eine Fähigkeit aktiviert, die der Nachbar nicht unterstützt. Die Aushandlung muss Profile, virtuelle Kanäle, DSCP, Prioritätszuordnung, Resets, Software-Upgrades und partielle Merkmalskombinationen berücksichtigen. Version 1.0.3 führte eine logische Aushandlungsfähigkeit ein, was die Bedeutung einer expliziten Einigung auf jeder Verbindung unterstreicht.

Diese Optionen bieten einen Pfad von einfachem zu optimiertem Ethernet. Sie erzeugen jedoch auch eine Matrix, die in der Beschaffungssprache verborgen bleiben kann. Ein Switch kann UET korrekt weiterleiten, ohne Trimming, LLR oder CBFC zu unterstützen. Ein anderer Switch kann diese Fähigkeiten nur in bestimmten Softwareversionen oder Portmodi bieten. Ein vertrauenswürdiges Deployment-Register benötigt den genauen Funktionsumfang, nicht nur den Namen des Konsortiums.

Physikalische Signale bei 100 und 200 Gbit/s pro Lane

Die physikalische Schicht bindet UEC an die Hardware-Roadmap. Die ursprüngliche Arbeit für Version 1.0 war auf 100 Gbit/s pro Lane ausgerichtet. Version 1.0.3 fügte die Unterstützung für 200 Gbit/s pro Lane hinzu. Dies passt zu einer Generation von Verbindungen und Systemen mit höherer Dichte, ist jedoch eine Spezifikationsfähigkeit und kein Beweis dafür, dass jedes UEC-Produkt sie sofort unterstützt.

Die PHY-Arbeit behandelt auch Forward Error Correction-Statistiken, korrigierte und unkorrigierbare Codeword-Raten, Control Ordered Sets, Link-Qualitätsberichte und die Interaktion zwischen physikalischen Fehlern und LLR. Diese Details sind wichtig, weil die Wiederherstellungsentscheidungen im Transport davon abhängen, was die unteren Schichten sehen und melden können.

Bei höheren Signalraten verschwimmen die Grenzen zwischen Optik, SerDes, FEC, Link-Retry und Transportwiederherstellung und werden wirtschaftlich bedeutsam. Eine stärkere FEC kann Restfehler auf Kosten von Latenz und Energie reduzieren. Lokale Wiederholungen können Fehler schneller beheben, benötigen aber Puffer und Zustand. Ende-zu-Ende-Wiederholungen sind einfacher im Netz, können aber mehr Zeit kosten. UEC versucht zu definieren, wie diese Schichten zusammenarbeiten, anstatt es jedem Anbieter zu überlassen, sie isoliert zu optimieren.

Die Hinzufügung von 200G pro Lane zeigt auch, dass sich das Ziel bewegt. Implementierer von 1.0 müssen die Kompatibilität wahren, während sie für neue physikalische Fähigkeiten planen. Testgeräte, Firmware und Managementsysteme müssen zwischen den Fähigkeiten jedes Ports unterscheiden. Käufer sollten die Lane-Geschwindigkeit nicht aus einer allgemeinen UEC-Unterstützungsbehauptung ableiten.

Optionale Ende-zu-Ende-Transportsicherheit

Der Transport Security Sublayer (TSS) bietet optionalen Schutz von Endpunkt zu Endpunkt. Das Bedrohungsmodell setzt kein Vertrauen in die Switches voraus. Er kann Vertraulichkeit, Integrität, Replay-Schutz, Aufgabenisolierung, sichere Domänen, Gruppenschlüssel, Schlüsselrotation und die Integration mit Hardware-Vertrauensankern bieten.

Das Design verwendet sichere Domänen, deren Mitglieder einen kryptografischen Kontext teilen. Die IDs, Verbindungsnummern, Epochen und die Authentifizierung des sicheren Absenders sowie die Schlüsselableitung sind darauf ausgelegt, besser zu skalieren als der Aufbau einer unabhängigen Sitzung für jedes Endpunktpaar. Dies ist notwendig, wenn sich die Beschleunigerpopulation und die Aufgabenzugehörigkeit schnell ändern.

Das Protokoll ist jedoch nur ein Teil des Sicherheitssystems. Eine produktive Umgebung muss Schlüsselautoritäten und Zertifikate oder andere Vertrauensanker, Aufgabenzugehörigkeitsdienste, Verteilung und Widerruf, Epochenübergänge, Endpunktwiederherstellung, Hardware-Verschlüsselung und Sicherheitstelemetrie betreiben. Ein Netz kann ein Profil erfüllen, ohne alle optionalen TSS-Funktionen zu aktivieren. „UEC-konform" bedeutet nicht automatisch, dass der Verkehr verschlüsselt ist.

Die Optionalität spiegelt unterschiedliche Deployment-Annahmen wider. Ein dediziertes, physisch kontrolliertes Fabric mag der Leistung Vorrang geben und sich auf Umgebungskontrollen verlassen. Eine Multi-Tenant-Cloud benötigt unter Umständen starke Isolierung und kryptografischen Schutz. Das Profil- und Beschaffungswesen muss diesen Unterschied abbilden.

Das größte Risiko sind nicht allein die Verschlüsselungskosten, sondern ein Fehler im Lebenszyklus im großen Maßstab: veraltete Zugehörigkeiten, verzögerte Sperrungen, inkonsistente Epochen, die Wiederherstellung nach einem Endpunktausfall oder die Unfähigkeit zu beweisen, welche Aufgabe 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, doch das öffentliche System ist kein ausgereiftes unabhängiges Zertifizierungsprogramm. Das verfügbare Paket ist vor allem für die Selbstauskunft durch Implementierer ausgelegt. Die Matrizen verknüpfen Spezifikationsanforderungen mit Profilen, und die Testbed-Richtlinien beschreiben empfohlene Konfigurationen für Endpunkte und Switches. Es gibt keine öffentliche, umfassende Datenbank, in der eine unabhängige Stelle festhält, welche Produkte ein vollständiges UEC-Programm bestanden oder nicht bestanden haben.

Die Unterscheidung ist notwendig, weil auf dem Markt unterschiedliche Behauptungen kursieren. Ein Produkt kann um in der Entwicklung befindliche UEC-Merkmale herum entworfen sein, ausgewählte Leitungsfunktionen implementieren, ein Profil oder Teile davon in einer bestimmten Softwareversion unterstützen. Ein Anbieter kann eine merkmalsspezifische Konformität beanspruchen oder ein Labor UET-Verkehr über einen Switch erzeugen. Nichts davon entspricht automatisch einer unabhängigen, Multi-Vendor-End-to-End-Zertifizierung.

Die öffentlichen Testbed-Richtlinien sind nützlich, aber bewusst begrenzt. Sie bieten Topologien und Überprüfungen für gute Praxis, nicht eine vollständige Systemqualifikation. Sie decken keine breitere Interoperabilität, Leistung, Stress, Skalierung, API-Lebenszyklus vollständig ab. Sie beweisen auch nicht das Verhalten bei gemischtem UET- und RoCE-Verkehr, partiellen Upgrades, wiederholten Ausfällen, großen Schlüsselmengen oder den größten angestrebten Endpunktzahlen.

Der Konflikt zwischen AI Full und AI Extended unterstreicht die Notwendigkeit einer disziplinierten Versionierung. Ein Käufer sollte nach der Spezifikation, dem Patch-Level, dem Profil, den optionalen Merkmalen, den Link-Modi und den Sicherheitsfunktionen fragen, die eine Behauptung abdeckt. Die Antwort sollte angeben, ob der Nachweis aus internen Tests, einer bilateralen Demonstration, einer Konsortialveranstaltung oder einem unabhängigen Labor stammt.

Die nächste belastbare Stufe umfasst öffentliche, an exakte Versionen gebundene Testdefinitionen, Multi-Vendor-Plugfests, unabhängig geführte Ergebnisse einschließlich negativer Resultate und ein Register, das Endpunkte, Switches, Software und vollständige Systeme unterscheidet. Bis dahin bleibt die Aussage „UEC-konform" ein Ausgangspunkt für die Überprüfung, keine vollständige Garantie.

Offenes Dokument mit RAND-Patentverpflichtungen

Die Ultra Ethernet Specification 1.0.3 ist öffentlich verfügbar und wird unter der Creative Commons Attribution-NoDerivatives 4.0-Lizenz verbreitet. Die Lizenz erlaubt die Weiterverbreitung mit Namensnennung, aber keine Verbreitung modifizierter Versionen. Wichtiger ist, dass das urheberrechtliche Zugangsrecht von der Patentnutzung getrennt ist.

Die dokumentierten Arbeitsgruppen-Charta verwenden im Allgemeinen ein traditionelles Spezifikationsentwicklungsmodell mit einer Patentlizenz zu fairen, angemessenen und nichtdiskriminierenden (RAND) Bedingungen. RAND bedeutet nicht notwendigerweise lizenzgebührenfrei, garantiert keinen weltweiten Preis, beseitigt keine Verhandlungen und verhindert keine Streitigkeiten über Gültigkeit, Wesentlichkeit, geografischen Umfang oder defensive Bedingungen. Das kommerzielle Bild hängt von jedem offengelegten Patent, der Mitgliederverpflichtung und etwaigen bilateralen Vereinbarungen ab.

UEC führt ein öffentliches Register für Erklärungen zu Necessary Claims. Zum Recherchezeitpunkt erschienen Erklärungen im Zusammenhang mit Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell und anderen, darunter Einreichungen, die sich auf zukünftige Arbeiten für Version 1.1 beziehen. Das Register erhöht die Transparenz, weil es deutlich macht, dass Implementierer möglicherweise geistiges Eigentum prüfen müssen, bevor sie ein Produkt bauen oder ausliefern.

Das Konsortium erklärt, dass es nicht feststellt, ob ein offengelegtes Patent tatsächlich gültig, notwendig, verletzt oder zu einem bestimmten Preis verfügbar ist. Es veröffentlicht auch keine gemeinsame Lizenz. Kleine Implementierer könnten mit rechtlichen und Transaktionskosten konfrontiert werden, die große Unternehmen leichter tragen können. Eine öffentliche Spezifikation kann einen konzentrierten Implementierungsmarkt hervorbringen, wenn die Kosten für Patentklärung, Silizium und Tests hoch sind.

Der IP-Rahmen beeinflusst auch die Governance-Anreize. Unternehmen bringen Technologie teilweise ein, um einen breiten Markt für ihre Produkte zu schaffen, und teilweise, um sicherzustellen, dass ihre Fähigkeiten im gemeinsamen Design vertreten sind. Patentoffenlegungen schützen Implementierer nur dann vor Überraschungen, wenn sie früh genug und klar sind. Sie beseitigen auch nicht die Möglichkeit, dass die Lizenzierung nach einer weiten Verbreitung zu einer Barriere wird.

Die ehrliche Beschreibung lautet daher „öffentlich zugänglich und Multi-Vendor-fähig mit RAND-Verpflichtungen", nicht „universell lizenzgebührenfrei". Beschaffungsteams benötigen das technische Profil und den Lizenzpfad gemeinsam.

Die erste Welle von Produkten und Tests

Implementierungsbelege tauchten rund um Version 1.0 auf, aber die Beispiele weisen unterschiedliche Reifegrade auf.

AMD brachte die Pollara 400 AI NIC im April 2025 auf den Markt und beschrieb sie als um in der Entwicklung befindliche UEC-Fähigkeiten herum entworfen. Pollara ist eine programmierbare Endpunktplattform und ein wichtiges Signal dafür, dass der Transport in tatsächlich ausgelieferte Hardware einfließt. Die Formulierung ist jedoch wichtig: Ein Design um sich entwickelnde Merkmale herum ist nicht gleichbedeutend mit einer unabhängigen Zertifizierung gegen alle finalen 1.0.3-Anforderungen.

Broadcom kündigte im Juni 2025 Tomahawk 6 als 102,4-Tbit/s-Switch-ASIC mit für UEC-Fabrics relevanten Merkmalen an. Im Oktober kündigte es die Thor Ultra 800G NIC an und erklärte, das Design biete vollständige UEC-Merkmalskonformität. Dies ist eine wesentliche Anbieterbehauptung, aber der öffentliche Nachweis macht sie nicht zu einer unabhängigen Konsortialzertifizierung. Sampling, Software-Reife und die genaue Profilunterstützung müssen getrennt betrachtet werden.

Nokia und Keysight demonstrierten im Oktober 2025 Ende-zu-Ende-UET-Verkehr über die Nokia-Rechenzentrums-Switch-Familien 7220 und 7250 bei 800 Gigabit Ethernet. Keysight lieferte Verkehrsgenerierung und Verifikation. Der Test belegt, dass UET-Verkehr kommerzielle Switch-Systeme durchqueren kann und dass die Testausrüstung reift. Er belegt jedoch kein vollständiges, Multi-Vendor-Endpunktprofil, keine Produktionsvolumina oder eine unabhängige Zertifizierung aller optionalen Merkmale.

Weitere Mitglieder beschrieben UEC-fähige Switches, Systeme, Software und Testpläne, und der Gipfel 2026 war stark auf Produktisierung ausgerichtet. Die Belege stützen einen Wandel hin zur Implementierung, belegen aber keine genaue Zahl ausgelieferter UET-Karten, zertifizierter Switches, betriebener Cloud-Regionen oder vollständiger Fabrics.

Die beste Lesart dieser Welle ist eine Evidenzkette. Die öffentliche Spezifikation ermöglicht das Design. Silizium- und NIC-Ankündigungen zeigen Investitionen. Verkehrsdemonstrationen zeigen etwas Interoperabilität. Compliance-Matrizen organisieren die Anforderungen. Betreiberberichte werden den betrieblichen Wert zeigen. Unabhängige Plugfests und Produktionsergebnisse werden das breitere Vertrauen liefern, das noch fehlt.

RoCE, InfiniBand, Slingshot und UALink

UEC tritt in einen Markt mit ausgereiften Alternativen und angrenzenden Technologien ein. Sein strategisches Argument beruht nicht darauf, dass Ethernet noch nie RDMA transportiert hat oder dass spezialisierte Fabrics nicht funktionieren, sondern dass die Größe und Synchronität heutiger KI-Lasten eine neue, durchgängige Ethernet-Architektur rechtfertigen, die bei Auslieferung, Pfadnutzung und Congestion Control flexibler ist.

RoCEv2 ist der direkte Vorgänger und eine weit verbreitete Technologie. Es legt RDMA-Verkehr über routbares Ethernet und genießt breite Anwendungs- und Produktunterstützung. UEC kritisiert gängige RoCE-Implementierungen dafür, dass sie komplette Flows an einen einzigen Pfad binden, Go-Back-N und empfängerseitige Neuordnung verwenden, schwer abstimmbares DCQCN erfordern, in vielen Designs auf Priority Flow Control angewiesen sind und bei Incast oder kollektiven Bursts schlechtes Verhalten zeigen. Dies sind technische Positionen des Konsortiums, kein Beweis für die Schwäche jedes RoCE-Netzes.

Zudem ist der Vergleich in Bewegung. Anbieter können adaptives Routing, Packet Spraying, bessere Congestion-Algorithmen oder UEC-ähnliche Funktionen zu programmierbaren NICs hinzufügen und gleichzeitig die RoCE-Kompatibilität wahren. So zeigt AMD in den Pollara-Materialien sowohl RoCEv2 als auch UEC-RDMA als Optionen auf programmierbarer Hardware. UEC kann als vollständiger Transport mit RoCE konkurrieren und zugleich die Entwicklung künftiger RoCE-Produkte beeinflussen.

InfiniBand ist die bedeutendste spezialisierte Alternative. Es bietet ein integriertes Ökosystem aus RDMA, Congestion-Management, Link-Zuverlässigkeit und Management mit langer HPC-Erfahrung. Die Arbeit der InfiniBand Trade Association an 2.0 umfasst physikalische XDR-Unterstützung bei 200 Gbit/s pro Lane und aktualisierte Telemetrie. Das stärkste Unterscheidungsmerkmal von UEC ist nicht die Behauptung, InfiniBand fehle es an Leistung, sondern das Potenzial, KI/HPC-Verhalten über die breitere Ethernet-Lieferkette, Standard-IP-Routing und eine größere Anbieterauswahl zu erreichen.

HPE Slingshot nimmt eine mittlere Position ein. Es ist ein kommerzielles, Ethernet-kompatibles HPC-Fabric mit adaptivem Routing und Congestion-Management und lieferte bedeutende technische Vorläufer für UET. Es beweist, dass spezialisiertes Verhalten auf Ethernet aufgebaut werden kann, veranschaulicht aber auch den Unterschied zwischen einer kontrollierten kommerziellen Plattform und einer branchenweiten Spezifikation.

UALink ist oft komplementär und kein direkter Ersatz. Seine aktuelle öffentliche 200G-Spezifikation zielt auf Scale-up-Verbindungen mit niedriger Latenz zwischen Beschleunigern innerhalb eines Pods und beschreibt Systeme mit bis zu 1.024 Beschleunigern. UEC 1.0 ist hauptsächlich ein Scale-out-Fabric, das Knoten über Switches verbindet. Ein Rechenzentrum könnte eine Scale-up-Verbindung innerhalb des Pods und UEC zwischen Pods oder Knoten nutzen. Zukünftige UEC-Arbeiten zu Scale-up-Transport und In-Network-Collectives könnten die Grenzen verschieben und zu Konvergenz oder Wettbewerb führen.

NVIDIA Spectrum-X und proprietäre Beschleuniger-Fabrics bieten einen weiteren Vergleich. Ein eng integrierter Stack kann Hardware, Software und Support schnell optimieren, erhöht aber die Abhängigkeit von einem einzigen Ökosystem. UEC tauscht einen Teil dieser Integration gegen das Versprechen gemeinsamer Schnittstellen und Anbieterwahl. Der Erfolg dieses Tauschs hängt von Leistung, Support, Patentbedingungen, Interoperabilität und Gesamtbetriebskosten ab – nicht vom Schlagwort „offen".

Das betriebliche Problem ist größer als das Protokoll

Eine 573-seitige Spezifikation kann viele Anforderungen definieren, aber ein Produktions-Fabric benötigt dennoch ein Betriebsmodell. UEC 1.0 lässt wichtige Managementarbeiten außerhalb oder am Rande des Kernspezifikationsdokuments. Betreiber müssen Profile, Verkehrsklassen, ECN-Schwellen, Entropy-Gruppen, optionale Link-Merkmale, Schlüssel, Firmware, Telemetrie und Fehlerrichtlinien konsistent über Endpunkte und Switches hinweg konfigurieren.

Mischverkehr macht es noch schwieriger. Ein Rechenzentrums-Fabric kann UET, RoCE, TCP, Speicher-, Management- und geordnete sowie ungeordnete UET-Dienste transportieren. Das Warteschlangenlayout und die Fairness-Probleme lösen sich nicht allein dadurch, dass jede Protokollimplementierung korrekt ist. Ein Congestion-Algorithmus mag isoliert gut funktionieren, sich aber schlecht verhalten, wenn er mit einem anderen Controller konkurriert, der auf anderen Signalen und Annahmen beruht.

Die Endpunktkomplexität ist ein weiteres strukturelles Risiko. UET platziert Multipathing, Direct Data Placement, selektive Wiederholungen, mehrere Auslieferungsmodi, Fenstersteuerung, Credits, Trimming-Empfang, Sicherheit und umfangreichen Zustand innerhalb des FEP. Dies kann den NIC-Die-Bereich, die Firmware-Größe, den Verifikationsaufwand, die Leistungsaufnahme und die Anzahl der zu diagnostizierenden Fehlerzustände erhöhen. Die Endpunktintelligenz ermöglicht eine breite Lieferkette, legt aber die schwierigste Implementierung möglicherweise in die Komponente, die jeder Server kaufen muss.

Optionale Merkmale schaffen sowohl Produktdifferenzierung als auch Fragmentierung. Ein Basis-Endpunkt könnte für AI Base mit normalem ECMP und ECN optimiert sein. Ein anderer könnte AI Full, HPC, TSS, Trimming, LLR und CBFC unterstützen. Beide sind Teil des UEC-Ökosystems, aber Betreiber können nicht dieselbe Semantik, Leistung oder Sicherheit voraussetzen. Compliance-Matrizen müssen zu betrieblichen Fähigkeitsmatrizen werden.

Versionspflege wird kontinuierlich sein. Die Patches von 1.0.1 bis 1.0.3 betrafen Congestion, Credits, Retry und Paketverhalten. Ein großer Cluster kann verschiedene NIC-Firmware-Versionen, mehrere Switch-Generationen und Testwerkzeuge enthalten. Die Aktualisierung einer Schicht ohne Koordination der anderen kann genau jene schichtenübergreifende Interaktion offenlegen, die das Konsortium zu vermeiden sucht.

Deshalb sind externe Beziehungen zentral und nicht symbolisch. Das Open Compute Project kann den Transport mit offenen Systemen und Hardware verbinden. Die OpenFabrics Alliance und die libfabric-Community verbinden die Anwendungen. IEEE 802.3 liefert die formelle Ethernet-Arbeit. SNIA und NVM Express fügen Speicher- und Managementanforderungen hinzu. IETF-Technologien stellen IP, ECN und verwandte Mechanismen bereit. Diese Gremien haben unterschiedliche Entscheidungsprozesse und Roadmaps; Koordination reduziert Doppelarbeit, garantiert aber keine gleichzeitige Übernahme.

Der ultimative Betriebstest ist die laufende Infrastruktur. Ein Dokument kann Verhalten definieren, ein Anbieter ein Produkt ankündigen und ein Konsortium einen Gipfel veranstalten. Nichts davon ersetzt einen Cluster, in dem unabhängige Endpunkte und Switches echte Aufgaben unter Überlast, Ausfall und Upgrade bewältigen und die Betreiber verstehen können, was passiert ist.

Aktuelle Bedeutung: Vom Spezifikationserfolg zur Implementierungsglaubwürdigkeit

Bis Juli 2026 hat UEC Dinge erreicht, die bei der Gründung keineswegs garantiert waren. Es hat ein breites Konsortium gebildet, eine kohärente Fünf-Schichten-Architektur entworfen, eine vollständige Spezifikation 1.0 veröffentlicht, sie durch mehrere Patches gepflegt, 200G pro Lane hinzugefügt, Patentoffenlegungen sichtbar gemacht und Produktankündigungen sowie Tests angezogen. Das Projekt ist aktiv, und seine Agenda hat sich deutlich in Richtung Implementierung verschoben.

Diese Fortschritte machen die folgenden Unsicherheiten wichtiger, nicht weniger. Die genaue aktuelle Mitgliederzahl und die Steering-Roste erscheinen nicht in einem einzigen Referenzdokument. Die öffentlichen Mitgliedsseiten und das Organisationsdokument beschreiben den Zugang auf unterschiedliche Weise. Die derzeitige formelle TAC-Führung stimmt nicht vollständig mit den Gipfelrollen überein. Offizielle Dokumente unterscheiden sich beim Datum von 1.0.2, und das Compliance-Paket verwendet veraltete Profilbegriffe.

Nichts davon zerstört die Architektur, aber es ist ein Indikator für die Dokumentdisziplin und Transparenz in einem Projekt, dessen Ergebnisse von exakten Versionen abhängen.

Die wichtigeren Lücken betreffen die Akzeptanz. UEC veröffentlicht keine Nutzungsstatistiken, kein unabhängig überprüftes Produktregister, kein eigenständiges Budget und keine geprüften Konten. Es gibt keinen öffentlichen Nachweis eines vollständig interoperablen UEC-1.0-Netzes, das die maximalen Skalierungsziele des Konsortiums erreicht. Anbieterdemonstrationen und Behauptungen sind wertvoll, stammen aber von Parteien mit kommerziellem Interesse. Neutrale Vergleiche mit aktuellem RoCE, InfiniBand und integrierten Ethernet-Plattformen bleiben begrenzt.

Die Chance ist nach wie vor groß. Ethernet ist der gemeinsame Nenner in Rechenzentren, und der Markt für KI-Infrastruktur ist groß genug, um neue Generationen von NICs, Switches, Optiken und Software zu tragen. Betreiber haben starke Anreize, die Abhängigkeit von einem einzigen Anbieter zu verringern und die Beschleunigerauslastung zu verbessern. Ein gemeinsamer Stack kann diese Anreize in Kaufkraft umwandeln.

Das Risiko besteht darin, dass „Ultra Ethernet" zu einem Dach für inkompatible Merkmalssätze wird. Wenn das grundlegende Routing funktioniert, aber Profile, Congestion, Sicherheit und Management auseinanderlaufen, könnte sich die Marke schneller verbreiten als die Interoperabilität. Wenn RAND-Lizenzen teuer oder undurchsichtig sind, könnte sich der Anbieterkreis verengen. Wenn RoCE-Produkte die attraktivsten Ideen absorbieren, ohne einen neuen Transport einzuführen, könnte UEC den Markt beeinflussen, ohne selbst zum dominierenden Namen zu werden.

Die entscheidende Frage lautet nicht mehr, ob das Konsortium eine fortschrittliche Spezifikation veröffentlichen kann. Das hat es getan. Die Frage ist, ob unabhängige Organisationen dieselben Verträge implementieren, die notwendige Technologie lizenzieren, das Fabric in großem Maßstab betreiben und die Kompatibilität aufrechterhalten können, während sich die Spezifikation weiterentwickelt. UEC wird nur in dem Maße zur Infrastruktur, wie diese Behauptungen vor laufenden Systemen bestehen können.