IGMP: ¿qué se esconde detrás del Internet group management protocol?

A partir del éxito alcanzado por servicios de streaming como Netflix o Spotify, la multidifusión IP se ha convertido en un método de transferencia de datos indispensable para Internet y las redes domésticas. Este procedimiento técnico permite al emisor enviar flujos de datos dirigidos a grupos de destinatarios completos, lo que permite aprovechar de forma óptima estas capacidades de transporte y enrutamiento. Sin este método de transferencia, el emisor tendría que enviar paquetes de datos por separado a cada dispositivo receptor, lo que requeriría un enorme ancho de banda y provocaría una sobrecarga en poco tiempo. Esto haría prácticamente imposible mantener la disponibilidad del servicio de forma duradera.

Un protocolo que desempeña un papel fundamental en la organización de los mencionados grupos de receptores de multidifusión en redes IPv4 es el Internet group management protocol (IGMP).

Internet group management protocol es un protocolo de comunicación de la familia TCP/IP que se desarrolló en la Universidad de Stanford y se especificó por primera vez en 1989 en los host de extensiones RFC 1112. A esta primera versión del protocolo IGMPv1 le siguieron las revisiones IGMPv2 (RFC 2236) y IGMPv3 (RFC 3376; RFC 4604). Cada versión siempre es compatible con las versiones anteriores y, por lo tanto, un dispositivo IGMPv3 también es compatible automáticamente con la versión 1 y 2. Internet group management protocol es responsable únicamente de las redes IPv4, mientras que en las redes IPv6 se utiliza un protocolo muy parecido, el Multicast Listener Discovery (MLD).

La tarea fundamental del IGMP es gestionar grupos dinámicos para las transmisiones de multidifusión IP, aunque esta gestión no se realiza desde el propio dispositivo de emisión, sino a través de los routers integrados. Por un lado, estos reciben las solicitudes de inclusión en un grupo de multidifusión determinado de los dispositivos receptores (o también de los routers subordinados correspondientes). Por otro lado, reenvían los mensajes IGMP a los routers principales correspondientes cuando reciben paquetes de datos de multidifusión apropiados. La estación emisora no recibe ninguna información sobre cuáles o cuántas son las estaciones de destino que alcanza un paquete enviado, ya que solamente reenvía un único paquete de datos a los routers principales.

Como ya hemos comentado, la gestión de los grupos a través del IGMP no es una de las funciones que se encuentran dentro del ámbito de responsabilidad del emisor del paquete. Sin embargo, como en todas las estaciones de la red implicadas, (incluida la del receptor), este host de salida debe apoyar a las conexiones de multidifusión. La recepción de las solicitudes de los clientes para su inclusión en un grupo de multidifusión concreto, así como la notificación a los clientes en el caso de flujos de datos de multidifusión entrantes, la realizan los routers de red individuales ubicados entre el transmisor y el receptor.

Con este fin, el Internet group management protocol ofrece, por una parte, funciones que permiten a una estación transmitirle al router que tiene asignado que un cliente puede unirse a un grupo de multidifusión. Por otro lado, habilita a los routers para que recuerden las interfaces salientes de aquellos dispositivos receptores que deben recibir flujos de datos de multidifusión IP específicos para, a continuación, poder enviar notificaciones (informes) específicas en cuanto se reciben los datos correspondientes. Los grupos de multidifusión se caracterizan por sus direcciones específicas en el rango 224.0.0.x. En la mayoría de los casos, el primer puerto de entrada de un dispositivo es el router doméstico que nos proporciona acceso a Internet, recibe la solicitud de adhesión y la transmite al siguiente nodo de la red, que suele ser el router del proveedor de servicios de Internet. Esta cadena de comunicación termina en el router del transmisor de flujo de datos que, a su vez, duplica el paquete IP según sea necesario cuando tiene que transmitir a varias interfaces de salida.

