IP Multicast 1999 - Servicios de transmisión Transmisión punto a punto (unicast): –Un emisor, un receptor. –Tipo de transmisión.

Presentación del tema: "IP Multicast 1999 - Servicios de transmisión Transmisión punto a punto (unicast): –Un emisor, un receptor. –Tipo de transmisión."— Transcripción de la presentación:

1 IP Multicast 1999 - grigotti@exa.unicen.edu.ar1 Servicios de transmisión Transmisión punto a punto (unicast): –Un emisor, un receptor. –Tipo de transmisión tradicional en la Internet. Transmisión punto a multipunto: –Un emisor, varios receptores. –Los receptores pertenecen a un grupo. –Aún no provista, en el futuro join específico de IGMPv3. –Ej. aplicación: emisión de radio broadcast, distribución de software. Multipunto a punto: –Varios emisores, un receptor. –No provista por la Internet. –Soportado por varias punto a punto. –Ej. aplicación: telemetría, monitoreo remoto de la red. Multipunto a multipunto (multicast): –Varios emisores, varios receptores. –Los receptores pertenecen a un grupo. –Los emisores pueden o no pertenecer al grupo. –Multicast provisto en la Internet. –Ej. aplicación: Conferencias multimedia, Whiteboard. Anycast: –Uno a cualquiera de un grupo. –Ej. Aplicación: servicios independientes de su ubicación. Transmisión punto a punto (unicast): –Un emisor, un receptor. –Tipo de transmisión tradicional en la Internet. Transmisión punto a multipunto: –Un emisor, varios receptores. –Los receptores pertenecen a un grupo. –Aún no provista, en el futuro join específico de IGMPv3. –Ej. aplicación: emisión de radio broadcast, distribución de software. Multipunto a punto: –Varios emisores, un receptor. –No provista por la Internet. –Soportado por varias punto a punto. –Ej. aplicación: telemetría, monitoreo remoto de la red. Multipunto a multipunto (multicast): –Varios emisores, varios receptores. –Los receptores pertenecen a un grupo. –Los emisores pueden o no pertenecer al grupo. –Multicast provisto en la Internet. –Ej. aplicación: Conferencias multimedia, Whiteboard. Anycast: –Uno a cualquiera de un grupo. –Ej. Aplicación: servicios independientes de su ubicación.

2 IP Multicast 1999 - grigotti@exa.unicen.edu.ar2 Alternativas para proveer un servicio multicast R E R R Varias transmisiones punto a punto Datagrams enviados por E: 3. Cantidad de paquetes transmitidos: 8. Memoria en E: 3 direcciones individuales. Carga por cambio en grupo: sí. Transmisión broadcast Datagrams enviados por E: 1. Cantidad de paquetes transmitidos: >13. Memoria en E: ninguna dirección. Carga por cambio en grupo: no. Soporte multicast en la red: Datagrams enviados por E: 1. Cantidad de paquetes transmitidos: 6. Memoria en E: 1 dirección de grupo. Carga por cambio en grupo: no.

3 IP Multicast 1999 - grigotti@exa.unicen.edu.ar3 Direcciones multicast Identifican a un grupo de 0, 1 ó más interfaces a la red (direcciones individuales). Los integrates de un grupo no tienen necesariamente relación topológica entre sí. Los integrantes de un grupo pueden variar dinámicamente. Una interfaz puede estar asociada a un número variable de grupos multicast. Extensión del modelo de ruteo IP: –Unicast: en base a dirección de destino, enviar hacia él. –Multicast: en base a las direcciones origen y destino, alejarse del origen. Información de estado en los routers: –Unicast: tablas de ruteo. –Multicast: árboles de distribución (MFC). Identifican a un grupo de 0, 1 ó más interfaces a la red (direcciones individuales). Los integrates de un grupo no tienen necesariamente relación topológica entre sí. Los integrantes de un grupo pueden variar dinámicamente. Una interfaz puede estar asociada a un número variable de grupos multicast. Extensión del modelo de ruteo IP: –Unicast: en base a dirección de destino, enviar hacia él. –Multicast: en base a las direcciones origen y destino, alejarse del origen. Información de estado en los routers: –Unicast: tablas de ruteo. –Multicast: árboles de distribución (MFC).

