Ultra Ethernet Consortium: Reconstruire l’Ethernet pour l’IA à grande échelle

Résumé

• L’Ultra Ethernet Consortium est un projet de la Joint Development Foundation lancé le 19 juillet 2023 par AMD, Arista Networks, Broadcom, Cisco, Eviden/Atos, Hewlett Packard Enterprise, Intel, Meta et Microsoft. Il s’agit d’un consortium de spécification industrielle, pas d’une entreprise conventionnelle ni d’un opérateur de réseau.
• La portée de l’UEC dépasse celle d’une liaison Ethernet plus rapide ou d’un remplacement de RoCE. Sa spécification 1.0.3, longue de 573 pages, couvre les couches logicielles, de transport, réseau, de liaison et physique, avec des travaux de gestion, de stockage, de test et de conformité autour de la pile centrale.
• Ultra Ethernet Transport combine plusieurs modes de livraison, le multi-acheminement au niveau des paquets, la retransmission sélective, le contrôle de congestion piloté par l’émetteur et le récepteur, l’ECN, l’élagage optionnel des paquets, la retransmission optionnelle de liaison, le contrôle de flux optionnel basé sur des crédits et une sécurité optionnelle de transport de bout en bout.
• Les produits et démonstrations d’AMD, Broadcom, Nokia et Keysight montrent que l’implémentation a commencé, mais la conformité publique repose principalement sur l’auto-attestation des implémenteurs et aucun registre de certification indépendant complet ou recensement de déploiement à grande échelle n’a été publié.
• L’opportunité stratégique de l’UEC provient de la base installée d’Ethernet et de la chaîne d’approvisionnement multi-fournisseurs. Ses principaux risques sont la complexité des points d’extrémité, la fragmentation des fonctionnalités optionnelles, les obligations de brevet RAND, la gestion et les tests encore immatures, et l’écart entre la publication d’une spécification et l’interopérabilité vérifiée en production.

Pourquoi l’IA a transformé le réseau en une partie de l’ordinateur

L’Ultra Ethernet Consortium a été créé autour d’un changement dans l’économie de l’informatique. Dans un réseau d’entreprise ordinaire, on s’attend à ce que la structure déplace de nombreux flux indépendants avec un débit et une disponibilité acceptables. Dans un grand système d’entraînement d’intelligence artificielle ou une machine de calcul haute performance, le réseau devient partie intégrante d’un calcul synchronisé. Des milliers d’accélérateurs peuvent échanger des paramètres de modèle, des gradients ou des données scientifiques lors d’opérations collectives.

Une phase peut ne pas avancer tant que le entité le plus lent n’a pas reçu les informations nécessaires. Une petite quantité de déséquilibre de chemin, de congestion ou de perte de paquets peut donc laisser des processeurs coûteux en attente même lorsque l’utilisation moyenne de la structure semble saine.

Cela change ce que les opérateurs optimisent. La bande passante agrégée compte toujours, mais elle ne suffit pas. Ils se soucient également du temps d’achèvement des tâches, de la latence de queue, des incasts, de la récupération après perte, de la répartition du trafic sur des chemins parallèles et de la quantité d’état que les points d’extrémité doivent maintenir. Un réseau qui livre la plupart des paquets rapidement mais qui retarde une petite fraction peut bloquer toute une opération collective. Une méthode de retransmission acceptable pour le trafic conventionnel peut faire perdre trop de temps lorsqu’un long message perd un seul paquet.

Un flux assigné à un chemin à coût égal peut sous-performer alors que de la capacité reste disponible ailleurs dans la topologie.

La proposition fondatrice de l’UEC était que ces problèmes ne pouvaient pas être résolus par une nouvelle fonctionnalité de commutateur ou un algorithme de congestion révisé. Le chemin de communication commence au-dessus du réseau, dans les bibliothèques logicielles et la sémantique des applications. Il traverse l’enregistrement mémoire, les opérations distantes, l’état de transport, la livraison des paquets, le contrôle de congestion, le transfert IP, les liaisons Ethernet, l’optique et la signalisation physique.

Si ces couches sont conçues indépendamment, une optimisation à un endroit peut simplement déplacer le goulot d’étranglement ou créer des hypothèses incompatibles ailleurs.

La réponse de l’UEC est une architecture coordonnée. Elle conserve Ethernet et IP parce que les opérateurs les comprennent déjà et parce qu’une énorme chaîne d’approvisionnement existe autour des commutateurs, de l’optique, des câbles, des systèmes d’exploitation réseau, de la télémétrie et de la gestion. Elle modifie ou étend les parties que le consortium juge mal adaptées aux grandes charges de travail d’IA et de HPC. Le résultat n’est pas « de l’Ethernet ordinaire avec un nouveau logo ».

C’est une tentative de faire supporter à un réseau familier un transport spécialisé dont le comportement est défini depuis l’API logicielle jusqu’au débit de ligne.

Cette distinction explique pourquoi l’UEC est importante pour l’infrastructure numérique. Le projet ne possède pas d’accélérateurs, d’usines, de centres de données ou de régions cloud. Il définit les contrats que les entreprises membres et d’autres implémenteurs peuvent placer dans les cartes réseau, les ASIC de commutation, les systèmes, les pilotes, les bibliothèques et les équipements de test. Son influence ne se concrétisera que lorsque ces produits indépendants échangeront correctement du trafic dans des conditions de panne, de congestion, de mise à niveau et de mixité de fournisseurs.

Ce qu’est l’UEC — et ce qu’elle n’est pas

Ultra Ethernet Consortium est le nom public d’un projet formel dont la série juridique s’appelle Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. La structure en série place le projet au sein de la Joint Development Foundation et de la famille élargie de la Linux Foundation. Elle fournit aux entités un cadre juridique préexistant pour l’adhésion, la gouvernance, la propriété intellectuelle, le financement et les relations externes sans avoir à créer une nouvelle société autonome.

Cette structure est importante car l’UEC est souvent décrit de manière imprécise comme une entreprise, une alliance ou un organisme de normalisation. Ce n’est pas une entreprise commerciale avec des actionnaires, un capital social, une valorisation ou des comptes déposés indépendamment. Elle ne vend pas de produits Ethernet, n’exploite pas de réseau public et ne possède pas le matériel promu par ses membres. C’est un consortium de développement de spécifications doté d’un cadre juridique et de propriété intellectuelle. Ses documents publics sont destinés à devenir des contrats d’implémentation entre plusieurs entreprises.

L’UEC n’est pas non plus identique à Ultra Ethernet Transport. L’UET est l’architecture de transport au cœur de la spécification. Les travaux du consortium sont plus larges. Ils incluent la correspondance logicielle avec libfabric, la sémantique des paquets et des messages, les hypothèses réseau, les options de couche de liaison, les exigences de couche physique, la gestion, l’alignement sur le stockage, les performances et le débogage, la conformité et les tests. Réduire le projet à « un nouveau protocole RDMA » masque la conception transversale qui le rend ambitieux et difficile.

L’UEC n’est pas non plus le groupe de travail IEEE 802.3. L’IEEE 802.3 élabore des normes fondamentales pour les couches MAC et physiques d’Ethernet selon son propre processus formel. L’UEC s’appuie sur cet écosystème et entretient une liaison, mais ne le remplace pas. La même frontière s’applique aux mécanismes de l’IETF sous-jacents à l’UET, notamment IPv4, IPv6 et Explicit Congestion Notification; à l’écosystème OpenFabrics qui assure la maintenance de libfabric; et aux organisations travaillant sur le stockage, le matériel ouvert et les interconnexions d’accélérateurs.

Le site Web du projet a utilisé un langage suggérant le statut d’une organisation internationale de normalisation. La description la plus sûre et la mieux étayée est que l’UEC est une organisation internationale d’élaboration de spécifications dans le cadre de la JDF. Rien ne prouve qu’elle fasse partie de l’Organisation internationale de normalisation, que ses documents soient des normes ISO ou qu’elle possède un numéro de norme ISO. La distinction n’est pas que terminologique. Elle identifie l’origine de l’autorité, le fonctionnement de la participation et les engagements juridiques auxquels les implémenteurs peuvent être confrontés.

