Está en la página 1de 59

MULTICAST

Multicasting
Direcciones que se refieren a grupos de hosts sobre una o ms redes. Usos:
Multimedia Teleconferencia Base de datos Computacin distribuida

Ejemplo Config

Broadcast y Unicast Multiple


Broadcast
Se enva una copia de un paquete a cada red. Requiere 13 copias del paquete.

Unicast multiple
Se enva paquetes slo a redes que tienen hosts en el grupo. Requiere 11 paquetes.

Verdadero Multicast
Determina camino de costo mnimo a cada red que tiene host en el grupo.
Esto resulta en un spanning tree conteniendo redes con miembros del grupo.

Se transmite un simple paquete a lo largo del spanning tree. Routers repiten paquetes en los puntos de ramificacin del spanning tree. Requiere 8 paquetes.

Ejemplo de Multicast

Direccionamiento Multicast
Las comunicaciones multicast tienen la necesidad de enviar el mismo contenido a mltiples destinos simultneamente.
El grupo, o grupos, de receptores son generalmente dinmicos y la velocidad con la que varan puede ser alta.

Existe el deseo en los ambientes multicast de tener control distribuido sobre los grupos de usuarios. Es decir, la fuente no debe saber la direccin de cada receptor individualmente, lo que requerira mantener grandes tablas de usuarios centralizadas.
Es por eso es que necesita un mecanismo que nos permita hacer esta distribucin de manera eficiente. Para esto, se utilizan direcciones IP multicast y direcciones MAC multicast.

Direcciones IP Multicast
Direcciones IP clase D son usadas en las direcciones de destino para paquetes multicast desde 224.0.0.0 a 239.255.255.255. No pueden aparecer direcciones clase D en los campos de direccin de origen de los paquetes IP.

Direcciones IP Multicast
En las transmisiones tipo unicast, un paquete es transmitido hop por hop de la direccin fuente a la direccin de destino. En un ambiente IP multicast, un paquete tiene ms que una direccin de destino, un grupo de direcciones de destino.
Todos los receptores de la informacin son agregados a un grupo. Cuando un receptor se une al grupo, los datos para este grupo de direcciones empiezan a fluir hasta este receptor. Todos los miembros en el grupo pueden recibir el paquete. La membreca es dinmica y un receptor puede unirse o dejar el grupo en cualquier momento.

Un grupo multicast puede ser permanente o temporario.


Hay direcciones oficialmente asignadas para los grupos permanentes y otras para los grupos temporarios. Las direcciones para los grupos permanentes son fijas pero la cantidad de miembros es arbitraria, es bastante probable que un grupo permanente no tenga ningn miembro.

Direcciones IP Multicast
Las direcciones en el rango 224.0.0.0 224.0.0.255 estn reservadas para protocolos de red sobre un segmento de red local. Se usan para descubrimiento de router automtico y para comunicar informacin de ruteo. Datagramas IP con estas direcciones no son reenviados por un router, tienen un TTL =1, se conocen como link-local addresses. Algunas link-local addresses son las siguientes:

Direcciones IP Multicast
Las direcciones en el rango 224.0.1.0 238.255.255.255 se conocen como globally scoped addresses. Se usan para transmitir informacin multicast a travs de la Internet y entre organizaciones.
Ejemplos de rangos de globally scoped addresses son:

Direcciones IP Multicast
A un nivel ms granular, ejemplos de globally scoped addresses son:

Direcciones IP Multicast
Las direcciones en el rango 239.0.0.0239.255.255.255 se llaman limited scope addresses ( administratively scoped addresses). RFC 2365 define que estas direcciones estn limitadas a un grupo local u organizacin.
Se requiere configurar los routers con filtros de paquetes para evitar que el trfico multicast en este rango de direcciones salga de un AS.

Son localmente asignadas y por lo tanto no se requiere que sean nicas a travs de lmites administrativos.
Esto permite reuso de direcciones y tambin provee la capacidad para que la infraestructura de servicios (tales como address allocation, session advertisement, service location) usen well-known addresses con significado local dentro de cada organizacin.

Direcciones Multicast Layer 2


