Ultra Ethernet Consortium: rebâtir 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 industriel de développement de spécifications, non d'une société traditionnelle ou d'un opérateur de réseau.
• La portée de l'UEC va bien au-delà d'une simple liaison Ethernet plus rapide ou d'une alternative à RoCE. La spécification 1.0.3, qui compte 573 pages, couvre les couches logicielle, de transport, réseau, liaison et physique, ainsi que les travaux de gestion, de stockage, de tests et de conformité entourant la pile de base.
• L'Ultra Ethernet Transport combine plusieurs modes de livraison, l'acheminement multipath au niveau paquet, la retransmission sélective, le contrôle de congestion côté émetteur et récepteur, l'ECN, le découpage optionnel des paquets, les tentatives locales optionnelles, le contrôle de flux optionnel basé sur les crédits et la sécurité de la couche transport optionnelle de bout en bout.
• Des produits et démonstrations d'AMD, Broadcom, Nokia et Keysight indiquent un début de mise en œuvre, mais la conformité publique repose encore largement sur l'auto-déclaration des implémenteurs, et aucun registre complet de certifications indépendantes ni comptage de déploiements à grande échelle n'a été publié.
• L'opportunité stratégique de l'UEC repose sur la base installée d'Ethernet et sa chaîne d'approvisionnement multi-fournisseurs. Les principaux risques incluent la complexité des points de terminaison, la fragmentation due aux fonctionnalités optionnelles, les engagements de licence de brevet RAND, le manque de maturité de la gestion et des tests, ainsi que l'écart entre la publication de la spécification et la démonstration de l'interopérabilité en environnement de production.

Pourquoi l'IA a fait du réseau un composant de l'ordinateur

L'Ultra Ethernet Consortium est né en réponse à un changement dans l'économie du calcul. Dans un réseau d'entreprise classique, on attend du tissu réseau qu'il transporte un grand nombre de flux indépendants avec un débit et une disponibilité acceptables. Dans un grand système d'entraînement d'IA ou dans une machine de calcul haute performance, le réseau devient une partie d'une opération de calcul unique et synchronisée. Des milliers d'accélérateurs peuvent échanger des paramètres de modèles, des gradients ou des données scientifiques dans le cadre d'opérations collectives.

L'étape suivante peut ne pas démarrer tant que le entité le plus lent n'a pas reçu les informations nécessaires. Un léger déséquilibre entre les chemins, un épisode de congestion ou une simple perte de paquet peut ainsi laisser des processeurs coûteux en attente, même si l'utilisation moyenne du tissu semble bonne.

Cela change ce que les opérateurs cherchent à optimiser. La capacité globale reste importante, mais elle ne suffit plus. Le temps d'achèvement de la tâche, la latence de queue, les incasts, la récupération après perte, la distribution du trafic sur des chemins parallèles et la quantité d'état que les points de terminaison doivent conserver comptent aussi. Un réseau qui livre la plupart des paquets rapidement mais retarde une petite fraction peut paralyser une opération collective entière. Une méthode de retransmission acceptable pour le trafic classique peut être trop lente si un seul paquet d'un long message est perdu.

Un flux bloqué sur un seul chemin à coût égal peut voir ses performances chuter alors que de la capacité reste disponible ailleurs dans la topologie.

L'hypothèse fondatrice de l'UEC est que ces problèmes ne se résolvent pas avec une seule nouvelle fonction de commutateur ou un algorithme de congestion modifié. Le chemin de communication commence au-dessus du réseau, dans les bibliothèques logicielles et les sémantiques applicatives, puis traverse l'enregistrement mémoire, les opérations distantes, l'état de la couche transport, la remise des paquets, le contrôle de congestion, le routage IP, les liaisons Ethernet, l'optique et les signaux physiques.

Si ces couches sont conçues indépendamment, une optimisation à un endroit peut 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 connaissent et parce qu'une vaste chaîne d'approvisionnement s'est développée autour des commutateurs, de l'optique, du câblage, des systèmes d'exploitation réseau, de la télémétrie et de la gestion. En même temps, elle modifie ou étend les parties que le consortium juge inadaptées aux charges de travail massives de l'IA et du HPC.

Le résultat n'est pas un « Ethernet ordinaire avec un nouveau logo », mais une tentative de faire en sorte que le réseau familier transporte une couche transport spécialisée dont le comportement est défini de l'interface logicielle à la vitesse du chemin physique.

Ce point illustre pourquoi l'UEC est important pour l'infrastructure numérique. Le projet ne possède ni accélérateurs, ni usines, ni centres de données, ni régions cloud. Mais il définit des contrats que les sociétés membres et d'autres implémenteurs peuvent intégrer dans les cartes réseau, les ASIC des commutateurs, les systèmes, les pilotes, les bibliothèques et les équipements de test. Son impact ne se matérialisera que lorsque ces produits indépendants échangeront correctement du trafic en présence de pannes, de congestion, de mises à niveau et de mélange de fournisseurs.

Ce qu'est l'UEC et ce qu'elle n'est pas

L'Ultra Ethernet Consortium est le nom public d'un projet formel dont le nom légal complet estJoint 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 plus large de la Linux Foundation. Elle offre aux entités un cadre juridique établi pour l'adhésion, la gouvernance, la propriété intellectuelle, le financement et les relations extérieures, sans les obliger à créer une nouvelle entité indépendante.

Cette structure est importante parce que l'UEC est parfois décrite de manière inexacte comme une entreprise, une alliance ou un organisme de normalisation. Ce n'est pas une société commerciale avec des actionnaires, du capital, une valorisation et des comptes propres. Elle ne vend pas de produits Ethernet, n'exploite pas de réseau public et ne possède pas le matériel que ses membres promeuvent. C'est un consortium de développement de spécifications dans un cadre juridique et de propriété intellectuelle. Ses documents publics sont destinés à devenir des contrats d'implémentation entre plusieurs sociétés.

L'UEC n'est pas non plus l'Ultra Ethernet Transport lui-même. L'UET est l'architecture de transport au cœur de la spécification, mais le travail du consortium est plus large. Il inclut l'alignement logiciel avec libfabric, les sémantiques de paquets et de messages, les hypothèses réseau, les options de la couche liaison, les exigences de la couche physique, la gestion, l'alignement avec le stockage, la performance et le débogage, ainsi que la conformité et les tests. Réduire le projet à « un nouveau protocole RDMA » masque la conception transversale qui le rend à la fois ambitieux et difficile.

L'UEC n'est pas non plus le groupe IEEE 802.3. Ce groupe développe les normes Ethernet fondamentales des couches MAC et physiques selon son propre processus formel. L'UEC s'appuie sur cet écosystème et entretient une relation de coordination, mais ne le remplace pas. Les mêmes limites s'appliquent aux mécanismes de l'IETF utilisés par l'UET, notamment IPv4, IPv6 et la notification explicite de congestion; à l'écosystème OpenFabrics qui gère libfabric; et aux organes travaillant sur le stockage, le matériel ouvert et les interconnexions d'accélérateurs.

Le site Web du projet a utilisé un langage évoquant le statut d'organisation internationale de normalisation. La description la plus sûre et la mieux étayée est que l'UEC est une organisation internationale de développement de spécifications dans le cadre de la JDF. Il n'y a aucune preuve 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 seulement verbale; elle détermine la source d'autorité, les modalités de participation et les engagements juridiques que les implémenteurs peuvent rencontrer.

L'UEC doit donc être évaluée sur le rôle qu'elle joue effectivement. Elle coordonne des concurrents et des opérateurs autour d'une conception technique commune, publie des spécifications, gère des groupes de travail et des déclarations de brevets, et développe des outils de conformité et des relations avec les organismes voisins. Mais elle ne peut pas, par simple annonce, rendre un produit interopérable ni imposer au marché l'adoption de son architecture.