4 IP Multicast 1999 - grigotti@exa.unicen.edu.ar4 Direcciones multicast en IP IPv4 prevé 2 ** 28 direcciones de grupo. IPv6 prevé 2 ** 112 direcciones de grupo IPv4 prevé 2 ** 28 direcciones de grupo. IPv6 prevé 2 ** 112 direcciones de grupo Clase A B C D E 81624032 0 REDHOST RED 10 110 1110 11110 RED ID GRUPO MULTICAST E X P E R I M E N T A L 0.0.0.0 a 127.255.255.255 128.0.0.0 a 191.255.255.255 192.0.0.0 a 223.255.255.255 224.0.0.0 a 239.255.255.255 240.0.0.0 a 247.255.255.255 FormatoRango 11111111flagsscopeGrupo (112 bits) IPv6

5 IP Multicast 1999 - grigotti@exa.unicen.edu.ar5 Multicast: mapeo a la subred Mapeo dependiente de la capacidad de la subred: –varios frames punto a punto –un frame broadcast –un frame multicast Correspondencia multicast IP- multicast Ethernet –Reserva (IANA) de direcciones Ethernet para direcciones multicast IP: 01-00-5E-00-00-00 a 01-00-5E-FF-FF-FF (23 últimos bits) –Conversión sencilla (sin ARP o similar) –32 direcciones multicast IP asignadas a una única dirección multicast Ethernet –Filtrado no completo en el nivel Ethernet (placa) Mapeo dependiente de la capacidad de la subred: –varios frames punto a punto –un frame broadcast –un frame multicast Correspondencia multicast IP- multicast Ethernet –Reserva (IANA) de direcciones Ethernet para direcciones multicast IP: 01-00-5E-00-00-00 a 01-00-5E-FF-FF-FF (23 últimos bits) –Conversión sencilla (sin ARP o similar) –32 direcciones multicast IP asignadas a una única dirección multicast Ethernet –Filtrado no completo en el nivel Ethernet (placa)

6 IP Multicast 1999 - grigotti@exa.unicen.edu.ar6 Características de los grupos multicast Tiempo de vida de un grupo –Grupos permanentes Direcciones asignadas (IANA), fijas, conocidas (“well-known”) en toda la red. Existen aunque no tengan hosts miembros. Un router NO reenvía un datagram con dirección permanente, independientemente de su TTL. Ejemplo (IPv4): 224.0.0.1 Todos los hosts en la red local que participan en multicast. –Grupos transitorios No tienen direcciones fijas asignadas. Requieren mecanismos de asignación de grupos a las aplicaciones. Existen mientras tengan hosts miembros. Reconocimiento de direcciones permanentes y temporarias: –IPv4: reserva direcciones de 224.0.0.0 a 224.0.0.255. grupos 239.0.0.0 a 239.255.255.255: aplicaciones administrativas en redes privadas –IPv6: bit T (1) de campo de flags de la dirección. Tiempo de vida de un grupo –Grupos permanentes Direcciones asignadas (IANA), fijas, conocidas (“well-known”) en toda la red. Existen aunque no tengan hosts miembros. Un router NO reenvía un datagram con dirección permanente, independientemente de su TTL. Ejemplo (IPv4): 224.0.0.1 Todos los hosts en la red local que participan en multicast. –Grupos transitorios No tienen direcciones fijas asignadas. Requieren mecanismos de asignación de grupos a las aplicaciones. Existen mientras tengan hosts miembros. Reconocimiento de direcciones permanentes y temporarias: –IPv4: reserva direcciones de 224.0.0.0 a 224.0.0.255. grupos 239.0.0.0 a 239.255.255.255: aplicaciones administrativas en redes privadas –IPv6: bit T (1) de campo de flags de la dirección. 000T

7 IP Multicast 1999 - grigotti@exa.unicen.edu.ar7 Características de los grupos multicast Alcance de un grupo –Los datagrams para un grupo deben ser difundidos en el ámbito del grupo. –IPV6 Campo scope de la dirección –IPv4 Valor de TTL Thresholds en interfaces de los routers Un datagram con TTL < threshold de la interfaz NO es reenviado Problema (en MBONE): –Mecanismo usado para limitar alcance –Mecanismo usado para limitar alcance de tipo de aplicación –Tráfico para el site: enviado con TTL = 16 –Tráfico global: enviado con TTL = 127 Alcance de un grupo –Los datagrams para un grupo deben ser difundidos en el ámbito del grupo. –IPV6 Campo scope de la dirección –IPv4 Valor de TTL Thresholds en interfaces de los routers Un datagram con TTL < threshold de la interfaz NO es reenviado Problema (en MBONE): –Mecanismo usado para limitar alcance –Mecanismo usado para limitar alcance de tipo de aplicación –Tráfico para el site: enviado con TTL = 16 –Tráfico global: enviado con TTL = 127