Il convient donc de juger l’UEC sur son rôle effectif. Elle coordonne des concurrents et des opérateurs autour d’une conception technique commune. Elle publie des spécifications. Elle administre des groupes de travail et des déclarations d’obligations de brevet. Elle élabore des documents de conformité et des relations avec des organisations voisines. Elle ne peut pas, par une simple déclaration, rendre un produit interopérable ou faire adopter son architecture par le marché.

La coalition fondatrice de neuf entreprises

Le consortium a été annoncé le 19 juillet 2023 par neuf organisations positionnées à différents niveaux de la chaîne d’approvisionnement de l’IA et du HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden, alors associé à Atos, Hewlett Packard Enterprise, Intel, Meta et Microsoft. Cette diversité était un atout stratégique dès le départ. Un transport développé uniquement par des fournisseurs de commutateurs risquerait de négliger les contraintes des applications et des points d’extrémité. Une conception menée uniquement par des fournisseurs d’accélérateurs pourrait s’optimiser étroitement autour d’un seul écosystème matériel.

Un projet uniquement cloud risquerait de manquer de l’expertise en silicium, en optique et en systèmes nécessaire pour transformer une architecture en produits.

AMD a apporté des processeurs, des accélérateurs et des réseaux de points d’extrémité. Arista et Cisco ont apporté des commutateurs Ethernet à grande échelle et une expérience opérationnelle. Broadcom a apporté du silicium de commutation, des cartes réseau et des SerDes haute vitesse. HPE et Eviden ont apporté des systèmes HPC et une expérience en interconnexions spécialisées. Intel a apporté des processeurs, de l’expertise en Ethernet et en logiciels. Meta et Microsoft représentaient des opérateurs hyperscale ayant un intérêt direct à augmenter l’utilisation des grands clusters d’IA et à réduire leur dépendance à un seul fournisseur intégré.

La coalition comprenait également des intérêts commerciaux concurrents. Les membres vendent des cartes réseau, des ASIC de commutation, des systèmes, de la capacité cloud, de l’optique, des logiciels et de l’assistance. Certains possèdent des portefeuilles de brevets pouvant être nécessaires à l’implémentation. Certains ont intérêt à disposer d’une norme multi-fournisseurs large, tandis que d’autres peuvent aussi tirer profit de fonctionnalités propriétaires différenciées. Le consortium n’élimine donc pas la concurrence.

Il crée un forum au sein duquel des concurrents conviennent d’interfaces minimales tout en continuant à se concurrencer sur la qualité d’implémentation, les performances, l’intégration et les conditions commerciales.

L’interconnexion Slingshot de HPE constitue un exemple utile de filiation technique. Slingshot est une infrastructure HPC compatible Ethernet dotée de fonctions de routage adaptatif et de gestion de la congestion. Des commentaires associés à HPE ont indiqué qu’une spécification Ethernet HPC avait été apportée à l’UEC et qu’une part importante de l’UET dériverait des idées de transport de Slingshot. Le pourcentage exact n’est pas vérifié indépendamment et ne doit pas être considéré comme une comptabilité du consortium. Le point plus large est bien étayé: l’UEC n’est pas partie d’une page blanche.

Elle s’est appuyée sur l’expérience de production des domaines HPC, des réseaux cloud, de RDMA et d’Ethernet.

Ce mélange de systèmes antérieurs est l’une des raisons pour lesquelles le mot « ouvert » appelle de la précision. La spécification ratifiée de l’UEC est téléchargeable publiquement. L’architecture est destinée à être implémentée par plusieurs fournisseurs. Mais le projet est aussi un lieu où les membres apportent des connaissances, des brevets et des feuilles de route produits existants. L’ouverture du document ne supprime pas les conditions économiques ou juridiques entourant la technologie.

Une série juridique conçue pour que les concurrents collaborent

Le modèle de la Joint Development Foundation confère à l’UEC une enveloppe formelle sans en faire une société d’exploitation conventionnelle. Le projet possède son propre nom, son propre périmètre, ses propres catégories de membres, son comité de pilotage, ses groupes de travail et ses obligations de propriété intellectuelle. La structure faîtière de la JDF fournit l’infrastructure juridique et sans but lucratif et peut détenir les actifs et les accords du projet. Cela réduit le coût de formation d’un consortium et offre aux concurrents un processus reconnu pour collaborer.

Le comité de pilotage gouverne le projet. Ses responsabilités documentées comprennent la coordination des groupes de travail, l’approbation des membres, la gestion des actifs et des finances, la sélection ou le remplacement du président, la supervision des progrès et le contrôle de la divulgation publique et des marques du projet. Le consensus est privilégié. Si le consensus échoue, la charte prévoit un mécanisme de majorité qualifiée des trois quarts parmi les entités éligibles remplissant les conditions de participation. Les recours écrits peuvent être adressés au président.

Le président initial était Brad Booth de Meta. La spécification actuelle 1.0.3 indique que J Metz d’AMD est le président, Barry Davis de HPE le vice-président, Hugh Holbrook d’Arista le président du comité consultatif technique et Puneet Agarwal de Marvell le vice-président du TAC. Paul Congdon est mentionné comme éditeur de la spécification. Le document identifie également les responsables et les auteurs des travaux sur les couches physique, de liaison, de transport et logicielle. Un programme de sommet de 2026 nomme des responsables opérationnels supplémentaires.

Ces rôles de sommet ne remplacent pas nécessairement les titres formels de la spécification; le matériel public ne fournit pas un organigramme complet à jour.

Trois catégories de membres figurent dans la charte: Steering, General et Contributor. Les membres Steering participent à la gouvernance et désignent normalement des représentants au comité de pilotage. Les membres General peuvent travailler dans les groupes techniques mais ne siègent pas au comité de pilotage. Les membres Contributor participent à des groupes sélectionnés et n’ont pas droit de vote à la majorité qualifiée. La page publique actuelle des membres promeut les niveaux General et Contributor, avec des prix annuels par projet de 20 000 et 5 000 dollars respectivement, auxquels s’ajoute l’adhésion à la Linux Foundation.

Elle n’explique pas clairement la voie d’accès ni le prix actuel pour le statut Steering.

La différence de pouvoir formel est importante. Une large adhésion peut apporter expertise et portée d’implémentation, mais la gouvernance n’est pas également répartie. Les grandes entreprises capables d’occuper des postes Steering, de fournir des ingénieurs dans de nombreux groupes et de gérer des programmes de brevets et de produits ont plus d’influence pratique que les petits membres Contributor. Les non-membres peuvent télécharger la spécification finale mais ne peuvent pas observer l’intégralité du processus d’élaboration ni participer dans des conditions égales.

Les informations internes du projet ne sont pas traitées comme des données confidentielles ordinaires d’entreprise, mais il est interdit aux membres de divulguer les documents à l’état de projet tant que le comité compétent n’a pas approuvé leur publication. Cette disposition peut aider les concurrents à discuter d’idées inachevées sans signalisation prématurée au marché. Elle signifie aussi que les personnes extérieures ne peuvent pas voir les propositions rejetées, les registres de vote, les préoccupations intermédiaires sur l’implémentation ou les négociations qui ont produit les fonctionnalités optionnelles.

La spécification finale est ouverte; le chemin pour y parvenir n’est que partiellement visible.

D’un lancement à quatre groupes à une spécification de 573 pages

La première structure publique de l’UEC en 2023 s’articulait autour de quatre groupes de travail: logiciel, transport, liaison et physique. Cet ordre reflétait l’ambition de bout en bout du projet. L’adhésion n’a pas été ouverte comme une liste de diffusion publique sans restriction. Plus de 200 organisations avaient exprimé leur intérêt, et le consortium a échelonné l’intégration tout en exigeant une orientation sur les processus et le droit de la concurrence.

Cette prudence était compréhensible car les entités se livrent directement concurrence sur plusieurs marchés et allaient discuter d’exigences communes en matière de produits et de protocoles.

En décembre 2023, l’UEC comptait environ 40 entreprises et plus de 300 individus. Elle avait créé un comité consultatif technique et était passée à huit groupes de travail. Le TAC avait pour objet d’assurer la cohérence architecturale: une conception de transport ne pouvait pas supposer un comportement de commutateur, une méthode de signalisation ou une API qu’un autre groupe n’avait pas accepté de prendre en charge. En mars 2024, le consortium comptait 55 entreprises et plus de 750 entités actifs et publiait une description bien plus claire de son architecture prévue.

