RDMA over Converged Ethernet

RDMA over Converged Ethernet (RoCE) ist ein Netzwerkprotokoll, das den Remote Direct Memory Access (RDMA) über ein Ethernet-Netzwerk ermöglicht. Es gibt mehrere RoCE-Versionen. RoCE v1 ist ein Protokoll der Ethernet-Verbindungsschicht und ermöglicht daher die Kommunikation zwischen zwei beliebigen Hosts innerhalb derselben Ethernet-Broadcast-Domäne. RoCE v2 ist ein Protokoll der Internetschicht, was bedeutet, dass RoCE-v2-Pakete geroutet werden können. Obwohl das RoCE-Protokoll von den Eigenschaften eines konvergierten Ethernet-Netzwerks profitiert, kann es auch in einem herkömmlichen oder nicht konvergierten Ethernet-Netzwerk eingesetzt werden. Das RoCE-Protokoll wird von der InfiniBand Trade Association (IBTA) veröffentlicht und gepflegt.

Hintergrund

Netzwerkintensive Anwendungen wie vernetzte Speichersysteme oder Cluster-Computing erfordern eine Netzwerkinfrastruktur mit hoher Bandbreite und geringer Latenz. Die Vorteile von RDMA gegenüber anderen Netzwerk-APIs wie Berkeley-Sockets sind eine geringere Latenz, eine geringere CPU-Auslastung und eine höhere Bandbreite. Das RoCE-Protokoll ermöglicht geringere Latenzen als sein Vorgänger, das iWARP-Protokoll. Es gibt RoCE-HCAs (Host Channel Adapter) mit einer Latenz von nur 1,3 Mikrosekunden, während die niedrigste bekannte iWARP-HCA-Latenz im Jahr 2011 bei 3 Mikrosekunden lag.

RoCE-Familie

Die RoCE-Versionen unterscheiden sich in Schicht 3 und Schicht 4 des OSI-Modells. Alle RoCE-Versionen unterstützen RDMA-Funktionalität über dieselben zugrunde liegenden InfiniBand-Nachrichten. Diese Nachrichten befinden sich im Base Transport Header (BTH), im Extended Transport Header (ETH) und in der Nutzlast, gefolgt von einer invarianten zyklischen Redundanzprüfung, die der Datenintegrität dient.

RoCE im Vergleich zu InfiniBand

Sowohl InfiniBand als auch RoCE sind umfassende Netzwerkstandards und keine einzelnen Protokolle. InfiniBand spezifiziert jedoch die Transportschicht als „InfiniBand Transport Layer“, die auch von RoCE genutzt wird. Dies kann zu Verwechslungen zwischen den beiden Standards führen, da RoCE die obersten Schichten von InfiniBand implementiert, nicht jedoch den Rest der Architektur.

RoCE definiert, wie RDMA über Ethernet durchgeführt wird, während die InfiniBand-Architekturspezifikation festlegt, wie RDMA über ein InfiniBand-Netzwerk durchgeführt wird. Von RoCE wurde erwartet, dass es InfiniBand-Anwendungen, die überwiegend auf Clustern basieren, auf eine gemeinsame, konvergierte Ethernet-Struktur überführt. Andere gingen davon aus, dass InfiniBand weiterhin eine höhere Bandbreite und geringere Latenz bieten wird als dies über Ethernet möglich ist.

Die technischen Unterschiede zwischen den Protokollen RoCE und InfiniBand sind:

• Flusskontrolle auf Verbindungsebene: InfiniBand nutzt einen kreditbasierten Algorithmus, um eine verlustfreie Kommunikation zwischen HCA-Geräten zu gewährleisten. RoCE läuft auf Ethernet-Basis. Um Leistungsmerkmale zu erreichen, die denen von InfiniBand ähneln, erfordern Implementierungen unter Umständen ein verlustfreies Ethernet-Netzwerk. Verlustfreies Ethernet wird in der Regel über die Ethernet-Flusskontrolle oder die Prioritätsflusskontrolle (PFC) konfiguriert. Die Konfiguration eines Ethernet-Netzwerks mit Data Center Bridging (DCB) kann komplexer sein als die Konfiguration eines InfiniBand-Netzwerks.
• Überlastungskontrolle: Infiniband definiert eine Überlastungskontrolle auf Basis der FECN/BECN-Kennzeichnung, während RoCE v2 ein Überlastungskontrollprotokoll definiert, das ECN zur Kennzeichnung verwendet, wie es in Standard-Switches implementiert ist, sowie CNP-Frames für Bestätigungen.
• InfiniBand-Switches weisen in der Regel eine geringere Latenz auf als Ethernet-Switches. Die Port-zu-Port-Latenz beträgt bei einem bestimmten Ethernet-Switch-Typ 230 ns, während sie bei einem InfiniBand-Switch mit derselben Anzahl an Ports bei 100 ns liegt.

RoCE im Vergleich zu iWARP