Durante operacin normal como se defini en la especificacin LAN IEEE 802.3, una Network Interface Card (NIC) acepta slo tramas destinadas para esa tarjeta definida por la direccin MAC destino bien la direccin MAC broadcast (0xFFFF.FFFF.FFFF). Se debe definir algn mecanismo para que mltiples hosts puedan recibir el mismo paquete y adems sean capaces de diferenciar entre grupos multicast. En el standard IEEE 802.3, el bit 0 del primer octeto se usa para indicar una trama broadcast y/o multicast, como se muestra en la figura siguiente.

Direcciones Multicast Layer 2

Direcciones Multicast Layer 2


La IANA decidi reservar la mitad del bloque de direcciones MAC Ethernet 0100.5E00.0000 para alocar direcciones multicast IP, es decir, se usa: 0100.5E00.0000 0100.5E7F.FFFF Con este mtodo 23 bits de la direccin Ethernet se hacen corresponder a la direccin de grupo multicast IP, en verdad, a los 23 bits ms bajos de la direccin multicast IP. Sin embargo, debido a que los cinco bits ms altos se pierden, la direccin resultante no es nica: 32 diferentes IDs de grupos multicast se mapean en la misma direccin Ethernet. Esto se debe tener en cuenta cuando se disea un sistema.

Mapeo de direcciones IP Multicast a MAC Ethernet

Multicast sobre un segmento de LAN


Multicast sobre la subred local no requiere un router multicast o el uso de un algoritmo de ruteo multicast. Sobre una subred de medio compartido un host fuente, que no necesariamente debe ser un miembro del grupo, transmite un paquete de datos multicast.
El proceso destino informa a sus drivers de dispositivos de red que desea recibir datagramas destinados para una dada direccin multicast IP. El driver del dispositivo habilita recepcin de paquetes para esa direccin multicast IP. Debido al mapeo no nico de direcciones IP a Ethernet se requiere filtrado por el driver del dispositivo. Esto se realiza chequeando la direccin destino en el header IP antes de pasar el paquete al layer IP. Hosts que no estn participando en un grupo de hosts no escuchan direcciones multicast, por lo tanto paquetes multicast se filtran por el hardware de la interface de red de capa ms baja.

Multicast sobre un segmento de LAN

Multicast entre segmentos de red


Cuando el multicast se extiende ms all de la subred local, la subred debe estar conectada a un router con capacidad multicast, que a su vez est conectado con otros routers con capacidad multicast. Esto requiere 3 mecanismos: 1) La habilidad de construir rboles de distribucin, 2) La presencia de un protocolo de ruteo multicast (ej. PIM) y 3) La presencia de un protocolo de gestin de grupos en los bordes que permita al router/s multicast de la subred monitorear la presencia de miembros de grupos sobre sus enlaces directamente conectados.

Multicast entre segmentos de red


Se ha desarrollado protocolos de ruteo multicast para transmitir paquetes a travs de una red ruteada y al mismo tiempo para evitar lazos de ruteo. Hay 2 funciones requeridas para soportar transmisin multicast a travs de una red ruteada:
Determinar participantes multicast: una capacidad para determinar si datagramas multicast necesitan ser enviados sobre una red especfica. El protocolo IGMP soporta esta capacidad. Determinar el mbito del multicast: el campo TTL de un datagrama multicast se usa para determinar el mbito de una transmisin.

Multicast entre segmentos de red


Cuando un host o router con capacidad multicast recibe un datagrama, el procesamiento del mismo depende de la direccin IP destino y del valor del TTL:
Si TTL = 0, el datagrama est restringido al host fuente. Si TTL = 1, el datagrama alcanza todos los hosts sobre la subred que son miembros del grupo. Si TTL > 1, el datagrama alcanza todos los hosts sobre la subred que son miembros del grupo. La accin realizada por los routers multicast depende de la direccin del grupo, como sigue:
Direcciones en el bloque 224.0.0.0 224.0.0.255: routers multicast no reenvan datagramas con direcciones destino en este rango debido a que est destinado para aplicaciones multicast de un solo salto. Sin embargo, un host debe reportar membresa en un grupo dentro de este rango, el reporte se usa para informar a otros hosts sobre la subred que el host que se reporta es un miembro del grupo. Direcciones fuera del bloque 224.0.0.0 224.0.0.255: estos datagramas son reenviados por el router con capacidad multicast pero el valor del TTL es decrementado por uno cada vez.

