Storage-Netzwerke
iWARP
iWARP bringt RDMA über den klassischen TCP/IP-Stack; es toleriert Paketverlust und braucht kein verlustarmes Netz, ist aber latenzreicher und seltener als RoCE.
- RDMA über TCP/IP
- Kein verlustarmes Netz nötig
- IETF (RFC 5040 ff.)
- WAN- und routingtauglich
- Kleinere Verbreitung als RoCE
iWARP (Internet Wide Area RDMA Protocol) bringt RDMA, also direkten Speicherzugriff ohne CPU-Kopien, über den ganz normalen TCP/IP-Stack. Damit erbt es eine wichtige Eigenschaft: TCP sorgt für die zuverlässige Übertragung und das erneute Senden verlorener Pakete, sodass iWARP, anders als RoCEv2, kein eigens verlustarm konfiguriertes Netz braucht.
Dieser Artikel erklärt den Protokollaufbau über TCP, warum kein verlustarmes Netz nötig ist, die Abgrenzung zu RoCE, die Hardware- und Software-Lage sowie die Sicherheitsfrage.
1. RDMA über den TCP/IP-Stack
iWARP ist genau genommen eine kleine Protokollfamilie der IETF: RDMAP (RFC 5040) für die RDMA-Operationen, DDP (Direct Data Placement, RFC 5041) für das direkte Ablegen von Daten im Zielpuffer und MPA (RFC 5044), das zwischen dem Byte-Strom von TCP und den Nachrichtengrenzen vermittelt. Alles läuft über TCP, weshalb iWARP über jedes routbare IP-Netz funktioniert.
2. Kein verlustarmes Netz nötig
Der zentrale Unterschied zu RoCEv2: Weil TCP Paketverluste über Neuübertragung und Staukontrolle abfängt, braucht iWARP weder Priority Flow Control noch Data Center Bridging. Es läuft auf Standard-Switches, auch über weniger kontrollierte Strecken, und ist prinzipiell routing- und WAN-tauglich. Der Preis ist die Latenz: Der TCP-Stack fügt Verarbeitungsaufwand hinzu, weshalb iWARP unter Last in der Regel langsamer ist als gut konfiguriertes RoCEv2.
iWARP tauscht ein Stück Latenz gegen Betriebseinfachheit: kein PFC, kein DCB, keine verlustarme Fabric, dafür der vertraute TCP-Stack.
3. Hardware und Software
iWARP erfordert iWARP-fähige Netzwerkkarten mit TCP/RDMA-Offload; die Auswahl ist deutlich kleiner als bei RoCE, getragen vor allem von Chelsio und Intel. Marktführende RDMA-NIC-Anbieter setzen schwerpunktmäßig auf RoCE, was die geringere Verbreitung von iWARP erklärt. Für Tests und kleinere Lasten gibt es Soft-iWARP (Kernel-Modul siw) seit Linux 5.2, das iWARP in Software auf normalen Netzwerkkarten bereitstellt und mit Hardware-iWARP interoperabel ist. iWARP und RoCE lassen sich nicht auf demselben Pfad mischen.
4. Sicherheit
iWARP hat keine eigene Verschlüsselung auf Protokollebene. Der zugehörige Sicherheits-RFC (RFC 5042) verweist auf IPsec als Schutzmittel und rät von TLS ab, weil TLS die RDMA-/DDP-Header nicht schützt und seine in-order-Verarbeitung den direkten Datenpfad-Vorteil aufheben würde. Verschlüsselung ist also über das Netz (IPsec) zu lösen, nicht über das Protokoll selbst.
5. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Läuft auf Standard-IP-Netzen, kein PFC/DCB nötig | höhere Latenz als RoCEv2 durch den TCP-Stack |
| Paketverlusttolerant (TCP), routing- und WAN-tauglich | kleine Hardware-Auswahl (v. a. Chelsio, Intel) |
| IETF-standardisiert, offene Spezifikation | in Neuinstallationen selten; RoCEv2 dominiert |
| Soft-iWARP (siw) für Test ohne Spezialhardware | nicht mit RoCE auf demselben Pfad mischbar |
| Kein Risiko von PFC-Deadlocks | keine native Verschlüsselung (IPsec nötig) |
Häufige Fragen zu iWARP
iWARP setzt RDMA auf TCP, RoCE auf Ethernet (RoCEv2 über UDP/IP). Dadurch toleriert iWARP Paketverluste über die TCP-Neuübertragung und braucht kein verlustarmes Netz mit Priority Flow Control, während RoCEv2 ein sorgfältig konfiguriertes, verlustarmes Ethernet voraussetzt. RoCEv2 ist dafür latenzärmer und weiter verbreitet; iWARP ist betriebseinfacher, aber langsamer und seltener.
Es ist eine Nische. In neuen Rechenzentren und KI-/HPC-Backends dominiert RoCEv2, und für einfachen Speicher im Netz hat NVMe/TCP an Boden gewonnen. iWARP bleibt interessant, wo RDMA über Standard- oder routbare Netze ohne verlustarme Fabric gebraucht wird, und mit Soft-iWARP für Tests.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
iWARP im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.