La mise à jour de mars a introduit les principales idées qui figureront plus tard dans la spécification normative: libfabric comme API exposée aux logiciels, la diffusion de paquets, la livraison flexible, plusieurs modes de livraison, le contrôle de congestion piloté par l’émetteur et le récepteur, l’ECN, l’élagage des paquets, la retransmission de couche liaison, le contrôle de flux optionnel basé sur des crédits, la sécurité du transport et les futures opérations collectives intégrées au réseau.

Elle a également souligné que l’UET pouvait fonctionner avec les commutateurs Ethernet existants, tandis que les commutateurs améliorés pouvaient offrir des performances supplémentaires.

La portée institutionnelle a grandi parallèlement aux travaux techniques. L’UEC a fait état de 1 193 entités actifs en juillet 2024 et de 97 organisations membres en août. Il s’agit de chiffres datés du consortium, fondés sur des définitions qui ne sont pas entièrement publiques. Ils ne doivent pas être ajoutés mécaniquement aux annonces ultérieures. En 2025, l’UEC a indiqué que 27 nouvelles entreprises l’avaient rejointe, mais les départs, les fusions et les chevauchements de périodes de reporting empêchent d’établir un total actuel exact à partir de cette déclaration. Le site Web lui-même indique que tous les membres ne sont pas affichés.

Le consortium a publié la spécification Ultra Ethernet 1.0 le 11 juin 2025. C’est à ce moment que l’UEC est passée du stade de la feuille de route à celui d’une base d’implémentation publique. La version 1.0.1 a suivi en septembre et a corrigé l’algorithme source de contrôle de congestion par crédit du récepteur ainsi que des problèmes éditoriaux. La version 1.0.2 est arrivée en janvier 2026 et a corrigé les algorithmes de gestion de la congestion, bien que les documents officiels divergent quant à sa date de sortie, le 21 ou le 28 janvier. L’incohérence doit rester visible plutôt que d’être résolue silencieusement.

La version 1.0.3, publiée le 16 juillet 2026, est la référence actuelle à la date de clôture des recherches. Elle compte 573 pages et ajoute la prise en charge de la signalisation à 200 Gb/s par ligne ainsi qu’une capacité de négociation booléenne. Ses notes de version mentionnent également des corrections obligatoires concernant la livraison des paquets, les crédits de congestion, la retransmission de couche liaison et les ensembles ordonnés de contrôle de la couche physique, ainsi que des clarifications pour la sécurité du transport, les opérations atomiques et les paquets élagués.

La distinction entre corrections obligatoires et clarifications éditoriales est importante: certaines modifications affectent le comportement conforme et donc la maintenance des implémentations.

Le sommet des membres 2026 à Denver a marqué une seconde transition. L’ordre du jour était centré sur le déploiement, l’industrialisation, la conformité, la gestion, les performances, le débogage, l’intégration du stockage et les tests des commutateurs et des points d’extrémité. Le document architectural central existe; la crédibilité du projet dépend désormais de plus en plus de la capacité des implémenteurs à construire, qualifier, exploiter et faire évoluer la pile au-delà des frontières organisationnelles.

Une architecture unique sur cinq couches fonctionnelles

La spécification actuelle divise l’Ultra Ethernet en couches logicielle, de transport, réseau, de liaison et physique. Cette division est utile, mais la valeur du projet réside dans les hypothèses qui relient les couches.

Au sommet, les cadres d’IA, MPI, SHMEM et les bibliothèques collectives interagissent via les interfaces OpenFabrics, en particulier libfabric. La sous-couche des services sémantiques UET traduit les opérations applicatives en transactions de transport. La sous-couche de livraison des paquets décide comment les messages sont fragmentés en paquets, ordonnés, acquittés et récupérés. La gestion de la congestion contrôle la quantité de données qui entrent dans la structure et la manière dont le trafic est réparti entre les chemins. La sécurité optionnelle du transport protège le trafic de point d’extrémité à point d’extrémité.

Les protocoles standard IPv4 ou IPv6 assurent le transfert au niveau réseau. Ethernet fournit la liaison, avec l’élagage optionnel des paquets, la retransmission de couche liaison, le contrôle de flux basé sur des crédits et la négociation des fonctionnalités. La couche physique définit les statistiques et les exigences de signalisation à 100 ou 200 Gb/s par ligne.

Cette architecture préserve des parties importantes du réseau existant. L’UEC ne définit pas de remplacement du routage IP. Elle s’attend à un transfert conventionnel à trajets multiples à coût égal et à des commutateurs compatibles ECN. Une grande partie de l’intelligence reste au niveau des points d’extrémité de structure, qui manipulent l’entropie, suivent l’état du transport, placent les données et répondent aux signaux de congestion. Les commutateurs avancés peuvent ajouter des fonctions, mais la conception n’exige pas que chaque déploiement remplace l’intégralité de sa structure pour que le trafic UET puisse transiter.

Cela crée un avantage en termes de migration et un problème de classification. Un déploiement peut utiliser des points d’extrémité UET sur un réseau Ethernet conventionnel avec ECMP et ECN. Un autre peut ajouter l’élagage, la retransmission de liaison, les crédits par canal virtuel, une télémétrie plus riche et, plus tard, des opérations intégrées au réseau. Tous deux peuvent être qualifiés d’Ultra Ethernet, même si leurs performances, leurs caractéristiques de récupération et leur complexité opérationnelle diffèrent sensiblement.

L’approche en cinq couches rend également les défaillances d’implémentation plus difficiles à isoler. Un mauvais résultat peut provenir de la correspondance applicative, de la machine d’état du point d’extrémité, des paramètres de congestion, de la configuration de la file d’attente du commutateur, de la correspondance DSCP, de l’optique, du micrologiciel ou du système de sécurité. Faire passer des paquets ne suffit pas. Le système doit préserver la sémantique et les performances voulues dans des conditions d’échelle, de trafic mixte, de pannes et de changements de version.

Le contrat logiciel: libfabric plutôt qu’une API applicative propriétaire

L’UEC choisit libfabric 2.0 comme API nord de référence pour les points d’extrémité conformes. Ce choix relie le projet à un écosystème logiciel existant de HPC et de réseaux avancés plutôt que de demander à chaque infrastructure d’adopter une nouvelle interface propriétaire. Libfabric représente déjà les structures, les domaines, les points d’extrémité, les files d’attente de complétion, les files d’événements, les vecteurs d’adresses, les régions mémoire, la messagerie, les opérations en mémoire distante et les opérations atomiques.

L’UEC mappe et contraint ces concepts afin que les fournisseurs puissent traduire les appels en comportement UET.

L’intérêt stratégique est la continuité au-dessus du transport. MPI, SHMEM et les bibliothèques de communication pour accélérateurs peuvent utiliser des abstractions familières tandis que le fournisseur sous-jacent change. En principe, une application peut demander une opération sans savoir quel fournisseur de carte réseau met en œuvre la livraison des paquets ni quel silicium de commutateur transmet les paquets. C’est l’un des principaux mécanismes par lesquels un transport commun pourrait créer un choix de fournisseurs.

L’abstraction ne garantit pas des implémentations équivalentes. Les fournisseurs peuvent prendre en charge différentes tailles d’injection, limites de dispersion/agrégation, nombres de points d’extrémité, opérations atomiques, techniques d’enregistrement mémoire, comportement de complétion, déchargement matériel et fonctions de sécurité. Une bibliothèque qui se compile avec la même API peut néanmoins rencontrer des limites de performance ou de capacité différentes. L’achat et la qualification logicielle exigent donc plus qu’une simple case à cocher « compatible libfabric ».

La couche logicielle de l’UEC porte également une sémantique de tâches et d’autorisations. Les systèmes d’IA et de HPC exécutent souvent de nombreuses tâches sur une infrastructure partagée, chacune avec ses propres processus, régions mémoire et frontières de sécurité. La spécification doit identifier quel point d’extrémité appartient à quelle tâche, quelles mémoires tampons sont accessibles, comment une opération distante est mise en correspondance et comment les informations de complétion ou d’erreur sont renvoyées au logiciel.

