IGMP: ¿qué se esconde detrás del Internet group ma­na­ge­me­nt protocol?

A partir del éxito alcanzado por servicios de streaming como Netflix o Spotify, la mu­l­ti­di­fu­sión IP se ha co­n­ve­r­ti­do en un método de tra­n­s­fe­re­n­cia de datos in­di­s­pe­n­sa­ble para Internet y las redes do­mé­s­ti­cas. Este pro­ce­di­mie­n­to técnico permite al emisor enviar flujos de datos dirigidos a grupos de de­s­ti­na­ta­rios completos, lo que permite apro­ve­char de forma óptima estas ca­pa­ci­da­des de tra­n­s­po­r­te y en­ru­ta­mie­n­to. Sin este método de tra­n­s­fe­re­n­cia, el emisor tendría que enviar paquetes de datos por separado a cada di­s­po­si­ti­vo receptor, lo que re­que­ri­ría un enorme ancho de banda y pro­vo­ca­ría una so­bre­ca­r­ga en poco tiempo. Esto haría prá­c­ti­ca­me­n­te imposible mantener la di­s­po­ni­bi­li­dad del servicio de forma duradera.

Un protocolo que desempeña un papel fu­n­da­me­n­tal en la or­ga­ni­za­ción de los me­n­cio­na­dos grupos de re­ce­p­to­res de mu­l­ti­di­fu­sión en redes IPv4 es el Internet group ma­na­ge­me­nt protocol (IGMP).

Internet group ma­na­ge­me­nt protocol es un protocolo de co­mu­ni­ca­ción de la familia TCP/IP que se de­sa­rro­lló en la Uni­ve­r­si­dad de Stanford y se es­pe­ci­fi­có por primera vez en 1989 en los host de ex­te­n­sio­nes RFC 1112. A esta primera versión del protocolo IGMPv1 le siguieron las re­vi­sio­nes IGMPv2 (RFC 2236) y IGMPv3 (RFC 3376; RFC 4604). Cada versión siempre es co­m­pa­ti­ble con las versiones an­te­rio­res y, por lo tanto, un di­s­po­si­ti­vo IGMPv3 también es co­m­pa­ti­ble au­to­má­ti­ca­me­n­te con la versión 1 y 2. Internet group ma­na­ge­me­nt protocol es re­s­po­n­sa­ble úni­ca­me­n­te de las redes IPv4, mientras que en las redes IPv6 se utiliza un protocolo muy parecido, el Multicast Listener Discovery (MLD).

La tarea fu­n­da­me­n­tal del IGMP es gestionar grupos dinámicos para las tra­n­s­mi­sio­nes de mu­l­ti­di­fu­sión IP, aunque esta gestión no se realiza desde el propio di­s­po­si­ti­vo de emisión, sino a través de los routers in­te­gra­dos. Por un lado, estos reciben las so­li­ci­tu­des de inclusión en un grupo de mu­l­ti­di­fu­sión de­te­r­mi­na­do de los di­s­po­si­ti­vos re­ce­p­to­res (o también de los routers su­bo­r­di­na­dos co­rre­s­po­n­die­n­tes). Por otro lado, reenvían los mensajes IGMP a los routers pri­n­ci­pa­les co­rre­s­po­n­die­n­tes cuando reciben paquetes de datos de mu­l­ti­di­fu­sión apro­pia­dos. La estación emisora no recibe ninguna in­fo­r­ma­ción sobre cuáles o cuántas son las es­ta­cio­nes de destino que alcanza un paquete enviado, ya que solamente reenvía un único paquete de datos a los routers pri­n­ci­pa­les.

Como ya hemos comentado, la gestión de los grupos a través del IGMP no es una de las funciones que se en­cue­n­tran dentro del ámbito de re­s­po­n­sa­bi­li­dad del emisor del paquete. Sin embargo, como en todas las es­ta­cio­nes de la red im­pli­ca­das, (incluida la del receptor), este host de salida debe apoyar a las co­ne­xio­nes de mu­l­ti­di­fu­sión. La recepción de las so­li­ci­tu­des de los clientes para su inclusión en un grupo de mu­l­ti­di­fu­sión concreto, así como la no­ti­fi­ca­ción a los clientes en el caso de flujos de datos de mu­l­ti­di­fu­sión entrantes, la realizan los routers de red in­di­vi­dua­les ubicados entre el tra­n­s­mi­sor y el receptor.

Con este fin, el Internet group ma­na­ge­me­nt protocol ofrece, por una parte, funciones que permiten a una estación tra­n­s­mi­ti­r­le al router que tiene asignado que un cliente puede unirse a un grupo de mu­l­ti­di­fu­sión. Por otro lado, habilita a los routers para que recuerden las in­te­r­fa­ces salientes de aquellos di­s­po­si­ti­vos re­ce­p­to­res que deben recibir flujos de datos de mu­l­ti­di­fu­sión IP es­pe­cí­fi­cos para, a co­n­ti­nua­ción, poder enviar no­ti­fi­ca­cio­nes (informes) es­pe­cí­fi­cas en cuanto se reciben los datos co­rre­s­po­n­die­n­tes. Los grupos de mu­l­ti­di­fu­sión se ca­ra­c­te­ri­zan por sus di­re­c­cio­nes es­pe­cí­fi­cas en el rango 224.0.0.x. En la mayoría de los casos, el primer puerto de entrada de un di­s­po­si­ti­vo es el router doméstico que nos pro­po­r­cio­na 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 co­mu­ni­ca­ción termina en el router del tra­n­s­mi­sor de flujo de datos que, a su vez, duplica el paquete IP según sea necesario cuando tiene que tra­n­s­mi­tir a varias in­te­r­fa­ces de salida.