rboles de distribucin multicast


Routers con capacidad multicast crean rboles de distribucin lgicos que controlan el camino que toma el trfico multicast IP. Los diferentes algoritmos multicast (PIM, DVMRP, etc.) usan tcnicas diferentes para establecer el rbol de distribucin.
Se pueden clasificar en algoritmos de rbol basado en fuente (rboles fuente Shortest Path Trees (SPT)) y algoritmos de rbol compartido.

Un rbol fuente tiene su raz en la fuente multicast y tiene ramas formando un spanning tree sobre la red a los receptores. Hace uso del camino ms corto a travs de la red y as puede existir un SPT separado para cada fuente individual que enva a ese grupo.

rbol fuente SPT


Se usa la notacin (S,G) donde S es la direccin IP de la fuente y G es la direccin del grupo multicast. En el ejemplo de la figura el SPT es (92.1.1.1, 239.1.1.1).

rbol fuente SPT


SPT alcanza, por definicin, el camino ptimo entre la fuente y los receptores en trminos del nmero de hops, resultando en mnima latencia de red para distribuir trfico multicast. Pero, los routers con capacidad multicast deben mantener informacin de path para cada fuente.
En redes grandes, ya sea con muchas fuentes y/ muchos grupos, esta informacin de estado puede saturar los recursos de memoria de los routers necesarios para almacenar la tabla de ruteo multicast.

La siguiente figura muestra un ejemplo simple de IPTV: el SPT se emplea para distribuir video a usuarios remotos. La siguiente figura muestra la poda en tiempo real que ocurre.

rbol fuente SPT

rbol fuente SPT

rboles compartidos
rboles compartidos usan una nica raz comn colocada en un punto seleccionado de la red. Esta raz compartida se llama Rendezvous Point (RP) (tambin llamada core o centro). La siguiente figura muestra un rbol compartido para el grupo 239.1.1.1 y la raz compartida. Cuando se utilizan rboles compartidos, las fuentes envan su trfico a la raz (RP) y luego el trfico es reenviado a lo largo del rbol compartido para alcanzar a todos los receptores activos. Todas las fuentes en el grupo multicast usan el mismo rbol compartido. Se usa la notacin (*,G) para representar el rbol. Para el caso de la figura, el rbol compartido es (*, 239.1.1.1).

rboles compartidos

rboles compartidos
rboles compartidos requieren la cantidad mnima de informacin de estado en cada router, minimizando as los requerimientos de memoria para los routers y los mecanismos para mantener la informacin de estado actualizada. Pero los caminos entre la fuente y los receptores pueden no ser los ptimos en trminos de hops y, por lo tanto, de latencia. rboles multicast basados en fuente se construyen por un algoritmo basado en vector distancia, que puede ser implementado separadamente del algoritmo de ruteo unicast (ej. DVMRP) o el rbol multicast puede ser construido usando la informacin presente en la tabla de ruteo unicast (ej. PIM DM). El otro algoritmo es el algoritmo link-state (ej. M-OSPF).

Dense-mode y Sparse-mode
La mayora de los algoritmos multicast de rbol basado en fuente son tpicamente referidos como algoritmos dense-mode.
Asumen que la poblacin de receptores densamente puebla el dominio de operacin y por lo tanto el overhead que acompaa los algoritmos (en trminos de estado, uso de ancho de banda y/ costos de procesamiento) es aceptable. Esto tiende a ser el caso en un entorno local y para varias aplicaciones de rea amplia como IPTV y DVB-H.

Para otras aplicaciones (ej. computacin en red, datacasting), los miembros del grupo tienden a estar distribuidos dispersamente a travs de la red institucional, red de transporte o Internet y es conveniente usar rboles compartidos.

Escalabilidad
Una arquitectura de rbol compartido ofrece un mejoramiento en escalabilidad sobre arquitecturas de rbol fuente por un factor del nmero de fuentes activas.
rboles fuente escalan: O(SxG) rbol compartido escala: O(G)

