Servicios Multidestino. Contenido.

(1)

Dpto. de Ingeniería de Telecomunicación Área de Ingeniería Telemática

VERSIÓN 1.0 Universidad de Jaén

E. P. S. de Linares 2.1 Introducción. Orígenes: MBONE.

Introducción. Reseña histórica. Características técnicas.

2.2 Modelo IP multicast. Señalización host-router: IGMP.

IGMP versión 1, versión 2 y versión 3

2.3 Multicast sobre LAN.

Snooping. 2.4 Encaminamiento multicast. DVMRP MOSPF PIM-DM PIM-SM

Tema 2 Servicios Multidestino 2

Bibliografía

Ref

Comer, Douglas E. "Internetworking with TCP/IP Principles, Protocols, and Architectures"4ª Edición vol. 1, 2000, Prentice Hall.

Grenville Armitage. “Quality of Service in IP Networks”. MacMillan Technical

Plublishing, 2000.

Stallings, William. “Redes e Internet de Alta Velocidad Rendimiento y Calidad de Servicio”, 2ª Edición. Prentice Hall, 2004.

(2)

E. P. S. de Linares Request for Comments (http://www.ietf.org/rfc.html)

[RFC1112] Host extensions for IP multicasting

S.E. Deering August 1989

Obsoletes RFC988, RFC1054, Updated by RFC2236. STANDARD

[RFC2236] Internet Group Management Protocol, Version 2

W. Fenner November 1997

Obsoleted by RFC3376, Updates RFC1112. PROPOSED STANDARD

[RFC3376] Internet Group Management Protocol, Version 3

B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan October 2002 Obsoletes RFC2236. PROPOSED STANDARD

Bibliografía en Internet

Otros documentos

Ref

[RedIrisEvo] Evolución de la red Mbone: Arquitectura y aplicaciones.

A.F. Gómez Skarmeta, A.L. Mateo y P. M. Ruíz

http://www.rediris.es/rediris/boletin/50-51/ponencia12.html

[RedIrisArq]MBone: Arquitectura y Aplicaciones

Juan Antonio García

http://www.rediris.es/rediris/boletin/43/enfoque3.html

[MBoneCastelo] MBone: El camino hacia una Internet multimedia.

Víctor Castelo, Juan Antonio García

http://www.ucm.es/info/multidoc/multidoc/revista/cuad6-7/castelo.htm

(3)

E. P. S. de Linares [MBoneSavetz] MBONE: Multicasting Tomorrow's Internet

Kevin Savetz, Neil Randall, and Yves Lepage, 1998 http://www.savetz.com/mbone/

[IGMPGibbs] Internet Group Management Protocol. Advanced Technical Paper Series. M. Gibbs, Riverstone Networks.

IETF Working Group: Inter-Domain Multicast Routing (idmr) http://www.ietf.org/html.charters/OLD/idmr-charter.html

Introducción. Orígenes: MBone.

Fue a principio de los 90 cuando se comenzó a diseñar MBone (IP Multicast

Backbone), entendida como una subred dentro de Internet para trabajar con tráfico IP

Multicast.

Se pensó que se convertiría en la tecnología idónea para el desarrollo eficiente de servicios multimedia y tele-conferencia multipunto sobre Internet.

Sin embargo, han pasado los años, y aún no ha alcanzado la madurez y popularidad necesaria para cubrir las expectativas que generó el proyecto.

2.1

(4)

E. P. S. de Linares La idea fundamental de IP Multicast que lo hace tan viable para desarrollar servicios de videoconferencia multipunto se basa en la utilización de direcciones IP multicast, en vez de las direcciones IP unicast tradicionales. Gracias a esto se tienen las siguientes ventajas:

Optimización del ancho de banda utilizado al circular por cada enlace entre el origen y el destino(s) de datos un único paquete.

La complejidad de la distribución a todos los destinos recae en los equipos de red y no en los equipos finales. Esto simplifica su trabajo y los libera de carga.

Sin embargo, también presenta otras carencias, que han sido las que han limitado el crecimiento de este servicio.

Introducción.

i

Introducción. Orígenes: MBone.

Históricamente MBone surgió en 1992 tras una de las reuniones de coordinación del IETF, con el fin de experimentar sobre el concepto de direcciones multicast propuesto por Steve Deering (Universidad de Stanford) en su tesis doctoral. Van Jacobson, de los laboratorios Lawrence Berkeley (LBL), Steve Casner, del ISI (Information Science Institute) y varios ingenieros más, se unieron al proyecto propuesto por Steve Deering dando lugar a un grupo de trabajo que sentaría las bases de lo que ahora es MBone. RedIRIS se unió a este proyecto en 1993 de forma local, dado que las condiciones de los enlaces troncales de la red académica y de investigación no permitían su difusión por toda ella. A raíz de la ampliación de la infraestructura de los enlaces troncales de RedIRIS en 1995, se procedió a la distribución del servicio piloto de MBone a los centros afiliados que lo solicitaron.

2.1

(5)

E. P. S. de Linares Cuando un equipo envía un datagrama IP a una determinada dirección IP multicast, sólo es recibida por aquellos equipos que están a la escucha de esa dirección y, que por tanto, son capaces de entender las direcciones multicast.

Actualmente prácticamente todos los ordenadores modernos soportan IP multicast según se especificó en el RFC 1112 (ampliada varias veces).

i

Introducción. Orígenes: MBone.

2.1

Recordatorio familias de direcciones IP

Tipo Rango en decimal

Clase A 0.0.0.0 a 127.255.255.255

Clase B 128.0.0.0 a 191.255.255.255

Clase C 192.0.0.0 a 223.255.255.255

Clase D 224.0.0.0 a 239.255.255.255

Clase E 240.0.0.0 a 247.255.255.255 Experimental

(6)

E. P. S. de Linares Las direcciones IP multicast son de la forma:

224.xxx.xxx.xxx - 239.xxx.xxx.xxx

Características Técnicas.

Introducción. Orígenes: MBone.

De todas las direcciones IP multicast posibles con el formato anterior, algunas están reservadas para uso interno por equipos de comunicaciones que intercambian información sobre multicast, otras para uso local dentro de Intranets.

Las direcciones multicast que usa MBone para las conferencias multimedia son las comprendidas en el rango:

224.2.0.0.0 - 239.255.255.255

Dentro de este rango hay ciertas direcciones reservadas para los anuncios de sesiones MBone y ciertos rangos reservados para conferencias de ámbito local, institucional o parcialmente restringido.

2.1

(7)

E. P. S. de Linares IP Multicast es en sí la variación, o conjunto de variaciones y protocolos sobre IP que permiten el multicasting en Internet, y forma la base de MBone.

IP Multicast persigue el aprovechamiento eficiente de las infraestructuras existentes para la distribución de información uno a muchos.

IP Multicast se sirve de un conjunto nuevo de direcciones, de protocolos de enrutado multicast y protocolos de comunicación entre router para el manejo de equipos (IGMP). Los protocolos de encaminamiento multicast se verán en la parte final del tema.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

Introducción.

SERVIDOR

(8)

E. P. S. de Linares Como bien es sabido, Internet es una red en la que el intercambio de información entre equipos locales o remotos se hace a través de datagramas IP

Estos datagramas IP están formados principalmente por una dirección origen y una dirección destino.

Cada equipo conectado a Internet tiene una (o varias) direcciones IP, las constituyen un sello de identidad global y único para cada equipo en Internet.

Direcciónes IP Multicast

Modelo IP multicast. Señalización host-router: IGMP.

Las direcciones IP en función de la dirección de destino se pueden clasificar en tres tipos:

IP unicast: La dirección corresponde a un solo receptor y será éste el único que

procese los datagramas IP con ese destino (conexión uno-a-uno).

IP broadcast:La dirección corresponde a todos los equipos conectados en un mismo

tramo de red local y el datagrama IP es procesado por todos ellos (conexión uno-a-todos dentro de la misma subred).

IP multicast: La dirección corresponde a un grupo de equipos, y sólo estos

procesarán los datagramas IP con ese destino (conexión uno-a-muchos, o uno-a-varios).

2.2

(9)

E. P. S. de Linares Cuando un equipo envía un datagrama IP a una determinada dirección IP multicast, sólo es recibida por aquellos equipos que están a la escucha de esa dirección y, que por tanto, son capaces de entender las direcciones multicast.

Las direcciones IP multicast se suelen denominar “grupo multicast”, ya que no están asignadas a un equipo concreto de forma permanente, sino a un grupo determinado y de forma temporal. Así mismo, es necesario que un equipo pertenezca a un grupo concreto multicast para enviar datagramas al mismo.

Para la gestión de los grupos multicast se utiliza en protocolo IGMP (Internet Group Management Protocol) que se verá más adelante.

Modelo IP multicast. Señalización host-router: IGMP.

Los datagramas multicast son enviados hacia los miembros del grupo destino usando la misma fiabilidad `best effort' que los datagramas IP unicast.

No existe garantía de que los datagramas lleguen a su destino, ni de que lo hagan de forma ordenada. El protocolo de transporte empleado generalmente es UDP (User Datagram Protocol).

La demanda de aplicaciones en tiempo real, como son las conferencias de audio y vídeo, si bien son tolerantes a perdidas de paquetes, no lo son en cuanto a que estos lleguen de forma desordenada. Se hacen necesarios nuevos mecanismos o protocolos, como el RTP (Real Time Protocol)

2.2

(10)

E. P. S. de Linares Para que se puedan crear los grupos mulitcast, y esto se de a conocer a los routers que forman parte de la ruta necesaria para la distribución a cada receptor se usa el protocolo IGMP.

Los routers usarán la información distribuida por IGMP para construir o podar árboles de distribución multicast y usarlos en algún algoritmo de encaminamiento multicast. IGMP no es un protocolo de enrutamiento.

IGMP. Introducción.

Modelo IP multicast. Señalización host-router: IGMP.

La información IGMP pasa desapercibida para cualquier router que no lo soporte ya que va sobre un datagrama IP, ya sea IPv4 o IPv6, como si fuera un protocolo de transporte, aunque su funcionamiento es a nivel de red, como por ejemplo ICMP (Internet Control Message Protocol).

La forma en que los mensajes IGMP van encapsulados dentro de datagramas IP es: Número de protocolo IP = 2, TTL = 1 y con la opción IP Router Alert en la cabecera IP [RFC 2113].

Existen 3 versiones incrementales. La más usada es la versión 2. La versión 3 está pensada para funcionar tanto con la versión 1 como la 2.

2.2

(11)

E. P. S. de Linares IGMP Version 1 [RFC1112], fue el primero que se desplegó ampliamente y la primera versión que se convirtió en un estándar.

IGMP Version 2 [RFC2236], añadía la característica de "low leave latency", que reducía el tiempo que un router tardaba en darse cuenta en que no había miembros en un grupo de una red adyacente.

IGMP Version 3 [RFC3376] aporta "source filtering", por la que un sistema puede requerir recibir paquetes “sólamente de una dirección” o de “todas salvo una”.

Modelo IP multicast. Señalización host-router: IGMP.

IGMP version 1 es un protocolo bastante simple. Esencialmente tan sólo existen dos mensajes que se comunican entre los routers, información de adscripción a grupo (membership queries) y solicitud de adscripción (membership reports).

IGMP membership queries: Permite al router solicitar información de adscripción de los hots directamente conectados a sus interfaces.

IGMP membership reports: Permite a un host informar a su router local del deseo de recibir un grupo multicast concreto.

IGMP Versión uno se especifica en la RFC 1112, aunque existe una versión 0 (RFC-988) pero está completamente obsoleta.

2.2

(12)

E. P. S. de Linares

Versión = 1. 0 si fuese la versión 0 de IGMP (ya

obsoleta).

Tipo:

1 = Membership Query. 2 = Membership Report.

IGMP Versión 1. Formato de mensaje

Unused:Todo ceros cuando se

envía, son ignorados en recepción.

CheckSum: 16 bits. Complemento a uno

de los 8 octetos del mensaje IGMP, dejando el campo checksum a 0.

Versión Tipo Unused Checksum

Dirección de grupo

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Modelo IP multicast. Señalización host-router: IGMP.

Dirección de Grupo:

Para los mensajes Membership Report contiene la dirección IP del grupo multicast al que se quiere unir el host.

Para los mensajes Membership Querysu valor es cero. Acciones Unirse a un grupo Pregunta-Respuesta Abandonar un grupo 2.2 IGMP Versión 1

(13)

E. P. S. de Linares Unión a un grupo

El host H que se quiera unir a un grupo G debe mandar un Membership Reporta la dirección del grupo al que quiere unirse. Por lo tanto este mensaje es recibido por todos los integrantes del grupo.

Para cubrir la posibilidad de que el mensaje inicial se pierda o se dañe, se recomienda que sea repetido una o dos veces después de cortos intervalos.

Modelo IP multicast. Señalización host-router: IGMP.

Pregunta-Respuesta

Permite a los routers multicast saber qué grupos están activos en la subred. El router envía a todos los equipos de la red un Membership Query. Esto lo hace cada cierto tiempo usando la dirección 224.0.0.1.

Cuando un host recibe el Membership Querypone un marcha un temporizador D distinto para cada grupo al que pertenezca (entre 0 s < D ≤10 s).

Cuando el temporizador expira, el host envía un Membership Reportal grupo correspondiente al temporizador.

La inicialización de los temporizadores es aleatoria y distinta cada vez, siempre por debajo de un tiempo máximo.

2.2

(14)

E. P. S. de Linares Pregunta-Respuesta

Si el router no recibe ningún Reportde algún grupo, entonces considera que ese grupo ya no existe.

Sólo un host de cada grupo responde al router. Si un host en espera de contestar a una Queryescucha un Reportde otro host del mismo grupo, interrumpe su

temporizador y cancela la respuesta.

IGMP Versión 1

Modelo IP multicast. Señalización host-router: IGMP.

Abandonar un grupo

Es una seria limitación de esta versión, ya que no provee un mensaje concreto para que un host pueda abandonar un grupo multicast explícitamente.

Cuando un host quiere abandonar un grupo simplemente deja de responder como miembro de ese grupo a los mensajes Membership Query del router.

Las Queries son enviadas periódicamente, pero para evitar tener una sobrecarga por IGMP en la red no se suelen enviar más de una por minuto. Sin embargo cuando un router multicast arranca puede hacer varias Queriesen intervalos cortos de tiempo para construir su conocimiento acerca de las adscripciones locales rápidamente.

2.2

(15)

E. P. S. de Linares

No miembro: El host no pertenece al grupo. Es el estado inicial para todos los interfaces de red, y no requiere e ningún almacenamiento.

Miembro en espera: Cuando el host pertenece a un grupo y tiene un temporizador de Report activo.

Miembro activo: Pertenece al grupo y no tiene un temporizador activo para ese grupo.

Máquina de estados de IGMP v1

NO MIEMBRO MIEMBRO EN ESPERA MIEMBRO ACTIVO Abandonar Grupo (parar el timer) Unirse al grupo (enviar report iniciar timer) Abandonar grupo Query recibida (iniciar timer) Report recibido (Parar timer) Timer expirado (Enviar report)

Modelo IP multicast. Señalización host-router: IGMP.

Parámetros de tiempo

Query Interval: Tiempo que ha de transcurrir entre cada Query del router (Por defecto

125s.).

Group Membership Interval: Tiempo que ha de transcurrir sin recibir Reports para

que el router decida que ya no existen miembros de un determinado grupo.

2.2

(16)

E. P. S. de Linares IGMP versión 2 es el estándar por defecto de IGMP. Se implementa en sistemas operativos Microsoft Windows 98, 2000, ME en la mayoría de versiones actuales de Linux y Unix.

La principal mejora sobre su predecesor es la incorporación del mecanismo de “expedited leave”, que permite a host comunicar específicamente su deseo de abandonar un grupo multicast.

IGMP Versión 2 se especifica en la RFC 2236,.

IGMP Versión 2

Modelo IP multicast. Señalización host-router: IGMP.

Tipo

Membership Query (=0x11): General Query Group-Specific Query

Membership Report versión 1 (=0x12) Membership Report versión 2 (=0x16) Membership Leave Group(=0x17)

2.2

IGMP Versión 2. Formato de mensaje

Tipo Máximo Tiempo

de Respuesta Checksum Dirección de grupo

(17)

E. P. S. de Linares Tiempo de Respuesta Máximo:

Se usa sólo en mensajes de tipo Membership Query. Especifica el valor, en décimas de segundo, que un host debe esperar como máximo para contestar a un Membership Query. Por defecto es igual a 100 (10s.). Usada para controlar la dispersión de las respuestas y la latencia.

Checksum: Igual que en la versión 1.

Dirección de Grupo:

0 en mensajes de tipo General Query.

Contiene la dirección del grupo multicast en mensajes de tipo Group-Specific Query.

Contiene la dirección del grupo multicast en mensajes de tipo Membership Report y Membership Leave Group.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 2 Acciones

Unirse a un grupo (igual que en versión 1)

Pregunta-Respuesta General (igual que en versión 1) Pregunta-Respuesta Específica

Abandonar un grupo

(18)

E. P. S. de Linares IGMP Versión 2

Pregunta-Respuesta específica

El router pregunta por la existencia de miembros de un grupo concreto. Los host responden igual que a una Query general. Usando un tiempo de respuesta máximo menor(=1s) se reduce la latencia de abandono de grupo.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 2 Abandonar un grupo

El host que quiera abandonar un grupo manda un mensaje de tipo Membership Leave Group a la dirección de todos los routers multicast (224.0.0.2).

A continuación, el router envía un mensaje Membership Group-Specific Query al grupo que quiere abandonar el host.

Si algún host contesta con un Report, entonces el router mantiene el grupo. Si ningún host contesta en un tiempo dado, se considera que el que ha abandonado era el último del grupo y el router lo elimina.

(19)

E. P. S. de Linares Elección del router mulitcast (querier)

Cada router multicast envía un General Query al grupo de todos los sistemas multicast (224.0.0.1), con su dirección IP en el origen.

Cuando un router recibe esta General Query,

Si la dirección IP de origen del mensaje es menor que la suya, entonces deja de ser el router multicast. Si no vuelve a recibir una General Query con menor IP en un tiempo dado comienza de nuevo a enviar Queries.

Si la dirección IP de origen es mayor que la suya, sigue haciendo las funciones de router multicast y enviando Queries.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 2

Máquina de estados de IGMP v2

NO MIEMBRO MIEMBRO EN ESPERA MIEMBRO ACTIVO Dejar grupo (detener timer Enviar abandono si señal activada Unirse al grupo (enviar report Activar señal iniciar timer) Abandonar Grupo (enviar report si señal activada) Query recibida (iniciar timer) Report recibido (Parar timer, borrar señal)

Timer expirado Report recibido

Borrar timer Si tiempo max. resp

< temp actual

Señal:Informa si el host fue el último en enviar un report en el grupo

(20)

i

Compatibilidad con IGMP v1

Hosts versión 2 - routers versión 1

Reports versión 2 son ignorados por lo routers. Los hosts deben mandar Reports vesión 1 en respuestas a Queries.

Hosts versión 1 - routers versión 2

Hosts responden igual a Queries v1 y v2.

Los Reports versión 2 no suponen cancelación del temporizador en los hosts versión 1. El proceso de abandono se suspende, puesto que los hosts versión 1 no realizan esta acción y el router la requiere.

Routers versión 1 - routers versión 2

Detección automática de routers versión 1. Si existen estos últimos es necesario configurar la versión 1 en todos los routers de la subred.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 2

Parámetros de tiempo adicionales a la versión 1

Query Response Interval. Tiempo que se inserta en el campo de Tiempo de Respuesta Máximo de los mensajes de tipo General Query(Por defecto = 10s). Other Querier Present Interval. Tiempo que debe transcurrir antes de que un router decida que no hay otro router que pueda ser el Querier multicast.

(21)

E. P. S. de Linares Parámetros de tiempo adicionales a la versión 1

Startup Query Count. Número de General Queriesenviadas al arrancar un router. Last Member Query Interval. Tiempo que se inserta en el campo de Tiempo de Respuesta Máximo de los mensajes de tipo Group-Specific Query(Por defecto = 1s), e indica además el intervalo entre cada una de las Group-Specific Queries.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 3 Introducción

Lo más novedoso de la versión 3 de IGMP es que aporta la capacidad de filtrar fuentes, tanto en el sentido de recibir paquetes tan sólo de un grupo en concreto, como de especificar querer recibir de cualquier grupo menos de uno concretamente.

Esta información es útil también para los protocolos de enrutamiento multicast, ya que impide que se redireccionen paquetes multicast a lugares donde no son deseados. La versión 3 se ha diseñado para operar con las versiones 1 y 2.

(22)

i

Introducción

Existe una contrapartida para IGMP en IPv6, Multicast Listener Discovery (MLD), siendo usado en una forma similar por IPv6. MLD versión 1 [MLD] implementa la funcionalidad de IGMP v2 y MLD versión 2 [MLDV2] implementa la funcionalidad de IGMP v3.

[MLD] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

[MLDV2] Vida, R., L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, and B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Work in Progress.

i

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 3

Cambios con respecto a la versión 2

Aunque la principal característica adicional de IGMPv3 sea el filtrado de fuentes, a continuación se presenta un resumen de otros cambios con respecto a la RFC 2236:

Se guarda la información de estado con Grupo+Lista de fuentes, no sólo el Grupo como en IGMPv2

Interoperatibilidad con sistemas IGMPv1 y IGMPv2 esta definido como operaciones dentro de un estado IGMPv3.

(23)

E. P. S. de Linares Cambios con respecto a la versión 2

El Querier incluye su Robustness Variable y Query Interval en los paquetes Query para permitir la sincronización de esas variables en los routers no-Querier.

El Max Response Time en los mensajes de Query tiene un rango exponencial, cambiando el máximo de 25.5 s a 53 minutos, para el uso en enlaces con un número muy elevado de sistemas. Los host retransmiten los mensajes de cambio de estado para incrementar la robustez.

Para permitir extensiones posteriores se han definido secciones de datos adicionales.

Los mensajes Report son enviados a la dirección 224.0.0.22, para asistir a los switches de capa 2 en el “snooping”

i

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 3

Cambios con respecto a la versión 2

Los paquetes Report pueden contener múltiples registros de grupos para permitir informar del estado actual en menos paquetes.

Los Host ya no podrán realizar una supresión, para simplificar las implementaciones y permitir el seguimiento de las adscripciones.

Se añade un nuevo bit de control (S) o Suppress Router-Side Processing en los mensajes de Query, que soluciona problemas de robustez, también existentes en IGMPv2.

(24)

E. P. S. de Linares IGMP Versión 3. DIRECCIÓN DE FUENTE [N] … DIRECCIÓN DE FUENTE [1] NÚMERO DE FUENTES (N) QQIC QRV S RESV DIRECCIONES DE GRUPO CHECKSUM Tiempo Máx. Respuesta TIPO 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

Formato de mensajes Query

Modelo IP multicast. Señalización host-router: IGMP.

2.2 IGMP Versión 3 Tipos de mensajes. Membership Query (=0x11) General Query Group-Specific Query Group-and-Source-Specific Query Membership Report versión 3 (=0x22) Membership Report versión 1 (=0x12) Membership Report versión 2 (=0x16) Membership Leave Group versión 2 (=0x17)

(25)

E. P. S. de Linares Tiempo Máximo de Respuesta

Tiempo máximo permitido antes de enviar un Report.

Si >=128 entonces se interpreta como un número en coma flotante, con el primer bit a 1, los tres siguientes el exponente y los restantes la mantisa.

Checksum(igual que en las versiones anteriores) Dirección de Grupo

Igual a 0 en General Queries.

Dirección de grupo multicast en otras Queries.

Resv.Campo reservado.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 3. Mensajes Query

Flag S: Cuando es igual a 1, indica a los routers multicast que tienen que suprimir las

actualizaciones de los temporizadores cuando escuchen una Query. Si no, elimina la elección del router multicast.

QRV (Querier Robustness Variable)

QQIC (Querier’s Query Interval Code): Especifica el intervalo del router para

mandar Queries.

Número de Fuentes: Indica el número de fuentes presentes en el mensaje Query. Dirección de Fuentes [i]:Vector de N direcciones IP unicast, indicando las fuentes.

(26)

E. P. S. de Linares IGMP Versión 3.

REGISTRO DE GRUPO [N] …

REGISTRO DE GRUPO [1]

NÚMERO DE REG. DE GRUPO (N) RESERVADO CHECKSUM RESERVADO TIPO 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

Formato de mensajes Report

Tipo (=0x22)

Checksum (igual que anteriormente)

Número de Registros de Grupo: Indica el número de registro que contiene el Report.

Modelo IP multicast. Señalización host-router: IGMP.

2.2 IGMP Versión 3. DIRECCIÓN DE FUENTE [M] DATOS AUXILIARES … DIRECCIÓN DE FUENTE [1] DIRECCIÓN DE GRUPO Número de fuentes (M)

Longitud Datos Aux

TIPO 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

(27)

E. P. S. de Linares Registro de grupo.

Tipo de Registro: Estado Actual, Cambio de modo Filtro y Cambio de Lista de Fuentes Longitud de Datos Aux: Longitud del campo Datos Auxiliares

Dirección de Grupo:La dirección multicast del grupo.

Dirección de Fuentes [i]:Igual que en los mensajes Query.

Datos auxiliares:Contiene información adicional sobre el registro de grupo

En la implementación actual de la versión 3, no debe usarse este campo, debiendo ser igual a 0. Su uso se definirá en futuras versiones.

Modelo IP multicast. Señalización host-router: IGMP.

2.2

IGMP Versión 3. Acciones del protocolo

Las propias de las versiones 1 y 2.

Unirse a un grupo.

Igual que en versiones anteriores, pero el Reportse manda a 224.0.0.22, y se pueden especificar fuentes dentro de los grupos a las que unirse. La decisión de hacer el registro en la dirección 224.0.0.22 es la de aportar robustez y control al mantenimiento de la información de estado, así como ayudar al “snooping” de los switches de nivel 2.

Dejar un grupo.

Igual que en la versión 2, pero el mensaje lo mandan los host ahora a 224.0.0.22. Se puede dejar un grupo, o una o varias fuentes específicas dentro de un grupo.

(28)

E. P. S. de Linares IGMP Versión 3. Acciones del protocolo

Pregunta-respuesta.

Igual que en la versión 2, pero se pueden hacer, además, Queries específicas sobre grupos y fuentes en esos grupos (Group-and-Source-Specific Query). Todas las Queries se mandan ahora a 224.0.0.0

Elección del router multicasting (Querier).Igual que en versión 2.

Permite especificar pares grupo/fuente a los hosts para que puedan recibir datos destinados a esos grupos y desde esas fuentes, o desde cualquiera menos esas.

Multicast sobre LAN.

Es de todos conocidos que Internet discurre por gran cantidad de tipos de redes, enlaces de capacidades y tecnologías totalmente dispares, y que por supuesto, el protocolo IP es un protocolo de RED, no de enlace (capa 2).

Por lo tanto, sin un nivel de enlace que posibilite el multicasting, todo al final, dentro de la subred, será un ejemplo más de unicast.

Existen redes que típicamente son entornos multicast de facto, como las redes Token Bus, Token ring, WiFi (802.11x), pero sin embargo, una de las más usadas como base para las subredes es la red Ethernet (802.3) la cual, también permite el multicasting aportando un conjunto de direcciones de multicast.

2.3

(29)

E. P. S. de Linares En previsión de expandir IP multicast eficientemente dentro del entorno Ethernet, el IANA posee el rango de direcciones MAC: 01-00-5E-XX-XX-XX, del cual se reserva la mitad para IP multicast.

Con el espacio de direcciones Ethernet para multicasting reservado para IP Multicast (23 bits) no se pueden direccionar uno a uno cada grupo:

Cada dirección Ethernet multicast corresponde con 32 grupos IP multicast

Multicast sobre LAN.

2.3

Direcciones MAC de multicast

0000 0001 0000 0000 0101 1110 Ethernet Multicast bit 01-00-5E 0 23 bits 24 0 0: IP Multicast 1: Reservado 00-00-00 al 7F-FF-FF 1110

IP Multicast (Clase D) 32 bits 28 bits Ethernet Multicast 48 bits

(30)

E. P. S. de Linares Cuando un host se quiere unir a un grupo multicast envía mensajes Report para unirse. En un entorno Ethernet normal no preparado para usar eficientemente el multicasting, ese mensaje, si llegara a un switch, éste lo enviaría por todos sus enlaces menos por el de entrada de la trama (flooding).

Este modo es sencillo, pero poco eficiente en servicios que requieran alto ancho de banda, ya que colapsarían la red, o un número masivo de usuarios dentro de la misma Ethernet.

Para evitar esto se usa entre otras técnicas el “snooping”, comentado a continuación.

Direcciones MAC de multicast

Multicast sobre LAN.

El Snooping (fisgoneo), es una técnica por la cual los switches de nivel 2 pueden inspeccionar algunos campos de protocolos de nivel 3 como DHCP o IGMP, para hacer un uso más eficiente de los recursos evitando usar la técnica de inundación (flooding) para el caso de multicasting.

Existe una amplia cantidad de fabricantes que aportan esta capacidad (por ejemplo la familia Catalyst de Cisco, o los 3Com 4xxx y 5xxx o Nortel BayStack, entre otros). Esta técnica es ampliamente usada, además del soporte de los protocolos de enrutamiento multicast que se verán al final del tema.

2.3

(31)

E. P. S. de Linares Cuando el switch escucha un mensaje IGMP de unirse a un grupo proveniente de un host, almacena la dirección del grupo multicast y el puerto por donde escuchó el mensaje.

El switch mantiene una tabla con los grupos multicast que están activos en cada enlace. Luego, cuando le llegue un mensaje dirigido a la dirección de grupo almacenada, lo enviará sólo por lo puertos por donde haya escuchado mensajes de unión a ese grupo. En el caso de recibir un mensaje de dejar grupo (IGMPv2 o IGMPv3) el switch comprueba su tabla y elimina esa entrada. Si ya era el último host multicast en ese enlace, “poda” esa rama y no usará ese enlace para envíos posteriores.

Multicast sobre LAN.

El Snooping IGMP no es tan fácil como parece, y requiere un comportamiento inteligente y muy activo por parte del switch.

Los reports de cada host deben ser capturados y ocultados a los demás host evitando que entren en el estado activo.

De esta forma se les hace pensar que están solos para que así cada host envíe su report y pueda ser capturado por el switch.

Luego el switch envía uno de estos mensajes al router, pero sólo al router, o bien falsifica uno para simular su propio ingreso en la red.

2.3

(32)

E. P. S. de Linares Debido a que pueden existir más de un host perteneciente a un grupo multicast en cada enlace (si está conectado a un HUB), el switch debe hacer el mimo proceso que un router: query/timeout antes de podar un enlace.

En entornos de alta densidad de tráfico multicast, el switch puede verse saturado procesando tramas en busca de mensajes IGMP de report. Problema que normalmente se supera teniendo un software que separe inteligentemente los mensajes IGMP antes de ser enviados a la CPU (normalmente disponibles en switches de alta gama).

El switch tiene que conocer cual es el puerto del router multicast, lo cual lo consigue analizando las Queries IGMP.

Snooping con IGMP. Problemática

Multicast sobre LAN.

En general, debido a los diseños propios de las redes, el multicasting no se ha definido y no se entiende tan bien sobre LAN como sobre WAN. Algunos aspectos se relacionan a continuación:

El comportamiento de los switch no está estandarizado. Problemas con los switches:

Cuando el snooping está activado se descartan paquetes que NO deberían ser descartados.

Incluso sin snooping, algunas veces los switches rebasan su funcionalidad realizando tareas no propias de capa 2.

2.3

(33)

E. P. S. de Linares Intentar evitar el uso del snooping. Según algunos autores crea más problemas que soluciona.

Mantener las subredes pequeñas. De esta forma es menos probable que haya hosts que se unan a diferentes grupos multicast y así se evita tener el tráfico de estos grupos por la subred.

Si es posible, usar routers como puentes y no switches.

Si es necesario usar switches es conveniente que todos pertenezcan al mismo fabricante y tenga versiones iguales o similares del software. De esta forma se consigue un funcionamiento consistente y se evitan algunos comportamientos impredecibles.

Encaminamiento Multicast.

Una vez vista la gran ventaja que supone IP multicast, nos centramos en el trabajo de los routers.

Lo router no sólo deben saber la afiliación de los host a el conectados pertenecientes a su subred y usar IGMP para esto, si no que, al estar inmersos en Internet, deben:

Conocer o intentar conocer, donde están los diferentes grupos multicast.

Elegir el mejor camino posible para cada uno de los paquetes multicast que envían a grupos fuera de su subred.

Evitar siempre la formación de bucles que conllevaría a una “avalancha” multicast.

2.4

(34)

E. P. S. de Linares Para poder hacer esto se hace uso de protocolos de encaminamiento multicast.

Los protocolos de encaminamiento multicast hacen uso de IGMP para conocer la filiación de cada host a los grupos multicast, pero varía la forma de comunicar esta información entre routers vecinos, así como la forma de construir los árboles de distribución.

Los protocolos de encaminamiento podemos dividirlos en dos grandes familias: Protocolos de Vector de Distancia

Protocolos de Estado de Enlace.

Introducción.

i

Encaminamiento Multicast.

Protocolos de vector distancia (1/2).

Basados en el algoritmo de "camino más corto" del Bellman-Ford.

Cada nodo distribuye todo el mapa de encaminamiento a sus vecinos de forma periódica, de tal forma que cada nodo se va haciendo una imagen de la red en su conjunto.

Cada nodo asigna un "peso" o métrica a cada ruta en función de los saltos necesarios para alcanzar a otro nodo.

2.4

(35)

E. P. S. de Linares Protocolos de vector distancia (2/2).

Su principal ventaja es su sencillez de operación y por ende, de implementación. Mientras que su mayor desventaja es su problema de escalabilidad. A medida que la red se hace mayor y más compleja, el algoritmo se vuelve menos eficiente y se produce un mayor consumo de ancho de banda en los enlaces por la diseminación de las tablas de encaminamiento.

Por otro lado también es posible la formación de bucles de encaminamiento (aunque existen implementaciones de este tipo de protocolo que evitan, en gran medida, este inconveniente).

i

Encaminamiento Multicast.

Protocolos de estado del enlace (1/2).

Se basan en el concepto de un "mapa distribuido", es decir, que todos los nodos tienen una copia del mapa de la red, que se actualiza periódicamente.

Se han desarrollado a partir de un algoritmo más eficiente que el de Bellman-Ford, propuesto por E.W. Dijkstra, llamado "el camino más corto primero" (shortest path first).

2.4

(36)

i

E. P. S. de Linares Protocolos de estado del enlace (2/2).

Algunas de sus principales ventajas son:

Rápida convergencia a la descripción real del estado de la red,

Ausencia de creación de bucles, el soporte de métricas (costes asociados a un determinado enlace) múltiples,

Soporte de múltiples rutas a un mismo destino.

Como contrapartida requieren mayor poder de procesamiento en los routers y son complejos de implementar y/o configurar.

Nota sobre encaminamiento.

i

Encaminamiento Multicast.

En cuanto a los algoritmos empleados por los protocolos de encaminamiento multicast se pueden dividir en dos grandes categorías:

Basados en técnicas simples Inundación (flooding). MAC-layer Spanning Trees.

Basados en técnicas de árboles centrados en la fuente (Source-based trees) Reverse Path Broadcasting (RPB).

Truncated Reverse Path Broadcasting (TRPB). Reverse Path Multicasting (RPM).

2.4

(37)

E. P. S. de Linares Orientación y reenvío de ruta inversa (1/2)

La orientación representa un esquema sencillo de enrutamiento que no depende de ningún tipo de información de enrutamiento. En este esquema, se transmite un paquete a todas las interfaces excepto a la interfaz remitente. Para limitar el número de veces que el paquete se replica, se utiliza una métrica, por ejemplo una cuenta de saltos. Cuando la métrica alcanza un umbral, el paquete se elimina.

El problema que surge con este esquema es que se crea un número exponencial de copias de cada paquete. La orientación, por un lado, garantiza el envío a cada nodo de una copia de cada paquete, considerando que los paquetes no se pierden y, por otro lado, puede generar tanta congestión que es muy probable que los paquetes se pierdan.

i

Encaminamiento Multicast.

Orientación y reenvío de ruta inversa (2/2)

Reenvío de ruta inversa (RPF, Reverse Path Forwarding)es un concepto que fue utilizado por

primera vez por Yogen Dalal.

Representa una forma optimizada de orientación, en la que el enrutador acepta un paquete de un origen S a través de una interfaz I, sólo si I es la interfaz que el enrutador utilizaría para llegar a S. Determina si la interfaz es correcta mediante la consulta en las tablas de enrutamiento de unidifusión. Esta técnica disminuye en gran medida la sobrecarga de trabajo relacionado con la orientación estándar. Considerando que un enrutador acepta un paquete desde un único vecino, orienta el paquete sólo una vez, lo que significa (si suponemos vínculos de punto a punto) que cada paquete se transmite por un vínculo una sola vez en cada dirección.

2.4

(38)

i

E. P. S. de Linares Árboles de ruta de acceso más corta (1/2)

Los árboles de ruta de acceso más corta también se conocen como árboles basados en el origen, lo que significa que las rutas de reenvío se basan en la ruta de unidifusión al origen más corta. Esto es lo que se quiere dar a entender cuando se dice que los árboles de origen se consideran los árboles de ruta de acceso más corta desde la perspectiva de las tablas de enrutamiento de unidifusión.

Si la métrica de enrutamiento se basa en cuentas de saltos, las ramas de los árboles de ruta de acceso más corta de multidifusión representan los saltos mínimos. Si la métrica simboliza retraso, las ramas representan el retraso mínimo.

Notas sobre enrutamiento.

i

Encaminamiento Multicast.

Árboles de ruta de acceso más corta (2/2)

Para cada origen de multidifusión, hay un árbol de multidifusión correspondiente que conecta directamente el origen con todos los receptores.

Una vez construido el árbol para el origen y para el grupo asociado, todo el tráfico a los miembros del grupo circula por este árbol.

Los árboles de ruta de acceso más corta tienen una entrada (S, G) con una lista de interfaces salientes, donde S es la dirección de origen y G el grupo de multidifusión.

Como ejemplos de otros protocolos que utilizan este tipo de árboles se pueden destacar DVMRP y MOSPF, que son protocolos de modo denso.

2.4

(39)

E. P. S. de Linares Árboles compartidos (1/4)

Los árboles compartidos se conocen por árboles RP o árboles de punto de reunión (RPT), ya que confían en un enrutador central, el punto de reunión (RP), que recibe todo el tráfico desde los orígenes y lo reenvía a los receptores.

Los miembros envían uniones explícitas al nodo central, ya que no se supone que todos los hosts sean receptores. Se obtiene como resultado un único árbol para cada grupo de multidifusión, independientemente del número de orígenes.

Los únicos enrutadores que tienen información acerca del grupo son los que se encuentran en el árbol y los datos se envían sólo a los receptores interesados.

i

Encaminamiento Multicast.

Árboles compartidos (2/4)

Los árboles compartidos tienen una entrada (*, G), denominada comodín, donde G es el grupo de multidifusión. Con un punto de reunión, los receptores tienen un lugar al que se pueden unir aunque en ese momento no exista ningún origen.

El árbol compartido es unidireccional, lo que significa que los datos fluyen sólo desde el punto de reunión hacia los receptores.

Para que un host diferente al punto de reunión realice envíos en el árbol, los datos se deben enviar por un túnel al punto de reunión antes de que se pueda realizar la multidifusión a los participantes.

2.4

(40)

i

E. P. S. de Linares Árboles compartidos (3/4)

Según lo visto, si un receptor representa también un origen, no puede utilizar ese árbol para enviar paquetes al punto de reunión. Sólo lo puede utilizar para recibir paquetes desde él.

Hay casos excepcionales, como cuando el origen se encuentra entre el punto de reunión y los receptores, y ya está en el árbol. En este caso, los datos fluyen directamente desde el origen hacia los receptores.

Los árboles de punto de reunión sufren mayores retrasos (los paquetes deben enviarse al punto de reunión antes de que se puedan distribuir) pero tienen que mantener menos información de estado de enrutador.

Notas sobre enrutamiento.

i

Encaminamiento Multicast.

Árboles compartidos (4/4)

A continuación se indican algunos ejemplos de aplicaciones en los que este tipo de árboles resulta adecuado:

Redes con muchos orígenes de datos de baja velocidad Aplicaciones que pueden tolerar retrasos

Aplicaciones que requieren políticas y control de acceso lógicos para muchos de los participantes de un grupo

Redes en las que la mayor parte de los árboles de origen se solapan topológicamente con el árbol compartido

2.4

(41)

E. P. S. de Linares El primer protocolo de routing multicast que fue implementado, y que dio lugar al surgimiento de MBone, fue DVMRP (Distance Vector Routing Protocol, RFC 1075). Los routers multicast usaban este protocolo para intercambiar información con otros routers multicast similares a través de túnelesdefinidos por los administradores de los

mismos.

Desde la aparición del primer protocolo de encaminamiento multicast, se han realizado grandes esfuerzos (coordinados por el IETF), para definir otros protocolos más sencillos o de más fácil integración dentro de los protocolos de encaminamiento operativos en Internet. Uno de estos, el PIM (Protocol Independent Multicast), lo que ha hecho que fuera sustituyendo progresivamente al DVMRP.

Encaminamiento Multicast.

El DVMRP es un protocolo del tipo `vector distancia' que usa la técnica `Reverse Path Multicasting' (este es un refinamiento de la técnica `Reverse Path Forwarding' empleada originalmente en este protocolo), para construir árboles de encaminamiento multicast basados en la fuente (Source-based multicast delivery trees).

De acuerdo con esta técnica, el primer datagrama recibido para cualquier pareja {origen,grupo multicast} es remitido a todas las interfaces de red del mrouter, excepto a aquella por la que ha sido recibido, siempre que sea esta interfaz la usada por el protocolo de encaminamiento unicast para enviar datagramas a dicho origen, o en caso contrario será descartado el datagrama.

2.4

(42)

E. P. S. de Linares Tras recibir estos datagramas, los routers de los extremos del árbol de distribución, o routers hojas (leaf nodes), podrían transmitir mensajes de `podado' (pruning) hacia el origen de los mismos, en el caso de que no existiesen equipos finales conectados a dicho grupo multicast en la sub-red.

Por otro lado, se implementa el mecanismo de `injerto' (graft) que es remitido por cada router a sus vecinos ascendentes, en caso de que existan equipos que se hayan unido a un grupo multicast en una rama del árbol de distribución previamente `podada'.

El DVMRP construye su propia tabla de encaminamiento unicast de una forma similar al RIP (Routing Information Protocol), en la que guarda la información de la interfaz que conduce a la fuente de un determinado datagrama multicast.

DVMRP (Distance Vector Multicast Routing Protocol)

Encaminamiento Multicast.

Para poder extender el ámbito de distribución del multicast a través de encaminadores que no son capaces de entender este tipo de tráfico, se desarrolló el concepto de túneles. De esta forma se pueden interconectar entre sí las distintas sub-redes o `islas' multicast a través de medios físicos de transporte convencional unicast.

Cada túnel tiene asociado un umbral (threshold) que permite limitar el ámbito de distribución de los datagramas multicast en función del campo TTL asociado a los mismos.

Cada datagrama multicast recibido por un router decrementa el valor del TTL del mismo y posteriormente lo compara con los umbrales definidos en sus túneles.

2.4

(43)

E. P. S. de Linares Si el TTL resultante es mayor que dicho umbral, el datagrama será distribuido a través de dicho túnel y en caso contrario será descartado. Este método de limitación del ámbito de distribución de los datagramas multicast tiene sus limitaciones.

Por ejemplo, aparecen conflictos cuando se trata de aplicar límites simultáneamente en base a criterios topológicos, geográficos y de ancho de banda.

En particular, este esquema no es válido cuando se trata de aplicar a regiones que se solapan.

Encaminamiento Multicast.

Con la intención de resolver estos problemas se desarrolló un método de limitación del alcance en base a criterios administrativos (Administratively Scoped IP Multicast), ya sea localmente, a un determinado centro u organización, o a un conjunto de ellas. Para ello ha sido reservado por la IANA un determinado rango de direcciones multicast (239.0.0.0 a 239.255.255.255).

Estas extensiones han sido desarrolladas dentro del grupo de trabajo mboneddel IETF.

2.4

(44)

E. P. S. de Linares El MOSPF (Multicast Open Shortest Path First), definido en el RFC 1584, es una extensión al protocolo de encaminamiento unicast OSPF (RFC 1583).

El OSPF un protocolo del tipo `estado del enlace', que permite un cálculo rápido de las rutas con un mínimo de intercambio de información entre routers.

El MOSPF es una simple extensión al anterior, que incluye la posibilidad del encaminamiento del tráfico multicast.

La ventaja de este esquema es que el protocolo de encaminamiento multicast se aprovecha del protocolo unicast, y no tiene que construir sus propias tablas de encaminamiento independientemente.

MOSPF (Multicast Open Shortest Path First)

Encaminamiento Multicast.

El MOSPF sólo añade la información de origen y grupo multicast a los mensajes de estado del enlace, con los que el OSPF crea su mapa de la topología de red.

El disponer de una descripción del estado del enlace con la información de filiación de miembros a los distintos grupos multicast, permite la construcción de las árboles de envío de camino más corto en la memoria de los mrouters, esto es, no necesita, como DVMRP, diseminar el primer datagrama recibido hacia todas las interfaces.

Por otro lado, la construcción del diagrama de distribución se realiza "bajo demanda" cuando un mrouter recibe el primer datagrama para una determinada pareja {fuente, grupo}.

2.4

(45)

E. P. S. de Linares Este esquema presenta la desventaja de que puede sobrecargar la CPU del router en los casos en los que varias parejas {fuente,grupo} aparecen al mismo tiempo, o cuando concurran muchas circunstancias que fuercen la reconstrucción de las cachés de remisión (forwarding caches).

El MOSPF, al igual que su homólogo unicast (el OSPF) es un protocolo diseñado para operar dentro del ámbito de la intra-red (intranet), y no soporta el uso de túneles.

Encaminamiento Multicast.

Otros protocolos han sido definidos en el ámbito del grupo de trabajo idmr del IETF para solucionar el problema del encaminamiento multicast:

PIM-DM (Protocol Independent Multicast-Dense Mode) PIM-SM (Protocol Independent Multicast-Sparse Mode).

Ambos comparten parte del nombre y emplean mensajes de control similares, pero son dos protocolos diferentes.

PIM recibe su nombre de la independencia que presenta de los mecanismos de encaminamiento unicast subyacentes, delegando en estos la tarea de determinar el camino hacia la fuente de los datagramas multicast, a la hora de construir el árbol de distribución para cada pareja {fuente, grupo}.

2.4

(46)

E. P. S. de Linares PIM-DM usa, del mismo modo que el DVMRP, el algoritmo de `Reverse Path Multicasting‘.

A diferencia del el DVMRP, el protocolo PIM-DM remite los datagramas recibidos para cada pareja {fuente,grupo} a todas las interfaces de red, excepto a aquella por la que se ha recibido el datagrama multicast, y sólo son eliminados aquellos caminos por los se han recibido explícitamente mensajes de `podado' (pruning) porque no existan miembros de ese grupo.

Este modelo de funcionamiento presenta una mayor eficiencia en el caso de que los miembros de los grupos multicast estén próximos entre sí y el ancho de banda no sea un recurso escaso.

PIM –DM (Protocol Independent Multicast Dense Mode)

Encaminamiento Multicast.

El protocolo PIM-SM [RFC 4601 versión 2], se ha desarrollado principalmente para intentar paliar las deficiencias presentadas por el DVMRP y MOSPF en los casos en que los enlaces entre routers están dispersos a lo largo de amplias zonas y que los miembros de cada grupo multicast no están concentrados en las proximidades de los routers, situación que se presenta en las topologías de red extensa (WAN).

DVMRP, MOSPF y PIM-DM:

Se comportan más o menos eficientemente en condiciones de una distribución poblada de receptores dentro de una intranet.

Fallan cuando se aplican a entornos de red extensa (WAN) o de población esparcida.

2.4

(47)

E. P. S. de Linares Sparse Mode o Modo esparcido significa que el protocolo está diseñado para situaciones donde los grupos de multidifusión están dispersos en una región extensa. Los protocolos de modo esparcido pueden funcionar en entornos de redes de área local (LAN), pero son más eficaces en las redes de área extensa.

El protocolo PIM-SM puede usar simultáneamente las técnicas de árbol basado en la fuente (source-based tree) o de árbol compartido (shared tree).

Encaminamiento Multicast.

Características y objetivos de diseño.

Conservar el modelo de servicio tradicional de la multidifusión IP.

La pertenencia al grupo de multidifusión es iniciada por el receptor. En este modelo, las fuentes sólo colocan paquetes en Ethernet de primer salto, sin ninguna señalización. Los receptores emiten señales a los routers para unirse al grupo de multidifusión que recibirá los datos.

No alterar el modelo de host. PIM-SM es un protocolo de enrutador a enrutador.

Los hosts no tienen por qué actualizarse, pero deben distribuirse en la red enrutadores compatibles con PIM-SM.

2.4

(48)

E. P. S. de Linares Características y objetivos de diseño.

Permitir tanto árboles compartidos como de distribución de origen (PIM-SM puede utilizar cualquier tipo de árbol o ambos simultáneamente)

Árboles compartidos:PIM-SM utiliza un enrutador central, denominado punto de reunión

(RP, Rendezvous Point), como raíz del árbol. Todos los hosts de origen envían el tráfico de multidifusión al punto de reunión que, a su vez, reenvía los paquetes a través de un árbol común a todos los miembros del grupo.

Árboles de origen:Conectan directamente los orígenes con los receptores. Hay un árbol

independiente para cada origen. Desde la perspectiva de las tablas de enrutamiento de unidifusión, los árboles de origen se consideran árboles de ruta de acceso más corta.

PIM –SM (Protocol Independent Multicast Sparse Mode)

Encaminamiento Multicast.

Características y objetivos de diseño.

Conservar la independencia de cualquier protocolo de enrutamiento de unidifusión. Utilizar mecanismos de estado flexible para adaptarse a las condiciones de red y a las dinámicas de grupos de multidifusión cambiantes.

Estado flexible:significa que, a menos que se actualice, la configuración del estado del

enrutador es a corto plazo y que caduca después de un cierto tiempo.

La versión 2 de PIM-SM encapsula sus mensajes en paquetes IP con el número de protocolo 103

2.4

(49)

E. P. S. de Linares [RFC 1075] Distance Vector Multicast Routing Protocol, D. Waitzman, C.

Partridge, S. Deering, Standford University, Noviembre de 1988.

[RFC 2328] OSPF Version 2, J. Moy April 1998 ASCII STANDARD (Obsoletas

RFCs 2178 y 1583)

[PIM-DM] Protocol Independent Multicast Dense Mode, Protocol Specification.

V. Jacobson, D. Farinacci, L. Wei, S. Deering, A. Helmy. Internet-Draft.

[RFC 3973] Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised).

Adams, A., Nicholas, J., and W. Siadak, January 2005.

Bibliografía en Internet

Request for Comments (http://www.ietf.org/rfc.html)

Ref

[RFC4601] Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner, M. Handley, H. Holbrook, I. Kouvelas August

2006, Obsoletes RFC2362 PROPOSED STANDARD Otros enlaces de interés.

[PIMSM-MS] Protocolo de enrutamiento de multidifusión PIM-SM

http://www.microsoft.com/latam/technet/articulos/windows2k/pimsm2/