8 IP Multicast 1999 - grigotti@exa.unicen.edu.ar8 Multicast: envío de datagrams Envío de datagrams multicast: –No confiable, best effort –Los errores no generan mensajes ICMP Envío multicast en la red local –un host envía (local), los demás reciben Envío multicast más allá de la red local –un host envía (local) –un router multicast, reenvía el dg en las demás redes dependiendo de: la red debe tener miembros del grupo el TTL del dg debe ser mayor que cero (threshold) Envío de datagrams multicast: –No confiable, best effort –Los errores no generan mensajes ICMP Envío multicast en la red local –un host envía (local), los demás reciben Envío multicast más allá de la red local –un host envía (local) –un router multicast, reenvía el dg en las demás redes dependiendo de: la red debe tener miembros del grupo el TTL del dg debe ser mayor que cero (threshold)

9 IP Multicast 1999 - grigotti@exa.unicen.edu.ar9 Transmisión multicast Características + Mejor utilización del ancho de banda + Menor procesamiento en routers y hosts + No es necesario conocer las direcciones de los receptores + Posibilita la escalabilidad de las aplicaciones multipunto Utiliza UDP + Control de la aplicación sobre los datos enviados + Mecanismos propios para recuperación - Carece de mecanismos para control de congestión - Envío best effort Características + Mejor utilización del ancho de banda + Menor procesamiento en routers y hosts + No es necesario conocer las direcciones de los receptores + Posibilita la escalabilidad de las aplicaciones multipunto Utiliza UDP + Control de la aplicación sobre los datos enviados + Mecanismos propios para recuperación - Carece de mecanismos para control de congestión - Envío best effort

10 IP Multicast 1999 - grigotti@exa.unicen.edu.ar10 Multicast: requerimientos Modificaciones en los hosts para soporte de multicast. Routers con capacidad multicast. Protocolo para comunicar host c/routers y routers entre sí: IGMP (Internet Group Managment Protocol). Soporte para protocolos de ruteo multicast. Modificaciones en los hosts para soporte de multicast. Routers con capacidad multicast. Protocolo para comunicar host c/routers y routers entre sí: IGMP (Internet Group Managment Protocol). Soporte para protocolos de ruteo multicast.

11 IP Multicast 1999 - grigotti@exa.unicen.edu.ar11 Soporte multicast En la red local (hosts - routers) Mecanismos para anunciar vinculación/desvinculación de hosts a los grupos: IGMPv1, v2, v3 Entre los routers Mecanismos para la propagación de información de ruteo y mantenimiento de árboles de distribución: Protocolos de ruteo multicast (DVMRP, PIM-DM, PIM-SM, MOSPF, CBT,...) IGMP Router Host Router Host IGMP CBT Router CBT

12 IP Multicast 1999 - grigotti@exa.unicen.edu.ar12 Grupos densos y dispersos Grupo denso –Ambito restringido (intranet) –Gran porcentaje de los hosts es miembro –Vínculos homogéneos con considerable ancho de banda –Estrategia para construir el árbol de distribución: asumir que todos los hosts desean ser miembros los hosts que no lo desean lo comunican explícitamente Grupo disperso –Ambito: interredes (p.ej. Internet) –Un pequeño porcentaje de los hosts es miembro –Vínculos heterogéneos –Estrategia para construir el árbol de distribución: los hosts que desean ser miembros lo comunican explícitamente Grupo denso –Ambito restringido (intranet) –Gran porcentaje de los hosts es miembro –Vínculos homogéneos con considerable ancho de banda –Estrategia para construir el árbol de distribución: asumir que todos los hosts desean ser miembros los hosts que no lo desean lo comunican explícitamente Grupo disperso –Ambito: interredes (p.ej. Internet) –Un pequeño porcentaje de los hosts es miembro –Vínculos heterogéneos –Estrategia para construir el árbol de distribución: los hosts que desean ser miembros lo comunican explícitamente