Le consortium fondateur de neuf entreprises

Le consortium a été annoncé le 19 juillet 2023 par neuf organisations occupant différentes couches de la chaîne d'approvisionnement de l'IA et du HPC: AMD, Arista Networks, Broadcom, Cisco, Eviden (alors lié à Atos), Hewlett Packard Enterprise, Intel, Meta et Microsoft. Cette diversité était une intention stratégique dès le départ. Un transport conçu uniquement par des fabricants de commutateurs risquerait de négliger les contraintes applicatives et les points de terminaison. Une conception menée par les fabricants d'accélérateurs pourrait être optimisée autour d'un seul écosystème matériel.

Un projet mené uniquement par des fournisseurs de cloud pourrait manquer de l'expertise en silicium, en optique et en systèmes nécessaire pour transformer l'architecture en produits.

AMD apportait ses processeurs, accélérateurs et réseaux de points de terminaison. Arista et Cisco apportaient leur expertise en commutation Ethernet à grande échelle et leur expérience opérationnelle. Broadcom contribuait au silicium de commutation, aux cartes réseau et aux SerDes haut débit. HPE et Eviden apportaient leur expérience des systèmes HPC et des interconnexions spécialisées. Intel contribuait aux processeurs, à Ethernet et aux logiciels.

Meta et Microsoft représentaient des opérateurs hyperscale ayant un intérêt direct à améliorer l'utilisation de leurs grands clusters d'IA et à réduire leur dépendance envers un fournisseur unique intégré.

Le consortium rassemble des intérêts commerciaux concurrents. Les membres vendent des cartes réseau, des puces de commutateur, des systèmes, de la capacité cloud, de l'optique, des logiciels et du support. Certains détiennent des portefeuilles de brevets potentiellement indispensables à la mise en œuvre. Certains bénéficient d'une norme large et multi-fournisseurs, tout en pouvant tirer profit de fonctionnalités propriétaires différenciées.

Le consortium n'élimine donc pas la concurrence; il crée un forum où les concurrents s'accordent sur des interfaces minimales et continuent de se concurrencer sur la qualité de mise en œuvre, la performance, l'intégration et les conditions commerciales.

Slingshot de HPE offre un exemple instructif d'antécédent technique. C'est un tissu HPC commercial compatible Ethernet avec un routage adaptatif et une gestion de la congestion. Des commentaires associés à HPE ont indiqué qu'une spécification « HPC Ethernet » a été soumise à l'UEC, et ont estimé qu'une part significative de l'UET est dérivée des idées de transport de Slingshot. Le pourcentage exact n'a pas été vérifié de manière indépendante et ne doit pas être présenté comme un calcul officiel du consortium.

Le point plus large est bien étayé: l'UEC n'est pas parti d'une page blanche, mais a capitalisé sur l'expérience de production en HPC, réseaux cloud, RDMA et Ethernet.

Ce mélange d'antécédents explique pourquoi le mot « ouvert » doit être utilisé avec précision. La spécification adoptée est téléchargeable publiquement, et l'architecture est conçue pour être implémentée par plusieurs fournisseurs. Mais le projet est aussi un lieu où les membres apportent des connaissances préexistantes, des brevets et des feuilles de route de produits. L'ouverture du document n'élimine pas les conditions économiques ou juridiques qui entourent la technologie.

Une chaîne juridique conçue pour la collaboration entre concurrents

Le modèle de la Joint Development Foundation donne à l'UEC une structure formelle sans en faire une société d'exploitation traditionnelle. Le projet a un nom, une portée, des catégories de membres, un Steering Committee, des groupes de travail et des engagements de propriété intellectuelle. L'égide de la JDF fournit la structure institutionnelle et à but non lucratif, et peut détenir les actifs et les accords du projet. Cela réduit le coût de création d'un consortium et offre aux concurrents un processus reconnu pour collaborer.

La gouvernance du projet est assurée par le Steering Committee. Ses responsabilités documentées incluent la coordination des groupes de travail, l'admission des membres, la gestion des actifs et du financement, la sélection ou le remplacement du président, le suivi des progrès et le contrôle des divulgations publiques et des marques du projet. Le consensus est privilégié. À défaut, le document de gouvernance prévoit un mécanisme de super-majorité des trois quarts des entités qualifiés ayant satisfait aux exigences de participation. Des objections écrites peuvent être soumises au président.

Brad Booth de Meta a été le président initial. La spécification actuelle 1.0.3 nomme J Metz d'AMD comme président, Barry Davis de HPE comme vice-président, Hugh Holbrook d'Arista comme président du Technical Advisory Committee (TAC), et Puneet Agarwal de Marvell comme vice-président du TAC. Paul Congdon apparaît comme rédacteur de la spécification. Le document nomme également des responsables et auteurs pour les travaux sur la couche physique, la liaison, le transport et les logiciels. L'agenda du sommet 2026 mentionne d'autres responsables opérationnels.

Ces rôles ne remplacent pas nécessairement les titres officiels indiqués dans la spécification, et aucun organigramme public complet et à jour n'est disponible.

Le document de gouvernance prévoit trois catégories de membres: Steering, General et Contributor. Les membres Steering participent à la gouvernance et nomment habituellement des représentants au Steering Committee. Les membres General peuvent travailler dans tous les groupes techniques mais n'occupent pas de siège au comité. Les membres Contributor participent à des groupes sélectionnés et n'ont pas de droit de vote sur les décisions à super-majorité.

Actuellement, la page publique d'adhésion affiche les catégories General et Contributor à des tarifs annuels de 20 000 $ et 5 000 $ respectivement, auxquels s'ajoute l'adhésion à la Linux Foundation, mais elle n'explique pas clairement le processus d'admission ni le tarif actuel de la catégorie Steering.

La différence d'autorité formelle est importante. Une large adhésion apporte de l'expertise et une diffusion de l'implémentation, mais la gouvernance n'est pas également répartie. Les grandes entreprises capables d'occuper des sièges au Steering Committee, d'affecter des ingénieurs à plusieurs groupes et de gérer des programmes de brevets et de produits ont une influence pratique bien plus grande que les petits membres Contributor. Les non-membres peuvent télécharger la spécification finale, mais ne voient pas l'intégralité du processus de rédaction ni ne participent sur un pied d'égalité.

Les informations internes du projet ne sont pas traitées comme des secrets commerciaux ordinaires, mais il est interdit aux membres de divulguer les documents en cours avant que le comité compétent n'approuve la publication. Cela peut aider les concurrents à discuter d'idées inachevées sans signaux de marché précoces. Mais cela signifie aussi que le public n'a pas accès aux propositions rejetées, aux registres de vote, aux préoccupations intermédiaires de mise en œuvre ou aux négociations qui ont produit les fonctionnalités optionnelles. La spécification finale est ouverte; le chemin qui y mène n'est que partiellement visible.

De quatre groupes de travail à une spécification de 573 pages

La structure publique initiale de l'UEC en 2023 reposait sur quatre groupes de travail: logiciels, transport, liaison et couche physique. L'empilement reflétait l'ambition de bout en bout du projet. L'adhésion n'a pas été ouverte immédiatement comme une liste de diffusion publique sans restriction. Plus de 200 organisations ont manifesté leur intérêt, et le consortium a procédé à une intégration par phases, avec une orientation obligatoire sur les procédures et les règles antitrust.

Cette prudence était compréhensible car les entités sont directement concurrents sur plusieurs marchés et allaient discuter d'exigences communes pour les produits et les protocoles.

En décembre 2023, l'UEC comptait environ 40 entreprises et plus de 300 personnes. Elle avait créé le Technical Advisory Committee et s'était élargie à huit groupes de travail. Le rôle du TAC était de maintenir la cohérence architecturale: la conception de la couche transport ne devait pas supposer un comportement du 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, plus de 750 entités actifs et publiait une description beaucoup plus claire de l'architecture envisagée.