Esto implica que aplicaciones con muchos emisores activos, tales como simulacin interactiva distribuida y juegos de video distribuidos (donde la mayora de receptores son tambin emisores), tienen significativamente menos impacto sobre ruteo multicast si se usan rboles compartidos.

Algoritmos de ruteo multicast


El objetivo de los algoritmos de ruteo multicast es lograr lo siguiente:
Reenviar informacin slo a miembros del grupo. Optimizar el camino de fuente a destinos en trminos del nmero de hops y ancho de banda usado sobre cada hop. Establecer y mantener rutas libres de lazos. Proveer mecanismos de escalabilidad en trminos del nmero de receptores y grupos.

Se han desarrollado varios algoritmos, los cuales se utilizan en los protocolos de ruteo multicast. Un algoritmo es Reverse path forwarding (RPF).

Reverse path forwarding


El mtodo bsico en ruteo multicast es reenviar el trfico multicast lejos de la fuente, este mtodo se llama Reverse Path Forwarding (RPF). RPF permite a routers con capacidad multicast reenviar correctamente trfico multicast a lo largo del rbol de distribucin y evitar lazos. Un router con capacidad multicast debe realizar un seguimiento de la direccin en que est la fuente (upstream) y la/s direccin/es hacia el receptor (downstream). Un router con capacidad multicast slo reenva un paquete multicast si lo recibe sobre la interface upstream. Cuando hay mltiples caminos downstream, el router replica el paquete y lo reenva sobre dichos caminos.

Reverse path forwarding


RPF emplea la tabla de ruteo y cuando arriba un paquete multicast, el router har un chequeo RPF sobre la direccin fuente del paquete para determinar si ha sido recibido sobre la interface upstream:
Se acepta un paquete de fuente S va vecino N slo si N es el vecino que se elegira para alcanzar a S. Si el chequeo es satisfactorio se reenva el paquete, sino se lo descarta.

Un mejoramiento introducido por Dalal y Metcalfe consiste en:


Router R averigua cules de sus vecinos envan el trfico a S a travs de R y entonces R reenva los paquetes de S slo a esos vecinos.

Ejemplos de chequeos RPF

IGMP (INTERNET GROUP MANAGEMENT PROTOCOL)


IGMP es utilizado como protocolo para el registro de un host con su router local, especificando que se incorpora a un determinado grupo IP Multicast y as comenzar a recibir trfico destinado a ese grupo. Los hosts informan su pertenencia al grupo enviando mensajes IGMP al router IP Multicast local. Los routers peridicamente envan mensajes preguntando si los miembros del grupo se encuentran activos o inactivos. Utilizando la informacin obtenida a travs de los mensajes IGMP, los routers mantienen una lista con los grupos IP Multicast junto con la informacin de la interface por la cual se los alcanza.

IGMP
IGMPv2, ampliamente utilizado, est definido en RFC 2236 (Nov. 1997). IGMP3, definida en RFC 3376 (Oct. 2002), soporta que los receptores explcitamente sealen fuentes de las cules ellas desean recibir trfico. Se emplea por hosts para sealar acceso a canales en SSM.
Para que SSM funcione, IGMPv3 debe estar disponible en routers de ltimo salto y en el stack de red del sistema operativo. Los beneficios de SSM incluyen: Utilizacin de ancho de banda de acceso optimizado. Reduccin de riesgos: elimina ataques de denegacin de servicio (DoS) de fuentes desconocidas.

IGMPv1
Definido en RFC 1112. Los mensajes IGMP son trasmitidos dentro de los datagramas IP y estn denotados por el nmero 2 dentro del campo Protocol Type del paquete IP. Son transmitidos con el campo TTL=1 y no son reenviados por los routers fuera del ambiente LAN. El formato del mensaje IGMPv1 es:

Existen slo dos tipos de mensajes: Type=1: Membership Query (MQ), y Type=2: Membership Report

(MR)

IGMPv1
Los hosts envan un mensaje Membership Report indicando que estn interesados en unirse a un grupo en particular indicado en Group Address.
La direccin IP destino del datagrama es la direccin del grupo.