Ces décisions déterminent si un réseau rapide est utilisable par l’ordonnanceur, l’environnement d’exécution et l’application, plutôt que simplement impressionnant dans un banc d’essai de paquets.

Le projet dépend de l’écosystème OpenFabrics car il ne possède pas libfabric. Cette relation illustre une caractéristique plus large de l’UEC: l’architecture est composée de composants régis dans différents endroits. L’UEC peut définir comment son transport s’interface avec libfabric, mais elle doit se coordonner avec les mainteneurs et les utilisateurs de l’API. Des dépendances similaires existent avec l’Ethernet de l’IEEE, la mise en réseau de l’IETF, les organisations de stockage et les systèmes d’exploitation des fournisseurs.

Points d’extrémité de structure et profils de charge de travail

Un point d’extrémité de structure (Fabric Endpoint, ou FEP) est l’endroit logique où se termine l’UET. Il connecte une instance de système d’exploitation à un ou plusieurs plans de structure isolés et peut comprendre un fournisseur en espace utilisateur, un pilote noyau, une carte réseau ou un transport côté accélérateur, un système d’enregistrement mémoire, un contexte de sécurité, des files d’attente de complétion, des vecteurs d’adresses et l’état utilisé pour la livraison des paquets et le contrôle de congestion.

Cette conception centrée sur les points d’extrémité permet à la plupart des commutateurs de rester des équipements Ethernet et IP reconnaissables. Le FEP choisit les valeurs d’entropie, maintient l’état des paquets et de la congestion, place les données dans la mémoire autorisée et interprète les acquittements, l’élagage et les autres rétroactions. Cela peut réduire la dépendance à une intelligence de routage propriétaire intégrée aux commutateurs. Cela concentre également la complexité dans le silicium, le micrologiciel, les pilotes et les logiciels des cartes réseau.

L’UEC définit trois profils d’implémentation: AI Base, AI Full et HPC. Il ne s’agit pas de types de réseau distincts. Ce sont des ensembles qui spécifient les fonctions qu’une implémentation doit prendre en charge. AI Base est destiné à couvrir les communications IA courantes avec un coût d’implémentation et un état réduits. AI Full ajoute des fonctions telles que les envois différables, la correspondance exacte et les opérations atomiques de type extraction/comparaison. Le profil HPC comprend la plupart des capacités d’AI Full, exclut l’envoi différable et met davantage l’accent sur l’ordonnancement, les messages courts et la sémantique HPC.

Le système de profils vise à éviter que chaque produit doive implémenter l’ensemble maximal de fonctionnalités. Il reconnaît qu’une carte réseau IA à fort volume peut privilégier le mouvement de données collectif, tandis qu’un point d’extrémité HPC peut nécessiter un ordonnancement et des opérations atomiques plus stricts. Pourtant, les profils n’éliminent pas l’optionalité. Un produit peut implémenter des fonctionnalités optionnelles au sein d’un profil, et deux produits portant le même libellé de profil peuvent différer en termes de sécurité, d’améliorations de liaison, de capacité et de performances.

La terminologie est déjà un signe avant-coureur. La spécification 1.0.3 fait autorité et utilise AI Base, AI Full et HPC. Un fichier readme de conformité distinct de 2025 utilise AI Base, AI Extended et HPC. L’interprétation la plus étayée est que « AI Full » est la version actuelle et que le document de conformité est obsolète ou incohérent. Tant que le paquet de test public n’a pas été corrigé, les fournisseurs et les acheteurs doivent identifier à la fois la version de la spécification et la terminologie exacte du profil qui sous-tend une revendication.

De l’intention applicative à la livraison des paquets

À l’intérieur de l’UET, la sous-couche des services sémantiques porte l’intention applicative. Elle définit l’identité du message, l’adressage des tampons, les opérations étiquetées et non étiquetées, l’accès à la mémoire distante, les opérations atomiques, le comportement de complétion, les identifiants de tâche, l’autorisation des tampons, les réponses et les erreurs. La sous-couche de livraison des paquets détermine ensuite comment cette intention devient des paquets et comment ces paquets atteignent un autre point d’extrémité.

Pour les modes fiables, les points d’extrémité établissent des contextes de livraison de paquets (Packet Delivery Contexts, PDC). Un PDC contient des états tels que les numéros de séquence des paquets, les acquittements, la détection des doublons, le mode d’ordonnancement, les informations de congestion, l’état de la direction retour et la classe de trafic. Un PDC est associé à un mode de livraison et une classe de trafic uniques, et plusieurs PDC peuvent exister entre une même paire de FEP.

Cet état n’est pas un détail d’implémentation mineur. Les grands clusters peuvent générer un nombre considérable de relations de communication. Si chaque relation nécessite un état cible important, la mémoire et le coût de recherche des points d’extrémité peuvent devenir limitants. L’UEC n’impose donc pas à chaque opération d’entrer dans un modèle de connexion unique. Elle définit quatre services de livraison avec des contrats de fiabilité et d’ordonnancement différents.

La livraison fiable non ordonnée (Reliable Unordered Delivery, ou RUD) assure une livraison exactement une fois des paquets à la couche sémantique tout en permettant aux paquets d’arriver dans le désordre. Elle prend en charge la diffusion de paquets sur plusieurs chemins, la retransmission sélective, la suppression des doublons et le placement direct des données. Comme la destination peut placer les données selon des décalages plutôt que d’attendre un tampon de réorganisation au niveau transport, une longue opération collective peut exploiter plusieurs chemins sans devoir sérialiser tous les paquets derrière une unité manquante.

La livraison fiable ordonnée (Reliable Ordered Delivery, ou ROD) assure une livraison exactement une fois et dans l’ordre. Elle utilise un seul chemin et une seule valeur d’entropie, rejette les paquets hors séquence et repose sur une récupération Go-Back-N à partir de la première séquence manquante. Cela semble moins sophistiqué que RUD, mais cela préserve la sémantique requise pour les opérations pour lesquelles un ordonnancement strict est important. L’UEC traite l’ordonnancement comme une exigence applicative plutôt que de supposer que chaque transfert doit en supporter le coût.

La livraison fiable non ordonnée pour opérations idempotentes (Reliable Unordered Delivery for Idempotent Operations, ou RUDI) fait un compromis différent. Elle fournit une livraison au moins une fois et autorise les doublons, ce qui réduit l’état ordinaire de séquence et d’acquittement à la cible. Elle peut être utile lorsque la répétition d’une opération ne modifie pas le résultat final, comme certains mouvements de mémoire distante suivis d’une barrière distincte. Elle est dangereuse si elle est appliquée incorrectement. La couche paquet ne déduit pas si une opération est idempotente; c’est au logiciel de prendre cette décision.

Utiliser RUDI pour une opération non idempotente peut produire un état applicatif invalide.

La livraison non fiable non ordonnée (Unreliable Unordered Delivery, ou UUD) fournit des datagrammes au mieux sans garantie normale de fiabilité ou d’ordonnancement. Elle appartient au même cadre sémantique mais n’est pas soumise aux mêmes exigences de contrôle de congestion que RUD et ROD. Les applications doivent éviter de nuire au trafic contrôlé par la congestion lorsque UUD partage des files d’attente ou des classes de trafic.

Ces quatre modes révèlent une philosophie centrale de l’UEC: le réseau doit exposer plusieurs mécanismes afin que le logiciel puisse faire correspondre le coût du transport à la sémantique de l’opération. L’avantage est l’efficacité. Le coût est une surface d’implémentation et de test plus large, avec davantage d’opportunités pour un fournisseur, une application ou un opérateur de choisir une combinaison incompatible.

Distribution de paquets: utiliser la structure plutôt qu’un seul chemin chanceux

Le transfert conventionnel à trajets multiples à coût égal hache souvent un flux entier sur une seule route. Dans une structure Clos large, cela peut créer une loterie. Plusieurs flux importants peuvent entrer en collision sur les mêmes liaisons alors qu’une capacité équivalente reste inutilisée ailleurs. Un long transfert d’IA peut alors être limité par un hachage malchanceux pendant toute sa durée.