Les mises à jour de mars ont présenté les idées centrales qui apparaîtront plus tard dans la spécification normative: libfabric comme API orientée logiciel, la dispersion des paquets (packet spraying), la remise en ordre flexible, plusieurs modes de livraison, le contrôle de congestion côté émetteur et récepteur, l'ECN, le découpage de paquets (packet trimming), la retentative au niveau liaison (Link Layer Retry), le contrôle optionnel basé sur les crédits, la sécurité de la couche transport et les futures opérations collectives dans le réseau.

Elles soulignaient également que l'UET pouvait fonctionner sur des commutateurs Ethernet existants, tandis que les commutateurs optimisés offriraient des performances supplémentaires.

La participation institutionnelle a crû parallèlement au travail technique. L'UEC a fait état de 1 193 entités actifs en juillet 2024 et de 97 organisations membres en août. Ces chiffres, datés et émanant du consortium, reposent sur des définitions qui ne sont pas entièrement publiques et ne doivent donc pas être agrégés mécaniquement avec des annonces ultérieures. En 2025, le consortium a déclaré que 27 entreprises supplémentaires l'avaient rejoint, mais les départs, les fusions et les chevauchements de périodes empêchent d'établir un total actuel précis. Le site Web lui-même précise que tous les membres ne sont pas affichés sur la page.

Le consortium a publié l'Ultra Ethernet Specification 1.0 le 11 juin 2025. Ce fut le moment où l'UEC est passée d'une feuille de route à une base de référence publique pour l'implémentation. La version 1.0.1 a suivi en septembre, corrigeant l'algorithme source du contrôle de congestion basé sur les crédits du récepteur et des problèmes éditoriaux. La version 1.0.2 est sortie en janvier 2026, avec des corrections des algorithmes de gestion de la congestion, bien que les documents officiels divergent sur la date de publication (21 ou 28 janvier). Cette contradiction doit être conservée apparente plutôt que résolue sans déclaration.

La version 1.0.3, publiée le 16 juillet 2026, est la référence actuelle à la date de cette recherche. Elle compte 573 pages et ajoute la prise en charge de la signalisation à 200 Gbit/s par voie et une capacité de négociation logique. Les notes de version mentionnent également des corrections obligatoires relatives à la remise des paquets, aux crédits de congestion, à la Link Layer Retry et aux jeux de contrôle ordonné de la couche physique, ainsi que des clarifications sur la sécurité du transport, les opérations atomiques et les paquets découpés.

La distinction entre corrections obligatoires et clarifications éditoriales est importante, car certaines modifications affectent le comportement conforme et exigent une maintenance des implémentations.

Le sommet des membres de Denver en 2026 a marqué une deuxième transition. L'ordre du jour s'est concentré sur le déploiement, la transformation de la spécification en produits, la conformité, la gestion, les performances, le débogage, l'intégration du stockage et les tests des commutateurs et des points de terminaison. Le document architectural de base est en place; la crédibilité du projet dépend désormais davantage de la capacité des implémenteurs à construire, qualifier, exploiter et mettre à niveau la pile au-delà des frontières institutionnelles.

Une architecture unique sur cinq couches fonctionnelles

La spécification actuelle d'Ultra Ethernet découpe le système en couches logicielles, de transport, réseau, 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 frameworks d'IA, MPI, SHMEM et les bibliothèques d'opérations collectives interagissent via les interfaces OpenFabrics, notamment libfabric. La sous-couche UET Semantic Services traduit les opérations applicatives en transactions de transport. La sous-couche Packet Delivery détermine comment les messages sont segmentés, ordonnés, acquittés et récupérés. La gestion de la congestion contrôle la quantité de données entrant dans le tissu et la manière dont le trafic est réparti sur les chemins. La sécurité optionnelle de la couche transport protège le trafic de bout en bout.

Le routage IP standard (IPv4 ou IPv6) assure la couche réseau. Ethernet fournit la couche liaison avec, optionnellement, le découpage de paquets, la retentative au niveau liaison, le contrôle de flux basé sur les crédits et la négociation de fonctionnalités. Enfin, la couche physique définit les statistiques et les exigences de signalisation à 100 ou 200 Gbit/s par voie.

Cette architecture préserve des pans importants du réseau actuel. L'UEC ne définit pas un remplacement du routage IP. Elle s'attend à ce que l'ECMP traditionnel et les commutateurs compatibles ECN soient utilisés. Une grande partie de l'intelligence reste dans les Fabric Endpoints, qui modifient les valeurs d'entropie, suivent l'état du transport, placent les données et répondent aux signaux de congestion. Des commutateurs optimisés peuvent ajouter des fonctions, mais la conception n'impose pas de remplacer tout le tissu avant d'acheminer le trafic UET.

Cela offre un avantage de transition, mais crée un problème de classification. Un déploiement peut utiliser des points de terminaison UET sur un Ethernet classique avec ECMP et ECN. Un autre peut ajouter le découpage, la retentative, les crédits par canal virtuel, une télémétrie plus riche et des opérations futures dans le réseau. Les deux peuvent être appelés Ultra Ethernet alors que leurs performances, leurs caractéristiques de récupération et leur complexité opérationnelle diffèrent fondamentalement.

L'approche en cinq couches rend également plus difficile l'isolement des défaillances de mise en œuvre. Une mauvaise performance peut provenir de l'alignement applicatif, de la machine d'état du point de terminaison, des paramètres de congestion, de la configuration des files d'attente du commutateur, de l'alignement DSCP, de l'optique, du micrologiciel ou du système de sécurité. Le simple passage des paquets est insuffisant. Le système doit maintenir les sémantiques et les performances prévues lors de la montée en charge, du trafic mélangé, des pannes et des changements de version.

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

L'UEC choisit libfabric 2.0 comme API supérieure principale pour les points de terminaison conformes. Ce choix ancre le projet dans un écosystème logiciel existant pour le HPC et les réseaux avancés, sans obliger chaque framework à adopter une nouvelle interface propriétaire. libfabric représente déjà des fabrics, domains, endpoints, completion queues, event queues, address vectors, memory regions, des messages, des opérations d'accès mémoire à distance et des opérations atomiques. L'UEC aligne et contraint ces concepts afin que les fournisseurs traduisent les appels en comportement UET.

L'avantage stratégique est la continuité au-dessus de la couche transport. MPI, SHMEM et les bibliothèques de communication d'accélérateurs peuvent utiliser des abstractions familières même si le fournisseur sous-jacent change. En principe, une application peut demander une opération sans savoir quel fournisseur de carte réseau exécute la livraison ou quel type de silicium de commutateur achemine les paquets. C'est l'un des principaux mécanismes par lesquels un transport commun pourrait créer un choix de fournisseur.

L'abstraction ne garantit pas des implémentations équivalentes. Les fournisseurs peuvent prendre en charge des tailles d'injection, des limites de dispersion/regroupement, un nombre de points de terminaison, des opérations atomiques, des techniques d'enregistrement mémoire, des comportements d'achèvement, des déchargements matériels et des fonctions de sécurité différents. Une bibliothèque construite sur la même API peut rencontrer des limites de performance et de capacité différentes. Ainsi, les achats et la qualification logicielle exigent plus qu'un simple logo « compatible libfabric ».

La couche logicielle porte également la sémantique des tâches et l'isolation. Les systèmes d'IA et 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 définir à quelle tâche appartient un point de terminaison, quelle mémoire est accessible, comment l'opération distante est mise en correspondance et comment les informations d'achèvement ou d'erreur sont renvoyées au logiciel.

