# RDMA sobre Ethernet convergente

RDMA sobre Ethernet convergente (RoCE por sus siglas en inglés) es un protocolo de red que permite el acceso remoto directo a la memoria (RDMA) a través de una red Ethernet. Lo hace encapsulando un paquete de transporte InfiniBand a través de Ethernet. Hay dos versiones de RoCE, RoCE v1 y RoCE v2. RoCE v1 es un protocolo de capa de enlace Ethernet y, por lo tanto, permite la comunicación entre dos hosts en el mismo dominio de difusión Ethernet. RoCE v2 es un protocolo de capa de Internet que significa que los paquetes RoCE v2 pueden enrutarse. 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.

## Antecedentes

Las aplicaciones intensivas en red, como el almacenamiento en red o la informática en clúster, necesitan una infraestructura de red con un ancho de banda alto y una latencia baja. Las ventajas de RDMA sobre otras interfaces de programación de aplicaciones de red como los sockets de Berkeley son menor latencia, menor carga de CPU y mayor ancho de banda. El protocolo RoCE permite latencias más bajas que su predecesor, el protocolo iWARP. Existen HCA RoCE (Adaptador de canal de host) con una latencia tan baja como 1.3 microsegundos mientras que la latencia de HCA iWARP más baja conocida en 2011 fue de 3 microsegundos.

## Versiones
### RoCE v1

El protocolo RoCE v1 es un protocolo de capa de enlace Ethernet con Ethertype 0x8915. 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 jumbo.

### RoCE v1.5

El RoCE v1.5 es un protocolo poco común, experimental y no estandarizado que se basa en el protocolo IP. RoCE v1.5 usa 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 está especificado y se deja a la implementación para que lo seleccione.

### RoCE v2

El protocolo RoCE v2 existe sobre el protocolo UDP/IPv4 o UDP/IPv6. El número de puerto de destino UDP 4791 se ha reservado para RoCE v2. Dado que los paquetes RoCEv2 son enrutables, el protocolo RoCE v2 a veces se denomina RoCE enrutable o RRoCE. Aunque en general el orden de entrega de los paquetes UDP no está garantizado, la especificación RoCEv2 requiere que los paquetes con el mismo puerto de origen UDP y la misma dirección de destino no se deben reordenar. Además, RoCEv2 define un mecanismo de control de congestión que utiliza los bits IP ECN para marcar y las tramas CNP para la notificación de acuse de recibo. El soporte de software para RoCE v2 todavía está surgiendo. Mellanox OFED 2.3 o posterior tiene soporte RoCE v2 y también Linux Kernel v4.5.

## RoCE versus InfiniBand

RoCE define cómo realizar RDMA a través de Ethernet, mientras que la especificación de arquitectura InfiniBand define cómo realizar RDMA a través de una red InfiniBand. Se esperaba que RoCE trajera aplicaciones InfiniBand, que se basan predominantemente en clústeres, en una estructura convergente Ethernet común. Otros esperaban que InfiniBand siguiera ofreciendo un mayor ancho de banda y una latencia más baja de lo que es posible a través de Ethernet.
Las diferencias técnicas entre los protocolos RoCE e InfiniBand son:
* Control de flujo de nivel de enlace: InfiniBand utiliza un algoritmo basado en el crédito 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érdida para alcanzar características de rendimiento similares a InfiniBand, la Ethernet sin pérdida generalmente se configura mediante control de flujo de Ethernet o 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.
* 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 implementado en interruptores estándar y tramas CNP para acuses de recibo.
* Los conmutadores InfiniBand disponibles siempre han tenido una latencia menor que los conmutadores Ethernet. La latencia de puerto a puerto para un tipo particular de conmutador Ethernet es 230 ns versus 100 ns para un conmutador InfiniBand con el mismo número de puertos.

## RoCE versus iWARP

Mientras que los protocolos RoCE definen cómo realizar RDMA usando tramas Ethernet y UDP/IP, el protocolo iWARP define cómo realizar RDMA a través de un transporte orientado a la conexión como el Protocolo de Control de Transmisión (TCP). RoCE v1 está limitado a un solo 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 al usar iWARP en centros de datos a gran escala y para aplicaciones a gran escala (es decir, empresas a gran escala, computación en la nube, aplicaciones web 2.0, etc.). 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 multidifusión.
La confiabilidad en iWARP viene dada por el protocolo en sí, ya que TCP es confiable. RoCEv2, por otro lado, utiliza UDP, que tiene una sobrecarga mucho menor y un mejor rendimiento, pero no proporciona confiabilidad inherente, y por lo tanto, la confiabilidad debe implementarse junto con RoCEv2. Una solución es utilizar conmutadores Ethernet convergentes para hacer que la red de área local sea confiable. Esto requiere soporte convergente de Ethernet en todos los conmutadores en la red de área local y evita que los paquetes RoCEv2 viajen a través de una red de área amplia como Internet, lo cual no es confiable. Otra solución es agregar confiabilidad al protocolo RoCE (es decir, RoCE confiable) que agrega handshake a RoCE para proporcionar confiabilidad a costa del rendimiento.
La cuestión de qué protocolo es mejor depende del proveedor. Intel y Chelsio recomiendan y apoyan exclusivamente iWARP. Mellanox, Xilinx y Broadcom recomiendan y admiten exclusivamente RoCE/RoCEv2. Otros proveedores involucrados en la industria de la red brindan soporte para ambos protocolos, como Marvell, Microsoft, Linux y Kazan. Cisco admite tanto RoCE como su propio protocolo VIC RDMA.
Ambos protocolos están estandarizados con iWARP como el estándar para RDMA sobre TCP definido por el IETF y RoCE como el estándar para RDMA sobre Ethernet definido por el IBTA.

## Críticas

Algunos aspectos que podrían haberse definido en la especificación RoCE se han omitido. Estos son:
* Cómo traducir entre los GID principales de RoCE v1 y las direcciones MAC de Ethernet.
* 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 la ID de VLAN en el duodécimo y decimotercer byte del GID de dieciséis bytes, aunque la especificación RoCE v1 no menciona las VLAN en absoluto.
* Cómo traducir entre GCE multidifusión RoCE v1 y direcciones MAC Ethernet. Las implementaciones en 2010 utilizaron la misma asignación de direcciones que se ha especificado para asignar direcciones de multidifusión IPv6 a direcciones MAC de Ethernet.
* Cómo restringir el tráfico de multidifusión RoCE v1 a un subconjunto de los puertos de un conmutador Ethernet. A partir de septiembre de 2013, aún no se ha definido un equivalente del protocolo Multicast Listener Discovery para RoCE v1.
Además, cualquier protocolo que se ejecute a través de IP no puede asumir que la red subyacente ha garantizado el pedido, como tampoco puede suceder que se produzca congestión.
Se sabe que el uso de PFC puede conducir a un punto muerto en toda la red.

## Vendedores

Los vendedores populares de equipos habilitados para RoCE incluyen:
* Mellanox (adquirido por Nvidia, marca retenida)
* Emulex (adquirido por Broadcom)
* Broadcom
* QLogic (adquirido por Cavium, renombrado)
* Cavium (adquirido por Marvell Technology Group, renombrado)
* Huawei
* ATTO Technology