El router enva peridicamente mensajes Membership Query (con Group Address igual a cero) con la finalidad de averiguar si existe al menos un host en algn grupo IP Multicast interesado en recibir el trfico destinado al grupo.
La direccin IP destino del datagrama es el grupo all hosts: 224.0.0.1 Cuando no recibe respuesta a tres mensajes IGMP consecutivos, el router dejar de enviar trfico IP Multicast a ese grupo particular.

IGMPv1
REPORT SUPRESION MECHANISM: este mecanismo ayuda a reducir la cantidad de trfico IGMP en una determinada red LAN al mnimo necesario. A continuacin se detalla el funcionamiento de este mecanismo: 1) Cuando un host recibe un mensaje IGMP Membership Query, ste inicializa un Timer por cada grupo IP Multicast al cual pertenece. Cada Timer es inicializado con un valor entre 0 y el mximo tiempo de respuesta. El valor por default es de 10 segundos. 2) Cuando el Timer llega a su fin, el host enva un mensaje IP Multicast IGMP Membership Report asociado al grupo IP Multicast activo con el Timer de referencia. 3) Si un host escucha a otro host enviando un mensaje IGMP Membership Report, cancela el Timer asociado a este grupo y deja de enviar mensajes IGMP Membership Report a dicho grupo.

IGMPv1
IGMPV1 QUERIER
La RFC 1112 no especifica cmo debe ser elegido el IGMP Querier, de esta manera un router dentro de un ambiente LAN sera el responsable por el envo de los mensajes IGMP Queries. IGMPv1 deja esta tarea para ser resuelta en la capa 3, capa IP, por el protocolo de ruteo IP Multicast utilizado.

IGMPV1 JOIN PROCESS


Para reducir la latencia producida por la asociacin a un grupo IP Multicast (Join Process), no es necesario esperar el envo, por parte del router, del siguiente mensaje Membership Query antes que un host enve el correspondiente mensaje Membership Report para unirse a un determinado grupo IP Multicast. As se reduce la latencia asociada a este proceso.

IGMPv2
Esta versin funciona bsicamente en forma idntica a la versin 1, la diferencia principal radica en el mensaje Leave Group.
As los hosts comunican activamente al router IP multicast local que estn dejando el grupo. Entonces dicho router enva un mensaje Membership Query especfico a ese grupo IP multicast, preguntando si existe algn host del grupo interesado en seguir recibiendo trfico IP multicast. Si no recibe respuesta, dejar de enviar trfico IP multicast hacia el grupo. Esta funcionalidad reduce el trfico de control generado en la versin 1.

Los mensajes de Query Membership y Report Membership son idnticos a los mensajes de IGMPv1 con dos excepciones. Una diferencia es que en IGMPv2 los mensajes de Query Membership se dividen en dos categoras:

IGMPv2
General Queries: anlogo al definido en IGMPv1. Group-Specific Queries: son dirigidos a un grupo en particular.

La segunda diferencia radica que el hecho de que los mensajes Membership Report en IGMPv2 tienen un tipo de cdigo diferente al de IGMPv1.

Formato del mensaje IGMPv2:

Mejoras de IGMPv2 con respecto a IGMPv1


Querier Election Process
Provee la posibilidad de que los routers elijan al Querier Router sin tener que depender del protocolo de ruteo IP multicast para realizar este proceso.

Tiempo de Respuesta Mximo


Permite al Querier Router especificar el mximo tiempo de respuesta, permitiendo controlar la latencia producida por el proceso de dejar un grupo y el burtiness producido por dichos mensajes, lo cual produce trfico innecesario en la red.

Group-Specific Query Messages


Permite al Querier Router efectuar el proceso de consulta sobre un grupo determinado en lugar de enviar mensajes a todos los grupos IP multicast activos. Adems estos mensajes permiten reducir an ms la latencia generada por el proceso de dejar un grupo ya que utilizan un menor valor de tiempo de respuesta.

Mejoras de IGMPv2 con respecto a IGMPv1


Leave Group Messages
Permiten a los hosts informar al router IP multicast local que dejan de recibir trfico de un determinado grupo. En conjunto con la determinacin del Mximo Tiempo de Respuesta, permiten reducir a slo unos segundos la latencia generada por un host que deja de pertenecer a un dado grupo IP multicast.

