UDP 4791 · PFC + ECN · DCQCN

RoCEv2 : Ethernet sans perte pour les fabrics IA

RoCEv2 est la façon dont RDMA fonctionne sur de l'Ethernet standard : il encapsule le RDMA dans UDP/IP et utilise le port de destination UDP 4791, si bien que le trafic collectif GPU est routable sur un fabric leaf-spine ordinaire. Il requiert un fabric sans perte construit avec PFC et ECN, avec DCQCN comme boucle de contrôle de congestion, et OcNOS fournit l'ensemble de cette boîte à outils dès aujourd'hui sur du matériel ouvert 400G et 800G pris en charge.

UDP 4791Port de destination RoCEv2
jusqu'à 800Gplateformes RoCEv2 ouvertes
1 NOSOcNOS-DC sur matériel ouvert
256 à 4,096Conceptions de référence GPU
Le fabric sans perte

Les mêmes GPU sur un fabric leaf-spine sans perte

Une tranche de rail compacte : deux spines et deux leaves acheminant du RoCEv2 entre quatre GPU. Les trames de pause PFC circulent saut par saut en cas de congestion, tandis qu'ECN marque les flux éléphants pour une réaction DCQCN à la source. Le RDMA est encapsulé dans UDP/IP sur le port de destination 4791, si bien que le même trafic est routable sur un fabric Ethernet standard.

Topologie de fabric IA RoCEv2 : deux spines, deux leaves et quatre GPU, avec des flèches de pause PFC sur le trafic RoCEv2 sans perte
RoCEv2 : fabric IA à deux spines et deux leaves transportant un trafic GPU sans perte avec flux de pause PFC.
Pourquoi RoCEv2 est important pour les AI fabrics

Une perte quasi nulle maintient l'efficacité des collectifs GPU

Les collectifs GPU (all-reduce, all-gather, all-to-all) génèrent des flux éléphants qui saturent des chemins de fabric uniques et exigent une perte quasi nulle pour maintenir l'efficacité des tâches d'entraînement. Qu'un seul paquet soit perdu sur un lien RoCEv2 400G et le NIC concerné retransmet l'intégralité de la fenêtre d'envoi RDMA, ce qui se mesure en secondes de temps d'inactivité GPU. RoCEv2 transforme un fabric leaf-spine en transport sans perte pour ces charges de travail en encapsulant le RDMA dans UDP/IP sur le port de destination 4791, si bien que le même trafic est routable en Layer 3.

Parameter RoCEv1Couche 2 RoCEv2UDP/IP, routable
EncapsulationRDMA transporté directement sur Ethernet (EtherType dédié).RDMA encapsulé dans UDP/IP, utilisant le port de destination UDP 4791.
Couche réseauLayer 2 uniquement ; confiné à un seul domaine de broadcast.Layer 3 routable sur un fabric leaf-spine standard.
Entropie ECMPAucun en-tête IP ou UDP à hacher ; répartition des chemins limitée.Le port source UDP varie comme identifiant de flux pour répartir le trafic sur les chemins ECMP.
Exigence d'absence de perteNécessite un fabric sans perte construit avec PFC et ECN.Nécessite un fabric sans perte construit avec PFC et ECN, avec DCQCN comme boucle de contrôle de congestion.
Portée et échelleAu sein d'une baie ou d'un même sous-réseau.Fabrics de datacenter routés ; architectures de référence pour des clusters de 256 à 4,096 GPU.
Sans perte par conception

Les mécanismes qui maintiennent le fabric sans perte

Un fabric RoCEv2 reste sans perte grâce à trois mécanismes coopérants : le priority flow control met en pause la bonne classe de trafic, ECN et DCQCN maintiennent le débit sans perte, et le routage adaptatif éloigne les quelques flux volumineux des liens montants congestionnés.

Priority Flow Control

Pause par priorité

Le PFC 802.1Qbb met en pause une seule classe de trafic saut par saut pour que les files acheminant le RDMA ne perdent jamais de paquets. OcNOS l'associe à un watchdog d'interblocage PFC qui détecte une priorité bloquée et se rétablit automatiquement avant qu'elle ne se propage.

Contrôle de congestion

Marquage ECN et boucle DCQCN

Le marquage ECN basé sur WRED marque les paquets à mesure que les files se remplissent, et DCQCN est la boucle de contrôle de congestion qui réagit à la source pour maintenir le débit sans perte. Valeurs par défaut ajustées pour les collectifs xCCL, avec surcharge paramétrique pour les piles RDMA personnalisées.

Équilibrage de charge

Routage adaptatif par flowlet

Le hachage ECMP statique entre en collision sur les quelques flux éléphants volumineux que produisent les collectifs IA. DLB redistribue les flowlets en cas de saturation locale d'un lien dans des fenêtres inférieures à la milliseconde, éliminant les collisions du hachage statique qui pénalisent les topologies symétriques.

L'implémentation OcNOS

RoCEv2 tel qu'OcNOS le fournit

Au-delà des mécanismes sans perte, OcNOS apporte la télémétrie, les architectures de référence et un chemin de mise à niveau propre qui transforment une configuration sans perte en un fabric exploitable.

Télémétrie

Statistiques de file par priorité

Capteurs en streaming gNMI pour la profondeur des files, les compteurs de pause PFC, les paquets marqués ECN et la détection de micro-rafales, exportés selon un intervalle d'échantillonnage de 10 secondes pour une observabilité à l'échelle du fabric.

