RDMA sobre Ethernet convergente

RDMA over Converged Ethernet ( RoCE ) ^[1] es un protocolo de red que permite el acceso directo a memoria remota (RDMA) a través de una red Ethernet . Existen múltiples versiones de RoCE. RoCE v1 es un protocolo de capa de enlace Ethernet y, por lo tanto, permite la comunicación entre dos hosts cualesquiera en el mismo dominio de difusión Ethernet . RoCE v2 es un protocolo de capa de Internet , lo que significa que los paquetes RoCE v2 se pueden enrutar. Aunque el protocolo RoCE se beneficia de las características de una red Ethernet convergente , el protocolo también se puede utilizar en una red Ethernet tradicional o no convergente. ^{[2] [3] [4] [5]}

Las aplicaciones que hacen un uso intensivo de la red, como el almacenamiento en red o la computación en clúster, necesitan una infraestructura de red con un gran ancho de banda y una baja latencia. Las ventajas de RDMA sobre otras interfaces de programación de aplicaciones de red , como los sockets Berkeley, son una latencia menor, una carga de CPU menor y un mayor ancho de banda. ^[6] El protocolo RoCE permite latencias más bajas que su predecesor, el protocolo iWARP . ^[7] Hay adaptadores de canal de host (HCA) RoCE con una latencia de tan solo 1,3 microsegundos ^{[8] [9],} mientras que la latencia más baja conocida de un HCA iWARP en 2011 fue de 3 microsegundos. ^[10]

El protocolo RoCE v1 es un protocolo de capa de enlace Ethernet con Ethertype 0x8915. ^[2] Esto significa que se aplican los límites de longitud de trama del protocolo Ethernet: 1500 bytes para una trama Ethernet normal y 9000 bytes para una trama gigante .

RoCE v1.5 es un protocolo poco común, experimental y no estandarizado que se basa en el protocolo IP. RoCE v1.5 utiliza el campo de protocolo IP para diferenciar su tráfico de otros protocolos IP como TCP y UDP . El valor utilizado para el número de protocolo no se especifica y se deja a elección de la implementación.

El protocolo RoCE v2 existe sobre el protocolo UDP/IPv4 o el protocolo UDP/IPv6. ^[3] El número de puerto de destino UDP 4791 se ha reservado para RoCE v2. ^[11] Dado que los paquetes RoCEv2 son enrutables, el protocolo RoCE v2 a veces se denomina RoCE enrutable ^[12] o RRoCE. ^[4] Aunque en general no se garantiza el orden de entrega de los paquetes UDP, la especificación RoCEv2 requiere que los paquetes con el mismo puerto de origen UDP y la misma dirección de destino no se reordenen. ^[4] Además, RoCEv2 define un mecanismo de control de congestión que utiliza los bits ECN de IP para marcar y los marcos CNP ^[13] para la notificación de acuse de recibo. ^[14] El soporte de software para RoCE v2 aún está surgiendo ^{[ ¿cuándo? ]} . Mellanox OFED 2.3 o posterior tiene soporte para RoCE v2 y también Linux Kernel v4.5. ^[15]

RoCE define cómo ejecutar RDMA sobre Ethernet , mientras que la especificación de arquitectura InfiniBand define cómo ejecutar RDMA sobre una red InfiniBand. Se esperaba que RoCE incorporara aplicaciones InfiniBand, que se basan predominantemente en clústeres, a una estructura convergente Ethernet común. ^[16] Otros esperaban que InfiniBand siguiera ofreciendo un mayor ancho de banda y una menor latencia de lo que es posible a través de Ethernet. ^[17]

Las diferencias técnicas entre los protocolos RoCE e InfiniBand son:

• Control de flujo a nivel de enlace: InfiniBand utiliza un algoritmo basado en créditos para garantizar una comunicación HCA a HCA sin pérdidas. RoCE se ejecuta sobre Ethernet. Las implementaciones pueden requerir una red Ethernet sin pérdidas para alcanzar características de rendimiento similares a las de InfiniBand. La Ethernet sin pérdidas se configura normalmente a través del control de flujo Ethernet o el control de flujo prioritario (PFC). Configurar una red Ethernet de puente de centro de datos (DCB) puede ser más complejo que configurar una red InfiniBand. ^[18]
• Control de congestión: Infiniband define el control de congestión basado en el marcado FECN/BECN, RoCEv2 define un protocolo de control de congestión que utiliza ECN para el marcado tal como se implementa en conmutadores estándar y tramas CNP para reconocimientos.
• Los conmutadores InfiniBand suelen tener una latencia menor que los conmutadores Ethernet. La latencia de puerto a puerto para un tipo particular de conmutador Ethernet es de 230 ns ^[19] frente a los 100 ns ^[20] de un conmutador InfiniBand con la misma cantidad de puertos.