IGMPv3
Permite a los receptores subscribirse a, o excluir, un set especfico de fuentes dentro de un grupo multicast en vez de solamente a una fuente en particular (conocido como Source Specific Multicast).
Esta nueva funcionalidad agrega la capacidad de filtrado de fuentes: provee la habilidad de reportar el inters de recibir paquetes enviados a una direccin multicast solamente desde ciertas direcciones fuente en particular o de todas menos un conjunto especfico de direcciones.

IGMPv3
Receptores indican membresa a un grupo en los siguientes dos modos:
Include Mode: en este modo el receptor anuncia membresa a un grupo de hosts y provee un listado de direcciones IP (Include list) de las cuales desea recibir trfico. Exclude Mode: en este modo el receptor anuncia membresa a un grupo de hosts y provee una lista de direcciones IP (Exclude list) de las que NO quiere recibir trfico.

Para soportar esta capacidad:


El paquete MQ (tipo 0x11) ha sido cambiado. Se ha agregado un nuevo paquete tipo 0x22. Todas las implementaciones de IGMPv3 deben todava soportar los paquetes tipo 0x12, 0x16 y 0x17.

Estn las siguientes tres variantes en el mensaje Query:

IGMPv3
Un general query es enviado por un router multicast para aprender el estado de recepcin multicast completo de las interfaces vecinas. En un general query tanto el campo Group Address y el Number of Sources son cero. Un group-specific query es enviado por un router multicast para aprender el estado de recepcin con respecto a una direccin multicast simple, de las interfaces vecinas. En un group-specific query el campo Group Address contiene la direccin multicast de inters y el campo Number of Sources contiene cero. Un group-and-source-specific query es enviado por un router multicast para aprender si alguna interface vecina desea recepcin de paquetes enviados a una direccin multicast especfica de alguna de la lista de fuentes especificadas. En un group-and-source-specific query el campo Group Address contiene la direccin multicast de inters y los campos Source Address contienen la/s direccin/es fuente de inters.

IGMPv3 Mensaje Query

IGMPv3 Mensaje Query


El flag S (Suppress Router-Side Processing) = 1 indica que cualquier router multicast receptor debe suprimir las actualizaciones de timer normalmente hechas despus de recibir un query. QRV (Queriers Robustness Variable): se usa para sintonizar valores de timer para prdida de paquetes esperada. QQIC (Queriers Query Interval Code): transporta un valor especificando el intervalo de query, en segundos, usado por el originador de este query. Number of Sources: indica cuntas direcciones fuente estn contenidas dentro del mensaje query. Es cero en un general query o en un group-specific query y no cero en un groupand-source-specific query. Source Address: identifican las N direcciones unicast IP, donde el valor de N corresponde al campo nmero de fuentes.

IGMPv3 Mensaje Report

IGMPv3 Mensaje Report


MRs se envan por sistemas IP para reportar a routers vecinos el estado de recepcin multicast actual cambios en el estado de recepcin multicast, de sus interfaces. El campo Record Type indica el group record type:
Current-state records (MODE_IS_INCLUDE, MODE_IS_EXCLUDE): son records enviados por un sistema en respuesta a un query recibido sobre una interface y reportan el estado de la recepcin actual de esa interface. Filter-mode-change records (CHANGE_TO_INCLUDE_MODE, CHANGE_TO_EXCLUDE_MODE): son records enviados por un sistema cuando cambia el estado de una interface para una particular direccin multicast.

IGMPv3 Mensaje Report


Source-list-change records (ALLOW_NEW_SOURCES, BLOCK_OLD_SOURCES): son records enviados por un sistema cuando una interface desea alterar la lista de direcciones fuente sin alterar su estado.

Los reportes de Versin 3 se envan con una direccin IP destino de 224.0.0.22, en la cual escuchan todos los routers multicast con capacidad IGMPv3.
Un sistema que est operando en los modos de compatibilidad Version 1 2, enva reportes Version 1 2 al grupo multicast especificado en el campo Group Address del report. Adems un sistema debe aceptar y procesar cualquier report Version 1 2 cuyo campo direccin destino IP contiene cualquiera de las direcciones (unicast multicast) asignada a la interface sobre la cual arriba el report.