Ces décisions déterminent si le réseau rapide peut être utilisé par l'ordonnanceur, l'environnement d'exécution et l'application, et pas seulement comme un chiffre impressionnant dans un banc d'essai de paquets.

Le projet s'appuie sur l'écosystème OpenFabrics parce qu'il ne possède pas libfabric. Cette relation illustre une caractéristique plus large de l'UEC: l'architecture est une composition d'éléments régis à différents endroits. Le consortium peut définir l'alignement de son transport avec libfabric, mais il doit se coordonner avec les responsables de l'API et ses utilisateurs. Des dépendances similaires existent avec Ethernet auprès de l'IEEE, avec les mécanismes de réseau auprès de l'IETF, avec les organismes de stockage et avec les systèmes d'exploitation des fournisseurs.

Fabric Endpoints et profils de charge de travail

Un Fabric Endpoint (FEP) est l'endroit logique où se termine l'UET. Il associe une instance de système d'exploitation à un ou plusieurs niveaux de tissu isolés, et peut inclure un fournisseur en espace utilisateur, un pilote noyau, la couche transport à l'intérieur de la carte réseau ou de l'accélérateur, un système d'enregistrement mémoire, un contexte de sécurité, des files d'achèvement, des vecteurs d'adresses et l'état utilisé pour la remise des paquets et le contrôle de la congestion.

Cette conception centrée sur le point de terminaison permet à la plupart des commutateurs de rester de simples périphériques Ethernet/IP. Le FEP choisit les valeurs d'entropie, conserve l'état des paquets et de la congestion, place les données dans la mémoire autorisée et interprète les acquittements, le découpage et les autres retours d'information. Cela peut réduire la dépendance à un routage propriétaire intégré au commutateur, mais concentre la complexité dans le silicium de la carte réseau, le micrologiciel, les pilotes et les logiciels.

L'UEC définit trois profils d'implémentation: IA Base, IA Full et HPC. Il ne s'agit pas de types de réseaux distincts, mais de paquets de fonctions qu'une implémentation doit prendre en charge. IA Base vise à couvrir les communications IA courantes avec un coût et un état d'implémentation moindres. IA Full ajoute des capacités telles que les envois différables, la correspondance exacte et les opérations atomiques de type récupération ou comparaison. Le profil HPC inclut la plupart des capacités IA Full, mais exclut l'envoi différable et accorde plus de poids à l'ordonnancement, aux messages courts et aux sémantiques HPC.

Le système de profils tente d'empêcher que chaque produit ne soit tenu d'implémenter l'ensemble maximal des fonctionnalités. Il reconnaît qu'une carte réseau destinée à l'IA à grande échelle peut privilégier le trafic de données collectives, tandis qu'un point de terminaison HPC peut nécessiter un ordonnancement et des opérations atomiques plus robustes. Mais les profils n'éliminent pas les choix. Un produit peut implémenter des fonctionnalités optionnelles à l'intérieur d'un profil, et deux produits portant le même nom peuvent différer en matière de sécurité, d'optimisations de liaison, de capacité et de performance.

Un signal d'alarme apparaît dans la terminologie elle-même. La spécification de référence 1.0.3 utilise les dénominations IA Base, IA Full et HPC. Un fichier Lisez-moi distinct sur la conformité datant de 2025 utilise IA Base, IA Extended et HPC. L'interprétation la mieux étayée est que « IA Full » est le nom actuel et que le document de conformité est obsolète ou incohérent. Jusqu'à ce que la suite de tests publique soit corrigée, les fournisseurs et les acheteurs doivent préciser la version de la spécification et le nom exact du profil derrière chaque allégation.

De l'intention applicative à la remise des paquets

À l'intérieur de l'UET, la sous-couche Semantic Services porte l'intention applicative. Elle définit l'identité du message, les adresses des tampons, les opérations marquées et non marquées, l'accès mémoire à distance, les opérations atomiques, le comportement d'achèvement, les identifiants de tâche, l'isolation des tampons, les réponses et les erreurs. Ensuite, la sous-couche Packet Delivery détermine comment cette intention est transformée en paquets et comment ils atteignent un autre point de terminaison.

Dans les modes fiables, les points de terminaison créent des contextes de livraison de paquets (Packet Delivery Contexts, PDC). Un PDC contient un état tel 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 du chemin de retour et la classe de trafic. Un PDC unique est lié à un seul mode de livraison et à une seule classe de trafic, et plusieurs PDC peuvent exister entre la même paire de FEP.

Cet état n'est pas un détail mineur. Les grands clusters peuvent générer un nombre énorme de relations de communication. Si chaque relation nécessite un état étendu à la destination, la mémoire du point de terminaison et le coût de la recherche peuvent devenir une contrainte. C'est pourquoi l'UEC n'impose pas un modèle de connexion unique pour chaque opération, mais définit quatre modes de livraison avec des contrats différents de fiabilité et d'ordonnancement.

La livraison fiable non ordonnée (Reliable Unordered Delivery, RUD) garantit que chaque paquet est livré exactement une fois à la couche sémantique, tout en permettant leur arrivée dans le désordre. Elle prend en charge la dispersion des paquets sur plusieurs chemins, la retransmission sélective, la prévention des doublons et le placement direct des données.

Parce que la destination peut placer les données en fonction des décalages plutôt que d'attendre un tampon de réordonnancement dans la couche transport, une longue opération collective peut utiliser plusieurs chemins sans que tous les paquets ne soient bloqués derrière une unité manquante.

La livraison fiable ordonnée (Reliable Ordered Delivery, ROD) garantit une livraison unique et en ordre. Elle utilise un seul chemin et une seule valeur d'entropie, écarte les paquets hors d'ordre et s'appuie sur un retour en arrière (Go-Back-N) à partir de la première séquence manquante. Elle semble moins complexe que RUD, mais préserve des sémantiques nécessaires lorsque l'ordre strict est important. L'UEC traite l'ordonnancement comme une exigence applicative, au lieu d'en imposer le coût à chaque transport.

La livraison fiable non ordonnée pour les opérations idempotentes (Reliable Unordered Delivery for Idempotent Operations, RUDI) offre un autre compromis. Elle assure une livraison au moins une fois et tolère les doublons, ce qui réduit l'état de séquence et d'acquittement habituel à la destination. Cela peut être utile lorsque la répétition d'une opération ne modifie pas le résultat final, par exemple certains mouvements de mémoire à distance suivis d'une barrière distincte. Mais c'est risqué en cas d'utilisation incorrecte. La couche paquet ne détermine pas si une opération est idempotente; c'est le logiciel qui doit le décider.

Utiliser RUDI pour une opération non idempotente peut entraîner un état applicatif incorrect.

La livraison non fiable non ordonnée (Unreliable Unordered Delivery, UUD) fournit des datagrammes au mieux sans les garanties habituelles de fiabilité ou d'ordre. Elle s'inscrit dans le 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 avec lui.

Ces quatre modes révèlent une philosophie centrale: le réseau doit offrir plusieurs mécanismes afin que le logiciel puisse adapter 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 étendue, et davantage de possibilités qu'un fournisseur, une application ou un opérateur choisisse une combinaison incompatible.

La dispersion des paquets: utiliser le tissu plutôt que compter sur un chemin chanceux

L'ECMP traditionnel place souvent un flux entier sur un seul chemin en utilisant une fonction de hachage. Dans un grand tissu Clos, cela peut relever d'une loterie. Plusieurs flux volumineux peuvent entrer en collision sur les mêmes liaisons tandis qu'une capacité équivalente reste inutilisée ailleurs. Un long transfert d'IA peut rester confiné tout au long de sa vie à un chemin mal choisi.