L’UET résout ce problème en modifiant l’entropie à la granularité du paquet. Un émetteur peut utiliser des dizaines ou des centaines de valeurs d’entropie, ce qui permet aux mécanismes ECMP existants des commutateurs de répartir les paquets sur de nombreuses routes. La sous-couche de livraison des paquets fournit les informations de séquence; la sous-couche de gestion de la congestion sélectionne l’entropie ou le chemin; les commutateurs effectuent leur hachage normal; et la rétroaction indique à l’émetteur quelles valeurs d’entropie semblent congestionnées.

La distribution de paquets n’est praticable que parce que les autres parties de la conception la soutiennent. Les paquets peuvent arriver dans le désordre. RUD peut placer les données directement plutôt que d’attendre une réorganisation complète au niveau transport. La retransmission sélective peut ne récupérer que ce qui a été perdu. La rétroaction de congestion peut réduire l’utilisation des chemins problématiques. Le mécanisme n’est donc pas une astuce d’équilibrage de charge autonome. Il fait partie d’un modèle de transport construit autour de la diversité des chemins.

L’UEC n’exige pas que chaque commutateur exécute un algorithme de routage adaptatif propriétaire. Les implémentations de base peuvent utiliser une répartition circulaire ou pseudo-aléatoire de l’entropie sur l’ECMP standard. Des points d’extrémité plus avancés peuvent associer les signaux ECN, de latence ou d’élagage à des valeurs d’entropie particulières et éviter les chemins qui semblent congestionnés. Un transfert adaptatif propre à un fournisseur peut coexister avec l’UET, mais il n’est pas la seule source de connaissance des chemins.

La promesse est une meilleure utilisation de la structure et une latence de queue plus faible. La question non résolue est de savoir avec quelle constance les différents points d’extrémité interprètent la rétroaction et comment la distribution de paquets interagit avec les tampons des commutateurs, le réordonnancement, les pannes et le trafic mixte. Un algorithme qui fonctionne bien dans un laboratoire homogène peut se comporter différemment sur une grande structure comprenant plusieurs générations de commutateurs et classes de trafic. Les preuves indépendantes et multi-fournisseurs sont encore limitées.

Trois mécanismes de congestion pour trois goulots d’étranglement différents

L’UEC ne définit pas un algorithme de congestion universel. Elle distingue la congestion dans le cœur du réseau, les incasts au niveau du récepteur et les tampons limités des points d’extrémité.

Le contrôle de congestion par signal réseau (Network-signal Congestion Control, ou NSCC) est piloté par la source. L’émetteur maintient une fenêtre de congestion, estime les octets en transit et ajuste la fenêtre à l’aide des acquittements, des acquittements négatifs, des délais d’attente, de la latence et des signaux réseau tels que l’ECN. Il coordonne le comportement de la fenêtre avec le multi-cheminement au niveau des paquets.

L’UEC fait valoir qu’une fenêtre cesse naturellement d’admettre des données lorsque les paquets ne parviennent pas à quitter le réseau, tandis qu’un contrôleur purement basé sur le débit peut mal interpréter l’absence de rétroaction.

C’est la position architecturale du consortium, et non une preuve indépendante que chaque implémentation NSCC surpasse DCQCN ou d’autres contrôles de congestion RoCE. Les résultats dépendent des détails de l’algorithme, du marquage des commutateurs, de la topologie, des schémas de trafic et des choix de paramètres. « Utilise NSCC » n’est donc pas une revendication de performance suffisante.

Le contrôle de congestion par crédit du récepteur (Receiver-credit Congestion Control, ou RCCC) cible les incasts. Lorsque de nombreuses sources envoient simultanément à une destination, le dernier lien peut devenir le goulot d’étranglement même si le cœur du réseau n’est pas congestionné. Le récepteur suit la demande et répartit des crédits entre les émetteurs, en régulant l’arrivée agrégée et en faisant varier la fenêtre effective de chaque source en fonction de la concurrence. Le RCCC peut fonctionner parallèlement au NSCC, car la surcharge du récepteur et la congestion du cœur sont des problèmes distincts.

Le contrôle de flux de transport (Transport Flow Control, ou TFC) utilise également des crédits mais dessert des services point à point à tampon limité. Son objectif est d’empêcher directement le débordement du tampon du récepteur lorsque la tolérance aux pertes est faible. Il peut être utilisé avec ou sans multi-cheminement. Traiter chaque mécanisme de crédit comme identique masquerait les domaines de défaillance distincts que chacun est censé contrôler.

La spécification s’attend à une notification explicite de congestion dans l’ensemble de la structure et inclut des hypothèses opérationnelles concernant le marquage, notamment le marquage au retrait de la file plutôt que de s’appuyer uniquement sur le comportement à la mise en file d’attente. Les points d’extrémité interprètent l’ECN avec les acquittements, la latence et l’élagage. Une configuration cohérente des commutateurs est donc essentielle. Une implémentation de transport peut être correcte tandis qu’une structure mal configurée produit de mauvais résultats.

L’historique de maintenance démontre la difficulté. La version 1.0.1 a corrigé l’algorithme source RCCC. La version 1.0.2 a corrigé des cas de gestion de la congestion. La version 1.0.3 a corrigé des interactions impliquant les crédits et la retransmission de couche liaison. Ce sont des signes normaux d’une spécification vivante, mais ils montrent aussi que l’état des crédits, de la retransmission et du contrôle de chemin peuvent interagir de manière subtile. Les opérateurs auront besoin de discipline de version et de tests de régression, pas seulement de conformité au premier jour.

Élagage des paquets et récupération précise des pertes

L’élagage des paquets modifie ce que fait un commutateur capable lorsqu’il ne peut pas conserver un paquet entier. Au lieu de rejeter la trame sans autre information, le commutateur supprime la majeure partie ou la totalité de la charge utile, préserve suffisamment d’en-tête et de métadonnées pour identifier le paquet, le marque comme élagué et transmet la notification raccourcie vers le récepteur. Le récepteur peut alors signaler les données manquantes spécifiques à l’émetteur.

C’est plus informatif qu’une marque ECN. L’ECN indique qu’une congestion a été rencontrée; l’élagage identifie un paquet dont la charge utile n’a pas survécu. Combiné à RUD et à la retransmission sélective, cela peut accélérer la récupération sans attendre un délai d’expiration ni retransmettre une longue séquence après une seule perte.

La fonctionnalité du commutateur est optionnelle, mais les points d’extrémité conformes doivent recevoir et interpréter les paquets élagués selon les exigences applicables. Cette asymétrie permet le déploiement sur des commutateurs conventionnels tout en permettant aux structures améliorées de fournir des informations de perte plus riches. Elle crée également un problème de mise à niveau. Un réseau partiellement amélioré peut devoir limiter l’élagage par chemin, par profil ou par topologie afin que chaque point d’extrémité récepteur le traite correctement.

L’UEC définit également des classes de trafic différenciées pour les requêtes, les paquets de contrôle, les retransmissions et le trafic élagué. Les opérateurs doivent faire correspondre les valeurs DSCP, les files d’attente des commutateurs, les files d’attente des points d’extrémité et les niveaux de priorité de manière cohérente. La spécification ne fournit pas de système de gestion universel pour cette correspondance. Un désalignement peut affamer le trafic de contrôle, fausser la rétroaction de congestion ou mettre les paquets de récupération en concurrence avec le trafic qu’ils sont censés réparer.

L’élagage des paquets illustre le défi plus large de l’implémentation du projet. Le protocole peut définir le comportement sur le réseau, mais le résultat opérationnel dépend de la gestion des files d’attente des commutateurs, de la logique des points d’extrémité, de la télémétrie, de la configuration et de la gestion des pannes. L’interopérabilité est donc une propriété du système plutôt qu’une propriété du format des paquets.

Récupération de liaison, crédits et négociation des fonctionnalités

La retransmission de couche liaison (Link Layer Retry, ou LLR) tente de récupérer une corruption sur une liaison physique avant que le transport de bout en bout ne réagisse. Un pair détecte un trou de séquence ou une trame corrompue, envoie un acquittement négatif au niveau liaison et amène l’émetteur à rejouer la trame affectée depuis un tampon local. Si la récupération réussit rapidement, le transport peut éviter une retransmission de bout en bout plus longue.

