Resumen

  • La RFC 1112 hizo visible la pertenencia multicast mediante consultas e informes locales, pero la espera aleatoria permitía que el mensaje de un host representara al grupo sin enumerar sus miembros.
  • IGMPv1 no tenía mensaje de salida: el router solo detectaba que se había marchado el último receptor cuando cesaban los informes y vencía el estado. La RFC 2236 añadió después una señal de salida más rápida.

Una dirección de grupo no era una lista de invitados

Una dirección IP multicast podía ser permanente aunque no hubiera ningún host perteneciente al grupo. Un host también podía enviar datagramas a un grupo sin unirse a él. En la RFC 1112, Stephen Deering separó esos hechos: la dirección nombraba al grupo, mientras que la pertenencia se mantenía por host e interfaz de red. Una aplicación podía pedir a IP que se uniera o saliera; al router vecino le interesaba otra cuestión: si en esa red local seguía habiendo alguien interesado.

La norma describía dos niveles de soporte. Un host de Nivel 1 podía enviar multicast, pero no se unía a grupos ni implementaba IGMP. El Nivel 2 añadía la pertenencia y el protocolo para informar al router multicast vecino. Por eso la dirección, por sí sola, no decía quién recibiría los paquetes. Hacía falta una señal reciente del segmento local.

Por qué el primer informe no llegaba solo

Cuando el router enviaba una Host Membership Query a la dirección de todos los hosts 224.0.0.1, cada equipo de Nivel 2 revisaba sus grupos en esa interfaz. Si todos respondían de inmediato, el enlace recibiría una ráfaga de paquetes de control duplicados. La RFC 1112 asignaba a cada pertenencia un temporizador aleatorio. Si un host oía antes un informe válido del mismo grupo, cancelaba el suyo. Así, una sola respuesta podía indicar que al menos un miembro seguía presente.

Era una compresión deliberada de la evidencia. El router no recibía un recuento, una lista de máquinas ni prueba de que cada aplicación estuviera lista para consumir el tráfico. Recibía una indicación de presencia del grupo en una red local. Se reducían mensajes redundantes, pero también se descartaba información que el reenvío no necesitaba.

La entrada a un grupo nuevo seguía otra regla. El host debía informar enseguida, pues quizá fuese el primer miembro de esa red. Se recomendaba repetir el informe una o dos veces para cubrir la pérdida del primero. Aun así, el multicast ofrecía solo el mismo servicio best effort que IP unicast: no garantizaba que todos recibieran un datagrama íntegro ni en el mismo orden. La señal de pertenencia informaba al router, no aseguraba la entrega.

El silencio tras el último receptor

IGMPv1 definió consultas e informes, pero ningún mensaje Leave Group. Cuando un host salía, su módulo IP dejaba de considerarlo miembro; el router no recibía un aviso inmediato. Las consultas periódicas renovaban la información. Si nadie volvía a informar del grupo, el temporizador de pertenencia del router acababa venciendo. La sencillez del protocolo dejaba el estado activo durante un tiempo después de que se fuera el último receptor.

No era una creencia permanente: el retraso quedaba limitado por los temporizadores de consulta y pertenencia. Pero para un grupo de alto caudal o una red con cambios frecuentes, los paquetes podían seguir reenviándose a un segmento sin receptores hasta que venciera el estado.

La RFC 2236 incorporó a IGMPv2 un mensaje Leave Group para avisar antes. El router consultante enviaba después consultas específicas al grupo y esperaba una respuesta antes de declarar vacío el segmento. El cambio no convirtió el silencio en certeza: acortó el periodo de incertidumbre y buscó si aún quedaba otro receptor.

El compromiso de 1989 es concreto. IGMPv1 redujo tráfico de control al convertir la pertenencia en una pregunta de presencia. Un informe podía silenciar a sus vecinos y aun así dar al router lo suficiente para decidir si reenviaba tráfico al grupo en esa red. Lo que no podía revelar era cuántos miembros había detrás de aquel informe ni el instante en que se marchaba el último.

Fuentes