L'UET résout ce problème en modifiant l'entropie au niveau de chaque paquet. L'émetteur peut utiliser des dizaines, voire des centaines de valeurs, ce qui permet aux mécanismes ECMP existants dans les commutateurs de répartir les paquets sur de nombreux itinéraires. La sous-couche Packet Delivery fournit les informations de séquence, la sous-couche Congestion Management choisit la valeur d'entropie ou le chemin, les commutateurs exécutent leur hachage habituel, puis le retour d'information indique à l'émetteur quelles valeurs semblent congestionnées.

La dispersion des paquets n'est possible que parce que d'autres parties de la conception la soutiennent. Les paquets peuvent arriver dans le désordre. RUD peut placer les données directement sans attendre un réordonnancement complet dans la couche transport. La retransmission sélective ne récupère que ce qui a été perdu. Le retour d'information sur la congestion réduit l'utilisation des chemins affectés. Il ne s'agit donc pas d'une astuce d'équilibrage de charge isolée, mais d'un élément d'un modèle de transport construit autour de la diversité de chemin.

L'UEC n'exige pas que chaque commutateur exécute un algorithme de routage adaptatif propriétaire. Les implémentations de base peuvent utiliser un round-robin ou une entropie pseudo-aléatoire sur un ECMP standard. Les points de terminaison avancés peuvent associer les signaux ECN, la latence ou le découpage à des valeurs particulières et éviter les chemins congestionnés. Le routage adaptatif spécifique à 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 du tissu et des latences de queue plus faibles. La question non résolue est de savoir dans quelle mesure les différents points de terminaison interprètent le retour d'information de manière cohérente, et comment la dispersion 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 dans un grand tissu comprenant plusieurs générations de commutateurs et des classes de trafic différentes. Les preuves indépendantes multi-fournisseurs restent limitées.

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

L'UEC ne définit pas un unique algorithme universel de contrôle de congestion. Elle distingue la congestion dans le cœur du réseau, l'incast chez le récepteur et la limitation des tampons des points de terminaison.

Le contrôle de congestion par signal réseau (Network-signal Congestion Control, NSCC) est un mécanisme piloté par l'émetteur. L'émetteur maintient une fenêtre de congestion, estime la quantité de données en cours de transit et ajuste la fenêtre en fonction 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 également le comportement de la fenêtre avec le multipath au niveau paquet.

L'UEC avance que la fenêtre cesse naturellement d'injecter de nouvelles données lorsque les paquets ne peuvent plus quitter le réseau, alors qu'un contrôleur basé uniquement sur le débit pourrait mal interpréter l'absence de retour.

Il s'agit de l'argument architectural du consortium, et non d'une preuve indépendante que chaque implémentation NSCC surpasse DCQCN ou d'autres mécanismes 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 paramètres choisis. L'affirmation « utilise NSCC » ne suffit donc pas à démontrer une performance.

Le contrôle de congestion par crédits du récepteur (Receiver-credit Congestion Control, RCCC) cible le problème de l'incast. Lorsque de nombreuses sources envoient simultanément vers une même destination, le dernier lien peut devenir un goulot d'étranglement même si le cœur du réseau n'est pas congestionné. Le récepteur surveille la demande et distribue des crédits aux émetteurs, ce qui régule le débit total d'arrivée et ajuste la fenêtre effective de chaque source en fonction de la compétition. Le RCCC peut être utilisé parallèlement au NSCC, car la pression du récepteur et la congestion du cœur sont des problèmes distincts.

Le contrôle de flux de la couche transport (Transport Flow Control, TFC) utilise également des crédits, mais pour les connexions point à point dont les tampons sont limités. Son objectif direct est d'empêcher le dépassement de capacité du tampon de réception lorsque la tolérance aux pertes est faible. Il peut être utilisé avec ou sans multipath. Assimiler tous les mécanismes à base de crédits à une seule et même chose masque le domaine de défaillance distinct que chacun est censé traiter.

La spécification prévoit l'utilisation de la notification explicite de congestion (ECN) dans l'ensemble du tissu et pose des hypothèses opérationnelles sur le marquage, notamment le marquage à la sortie de la file d'attente plutôt que le marquage à l'entrée. Les points de terminaison interprètent l'ECN en combinaison avec les acquittements, la latence et le découpage. La cohérence de la configuration des commutateurs devient donc essentielle. Une implémentation de transport peut être correcte, et pourtant un tissu mal configuré produira de mauvaises performances.

L'historique de maintenance révèle la difficulté. La version 1.0.1 a corrigé l'algorithme source du RCCC, la 1.0.2 a corrigé des cas de gestion de la congestion, et la 1.0.3 a corrigé des interactions entre les crédits et la Link Layer Retry. Ce sont des signes normaux d'une spécification vivante, mais ils montrent aussi que les scénarios de crédit, de retransmission et de contrôle de chemin peuvent interagir de manière subtile. Les opérateurs auront besoin d'une discipline de versionnement et de tests de régression, pas seulement d'une conformité initiale.

Découpage de paquets et récupération fine des pertes

Le découpage de paquets (packet trimming) change ce que fait un commutateur capable lorsqu'il ne peut pas conserver un paquet complet. Au lieu de simplement abandonner la trame sans information supplémentaire, il supprime l'essentiel ou la totalité de la charge utile, conserve suffisamment d'en-tête et de métadonnées pour identifier le paquet, le marque comme découpé, puis envoie cet avis tronqué vers la destination. Celle-ci peut alors signaler à l'émetteur les données spécifiques perdues.

Cela fournit une information plus fine que le marquage ECN. L'ECN signale qu'une congestion a eu lieu, tandis que le découpage identifie un paquet dont la charge utile n'a pas survécu. Avec RUD et la retransmission sélective, la récupération peut être accélérée sans attendre de délai d'attente ni une longue remise en séquence due à une seule perte.

Cette fonctionnalité est optionnelle pour le commutateur, mais les points de terminaison conformes doivent pouvoir recevoir et interpréter les paquets découpés lorsque les exigences s'appliquent. Cette asymétrie permet de déployer UET sur des commutateurs ordinaires, tout en permettant aux tissus optimisés d'offrir un retour d'information sur les pertes plus riche. Mais cela crée également un problème de mise à niveau: un réseau partiellement optimisé peut nécessiter de restreindre le découpage en fonction du chemin, du profil ou de la topologie pour s'assurer que chaque point de terminaison récepteur le traite correctement.

L'UEC définit également différentes classes de trafic pour les requêtes, les paquets de contrôle, les retransmissions et le trafic découpé. Les opérateurs doivent aligner de manière cohérente les valeurs DSCP, les files d'attente des commutateurs, les files d'attente des points de terminaison et les niveaux de priorité. La spécification ne fournit pas de système de gestion universel pour cet alignement. Une erreur peut affamer le trafic de contrôle, fausser le retour d'information sur la congestion ou faire en sorte que les paquets de récupération entrent en compétition avec le trafic qu'ils sont censés réparer.

Le découpage de paquets résume le défi plus large de la mise en œuvre. Le protocole peut spécifier le comportement sur le câble, mais le résultat opérationnel dépend des files d'attente des commutateurs, de la logique des points de terminaison, de la télémétrie, de la configuration et du traitement des pannes. L'interopérabilité est une propriété du système dans son ensemble, pas seulement du format de paquet.

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

La retentative au niveau liaison (Link Layer Retry, LLR) tente de récupérer une erreur sur une liaison physique avant que la couche transport de bout en bout ne réagisse. Le récepteur détecte un trou de séquence ou une trame corrompue, envoie un acquittement négatif au niveau liaison et demande à l'émetteur de retransmettre la trame affectée depuis un tampon local. Si la récupération réussit rapidement, la couche transport peut éviter une retransmission plus longue sur l'ensemble du chemin.