Las tres versiones pu­bli­ca­das del Internet group ma­na­ge­me­nt protocol tienen muchas si­mi­li­tu­des. IGMPv2 y IGMPv3 ampliaron pri­n­ci­pa­l­me­n­te las funciones de su pre­de­ce­sor, mientras que las ca­ra­c­te­rí­s­ti­cas básicas como la dirección de grupo para consultas generales (0.0.0.0) se adoptaron sin cambios. Pero ¿en qué consiste exac­ta­me­n­te cada una de las am­plia­cio­nes?

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 po­si­bi­li­da­des: “1” (para so­li­ci­tu­des de adhesión) y “2” (para no­ti­fi­ca­cio­nes sobre flujos de datos de mu­l­ti­di­fu­sión). Le siguen los bits 8 a 15, que no tienen ninguna función y solo están co­m­pue­s­tos de ceros. El primer bloque de 32 bits termina con una suma de control. Si se trata de un paquete de no­ti­fi­ca­ción IGMP, le seguirá la dirección de grupo de 32 bits. Sin embargo, a las so­li­ci­tu­des 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 uti­li­zar­se para las consultas mu­l­ti­di­fu­sió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 es­pe­ci­fi­car el número de versión. Los códigos de tipos posibles son “0x11” (para so­li­ci­tu­des), “0x16” (para no­ti­fi­ca­cio­nes) y “0x17” (para mensajes de abandono). En cuanto a la co­m­pa­ti­bi­li­dad con versiones an­te­rio­res, también existe el código “0x12” para las no­ti­fi­ca­cio­nes IGMPv1. Los bits de 8 a 15 reciben una función es­pe­cí­fi­ca en IGMPv2 (al menos cuando se trata de so­li­ci­tu­des 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 es­pe­ci­fi­ca la regla de que el router con la dirección IP más baja de la subred se utiliza para las consultas mu­l­ti­di­fu­sión.

Las dos primeras se­cue­n­cias 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 po­si­bi­li­dad de in­te­r­ca­m­biar con versiones de protocolo an­te­rio­res: Para ello, el host tiene a su di­s­po­si­ció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 es­pe­cí­fi­ca de la consulta IGMPv3 cuyos primeros 32 bits tienen la siguiente co­m­po­si­ción:

• Res.: campo de 4 bits reservado que no tiene ninguna función y solo contiene ceros.
• S (Suppress Router-Side Pro­ce­s­si­ng): bandera S, que configura los routers con el valor “1” e indica que deben suprimir las ac­tua­li­za­cio­nes normales cuando reciban una solicitud. Si el valor es “0”, el campo estará inactivo.
• QRV (Querier’s Ro­bu­s­t­ne­ss Variable): 3 bits que pueden incluir el valor “variable de robustez”, que utilizan los host so­li­ci­ta­n­tes.
• QQIC (Querier’s Query Interval Code): campo de 8 bits sobre el que se es­pe­ci­fi­ca el intervalo de so­li­ci­tu­des IGMPv3.
• Número de di­re­c­cio­nes de origen: número de di­re­c­cio­nes de origen que se enumeran a co­n­ti­nua­ción.

A esta in­fo­r­ma­ción tan es­pe­cí­fi­ca le sigue la dirección de origen o un listado de cada una de las di­re­c­cio­nes de origen (de 32 bits cada una), siempre que deban definirse varias fuentes.

A di­fe­re­n­cia de su pre­de­ce­sor, IGMPv3 permite que un host se una a un grupo y abandone otro en una sola tra­n­sac­ción. IGMPv2 necesita para ello dos mensajes separados.

El papel del IGMP está cla­ra­me­n­te definido: el protocolo de co­mu­ni­ca­ción se utiliza siempre en aquellos casos en los que sean ne­ce­sa­rias las tra­n­s­mi­sio­nes de mu­l­ti­di­fu­sión en redes IPv4 como Internet. Algunos ámbitos de uso ha­bi­tua­les son las apli­ca­cio­nes en tiempo real que se ejecutan a través de co­ne­xio­nes mu­l­ti­pu­n­to; un ejemplo de ello pueden ser las he­rra­mie­n­tas para co­n­fe­re­n­cias web o los servicios de streaming en vivo. El objetivo no es servir a cada cliente de forma in­di­vi­dual con el flujo de datos que necesita, ya que esto podría conducir rá­pi­da­me­n­te a una so­bre­ca­r­ga del servidor de origen y de los nodos de red im­pli­ca­dos.