Designs de référence

Fabrics optimisées pour les rails

Architectures de référence pour les topologies alignées par rail et à fabric ordonnancé, couvrant des clusters de 256 à 4,096 GPU sur des commutateurs ouverts 400G et 800G du commerce. Les diagnostics CLI vérifient de bout en bout une configuration sans perte validée.

Transport de nouvelle génération

Une trajectoire claire vers Ultra Ethernet

Déployez du RoCEv2 sans perte aujourd'hui et gardez une voie ouverte vers Ultra Ethernet, qui ajoute le packet spray et le RDMA multi-chemins à l'Ethernet standard à mesure que les NIC UEC arrivent. Un seul NOS prend en charge les deux.

Why OcNOS

Une seule image NOS sur du matériel ouvert

La boîte à outils RoCEv2 fait partie de la licence OcNOS-DC de base, et non d'un ensemble d'options payantes, et elle fonctionne à l'identique sur un choix de matériel multifournisseur.

  • Choix matériel ouvert. Exécutez RoCEv2 sur des plateformes UfiSpace, Edgecore ou Celestica avec la même image NOS, de sorte que la couche fabric n'entraîne aucun verrouillage fournisseur.
  • Parité fonctionnelle dès le premier jour. L'équilibrage de charge adaptatif, le réglage DCQCN et la télémétrie native ASIC font partie de la licence OcNOS-DC de base, et non d'options payantes.
  • Conceptions de référence. Configurations de référence pour les topologies de fabric IA courantes, avec les configurations et les résultats de tests publiés.
  • Accès d'ingénierie. Le niveau de support premium inclut un dialogue direct avec l'équipe RoCEv2 d'OcNOS pendant la mise en service du fabric.
Le point de vue d'IP Infusion

Ethernet standard, performances RDMA, matériel ouvert

RoCEv2 permet à un fabric IA de réutiliser les opérations et les équipements Ethernet que le reste du datacenter fait déjà tourner, et OcNOS est l'élément habilitant qui le rend sans perte sur des commutateurs ouverts.

Ethernet standard, vitesse RDMA

RoCEv2 transporte le RDMA sur de l'UDP/IP routable, de sorte que les collectifs GPU bénéficient d'un déplacement de données à faible latence et faible consommation CPU, sans fabric dédié distinct.

Choix de matériel ouvert

La même configuration sans perte fonctionne sur les commutateurs UfiSpace, Edgecore et Celestica en 400G et 800G, préservant le caractère multifournisseur de la couche fabric.

OcNOS est l'élément habilitant

PFC, ECN, DCQCN, DLB et la télémétrie par priorité sont livrés dans un seul NOS sur des commutateurs ouverts, si bien que le fabric sans perte complet se construit, au lieu d'être un projet d'intégration.

FAQ

RoCEv2, questions et réponses

Qu'est-ce que RoCEv2 ?
RoCEv2 (RDMA over Converged Ethernet version 2) transporte le trafic RDMA sur des réseaux UDP/IP routables, permettant aux serveurs de déplacer des données directement de mémoire à mémoire avec une latence très faible et une faible charge CPU. Il est largement utilisé pour les clusters d'IA et le stockage haute vitesse sur les fabrics Ethernet.
Quelle est la différence entre RoCEv2 et RoCEv1 ?
RoCEv2 fait fonctionner le RDMA sur UDP/IP : il est donc routable à travers des réseaux Layer 3, tandis que RoCEv1 fonctionne directement sur Ethernet (Layer 2) et reste dans un unique domaine de broadcast. RoCEv2 s'étend à des fabric de data center routées et plus vastes, que RoCEv1 ne peut atteindre.
RoCEv2 nécessite-t-il un réseau sans perte ?
RoCEv2 requiert un fabric sans perte ou quasi sans perte, car les performances RDMA chutent fortement en cas de perte de paquets. Les opérateurs y parviennent avec le PFC pour le contrôle de flux et l'ECN associé au DCQCN pour le contrôle de congestion, en maintenant des files d'attente peu profondes afin que les flux RDMA évitent les rejets et les retransmissions.
Quel port UDP RoCEv2 utilise-t-il ?
RoCEv2 utilise le port UDP de destination 4791, le port réservé par l'IANA pour le trafic RoCEv2. Comme RDMA est encapsulé dans UDP/IP, les paquets sont routables et le port source UDP peut être varié comme identifiant de flux afin de répartir le trafic sur les chemins ECMP.
Comment RoCEv2 se compare-t-il à InfiniBand ?
RoCEv2 assure le RDMA sur Ethernet et IP standard, tandis qu'InfiniBand est une fabric distincte, conçue à cet effet, avec ses propres commutateurs et adaptateurs. RoCEv2 réutilise les opérations et les équipements Ethernet, ce qui explique pourquoi de nombreux réseaux d'IA et de stockage l'adoptent plutôt qu'une fabric InfiniBand dédiée.

Vous construisez ou faites évoluer un fabric IA ? Obtenez une analyse adaptée à votre charge de travail

Indiquez-nous l'échelle GPU et le motif collectif, et un ingénieur IP Infusion dimensionnera avec vous les étages de commutation et réglera la configuration sans perte, ou commencez par une première ébauche de topologie leaf-spine dans l'AI Fabric Design Suite.