La valeur potentielle augmente avec la vitesse des voies et la densité des ports. Des erreurs optiques ou électriques occasionnelles pourraient autrement introduire un retard significatif dans une tâche hautement synchronisée. Mais la LLR ajoute un état de séquence, des tampons de rejeu, des messages de contrôle, des fenêtres d'abandon 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 situations limites, y compris une condition de course entre les informations de crédit CBFC et la LLR.

Le contrôle de flux basé sur les crédits (Credit-Based Flow Control, CBFC) fonctionne par canal virtuel au niveau liaison. Il indique à l'émetteur la capacité de réception restante et peut offrir un contrôle plus fin qu'une pause globale basée sur la priorité. L'UEC le présente comme un moyen de soutenir un comportement sans perte maîtrisé sans exiger que chaque réseau UET soit entièrement sans perte. Le CBFC est optionnel, et UET est conçu pour fonctionner sur des réseaux au mieux.

Le CBFC ne doit pas être considéré comme un autre nom du Priority Flow Control. Les deux mécanismes diffèrent en signalisation et en granularité, bien qu'ils visent tous deux à éviter les débordements. Le CBFC nécessite toujours une configuration cohérente et une livraison correcte de ses propres trames de contrôle. Les crédits locaux peuvent interagir avec les fenêtres d'extrémité et les crédits du récepteur, produisant de multiples boucles de contrôle imbriquées.

L'UEC utilise une négociation basée sur LLDP pour découvrir les fonctionnalités optionnelles et empêcher une extrémité d'activer une capacité que le voisin ne prend pas en charge. La négociation doit prendre en compte les profils, les canaux virtuels, DSCP, l'alignement des priorités, les réinitialisations, les mises à niveau logicielles et les combinaisons partielles de fonctionnalités. La version 1.0.3 a introduit une capacité de négociation logique, renforçant l'importance d'un accord explicite sur chaque liaison.

Ces options offrent une trajectoire allant d'Ethernet de base à Ethernet optimisé. Mais elles créent également une matrice que le langage d'achat peut masquer. Un commutateur peut transmettre correctement le trafic UET sans découpage, LLR ou CBFC. Un autre peut ne prendre en charge ces capacités que dans certaines versions logicielles ou modes de port. Un registre de déploiement fiable doit indiquer l'ensemble précis de fonctionnalités, pas seulement le nom du consortium.

Signalisation physique à 100 et 200 Gbit/s par voie

La couche physique relie l'UEC à la feuille de route matérielle. Les premiers travaux pour la version 1.0 étaient conçus pour une signalisation à 100 Gbit/s par voie. La version 1.0.3 a introduit la prise en charge de 200 Gbit/s par voie. Cela correspond à une génération de liaisons et de systèmes à plus haute densité, mais il s'agit d'une capacité de la spécification, et non d'une preuve que chaque produit UEC la supporte immédiatement.

Le travail sur la couche physique couvre également les statistiques de correction d'erreurs sans voie de retour (FEC), les ratios de mots de code corrigés et incorrigibles, les jeux de contrôle ordonné, les rapports de qualité de liaison et l'interaction entre les erreurs physiques et la LLR. Ces détails sont importants car les décisions de récupération de la couche transport dépendent de ce que les couches inférieures peuvent voir et signaler.

À des vitesses de signalisation plus élevées, les frontières entre l'optique, le SerDes, la FEC, la retentative de liaison et la récupération de la couche transport acquièrent une importance économique. Une FEC plus forte peut réduire les erreurs résiduelles au prix de la latence et de la puissance. Une retentative locale peut récupérer l'erreur plus rapidement mais nécessite des tampons et de l'état. Une retransmission de bout en bout est plus simple d'un point de vue réseau, mais peut gaspiller davantage de temps. L'UEC cherche à définir comment ces couches coopèrent, plutôt que de laisser chaque fournisseur les optimiser de manière isolée.

L'ajout du 200G par voie montre également que la cible est mouvante. Les implémenteurs de la version 1.0 doivent maintenir la compatibilité tout en planifiant les nouvelles capacités physiques. Les équipements de test, les micrologiciels et les systèmes de gestion doivent distinguer les capacités de chaque port. Les acheteurs ne doivent pas déduire la vitesse de voie d'une allégation générale de support UEC.

Sécurité optionnelle de bout en bout au niveau transport

La sous-couche de sécurité de la couche transport (Transport Security Sublayer, TSS) offre une protection optionnelle de point de terminaison à point de terminaison. Le modèle de menace ne fait pas confiance aux commutateurs. Elle peut fournir confidentialité, intégrité, protection contre le rejeu, isolation des tâches, domaines sécurisés, clés de groupe, rotation des clés et intégration avec des 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 de liaison, les époques, l'identité source sécurisée et la dérivation des clés sont conçus pour mieux passer à l'échelle que l'établissement d'une session indépendante pour chaque paire de points de terminaison. Cela est nécessaire lorsque l'ensemble des 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 exploiter des autorités de clés et de certificats ou d'autres racines de confiance, des services d'appartenance aux tâches, la distribution et la révocation, les transitions d'époque, la récupération des points de terminaison, le chiffrement matériel et la mesure de sécurité. Le réseau peut se conformer à un profil sans activer toutes les fonctions optionnelles du TSS. « Compatible UEC » ne signifie pas automatiquement que le trafic est chiffré.

Le caractère optionnel reflète différentes hypothèses de déploiement. Un tissu dédié et physiquement contrôlé peut privilégier la performance et s'appuyer sur des contrôles environnementaux. Un cloud multi-locataires peut exiger une isolation forte et une protection cryptographique. Le système de profils et les achats doivent refléter cette différence.

Le risque le plus grave n'est pas seulement le coût du chiffrement, mais la défaillance du cycle de vie à grande échelle: appartenance obsolète, révocation tardive, époques incohérentes, récupération après défaillance d'un point de terminaison, ou incapacité à prouver quelle tâche peut accéder à quelle mémoire. Ces problèmes lient la sécurité du transport aux systèmes d'orchestration et d'identité qui se situent en dehors de 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 programme de certification indépendant mature. La suite disponible est principalement conçue pour l'auto-déclaration des implémenteurs. Des matrices associent les exigences de la spécification aux profils, et des directives de banc d'essai décrivent des configurations recommandées pour les points de terminaison et les commutateurs. Aucune base de données publique complète n'a été trouvée où une entité indépendante enregistre quels produits ont réussi ou échoué à un programme UEC complet.

La distinction est essentielle car différentes allégations circulent sur le marché. Un produit peut être conçu autour de fonctionnalités UEC en cours de développement, implémenter des fonctions sélectionnées sur le câble, ou prendre en charge un profil ou certaines de ses parties dans une version logicielle donnée. Un fournisseur peut revendiquer la conformité complète des fonctionnalités, ou un laboratoire peut générer du trafic UET à travers un commutateur. Aucune de ces situations n'équivaut automatiquement à une certification indépendante de bout en bout multi-fournisseurs.

Les directives de banc d'essai publiques sont utiles mais intentionnellement limitées. Elles proposent des topologies et des vérifications de bonnes pratiques, pas une qualification système complète. Elles ne couvrent pas entièrement l'interopérabilité étendue, les performances, le stress, l'échelle, le cycle de vie des API. Elles ne prouvent pas non plus le comportement en présence d'un mélange UET et RoCE, de mises à niveau partielles, de pannes répétées, de grands domaines de clés ou du nombre maximal de points de terminaison ciblé.

La contradiction entre IA Full et IA Extended démontre la nécessité d'un versionnement rigoureux. Tout acheteur doit interroger sur la spécification, le niveau de correctif, le profil, les fonctionnalités optionnelles, les modes de liaison et les fonctions de sécurité couvertes par l'allégation. La réponse doit préciser si la preuve provient de tests internes, d'une démonstration bilatérale, d'un événement du consortium ou d'un laboratoire indépendant.