Operacin de IGMP
IGMP es un protocolo asimtrico, especificando comportamientos distintos para miembros de grupos, es decir, hosts que quieren recibir informacin multicast y routers multicast.
OPERACIONES DEL HOST:
Para recibir datagramas multicast, un host debe unirse a un grupo. Para hacerlo, debe mandar un mensaje IGMP MR a travs de alguna interface. Como fue notado anteriormente, en IGMv3, un host puede especificar una lista de direcciones unicast desde las cuales desea (o no desea) recibir trfico. Un host puede modificar estas listas para agregar o quitar alguna direccin especfica.

OPERACIONES DEL ROUTER:


Los routers multicast escuchan todas las direcciones multicast para detectar Membership Reports (MR). Cuando un host receptor requiere unirse a un grupo, el router dentro de la subred recibe el paquete MR y crea una entrada en la base de datos local de grupos.

Operacin de IGMP
Esta base de datos registra las membresas en las redes conectadas directamente al router. La informacin en esta base de datos es usada para forwardear datagramas multicast. Cuando el router recibe un datagrama, lo reenva a cada interface que contenga hosts pertenecientes a ese grupo. Para verificar la membresa a los grupos los routers multicast envan regularmente (cada 125 s) un mensaje IGMP Query Message a todas las direcciones multicast de los hosts. Cada host que desea ser miembro del grupo enva una respuesta. Para evitar rfagas de trfico, las respuestas a los MQ son enviadas con un retardo aleatorio. Dado que los routers no tienen registro de la cantidad de hosts en cada grupo, cualquier host que detecta a otro anunciando su membresa, cancela cualquier MR pendiente para evitar informacin redundante. Si ningn host anuncia su membresa dentro del intervalo de tiempo especificado, el router asume que en esa red no hay ningn miembro del grupo.

En resumen:
Cada router multicast mantiene una lista de las membresas de los grupos y un Timer para cada una. Los Queriers envan MQ generales para solicitar informacin de membresa. Los hosts responden para reportar su estado de membresa con un MR. Se pueden enviar tambin MQs especficas para ciertos grupos, por ejemplo cuando un router necesita verificar si quedan miembros de un grupo luego de un LG.

Operacin de IGMP
Si no se recibe un MR despus de un periodo de tiempo, el router asume que ya no hay ms miembros y deja de enviar trfico a ese grupo. Cuando un host se una a un grupo multicast, enva un mensaje MR no solicitado para ese grupo. Para cubrir la posibilidad de que el MR inicial se dae o pierda, se recomienda que sea repetido una o dos veces despus de demoras breves. Cuando un host abandona un grupo, enva un mensaje LG. Cuando un Querier recibe un mensaje LG, enva MQs especficas para ese grupo. Si no se recibe ninguna MR en respuesta de esas MQs, el router asume que no hay ms miembros y deja de enviar informacin al grupo.

IGMP Snooping
Inundar un segmento de red con paquetes multicast cuando podra no haber ningn nodo sobre ese segmento que desea recibir estos paquetes puede saturar el enlace de la interface (aunque se opere a 10/100/1000 Mbps) y/ saturar los buffers sobre los NIC. IGMP snooping utiliza los mensajes IGMP Query que enva un router para identificar receptores potencialmente interesados. RFC 4541 provee mecanismos que permiten a los switches escuchar el trfico IGMP. Para que el switch conozca todos los ports que desean recibir una direccin multicast particular, es importante que todos los miembros enven una respuesta IGMP.

IGMP Snooping
Esto no lo hacen en versin 1 y 2 si ellos escuchan otra respuesta.
Por lo tanto es importante que el switch no enve la respuesta IGMP sobre ports con otros hosts. Lo que tipicamente se hace es que los switches conozcan qu ports contienen otros switches o routers y reenven las respuestas IGMP slo sobre esos ports.

Entonces cuando arriban datos multicast IP el switch puede enviar el trfico slo a los puertos que lo han pedido. La mayora de los vendedores de switch hacen que el switch haga la decisin basado sobre la direccin multicast de capa 2