Während die RoCE-Protokolle festlegen, wie RDMA über Ethernet- und UDP/IP-Frames durchgeführt wird, definiert das iWARP-Protokoll, wie RDMA über einen verbindungsorientierten Transport wie das Transmission Control Protocol (TCP) durchgeführt wird. RoCE v1 ist auf eine einzige Ethernet-Broadcast-Domäne beschränkt. RoCE-v2- und iWARP-Pakete sind routbar. Der Speicherbedarf einer großen Anzahl von Verbindungen sowie die Fluss- und Zuverlässigkeitskontrollen von TCP führen zu Skalierbarkeits- und Leistungsproblemen, wenn iWARP in großen Rechenzentren und für groß angelegte Anwendungen (z. B. große Unternehmen, Cloud Computing, Web-2.0-Anwendungen usw.) eingesetzt wird. Zudem ist Multicast in der RoCE-Spezifikation definiert, während die aktuelle iWARP-Spezifikation nicht festlegt, wie Multicast-RDMA durchgeführt werden soll.

Die Zuverlässigkeit bei iWARP wird durch das Protokoll selbst gewährleistet, da TCP zuverlässig ist. RoCE v2 hingegen nutzt UDP, das zwar einen weitaus geringeren Overhead und eine bessere Leistung aufweist, jedoch keine inhärente Zuverlässigkeit bietet. Daher muss die Zuverlässigkeit zusätzlich zu RoCE v2 implementiert werden. Eine Lösung besteht darin, konvergente Ethernet-Switches zu verwenden, um das lokale Netzwerk zuverlässig zu machen. Dies erfordert die Unterstützung von konvergentem Ethernet auf allen Switches im lokalen Netzwerk und verhindert, dass RoCE-v2-Pakete über ein Weitverkehrsnetz wie das Internet übertragen werden, das nicht zuverlässig ist. Eine weitere Lösung besteht darin, das RoCE-Protokoll um Zuverlässigkeitsfunktionen zu erweitern („Reliable RoCE“), wobei RoCE um einen Handshake-Vorgang ergänzt wird, um Zuverlässigkeit auf Kosten der Leistung zu gewährleisten.

Die Frage, welches Protokoll besser ist, hängt vom Anbieter ab. Chelsio empfiehlt und unterstützt ausschließlich iWARP. Mellanox, Xilinx und Broadcom empfehlen und unterstützen ausschließlich RoCE/RoCE v2. Intel unterstützte ursprünglich iWARP, unterstützt nun aber sowohl iWARP als auch RoCE v2. Andere Anbieter aus der Netzwerkbranche bieten Unterstützung für beide Protokolle an, darunter Marvell, Microsoft, Linux und Kazan. Cisco unterstützt sowohl RoCE als auch sein eigenes VIC-RDMA-Protokoll.

Beide Protokolle sind standardisiert, wobei iWARP der von der IETF (Internet Engineering Task Force) definierte Standard für RDMA über TCP ist und RoCE der von der IBTA definierte Standard für RDMA über Ethernet.

Kritik

Einige Aspekte, die in der RoCE-Spezifikation hätten definiert werden können, wurden ausgelassen. Dazu gehören:

• Wie lässt sich eine Zuordnung zwischen primären RoCE-v1-GIDs und Ethernet-MAC-Adressen herstellen?
• Wie lässt sich eine Zuordnung zwischen sekundären RoCE-v1-GIDs und Ethernet-MAC-Adressen herstellen? Es ist unklar, ob es möglich ist, sekundäre GIDs im RoCE-v1-Protokoll zu implementieren, ohne ein RoCE-spezifisches Adressauflösungsprotokoll hinzuzufügen.
• Wie lassen sich VLANs für das RoCE-v1-Protokoll implementieren? Aktuelle RoCE-v1-Implementierungen speichern die VLAN-ID im zwölften und dreizehnten Byte der 16-Byte-GID, obwohl die RoCE-v1-Spezifikation VLANs überhaupt nicht erwähnt.
• Wie lässt sich eine Zuordnung zwischen RoCE-v1-Multicast-GIDs und Ethernet-MAC-Adressen vornehmen? Bei den Implementierungen im Jahr 2010 wurde dieselbe Adresszuordnung verwendet, die für die Zuordnung von IPv6-Multicast-Adressen zu Ethernet-MAC-Adressen festgelegt wurde.
• Wie lässt sich der RoCE-v1-Multicast-Verkehr auf eine Teilmenge der Ports eines Ethernet-Switches beschränken? Stand September 2013 war für RoCE v1 noch kein Äquivalent zum Multicast Listener Discovery-Protokoll definiert worden.

Darüber hinaus kann kein Protokoll, das über IP läuft, davon ausgehen, dass das zugrunde liegende Netzwerk eine garantierte Reihenfolge gewährleistet, genauso wenig wie es davon ausgehen kann, dass es nicht zu einer Überlastung kommen kann.

Es ist bekannt, dass der Einsatz der primären Flusskontrolle (PFC) zu einem netzwerkweiten Deadlock führen kann.

Anbieter

Zu den Anbietern von RoCE-fähigen Geräten zählen unter anderem:

• Mellanox (2020 von Nvidia übernommen, Marke wurde beibehalten)
• ATTO-Technologie
• Bloombase
• Broadcom
• Emulex (von Broadcom übernommen)
• Cavium (von Marvell übernommen, umbenannt)
• QLogic (von Cavium übernommen, umbenannt)
• Dell Technologies
• H3C
• Huawei
• Intel
• Xilinx (von AMD übernommen) (über FPGA-Soft-IP-Core)
• Grovf

Einzelnachweise