La prochaine étape crédible comprend des définitions de tests publics liées à des versions précises, des plugfests multi-fournisseurs, des résultats gérés de manière indépendante (y compris les résultats négatifs), et un registre distinguant les points de terminaison, les commutateurs, les logiciels et les systèmes complets. Tant que cela n'est pas en place, l'expression « conforme UEC » reste un point de départ pour la vérification, pas une garantie.

Un document ouvert avec des engagements de licence de brevet RAND

L'Ultra Ethernet Specification 1.0.3 est accessible au public et distribuée sous licence Creative Commons Attribution-NoDerivatives 4.0. Cette licence autorise la redistribution avec attribution, mais pas la distribution de versions modifiées. Plus important encore, le droit d'accès via le droit d'auteur est distinct du droit d'utiliser les brevets.

Les chartes documentées des groupes de travail utilisent généralement un modèle traditionnel de développement de spécifications avec une licence de brevet à des conditions raisonnables et non discriminatoires (RAND). RAND ne signifie pas nécessairement sans redevance, ne garantit pas un prix universel, n'élimine pas la négociation et n'empêche pas les litiges sur la validité, la nécessité, la portée géographique ou les conditions défensives. La situation commerciale dépend de chaque brevet déclaré, de l'engagement de chaque membre et de tout accord bilatéral.

L'UEC tient un registre public des déclarations de « Necessary Claims ». À la date de cette recherche, des déclarations sont apparues liées à Broadcom, Microsoft, Huawei, Qualcomm, AMD, HPE, Google, Marvell et d'autres, y compris des dépôts liés aux futurs travaux de la version 1.1. Ce 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 précise qu'il ne détermine pas si un brevet déclaré est valide, effectivement nécessaire, contrefait ou disponible à un prix donné. Il ne publie pas non plus de licence groupée. Les petits implémenteurs peuvent faire face à des coûts juridiques et transactionnels que les grandes entreprises peuvent absorber plus facilement. Une spécification publique peut aboutir à un marché d'implémentation concentré si les coûts de clarification des brevets, du silicium et des tests sont élevés.

Le cadre de propriété intellectuelle influence également les incitations à la gouvernance. Les entreprises contribuent à la technologie en partie pour créer un vaste marché pour leurs produits, et en partie pour s'assurer que leurs capacités sont représentées dans la conception commune. Les déclarations de brevets ne protègent les implémenteurs des surprises que si elles sont précoces et suffisamment claires. Elles n'éliminent pas la possibilité que la licence devienne un obstacle une fois l'adoption généralisée.

Une description honnête est donc « publiée publiquement et multi-fournisseurs avec des engagements RAND », et non « exempte de redevance de manière universelle ». Les équipes d'achat ont besoin à la fois du profil technique et du parcours de licence.

La première vague de produits et de tests

Les preuves de mise en œuvre ont commencé à apparaître autour de la version 1.0, mais les exemples se situent à différents stades de maturité.

AMD a rendu disponible commercialement sa carte réseau Pollara 400 AI NIC en avril 2025, la décrivant comme conçue autour des capacités évolutives de l'UEC. Pollara est une plateforme de point de terminaison programmable et un signal important de la transition de la couche transport vers du matériel effectivement expédié. Mais la formulation est importante: une conception autour de fonctionnalités en cours d'évolution n'équivaut pas à une certification indépendante par rapport à toutes les exigences de la version 1.0.3 finale.

Broadcom a annoncé en juin 2025 le Tomahawk 6 comme un ASIC de commutation de 102,4 Tbit/s avec des fonctionnalités pertinentes pour les tissus UEC. En octobre, elle a annoncé la carte réseau Thor Ultra 800G, affirmant que la conception offrait une conformité complète aux fonctionnalités UEC. Il s'agit d'une allégation significative du fournisseur, mais la preuve publique ne la transforme pas en une certification indépendante du consortium. Il convient de séparer l'échantillonnage, la maturité logicielle et la prise en charge précise des profils.

Nokia et Keysight ont annoncé en octobre 2025 une démonstration de trafic UET de bout en bout sur les familles de commutateurs de centre de données Nokia 7220 et 7250 à 800 Gigabit Ethernet. Keysight a fourni la génération de trafic et la vérification. Ce test prouve que le trafic UET peut traverser des systèmes de commutation commerciaux et que le support des équipements de test progresse. Mais il ne prouve pas un profil de point de terminaison complet multi-fournisseurs, un volume de production ou une certification indépendante pour toutes les fonctionnalités optionnelles.

D'autres membres ont décrit des commutateurs, des systèmes, des logiciels et des plans de test compatibles UEC, et le sommet de 2026 s'est fortement concentré sur la mise en produits. Les preuves soutiennent une transition vers l'implémentation, mais elles ne démontrent pas un nombre précis de cartes UET expédiées, de commutateurs certifiés, de régions cloud opérationnelles ou de tissus complets.

La meilleure lecture de cette vague est une chaîne de preuves. La spécification publique rend la conception possible. 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 des opérateurs montreront la valeur opérationnelle. Les plugfests indépendants et les résultats de production fourniront la confiance plus large qui fait encore défaut.

RoCE, InfiniBand, Slingshot et UALink

L'UEC entre sur un marché où existent des alternatives matures et des technologies voisines. Son argument stratégique ne repose pas sur le fait qu'Ethernet n'a jamais transporté de RDMA ou que les tissus spécialisés ne fonctionnent pas, mais sur l'idée que l'échelle et la synchronisation des charges de travail actuelles de l'IA justifient une nouvelle architecture Ethernet de bout en bout, plus flexible dans la livraison, l'utilisation des chemins et le contrôle de la congestion.

RoCEv2 est le prédécesseur direct et une technologie largement déployée. Elle transporte le trafic RDMA sur un réseau Ethernet routable et bénéficie d'un large support applicatif et produit. L'UEC critique les déploiements RoCE courants parce qu'ils fixent le flux entier sur un seul chemin, utilisent le retour en arrière (Go-Back-N) et le réordonnancement au récepteur, exigent un réglage difficile de DCQCN, s'appuient sur le Priority Flow Control dans de nombreuses conceptions et présentent de mauvais comportements lors d'incasts ou de rafales collectives.

Il s'agit de positions techniques du consortium, et non de la preuve que chaque réseau RoCE est défaillant.

La comparaison est également mouvante. Les fournisseurs peuvent ajouter le routage adaptatif, la dispersion des paquets, de meilleurs algorithmes de congestion ou des fonctions analogues à l'UEC sur des cartes réseau programmables tout en maintenant la compatibilité RoCE. Par exemple, AMD, dans sa communication autour de Pollara, propose à la fois RoCEv2 et l'UEC RDMA comme options sur un matériel programmable. L'UEC peut concurrencer RoCE en tant que transport complet tout en influençant l'évolution des futurs produits RoCE.

InfiniBand est la principale alternative spécialisée. Il offre un écosystème intégré pour le RDMA, la congestion, la fiabilité des liaisons et la gestion, avec une longue expérience en HPC. Les travaux de l'InfiniBand Trade Association sur la version 2.0 incluent le support physique XDR à 200 Gbit/s par voie et une télémétrie actualisée. La distinction la plus forte de l'UEC n'est pas d'affirmer qu'InfiniBand manque de performances, mais le potentiel d'obtenir un comportement IA/HPC à travers la plus large chaîne d'approvisionnement Ethernet, un routage IP standard et un plus grand choix de fournisseurs.

Le Slingshot de HPE occupe une position intermédiaire. C'est un tissu HPC commercial compatible Ethernet, doté de routage adaptatif et de gestion de la congestion, et il a fourni des antécédents techniques importants pour l'UET. Il démontre qu'un comportement spécialisé peut être construit au-dessus d'Ethernet, mais il illustre aussi la différence entre une plateforme commerciale contrôlée et une spécification à l'échelle de l'industrie.