La valeur potentielle augmente à mesure que les débits de ligne et les densités de port augmentent. Des erreurs optiques ou électriques occasionnelles peuvent sinon créer un retard disproportionné dans une tâche étroitement synchronisée. Cependant, LLR ajoute un état de séquence, des tampons de rejeu, des messages de contrôle, des fenêtres de rejet et de nouveaux modes de défaillance. Elle doit également coexister avec les mises à jour de crédits et les réinitialisations de liaison. La version 1.0.3 a corrigé plusieurs cas limites, notamment une condition de concurrence impliquant les informations de crédit CBFC et LLR.

Le contrôle de flux basé sur des crédits (Credit-Based Flow Control, ou CBFC) fonctionne par canal virtuel au niveau de la liaison. Il indique à l’émetteur la capacité de réception restante et peut fournir un contrôle plus fin que les larges pauses de priorité. L’UEC le présente comme un moyen de prendre en charge un comportement sans perte contrôlé sans exiger que chaque déploiement UET soit globalement sans perte. CBFC est optionnel, et UET est conçu pour fonctionner sur des réseaux au mieux.

Il ne faut pas considérer CBFC comme un autre nom pour le contrôle de flux prioritaire. Les mécanismes diffèrent en termes de signalisation et de granularité, même si tous deux cherchent à empêcher le débordement des tampons. CBFC nécessite néanmoins une configuration cohérente et une livraison correcte de ses propres trames de contrôle. Les crédits locaux peuvent également interagir avec les fenêtres de bout en bout et les crédits du récepteur, créant plusieurs boucles de contrôle imbriquées.

L’UEC utilise une négociation basée sur LLDP pour découvrir les fonctionnalités optionnelles de liaison et empêcher qu’un côté active une capacité que son voisin ne prend pas en charge. La négociation doit tenir compte des profils, des canaux virtuels, de la correspondance DSCP et de priorité, des réinitialisations, des mises à jour logicielles et des combinaisons partielles de fonctionnalités. La version 1.0.3 a ajouté une capacité de négociation booléenne, renforçant l’importance d’un accord explicite sur chaque liaison.

Ces options offrent une voie allant de l’Ethernet de base à l’Ethernet amélioré. Elles créent également une matrice que le langage des achats peut masquer. Un commutateur peut transmettre l’UET parfaitement sans disposer de l’élagage, de LLR ou de CBFC. Un autre peut prendre en charge ces fonctionnalités uniquement dans certaines versions logicielles ou certains modes de port. Un dossier de déploiement crédible nécessite l’ensemble exact des fonctionnalités, et pas simplement le nom du consortium.

Signalisation physique à 100 et 200 gigabits par ligne

La couche physique ancre l’UEC dans la feuille de route matérielle. Les travaux initiaux 1.0 étaient rédigés autour de la signalisation à 100 Gb/s par ligne. La version 1.0.3 a ajouté la prise en charge de 200 Gb/s par ligne. Ce changement aligne la spécification sur une génération de liaisons et de systèmes de densité supérieure, mais il s’agit d’une capacité spécifiée, et non de la preuve que tous les produits UEC prennent immédiatement en charge ce débit.

Les travaux PHY de l’UEC traitent également des statistiques de correction aval des erreurs, des ratios de mots de code corrigés et non corrigibles, des ensembles ordonnés de contrôle, des rapports de qualité de liaison et de l’interaction entre les erreurs physiques et LLR. Ces détails sont importants parce que les décisions de récupération du transport dépendent de ce que les couches inférieures peuvent observer et signaler.

À des débits de signalisation plus élevés, la frontière entre l’optique, les SerDes, la FEC, la retransmission de liaison et la récupération du transport devient économiquement significative. Une FEC plus forte peut réduire les erreurs résiduelles au prix de la latence et de la puissance. La retransmission de liaison peut récupérer plus rapidement une corruption locale mais nécessite des tampons et de l’état. La retransmission de bout en bout est plus simple sur l’ensemble du réseau mais peut faire perdre plus de temps. L’UEC tente de définir comment ces couches coopèrent plutôt que de laisser chaque fournisseur optimiser isolément.

L’ajout de lignes à 200G illustre également la cible mouvante du consortium. Les implémenteurs de la version 1.0 doivent maintenir la compatibilité tout en planifiant de nouvelles capacités physiques. Les équipements de test, les micrologiciels et les systèmes de gestion doivent distinguer ce qui est pris en charge sur chaque port. Les acheteurs ne doivent pas déduire le débit de ligne d’une revendication UEC générique.

Sécurité optionnelle de transport de bout en bout

La sous-couche de sécurité du transport (Transport Security Sublayer, ou TSS) fournit une protection optionnelle de point d’extrémité à point d’extrémité. Son modèle de menace ne nécessite pas que les commutateurs soient dignes de confiance. Elle peut fournir la confidentialité, l’intégrité, la protection contre la relecture, l’isolation des tâches, des domaines sécurisés, un groupement de clés, une rotation des clés et l’intégration avec les racines de confiance matérielles.

La conception utilise des domaines sécurisés dont les membres partagent un contexte cryptographique. Les identifiants, les numéros d’association, les époques, l’identité source sécurisée et la dérivation de clés sont conçus pour passer à l’échelle au-delà de l’établissement d’une session indépendante pour chaque paire de points d’extrémité. C’est nécessaire lorsque les populations d’accélérateurs et l’appartenance aux tâches changent rapidement.

Le protocole n’est qu’une partie du système de sécurité. Un opérateur en production doit gérer des autorités de clés, des certificats ou d’autres racines de confiance, des services d’appartenance aux tâches, de distribution et de révocation, des transitions d’époque, la récupération des points d’extrémité, la cryptographie matérielle et la télémétrie de sécurité. Le réseau peut être conforme à un profil sans activer toutes les fonctions optionnelles du TSS. « Conforme UEC » ne signifie pas automatiquement chiffré.

L’optionalité de la sécurité reflète des hypothèses de déploiement différentes. Une structure dédiée physiquement contrôlée peut privilégier les performances et s’appuyer sur des contrôles environnementaux. Un cloud multi‑locataire peut nécessiter une isolation forte et une protection cryptographique. Le système de profils et d’achats doit rendre cette différence visible.

Le risque le plus sérieux n’est pas simplement le surcoût du chiffrement. C’est la défaillance du cycle de vie à grande échelle: appartenance périmée, révocation retardée, époques incohérentes, récupération après un point d’extrémité défaillant ou incapacité à prouver quelle tâche peut accéder à quelle mémoire. Ces problèmes relient la sécurité du transport aux systèmes d’orchestration et d’identité extérieurs à la spécification de base.

Ce que signifie actuellement « conforme UEC »

L’UEC a commencé à publier des documents de conformité avec la version 1.0, mais le système public n’est pas un régime de certification indépendant mature. Le paquet disponible est principalement conçu pour l’auto-attestation des implémenteurs. Des matrices font correspondre les exigences de la spécification aux profils, et un guide de banc d’essai décrit les configurations recommandées de points d’extrémité et de commutateurs. Aucune base de données publique exhaustive n’a été identifiée dans laquelle une autorité indépendante enregistrerait les produits ayant réussi ou échoué à un programme UEC complet.

La distinction est essentielle car plusieurs revendications différentes circulent sur le marché. Un produit peut être conçu autour des fonctionnalités UEC en développement. Il peut implémenter certaines fonctions de transmission. Il peut prendre en charge un profil, ou des parties d’un profil, sur une version logicielle spécifique. Un fournisseur peut déclarer qu’il est entièrement conforme aux fonctionnalités. Un laboratoire d’essai peut générer du trafic UET à travers un commutateur. Aucune de ces déclarations n’est automatiquement équivalente à une certification indépendante, multi‑fournisseurs, de bout en bout.

Les recommandations publiques de banc d’essai sont utiles mais délibérément limitées. Elles fournissent des topologies exemplaires et des vérifications plutôt qu’une qualification système complète. Les documents excluent ou ne couvrent pas complètement les tests d’interopérabilité plus larges, de performance, de stress, d’échelle et de cycle de vie des API. Ils ne prouvent pas le comportement en présence de trafic mixte UET et RoCE, de mises à niveau partielles, de pannes répétées, de grands domaines de clés ou du nombre le plus ambitieux de points d’extrémité du consortium.