13 IP Multicast 1999 - grigotti@exa.unicen.edu.ar13 Protocolos de ruteo multicast Requerimientos Relativos a las aplicaciones: Calidades de servicio variadas –Demora máxima punta a punta –Tiempo de establecimiento Relativos a la red: Utilización de recursos –Memoria en los routers –Overhead en los vínculos debido a intercambio de información de control –Concentración de táfico (datos) Escalabilidad Factores que afectan el comportamiento de los protocolos Grupos densos o dispersos Porcentaje de emisores en el grupo (uno, varios, todos) Grado de simultaneidad de las emisiones Requerimientos Relativos a las aplicaciones: Calidades de servicio variadas –Demora máxima punta a punta –Tiempo de establecimiento Relativos a la red: Utilización de recursos –Memoria en los routers –Overhead en los vínculos debido a intercambio de información de control –Concentración de táfico (datos) Escalabilidad Factores que afectan el comportamiento de los protocolos Grupos densos o dispersos Porcentaje de emisores en el grupo (uno, varios, todos) Grado de simultaneidad de las emisiones

14 IP Multicast 1999 - grigotti@exa.unicen.edu.ar14 Arboles de distribución Conjunto de vínculos y nodos que cubre a todos los receptores de un grupo Construidos y mantenidos por el protocolo de ruteo multicast Información distribuida en los nodos Tipos de árboles –Por emisor (source based tree) –Por grupo (shared tree) unidireccional –Por grupo, bidireccional Pertenencia –Implícita Difusión periódica de datos multicast en toda la red No escalable –Explícita: Mecanismos explícitos de agregado de los routers al grupo Escalabilidad Conjunto de vínculos y nodos que cubre a todos los receptores de un grupo Construidos y mantenidos por el protocolo de ruteo multicast Información distribuida en los nodos Tipos de árboles –Por emisor (source based tree) –Por grupo (shared tree) unidireccional –Por grupo, bidireccional Pertenencia –Implícita Difusión periódica de datos multicast en toda la red No escalable –Explícita: Mecanismos explícitos de agregado de los routers al grupo Escalabilidad

15 IP Multicast 1999 - grigotti@exa.unicen.edu.ar15 Arboles por emisor Arboles por emisor (Source based trees) –Caminos de longitud mínima –Buenas demoras –Balanceo de carga en los vínculos –Significativo consumo de memoria y overhead en los routers (O (SxG) ) Arboles por emisor (Source based trees) –Caminos de longitud mínima –Buenas demoras –Balanceo de carga en los vínculos –Significativo consumo de memoria y overhead en los routers (O (SxG) ) R1 E1 E2 R2 R3 E1 y E2 emitiendo a grupo G (R1, R2 y R3) a b c d Emisor Grupo iif oifs E1 G a b c E2 G d a b Entradas en el router y reenvío Demoras E1 a R1:2 (2) E1 a R2:4 (4) E1 a R3:2 (2) E2 a R1:4 (4) E2 a R2:4 (4) E2 a R3:1 (1) Vínculos utilizados: 9

16 IP Multicast 1999 - grigotti@exa.unicen.edu.ar16 Arboles compartidos unidireccionales Arboles compartidos (Shared trees) unidireccionales –Caminos no óptimos –Considerable carga en los vínculos, dependiendo de la simultaneidad de las emisiones (varios emisores) –No aptos para aplicaciones de búsqueda de recursos (expanding ring search) –Buena escalabilidad fundamentalmente en el caso de grupos con varios emisores (memoria en routers) –Sensibles a fallas –Performance dependiente de la ubicación del core o centro –Carga del core (desencapsulación) Arboles compartidos (Shared trees) unidireccionales –Caminos no óptimos –Considerable carga en los vínculos, dependiendo de la simultaneidad de las emisiones (varios emisores) –No aptos para aplicaciones de búsqueda de recursos (expanding ring search) –Buena escalabilidad fundamentalmente en el caso de grupos con varios emisores (memoria en routers) –Sensibles a fallas –Performance dependiente de la ubicación del core o centro –Carga del core (desencapsulación) Entradas en el router y reenvío R1 C E1 E2 R2 R3 E1 y E2 emitiendo a grupo G (R1, R2 y R3) a b c d Grupo iif oifs G b a c Demoras E1 a R1:6 (2) E1 a R2:4 (4) E1 a R3:4 (2) E2 a R1:6 (4) E2 a R2:4 (4) E2 a R3:4 (1) Vínculos utilizados: 7