UALink est souvent complémentaire plutôt qu'un remplacement direct. Sa spécification publique actuelle 200G cible une connexion scale-up à faible latence entre accélérateurs à l'intérieur d'un pod, et décrit des systèmes allant jusqu'à 1 024 accélérateurs. L'UEC 1.0 est principalement un tissu scale-out qui relie les nœuds à travers des commutateurs. Un centre de données pourrait utiliser une liaison scale-up à l'intérieur d'un pod et UEC entre les pods ou les nœuds.

Les travaux futurs de l'UEC sur le transport scale-up et les opérations collectives dans le réseau pourraient rapprocher les frontières et produire une convergence ou une concurrence.

Le Spectrum-X de NVIDIA et les tissus propriétaires d'accélérateurs offrent une autre comparaison. Une pile étroitement intégrée peut optimiser rapidement le matériel, les logiciels et le support, mais elle accroît la dépendance envers un seul écosystème. L'UEC remplace une partie de cette intégration par la promesse d'interfaces communes et de choix de fournisseurs. Le succès de ce compromis dépend de la performance, du support, des conditions de brevet, de l'interopérabilité et du coût opérationnel total, et non du simple mot « ouvert » comme slogan.

Le problème opérationnel est plus grand que le protocole

Une spécification de 573 pages peut définir de nombreuses exigences, mais un tissu en production a encore besoin d'un modèle opérationnel. L'UEC 1.0 laisse ou contourne des tâches de gestion critiques en dehors du document normatif de base. Les opérateurs doivent configurer les profils, les classes de trafic, les seuils ECN, les ensembles d'entropie, les fonctionnalités optionnelles de liaison, les clés, les micrologiciels, la télémétrie et la politique de défaillance de manière cohérente entre les points de terminaison et les commutateurs.

Le trafic mixte rend la tâche plus difficile. Un tissu de centre de données peut transporter UET, RoCE, TCP, du stockage, de la gestion et des services UET ordonnés et non ordonnés. La répartition des files d'attente et l'équité entre elles ne sont pas résolues par le simple fait que chaque protocole est correctement implémenté. Un algorithme de congestion peut bien fonctionner seul, mais mal se comporter lorsqu'il est en concurrence avec un autre contrôleur qui utilise des signaux et des hypothèses différents.

La complexité du point de terminaison est un autre risque structurel. L'UET place le multipath, le placement direct, la retransmission sélective, les multiples modes de livraison, le contrôle de fenêtre, les crédits, la réception du découpage, la sécurité et un état important à l'intérieur du FEP. Cela peut augmenter la surface de la puce de la carte réseau, la taille du micrologiciel, l'effort de validation, la consommation d'énergie et le nombre de cas de défaillance à diagnostiquer.

L'intelligence du point de terminaison permet une large chaîne d'approvisionnement, mais elle peut placer la partie la plus difficile de l'implémentation dans le composant que chaque serveur doit acheter.

Les fonctionnalités optionnelles créent à la fois une différenciation produit et une fragmentation. Un fournisseur de point de terminaison peut optimiser pour le profil IA Base avec ECMP et ECN ordinaires. Un autre peut prendre en charge IA Full, HPC, TSS, le découpage, LLR et CBFC. Les deux font partie de l'écosystème UEC, mais les opérateurs ne peuvent pas présumer des mêmes sémantiques, performances ou sécurité. Les matrices de conformité doivent devenir des matrices opérationnelles de capacités.

La maintenance des versions sera continue. Les correctifs de 1.0.1 à 1.0.3 ont affecté la congestion, les crédits, la retentative et le comportement des paquets. Un grand cluster peut inclure différentes versions de micrologiciel de carte réseau, plusieurs versions de commutateur et des outils de test. La mise à niveau d'une couche sans coordonner le reste peut précisément révéler l'interaction transversale que le consortium cherche à éviter.

C'est pourquoi les relations externes sont centrales et non symboliques. L'Open Compute Project peut relier le transport aux systèmes et au matériel ouvert. L'OpenFabrics Alliance et la communauté libfabric relient les applications. L'IEEE 802.3 fournit le travail Ethernet formel. La SNIA et NVM Express ajoutent les exigences de stockage et de gestion. Les technologies de l'IETF fournissent les mécanismes IP, ECN et connexes. Ces organismes ont des processus de décision et des feuilles de route différents; la coordination réduit les doublons mais ne garantit pas 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, un consortium peut organiser un sommet. Aucun de ces éléments ne remplace un cluster où des points de terminaison et des commutateurs indépendants accomplissent des tâches réelles sous congestion, panne et mise à niveau, et où les opérateurs peuvent interpréter ce qui s'est passé.

Importance actuelle: du succès de la spécification à la crédibilité de la mise en œuvre

En juillet 2026, l'UEC avait accompli des choses qui n'étaient pas garanties lors de son lancement. Elle a constitué un large consortium, établi une architecture intégrée à cinq couches, publié une spécification 1.0 complète, l'a maintenue à travers plusieurs versions de correctifs, ajouté le 200G par voie, divulgué des déclarations de brevets et attiré des annonces de produits et des tests. Le projet est actif, et son agenda s'est clairement orienté vers la mise en œuvre.

Ces progrès rendent les incertitudes suivantes plus importantes, et non moins. Le nombre exact actuel de membres et la composition du Steering Committee ne figurent pas dans un registre de référence unique. Les pages publiques d'adhésion et le document de gouvernance décrivent l'accès de manière différente. La direction actuelle du TAC ne correspond pas entièrement aux rôles du sommet. Des documents officiels divergent sur la date de la version 1.0.2, et la suite de conformité utilise une terminologie de profil obsolète.

Aucun de ces éléments ne ruine l'architecture, mais c'est un indicateur de la rigueur documentaire et de la transparence dans un projet où les résultats dépendent de versions précises.

Les lacunes les plus importantes concernent l'adoption. L'UEC ne publie pas de statistiques de déploiement, ni de registre de produits vérifié par une entité indépendante, ni de budget indépendant ou d'états financiers audités. Il n'existe aucune preuve publique d'un réseau UEC 1.0 complet et interopérable aux objectifs d'échelle maximale du consortium. Les démonstrations et les allégations des fournisseurs ont de la valeur, mais elles proviennent d'acteurs ayant un intérêt commercial. Les comparaisons neutres avec les déploiements RoCE, InfiniBand et les plateformes Ethernet intégrées restent limitées.

L'opportunité reste considérable. Ethernet est le dénominateur commun dans les centres de données, et le marché des infrastructures d'IA est assez vaste 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 à réduire leur dépendance envers un fournisseur unique et à améliorer l'utilisation des accélérateurs. Une pile commune peut transformer ces incitations en pouvoir d'achat.

Le risque est que « Ultra Ethernet » devienne un terme générique pour des ensembles de fonctionnalités incompatibles. Si le routage de base fonctionne, mais que les profils, la congestion, la sécurité et la gestion diffèrent, la marque peut se répandre plus vite que l'interopérabilité. Si la licence RAND est coûteuse ou ambiguë, l'ensemble des fournisseurs peut se réduire. Si les produits RoCE absorbent les idées les plus attrayantes sans nouvelle couche transport, l'UEC peut influencer le marché sans devenir le nom dominant.

La question cruciale n'est plus de savoir si le consortium peut publier une spécification avancée. Il l'a fait. La question est de savoir si des organisations indépendantes peuvent implémenter les mêmes contrats, licencier la technologie nécessaire, exploiter le tissu à grande échelle et maintenir la compatibilité à mesure que la spécification évolue. L'UEC ne deviendra une infrastructure que dans la mesure où ces affirmations résistent à l'épreuve des systèmes en fonctionnement.