L’incohérence de nom de profil entre AI Full et AI Extended illustre encore pourquoi la conformité nécessite un versionnage discipliné. Un acheteur devrait demander quelle spécification, quel niveau de correction, quel profil, quelles fonctionnalités optionnelles, quels modes de liaison et quelles fonctions de sécurité une revendication couvre. La réponse devrait indiquer si les preuves proviennent de tests internes, d’une démonstration bilatérale, d’un événement du consortium ou d’un laboratoire indépendant.

Une prochaine étape crédible comprendrait des définitions de tests publiques liées aux versions exactes de la spécification, des plugfests multi‑fournisseurs, des résultats administrés de manière indépendante, des résultats négatifs comme des succès, et un registre qui distingue les points d’extrémité, les commutateurs, les logiciels et les systèmes complets. D’ici là, « conforme UEC » est une question initiale plutôt qu’une assurance complète.

Un document ouvert avec des obligations de brevet RAND

La spécification Ultra Ethernet 1.0.3 est téléchargeable publiquement et distribuée sous licence Creative Commons Attribution-NoDerivatives 4.0. Cela permet la redistribution avec attribution mais n’autorise pas la distribution de versions modifiées selon la licence. Plus important encore, l’accès au droit d’auteur et l’accès aux brevets sont distincts.

Les chartes documentées des groupes de travail utilisent généralement un modèle traditionnel d’élaboration de spécifications avec des licences de brevet raisonnables et non discriminatoires (RAND). RAND ne signifie pas nécessairement sans redevance. Cela ne garantit pas un prix universel unique, n’élimine pas les négociations et n’empêche pas les litiges concernant la validité, le caractère essentiel, la portée géographique ou les conditions défensives. La position commerciale réelle dépend de chaque brevet déclaré, de l’engagement du membre et de toute licence bilatérale.

L’UEC tient un registre public des déclarations de revendications nécessaires. À la date de clôture, des déclarations associées à Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell et d’autres étaient visibles, y compris des dépôts liés aux travaux futurs 1.1. Le registre améliore la transparence en montrant que les implémenteurs peuvent avoir besoin d’examiner la propriété intellectuelle avant de construire ou d’expédier un produit.

Le consortium ne détermine pas explicitement si un brevet déclaré est valide, réellement essentiel, contrefait ou disponible à un prix particulier. Il ne publie pas non plus de licence commune. Les petits implémenteurs peuvent donc être confrontés à des coûts juridiques et de transaction que les grands membres peuvent absorber plus facilement. Une spécification accessible au public peut néanmoins produire un écosystème d’implémentation commercialement concentré si la levée des brevets, le coût du silicium et les dépenses de test sont élevés.

Le cadre de propriété intellectuelle façonne également les incitations à la gouvernance. Les entreprises apportent de la technologie, en partie pour créer un vaste marché pour leurs produits et en partie pour s’assurer que leurs capacités existantes sont représentées dans la conception commune. Les déclarations de brevet ne peuvent protéger les implémenteurs contre les surprises que si elles sont faites en temps utile et suffisamment claires. Elles n’éliminent pas la possibilité que les licences deviennent un obstacle après que l’architecture a été adoptée.

La description honnête est donc « publiée ouvertement et multi‑fournisseurs, avec des engagements de brevet RAND », et non universellement sans redevance. Les équipes d’achats ont besoin à la fois du profil technique et du chemin de licence.

La première vague de produits et de tests

Des preuves d’implémentation sont devenues visibles autour de la sortie 1.0, mais les exemples se situent à différents stades de maturité.

AMD a rendu sa carte réseau IA Pollara 400 commercialement disponible en avril 2025 et l’a décrite comme conçue autour des capacités UEC en développement. Pollara est une plateforme de point d’extrémité programmable et un signal important que le transport est passé en matériel commercial. La formulation est importante: la conception pour des fonctionnalités UEC en évolution n’est pas la même chose qu’une certification indépendante par rapport à chaque exigence finale 1.0.3.

Broadcom a annoncé Tomahawk 6 en juin 2025 comme un ASIC de commutation de 102,4 térabits par seconde doté de fonctionnalités pertinentes pour les structures à l’échelle UEC. En octobre, elle a annoncé la carte réseau Thor Ultra 800G et déclaré que la conception offrait une conformité complète aux fonctionnalités UEC. Il s’agit d’une revendication importante de la part du fournisseur, mais les preuves publiques ne la transforment pas en un certificat indépendant du consortium. L’échantillonnage des produits, la maturité logicielle et le support exact du profil doivent être identifiés séparément.

Nokia et Keysight ont annoncé une démonstration de trafic UET de bout en bout en octobre 2025 sur les familles de commutateurs de centres de données Nokia 7220 et 7250 à 800 Gigabit Ethernet. Keysight a fourni la génération et la validation du trafic. Ce test montre que le trafic UET peut traverser des systèmes de commutation commerciaux et que le support des équipements de test se développe. Il n’établit pas un profil de point d’extrémité multi‑fournisseur complet, une échelle de production ou une certification indépendante de chaque fonctionnalité optionnelle.

D’autres membres ont décrit des commutateurs, des systèmes, des logiciels ou des plans de test compatibles UEC, et le sommet de 2026 s’est fortement concentré sur l’industrialisation. Les preuves soutiennent une transition vers l’implémentation. Elles ne permettent pas encore un décompte exact des cartes réseau UET livrées, des commutateurs certifiés, des régions cloud déployées ou des structures complètes.

La manière la plus utile de lire la vague de produits est comme une chaîne de preuves. Une spécification publique permet la conception. Les annonces de silicium et de cartes réseau montrent l’investissement. Les démonstrations de trafic montrent une certaine interopérabilité. Les matrices de conformité organisent les exigences. Les rapports de déploiement des opérateurs montreraient la valeur opérationnelle. Des plugfests indépendants et des résultats de production établiraient la crédibilité plus large qui fait encore défaut au dossier actuel.

RoCE, InfiniBand, Slingshot et UALink

L’UEC entre sur un marché où existent des alternatives matures et des technologies adjacentes. Son argument stratégique n’est pas qu’Ethernet n’a jamais transporté du RDMA ou que les structures spécialisées ne fonctionnent pas. C’est que l’échelle et la synchronisation des charges de travail d’IA actuelles justifient une nouvelle architecture Ethernet de bout en bout avec une livraison, une utilisation des chemins et un contrôle de congestion plus flexibles.

RoCEv2 est le prédécesseur direct et une technologie installée majeure. Il place le trafic RDMA sur Ethernet routable et bénéficie d’un large support applicatif et produit. L’UEC critique les déploiements RoCE courants pour l’assignation de flux entiers à un seul chemin, la récupération Go‑Back‑N, le réordonnancement au récepteur, le réglage difficile de DCQCN, la dépendance au contrôle de flux prioritaire dans de nombreuses conceptions et un comportement faible sous incasts ou rafales collectives. Ce sont les positions techniques de l’UEC, et non la preuve que chaque réseau RoCE fonctionne mal.

La comparaison est également dynamique. Les fournisseurs peuvent ajouter le routage adaptatif, la diffusion de paquets, de meilleurs algorithmes de congestion ou d’autres fonctions de type UEC aux cartes réseau programmables tout en conservant la compatibilité RoCE. La communication d’AMD autour de Pollara, par exemple, présente RoCEv2 et UEC RDMA comme des choix sur du matériel programmable. L’UEC peut donc concurrencer RoCE en tant que transport complet tout en influençant l’évolution des futurs produits RoCE.

InfiniBand est la principale alternative de structure spécialisée. Il fournit un écosystème intégré RDMA, de congestion, de fiabilité de liaison et de gestion avec une longue expérience HPC. Les travaux 2.0 de l’InfiniBand Trade Association incluent le support physique XDR à 200 Gb/s par ligne et une télémétrie mise à jour. La différenciation la plus forte de l’UEC n’est pas une affirmation selon laquelle InfiniBand manque de performance. C’est la possibilité d’obtenir un comportement IA et HPC via la chaîne d’approvisionnement Ethernet plus large, le routage IP standard et un plus grand choix multi‑fournisseurs.