17 IP Multicast 1999 - grigotti@exa.unicen.edu.ar17 Arboles compartidos bidireccionales Arboles compartidos (Shared trees) bidireccionales –No es necesaria la encapsulación –No hay chequeo de arribo por la interfaz “camino” al core –Aptos para aplicaciones de búsqueda de recursos (expanding ring search) si la subred del emisor pertenece al grupo –Caminos mejores que los unidireccionales, pero no óptimos Arboles compartidos (Shared trees) bidireccionales –No es necesaria la encapsulación –No hay chequeo de arribo por la interfaz “camino” al core –Aptos para aplicaciones de búsqueda de recursos (expanding ring search) si la subred del emisor pertenece al grupo –Caminos mejores que los unidireccionales, pero no óptimos Entradas en el router y reenvío Grupo interfaces G b a c Demoras E1 a R1:2 (2) E1 a R2:4 (4) E1 a R3:2 (2) E2 a R1:6 (4) E2 a R2:4 (4) E2 a R3:4 (1) Vínculos utilizados: 7 R1 C E1 E2 R2 R3 E1 y E2 emitiendo a grupo G (R1, R2 y R3) a b c d

18 IP Multicast 1999 - grigotti@exa.unicen.edu.ar18 Técnicas para construcción y reenvío, árboles por emisor Reverse path broadcasting (RPB) –Si el paquete arriba por la mejor interfaz al emisor, reenviarlo por las demás interfaces –Si el paquete arriba por otra interfaz, descartarlo –Mejora: Si el paquete arriba por la mejor interfaz al emisor, reenviarlo por las interfaces a los nodos que consideren (a este nodo) como el mejor camino al emisor –Mejor performance –Más información de control Truncated reverse path broadcasting (TRPB) –Los routers leaf no envían a la red local si no tienen miembros Reverse Path Multicasting (RPM) –Capacidad de los routers no leaf para enviar podas hacia los emisores Reverse path broadcasting (RPB) –Si el paquete arriba por la mejor interfaz al emisor, reenviarlo por las demás interfaces –Si el paquete arriba por otra interfaz, descartarlo –Mejora: Si el paquete arriba por la mejor interfaz al emisor, reenviarlo por las interfaces a los nodos que consideren (a este nodo) como el mejor camino al emisor –Mejor performance –Más información de control Truncated reverse path broadcasting (TRPB) –Los routers leaf no envían a la red local si no tienen miembros Reverse Path Multicasting (RPM) –Capacidad de los routers no leaf para enviar podas hacia los emisores

19 IP Multicast 1999 - grigotti@exa.unicen.edu.ar19 Protocolos multicast DVMRP –Modo denso –Árboles por emisor –Pertenecia implícita –Emplea RPM (con envío selectivo a downstreams) –Ruteo propio –No escalable –Utilizado en el MBONE PIM-DM –Modo denso –Árboles por emisor –Pertenencia implícita –Emplea RPM (sin envío selectivo) –Independiente del ruteo unicast –Simple –No escalable –Estado de borrador DVMRP –Modo denso –Árboles por emisor –Pertenecia implícita –Emplea RPM (con envío selectivo a downstreams) –Ruteo propio –No escalable –Utilizado en el MBONE PIM-DM –Modo denso –Árboles por emisor –Pertenencia implícita –Emplea RPM (sin envío selectivo) –Independiente del ruteo unicast –Simple –No escalable –Estado de borrador

20 IP Multicast 1999 - grigotti@exa.unicen.edu.ar20 Protocolos multicast MOSPF –Modo denso –Árboles por emisor –Pertenencia explícita –Construcción de árboles en cada nodo (Dijkstra) –No escalable –Ruteo propio (OSPF) CBT –Modo sparse –Árboles compartidos, bidireccionales –Pertenencia explícita –Independiente del ruteo unicast –Simple –Escalable –Estado de draft (v3) y RFC (v2) MOSPF –Modo denso –Árboles por emisor –Pertenencia explícita –Construcción de árboles en cada nodo (Dijkstra) –No escalable –Ruteo propio (OSPF) CBT –Modo sparse –Árboles compartidos, bidireccionales –Pertenencia explícita –Independiente del ruteo unicast –Simple –Escalable –Estado de draft (v3) y RFC (v2)