Mientras que los protocolos RoCE definen cómo realizar RDMA utilizando tramas Ethernet y UDP/IP, el protocolo iWARP define cómo realizar RDMA sobre un transporte orientado a conexión como el Protocolo de Control de Transmisión (TCP). RoCE v1 está limitado a un único dominio de difusión Ethernet . Los paquetes RoCE v2 e iWARP son enrutables. Los requisitos de memoria de una gran cantidad de conexiones junto con los controles de flujo y confiabilidad de TCP conducen a problemas de escalabilidad y rendimiento cuando se utiliza iWARP en centros de datos de gran escala y para aplicaciones de gran escala (es decir, empresas de gran escala, computación en la nube, aplicaciones web 2.0, etc. ^[21] ). Además, la multidifusión se define en la especificación RoCE, mientras que la especificación iWARP actual no define cómo realizar RDMA de multidifusión. ^{[22] [23] [24]}

La confiabilidad en iWARP está dada por el propio protocolo, ya que TCP es confiable. RoCEv2, por otro lado, utiliza UDP , que tiene una sobrecarga mucho menor y un mejor rendimiento, pero no proporciona una confiabilidad inherente, y por lo tanto, la confiabilidad debe implementarse junto con RoCEv2. Una solución es utilizar conmutadores Ethernet convergentes para que la red de área local sea confiable. Esto requiere soporte Ethernet convergente en todos los conmutadores de la red de área local y evita que los paquetes RoCEv2 viajen a través de una red de área amplia como Internet, que no es confiable. Otra solución es agregar confiabilidad al protocolo RoCE (es decir, RoCE confiable), que agrega protocolo de enlace a RoCE para brindar confiabilidad a costa del rendimiento.

La cuestión de qué protocolo es mejor depende del proveedor. Chelsio recomienda y admite exclusivamente iWARP. Mellanox, Xilinx y Broadcom recomiendan y admiten exclusivamente RoCE/RoCEv2. Intel inicialmente admitía iWARP, pero ahora admite tanto iWARP como RoCEv2. ^[25] Otros proveedores involucrados en la industria de redes brindan soporte para ambos protocolos, como Marvell, Microsoft, Linux y Kazan. ^[26] Cisco admite tanto RoCE ^[27] como su propio protocolo VIC RDMA.

Ambos protocolos están estandarizados, siendo iWARP el estándar para RDMA sobre TCP definido por el IETF y RoCE el estándar para RDMA sobre Ethernet definido por la IBTA . ^[26]

Se han omitido algunos aspectos que podrían haberse definido en la especificación RoCE. Estos son:

• Cómo traducir entre los GID primarios de RoCE v1 y las direcciones MAC de Ethernet . ^[28]
• Cómo traducir entre GID secundarios de RoCE v1 y direcciones MAC de Ethernet. No está claro si es posible implementar GID secundarios en el protocolo RoCE v1 sin agregar un protocolo de resolución de direcciones específico de RoCE.
• Cómo implementar VLAN para el protocolo RoCE v1. Las implementaciones actuales de RoCE v1 almacenan el ID de VLAN en el duodécimo y decimotercero byte del GID de dieciséis bytes, aunque la especificación de RoCE v1 no menciona las VLAN en absoluto. ^[29]
• Cómo traducir entre los GID de multidifusión RoCE v1 y las direcciones MAC de Ethernet. Las implementaciones de 2010 utilizaron la misma asignación de direcciones que se especificó para asignar direcciones de multidifusión IPv6 a direcciones MAC de Ethernet. ^{[30] [31]}
• Cómo restringir el tráfico de multidifusión de RoCE v1 a un subconjunto de los puertos de un conmutador Ethernet. A fecha de septiembre de 2013, todavía no se había definido un equivalente del protocolo Multicast Listener Discovery para RoCE v1.

Además, cualquier protocolo que se ejecute sobre IP no puede asumir que la red subyacente tiene un ordenamiento garantizado, como tampoco puede asumir que no puede ocurrir congestión.

Se sabe que el uso de PFC puede provocar un bloqueo en toda la red. ^{[32] [33] [34]}

Algunos proveedores de equipos habilitados para RoCE incluyen:

• Mellanox (adquirida por Nvidia en 2020, ^[35] marca conservada ^[36] )
• Emulex (adquirida por Broadcom )
• Broadcom
• QLogic (adquirida por Cavium y renombrada)
• Cavium (adquirida por Marvell Technology Group y rebautizada como Cavium)
• Huawei
• Tecnología ATTO
• Tecnologías Dell
• Intel
• Base de floración
• Xilinx (a través del núcleo IP de software FPGA )
• Groovf ^[37]
• Cerio ^[38]