Las tres versiones publicadas del Internet group management protocol tienen muchas similitudes. IGMPv2 y IGMPv3 ampliaron principalmente las funciones de su predecesor, mientras que las características básicas como la dirección de grupo para consultas generales (0.0.0.0) se adoptaron sin cambios. Pero ¿en qué consiste exactamente cada una de las ampliaciones?

La cabecera IGMP tiene una longitud total de 64 bits. Los primeros 8 bits siempre indican, en primer lugar, la versión de protocolo IGMPv1, así como el tipo de mensaje. Para este campo (tipo) existen dos posibilidades: “1” (para solicitudes de adhesión) y “2” (para notificaciones sobre flujos de datos de multidifusión). Le siguen los bits 8 a 15, que no tienen ninguna función y solo están compuestos de ceros. El primer bloque de 32 bits termina con una suma de control. Si se trata de un paquete de notificación IGMP, le seguirá la dirección de grupo de 32 bits. Sin embargo, a las solicitudes de adhesión va unida una sección que solo contiene ceros (dirección de grupo 0.0.0.0).

La versión original de la línea del protocolo no determina en sí misma qué router debe utilizarse para las consultas multidifusión (regulado por el Multicast Routing Protocol).

La línea de la cabecera tiene un comienzo similar al de primera versión del protocolo, sin especificar el número de versión. Los códigos de tipos posibles son “0x11” (para solicitudes), “0x16” (para notificaciones) y “0x17” (para mensajes de abandono). En cuanto a la compatibilidad con versiones anteriores, también existe el código “0x12” para las notificaciones IGMPv1. Los bits de 8 a 15 reciben una función específica en IGMPv2 (al menos cuando se trata de solicitudes de adhesión) y definen el tiempo de respuesta máximo admisible. A ello le sigue la suma de control (16 bits) y la dirección de grupo (32 bits) que, a su vez, tiene la forma típica de protocolo 0.0.0.0 para consultas generales.

IGMPv2 especifica la regla de que el router con la dirección IP más baja de la subred se utiliza para las consultas multidifusión.

Las dos primeras secuencias de 32 bits son idénticas a las de la cabecera IGMPv2: tipo, tiempo de respuesta máximo, suma de control y dirección de grupo. IGMPv3 también ofrece, en este punto, la posibilidad de intercambiar con versiones de protocolo anteriores: Para ello, el host tiene a su disposición el código “0x12” para la versión 1 y el “0x16” para la versión 2. Después de la dirección de grupo comienza la parte de la cabecera específica de la consulta IGMPv3 cuyos primeros 32 bits tienen la siguiente composición:

• Res.: campo de 4 bits reservado que no tiene ninguna función y solo contiene ceros.
• S (Suppress Router-Side Processing): bandera S, que configura los routers con el valor “1” e indica que deben suprimir las actualizaciones normales cuando reciban una solicitud. Si el valor es “0”, el campo estará inactivo.
• QRV (Querier’s Robustness Variable): 3 bits que pueden incluir el valor “variable de robustez”, que utilizan los host solicitantes.
• QQIC (Querier’s Query Interval Code): campo de 8 bits sobre el que se especifica el intervalo de solicitudes IGMPv3.
• Número de direcciones de origen: número de direcciones de origen que se enumeran a continuación.

A esta información tan específica le sigue la dirección de origen o un listado de cada una de las direcciones de origen (de 32 bits cada una), siempre que deban definirse varias fuentes.

A diferencia de su predecesor, IGMPv3 permite que un host se una a un grupo y abandone otro en una sola transacción. IGMPv2 necesita para ello dos mensajes separados.

El papel del IGMP está claramente definido: el protocolo de comunicación se utiliza siempre en aquellos casos en los que sean necesarias las transmisiones de multidifusión en redes IPv4 como Internet. Algunos ámbitos de uso habituales son las aplicaciones en tiempo real que se ejecutan a través de conexiones multipunto; un ejemplo de ello pueden ser las herramientas para conferencias web o los servicios de streaming en vivo. El objetivo no es servir a cada cliente de forma individual con el flujo de datos que necesita, ya que esto podría conducir rápidamente a una sobrecarga del servidor de origen y de los nodos de red implicados.