21 IP Multicast 1999 - grigotti@exa.unicen.edu.ar21 Protocolos multicast PIM-DM –Modo sparse –Árboles compartidos unidireccionales –Conmutación a árboles por emisor –Pertenencia explícita –Escalable ?? –Independiente del ruteo unicast –Estado de RFC –Implementaciones (CISCO) PIM-DM –Modo sparse –Árboles compartidos unidireccionales –Conmutación a árboles por emisor –Pertenencia explícita –Escalable ?? –Independiente del ruteo unicast –Estado de RFC –Implementaciones (CISCO)

22 IP Multicast 1999 - grigotti@exa.unicen.edu.ar22 Resumen protocolos multicast

23 IP Multicast 1999 - grigotti@exa.unicen.edu.ar23 Tipos de aplicaciones multicast 1 a M: Las más simples. –Eventos planificados (conferencias, audio, TV). AB considerable. Sincronización de streams. –Actualización de info dinámica, no esencial (p.ej. datos meteorológicos). Bajo AB. –Monitoreo (lectura de sensores, seguridad). AB variado, tráfico en ráfagas o regular. M a 1:Aplicaciones request/reply –Descubrimiento de recursos –Data collection –Polling M a M: Problemas complejos de sincronización entre participantes –Conferencias multimedia (audio + video + whiteboard). AB considerable. Sensibles y no sensibles a errores. Coordinación de streams. Muy sensibles a demoras y variación de demoras. –DIS: Grandes anchos de banda. Demoras bajas para incorporarse o dejar de pertenecer a un grupo. 1 a M: Las más simples. –Eventos planificados (conferencias, audio, TV). AB considerable. Sincronización de streams. –Actualización de info dinámica, no esencial (p.ej. datos meteorológicos). Bajo AB. –Monitoreo (lectura de sensores, seguridad). AB variado, tráfico en ráfagas o regular. M a 1:Aplicaciones request/reply –Descubrimiento de recursos –Data collection –Polling M a M: Problemas complejos de sincronización entre participantes –Conferencias multimedia (audio + video + whiteboard). AB considerable. Sensibles y no sensibles a errores. Coordinación de streams. Muy sensibles a demoras y variación de demoras. –DIS: Grandes anchos de banda. Demoras bajas para incorporarse o dejar de pertenecer a un grupo.

24 IP Multicast 1999 - grigotti@exa.unicen.edu.ar24 Requerimientos de las aplicaciones multicast Manejo de receptores heterogéneos –Receptores en subredes con diferentes capacidades (AB, demora, congestión). –Saturación del emisor con información de feedback. –Mecanismos en las aplicaciones para adaptar envío. Envío confiable de datos –Grados de confiabilidad dependiendo de la aplicación Receptor solicita paquetes erróneos (NACK). Emisor necesita confirmación de paquetes recibidos (ACK). –Saturación de la red con feedback (implosión) Recuperación local Limite en el alcance del feedback Manejo de receptores heterogéneos –Receptores en subredes con diferentes capacidades (AB, demora, congestión). –Saturación del emisor con información de feedback. –Mecanismos en las aplicaciones para adaptar envío. Envío confiable de datos –Grados de confiabilidad dependiendo de la aplicación Receptor solicita paquetes erróneos (NACK). Emisor necesita confirmación de paquetes recibidos (ACK). –Saturación de la red con feedback (implosión) Recuperación local Limite en el alcance del feedback

25 IP Multicast 1999 - grigotti@exa.unicen.edu.ar25 Requerimientos de las aplicaciones multicast Seguridad –Control de emisores. –Control de receptores. –Autenticación de contenidos. –Protección de identidad de los receptores. –Aspectos de performance ante cambios en la composición de un grupo. Administración de sesiones –Mapeo de direcciones y ports multicast a diferentes sesiones (SDP). –Distribución de información relativa a sesiones (SAP). Demoras acotadas para integración y salida de un grupo –IGMPv2. Seguridad –Control de emisores. –Control de receptores. –Autenticación de contenidos. –Protección de identidad de los receptores. –Aspectos de performance ante cambios en la composición de un grupo. Administración de sesiones –Mapeo de direcciones y ports multicast a diferentes sesiones (SDP). –Distribución de información relativa a sesiones (SAP). Demoras acotadas para integración y salida de un grupo –IGMPv2.