HPE Slingshot occupe une position intermédiaire. C’est une structure HPC commerciale compatible Ethernet avec un routage adaptatif et une gestion de la congestion, qui a fourni d’importants antécédents techniques à l’UET. Elle démontre qu’un comportement spécialisé peut être construit sur Ethernet, tout en montrant la différence entre une plateforme commerciale contrôlée et une spécification à l’échelle de l’industrie.

UALink est généralement complémentaire plutôt qu’un substitut direct. Sa spécification 200G publique actuelle cible une connectivité scale‑up à faible latence entre accélérateurs à l’intérieur d’un pod et décrit des systèmes jusqu’à 1 024 accélérateurs. L’UEC 1.0 est principalement une structure scale‑out connectant des nœuds entre les commutateurs. Un centre de données peut utiliser une liaison scale‑up à l’intérieur d’un pod de calcul et l’UEC entre les pods ou les nœuds.

Les travaux futurs de l’UEC sur le transport scale‑up optimisé et les opérations collectives intégrées au réseau pourraient rapprocher les frontières et créer soit une convergence, soit une concurrence.

NVIDIA Spectrum‑X et les structures d’accélérateur propriétaires présentent une autre comparaison: une pile étroitement intégrée peut optimiser rapidement le matériel, les logiciels et le support, mais elle augmente la dépendance à un seul écosystème. L’UEC troque une partie de cette intégration contre la promesse d’interfaces communes et de choix de fournisseurs. La valeur de ce compromis dépendra des performances, du support, des conditions de brevet, de l’interopérabilité et du coût total de possession – et non d’une étiquette ouverte abstraite.

Le problème opérationnel dépasse le protocole

Une spécification de 573 pages peut définir de nombreuses exigences, mais une structure de production a encore besoin d’un modèle d’exploitation. L’UEC 1.0 laisse un travail de gestion important en dehors ou autour du document normatif central. Les opérateurs doivent configurer les profils, les classes de trafic, les seuils ECN, les ensembles d’entropie, les fonctionnalités de liaison optionnelles, les clés, les micrologiciels, la télémétrie et la politique de défaillance de manière cohérente sur les points d’extrémité et les commutateurs.

Le trafic mixte rend le problème plus difficile. La structure d’un centre de données peut transporter de l’UET, du RoCE, du TCP, du stockage, de la gestion et des services UET ordonnés et non ordonnés à la fois. L’allocation de file d’attente et l’équité entre ces classes ne sont pas résolues par la simple implémentation correcte de chaque protocole. Un algorithme de congestion peut bien se comporter isolément et mal lorsqu’il est en concurrence avec un autre contrôleur utilisant des rétroactions et des hypothèses différentes.

La complexité des points d’extrémité est un autre risque structurel. L’UET place le multi‑cheminement, le placement direct, la retransmission sélective, plusieurs modes de livraison, le contrôle de fenêtre et de crédit, la réception d’élagage, la sécurité et un état substantiel dans le FEP. Cela peut augmenter la surface de la puce de la carte réseau, la taille du micrologiciel, l’effort de vérification, la puissance et le nombre de conditions de défaillance à diagnostiquer.

La dépendance du projet à l’intelligence des points d’extrémité rend possible une large chaîne d’approvisionnement, mais elle signifie aussi que l’implémentation la plus difficile peut se situer dans le composant que chaque serveur doit acheter.

Les fonctionnalités optionnelles créent à la fois une différenciation des produits et une fragmentation. Un fournisseur peut optimiser un point d’extrémité AI Base de base pour l’ECMP et l’ECN conventionnels. Un autre peut prendre en charge AI Full, TSS, l’élagage, LLR et CBFC. Tous deux peuvent participer à l’écosystème UEC, mais les opérateurs ne peuvent pas supposer la même sémantique, les mêmes performances ni la même sécurité. Les matrices de conformité doivent devenir des matrices de capacités opérationnelles.

La maintenance des versions sera continue. Les corrections de 1.0.1 à 1.0.3 ont affecté la congestion, les crédits, la retransmission et le comportement des paquets. Un grand cluster peut contenir plusieurs versions de micrologiciel de carte réseau, de commutateur et d’outils de test. Mettre à niveau une couche sans coordonner les autres peut exposer exactement la condition de concurrence inter‑couche que le consortium tente d’éviter.

Les alliances externes de l’UEC sont donc centrales plutôt que cérémonielles. L’Open Compute Project peut connecter le transport aux systèmes ouverts et au matériel. L’OpenFabrics Alliance et la communauté libfabric connectent les applications. L’IEEE 802.3 fournit le travail Ethernet formel. SNIA et NVM Express apportent des exigences de stockage et de gestion. Les technologies de l’IETF fournissent IP, ECN et les mécanismes associés. Ces organisations ont des processus de décision et des feuilles de route différents; la liaison réduit les doublons mais ne peut garantir une adoption simultanée.

Le test opérationnel ultime est l’infrastructure en fonctionnement. Un document peut spécifier un comportement, un fournisseur peut annoncer un produit et un consortium peut organiser un sommet. Rien de tout cela ne remplace un cluster dans lequel des points d’extrémité et des commutateurs indépendants exécutent de véritables tâches sous congestion, panne et mise à niveau pendant que les opérateurs peuvent expliquer ce qui s’est passé.

Pertinence actuelle: de la victoire de la spécification à la crédibilité de l’implémentation

En juillet 2026, l’UEC avait accompli plusieurs choses qui étaient incertaines à son lancement. Elle a formé une large coalition, produit une architecture intégrée sur cinq couches, publié une spécification 1.0 complète, l’a maintenue par des versions correctives, a ajouté le support 200G par ligne, a divulgué les déclarations de brevet et a attiré des annonces de produits et de tests. Le projet est actif et son programme s’est résolument tourné vers l’implémentation.

Ces progrès rendent les prochaines incertitudes plus importantes, et non l’inverse. Les effectifs exacts actuels et la composition du Steering ne sont pas publiés dans un registre unique faisant autorité. Les pages publiques des membres et la charte décrivent l’accès différemment. La direction formelle actuelle du TAC n’est pas entièrement réconciliée avec les rôles du sommet. La date de sortie 1.0.2 varie selon les documents officiels. Le paquet de conformité utilise une terminologie de profil obsolète.

Aucun de ces problèmes ne détruit l’architecture, mais chacun est un signal sur le contrôle des documents et la transparence dans un projet où les versions exactes comptent.

Les lacunes plus conséquentes concernent l’adoption. L’UEC ne publie aucun recensement de déploiement, aucun registre de produits vérifié indépendamment, aucun budget autonome ni aucun compte audité. Aucune preuve publique n’établit un réseau UEC 1.0 entièrement interopérable aux objectifs d’échelle maximale du consortium. Les démonstrations et revendications des fournisseurs sont précieuses mais commercialement intéressées. Les comparaisons de performances neutres avec les plateformes RoCE, InfiniBand et Ethernet intégrées actuelles restent limitées.

L’opportunité du consortium reste substantielle. Ethernet est le dénominateur commun des centres de données, et le marché de l’infrastructure IA est suffisamment grand pour soutenir de nouvelles générations de cartes réseau, de commutateurs, d’optique et de logiciels. Les opérateurs ont de fortes incitations à éviter la dépendance envers un seul fournisseur et à améliorer l’utilisation des accélérateurs. Une pile commune pourrait transformer ces incitations en levier d’achat.

Son risque est que « Ultra Ethernet » devienne un terme générique pour des sous‑ensembles de fonctionnalités incompatibles. Si le transfert de base fonctionne mais que les profils, la congestion, la sécurité et la gestion divergent, la marque pourrait se répandre plus vite que l’interopérabilité. Si les licences RAND sont coûteuses ou incertaines, l’ensemble des fournisseurs pourrait se réduire. Si les produits RoCE absorbent les idées les plus attrayantes sans nécessiter un nouveau transport, l’UEC pourrait influencer le marché sans en devenir l’étiquette dominante.

La question décisive n’est plus de savoir si le consortium peut publier une spécification sophistiquée. Il l’a fait. La question est de savoir si des organisations indépendantes peuvent implémenter les mêmes contrats, acquérir la licence de la technologie nécessaire, exploiter la structure à grande échelle et préserver la compatibilité à mesure que la spécification évolue. L’UEC ne deviendra une infrastructure que dans la mesure où ces affirmations résistent au contact du code en production.