Multicast IGMP v1

 Se basa en consultas (Membership Query) que hace el Router principal (Querier)

hacia los hosts que desean unirse al grupo multicast.
 El Querier envía mensajes de consulta IGMP al 224.0.0.1 con TTL = 1 (Hosts mas
cercanos)
 Se designa un router LAN para enviar dichas consultas (Querier).
 El intervalo de consulta del Querier es cada 60 segundos.
 Los Membership Reports (Informes) los envían los hosts y sirven para informar al
Querier que se desea unirse a un determinado grupo multicast.
 Los hosts responden el Query enviado a la 224.0.0.1 con la IP Multicast del grupo
al que desea unirse.
 No existe la forma de avisarle al Querier que se desea abandonar el grupo.
IGMP v1 – Uniéndose a un grupo
IGMP v1 – Uniéndose a un grupo
IGMP v1 – Uniéndose a un grupo
IGMP v1 – Abandono de un grupo
Problemas con IGMP v1
 Cuando un host abandona un grupo el tráfico multicast puede seguir inundando
esa LAN durante un tiempo largo (tres minutos). Si el usuario hace ‘zapping’
esto consume mucho ancho de banda inútilmente y puede suponer un problema
en la red. (Si un usuario
 No se especifica por que mecanismo se elige al ‘Query router’. Se supone que se
utilizará el router elegido como designado por el protocolo de routing.
 Los timeouts para la recepción de informes no se pueden configurar
dinámicamente.
Mejoras de Multicast IGMP v2
 Hay un mensaje ‘Leave Group’ que permite a los hosts notificar al router de forma
explícita cuando abandonan un grupo. Lo hacen enviando el mensaje a la dirección
224.0.0.2 que corresponde a todos los router multicast de la red.
 Existen dos tipos de Query:
 Query General (equivalente al Membership Query de IGMP v1)
 Query específico de grupo (permite a los routers lanzar una pregunta dirigida
exclusivamente a los miembros de un grupo multicast determinado).
 La elección del Query router se realiza de forma independiente al protocolo de
routing. Se elige el de dirección IP más baja.
 Los timeouts para la recepción de informes se pueden modificar dinámicamente y
anunciarse en los mensajes IGMP de Query
Mejoras de Multicast IGMP v2

Dirección
Tipo Emitido por Función
de destino
Consulta General Preguntar a los hosts si están
Routers 224.0.0.1
(General Query) interesados en algún grupo multicast
Consulta específica Preguntar a los hosts si están
La del grupo
Nuevo de grupo (Group- Routers interesados en un determinado grupo
en cuestión
Specific Query) multicast
Informe de Informar a los routers que el host
La del grupo
Pertenencia Hosts está interesado en un determinado
en cuestión
(Membership Report) grupo multicast
Informar a los routers que el host
Abandono de Grupo
Hosts deja de estar interesado en un grupo 224.0.0.2
(Leave Group)
multicast
Nuevo
 Multicast IGMP v2 leave
 En primer lugar la aplicación en el
host C decide abandonar el grupo
224.2.2.2 al que pertenece. Por tanto
emite un mensaje ‘Leave Group’ a la
dirección 224.0.0.2 (todos los routers
multicast).
 El mensaje es recibido por X, que
envía entonces un ‘Group-Specific
Query’ a la dirección 224.2.2.2.
 A responde con un ‘Membership
Report’ dirigido a 224.2.2.2 indicando
su interés en seguir perteneciendo a
dicho grupo.
 Como consecuencia de este mensaje
X e Y deciden mantener al grupo
224.2.2.2 en su lista.
 Multicast IGMP v2 leave
 En este caso el host A decide abandonar
el grupo 224.2.2.2, por lo que envía un
‘Leave Group’ a 224.0.0.2 indicándolo.
 Al recibirlo el router X envía un ‘Group-
Specific Query’ al grupo 224.2.2.2, y
espera el timeout establecido.
 Después de pasado ese tiempo sin haber
recibido respuesta X borra 224.2.2.2 de
su lista.
 El router Y, que no ha emitido ningún
mensaje IGMP, ha recibido todos los
mensajes y seguido todo el proceso, por
lo que también decide borrar 224.2.2.2
de sus tablas aproximadamente en el
mismo momento que X.
Compatibilidad IGMP v1 y v2 y mejoras de v3
 En general cuando en una red hay algún router o algún host que utiliza IGMP v1
todo el conjunto funciona como IGMP v1
 A menudo en estos casos los routers han de configurarse manualmente para que
funcionen con IGMP v1 (para que sepan que no deben enviar los mensajes ‘Group
Specific Query’)
 La aportación de IGMPv3 es que la elección de los flujos multicast ya no se limita
solo a la dirección de destino; también se puede especificar la dirección de origen
 Esto permite aislar a ‘saboteadores’ o ‘indeseables’. Evita que se puedan producir
ataques de denegación de servicio en emisiones multicast.
 A la funcionalidad aportada por IGMPv3 se la denomina SSM, Source Specific
Multicast.
Mensajes IGMP v3
 El Membership Report puede indicar una serie de fuentes a incluir, o a excluir, ej.:
 Unirse (Join):
 ‘Membership Report 224.1.1.1 EXCLUDE ()’ (indicar que se desea recibir el tráfico de todas las
fuentes menos las indicadas explícitamente)
 Abandonar (Leave):
 ‘Membership Report 224.1.1.1 INCLUDE ()’ (se desea recibir solo el tráfico de las fuentes
indicadas)
 El comando Query tiene ahora tres modalidades:
 General Query (v1)
 Group-Specific Query (v2)
 Group-and-Source-Specific Query (v3) (permite a los routers preguntar a los hosts si siguen
interesados en recibir el tráfico multicast de un grupo determinado originado por una fuente
concreta).
 Mensajes IGMP v3
Dirección de
Tipo Emitido por Función
destino

Consulta General Preguntar a los hosts si están

Routers interesados en algún grupo 224.0.0.1
(General Query) multicast

Consulta específica de grupo Preguntar a los hosts si están

La del grupo en
Routers interesados en un determinado
(Group-Specific Query) cuestión
grupo multicast
Preguntar a los hosts si están
Consulta específica de grupo y fuente interesados en un determinado La del grupo en
Routers
(Group-and-Source-Specific Query) grupo multicast de una serie de cuestión
Nuevo fuentes determinada
Informar a los routers que el
Informe de Pertenencia host está interesado en un
Hosts determinado grupo multicast 224.0.0.22
(Membership Report) (indicando una serie de fuentes
Modificado a incluir o a excluir)
 Multicast IGMP v3 en funcionamiento
 El host A está interesado en la emisión multicast
224.1.1.1, y así se lo indica X. Como en principio no
sabe quienes emiten en dicho grupo emite un
‘Membership Report’ indiscriminado, de forma que
recibe todo el tráfico multicast de la red.
 El router X recibe el ‘Membership Report’ y anota en su
tabla el nuevo grupo. El protocolo de routing recopila
todo el tráfico generado (Y, Z) en dicho grupo multicast,
con lo que A empieza a recibir el tráfico generado por las
fuentes B y C.
 Luego al host A no le interesa el trafico de C y se lo
indica al router X para que suprima el tráfico innecesario.
 Entonces envía un ‘Membership Report’ indicando el
filtro EXCLUDE (140.34.1.1). Entonces el router emite
un ‘Group-and-Source-Specific Query’ para confirmar
que ningún host está ya interesado en el tráfico generado
por C. Al no recibir ninguna respuesta dentro del timeout
previsto X decide añadir el filtro EXCLUDE (140.34.1.1)
en su lista. El protocolo de routing multicast envía un
mensaje de poda al router Z, que como consecuencia
suprime la emisión generada por 140.34.1.1
Multicast en una LAN conmutada
Servidores de vídeo
WAN
MPEG-2 multicast
P4 4 x 3 Mb/s
P1: 239.192.0.1 P3
P2: 239.192.0.2 P2 12 Mb/s
P1
P3: 239.192.0.3
P4: 239.192.0.4
 Problema:
Se inunda la red
con trafico
multicast 100 Mb/s
innecesario.
10 Mb/s

P3 P4

P1 P1
Multicast con router en medio
Solución: conectar los servidores de
video a un router. El router tiene que procesar
El mimso recibirá los mensajes IGMP P4 todo el tráfico de vídeo
de los hosts y sabrá que grupos P3
P2
multicast tienen miembros y cuales no. P1
Si algún servidor no está siendo visto WAN
por ningún usuario (caso del programa
P2 en el ejemplo de la figura) ese Servidores de vídeo 6
39Mb/s
Mb/s
tráfico multicast será filtrado por el MPEG-2 multicast
router.
Sin embargo esta solución no es muy
buena, ya que basta que un solo usuario
pida un contenido para que todos los
hosts de la LAN reciban el flujo
multicast correspondiente.
Además esta solución requiere que el
router procese todo el tráfico multicast
enviado por la LAN (9 Mb/s en el
ejemplo). Esta es una tarea mucho mas
pesada que el simple filtrado del tráfico
multicast para la detección de los
mensajes IGMP que realizaba el router
en la topología anterior. P3 P4

P1 P1
 Multicast con VLANs
Servidores de vídeo
MPEG-2 multicast WAN

P4 El router tiene que procesar

VLAN P3 todo el tráfico de vídeo
Servidores P2
P1 Enlaces ‘Trunk’

Otra Solución: utilizar

VLANs para usuarios que
comparten los mismos
intereses, para que cuando
soliciten un contenido, solo
inunden la VLAN a la que
pertenecen.

P3 P4

P1 P1

VLAN A VLAN B VLAN C

Multicast en LAN conmutada

 Cuando un host desea recibir un grupo multicast tiene que emitir un

IGMP Membership Report
 Analizando los mensajes IGMP que pasan por él un conmutador podría
saber por que puertos debe distribuir cada grupo multicast, y filtrar el
tráfico innecesario
 Esto se conoce como ‘IGMP snooping’ (snooping = husmear)
 IGMP Snooping
 Para realizar el IGMP snooping los conmutadores han de realizar el siguiente proceso:
 Ver si se trata de una trama multicast
 Ver si se trata de un paquete IP (por ejemplo campo Ethertype = x’0800)
 Ver si se trata de un mensaje IGMP (valor 2 en el campo protocolo de la cabecera IP)
 Una vez comprobado todo, el conmutador ha de interpretar el mensaje IGMP y actuar en consecuencia
 Este proceso puede hacerse de dos formas:
 Por hardware: se incorporan ASICs adicionales al conmutador para que no intervenga la CPU.
Normalmente esto solo se hace en conmutadores de gama alta
 Por software: la CPU realiza el IGMP snooping. Normalmente esto limita el rendimiento del equipo
en tráfico multicast
Multicast en LAN con IGMP snooping
Con IGMP Snooping cada
flujo multicast se
distribuiría únicamente
por aquellos puertos donde
fuera necesario para
El router no reenvía el tráfico multicast,
pero ha de procesar todos los paquetes
por si contuvieran mensajes IGMP
Servidores de vídeo WAN
MPEG-2 multicast
P4
P3
P2 Conmutador con IGMP
P1
Snooping por hardware

satisfacer las peticiones

realizadas por los
usuarios.
El router ha de recibir todo Conmutadores con
el tráfico multicast y IGMP Snooping por
software
procesarlo por si
contuviera mensajes
IGMP, pero no ha de
reenviarlo ya que no
participa en la distribución
de los flujos de vídeo. P3 P4

P1 P1
 Supresión de informes con IGMP Snooping
 La supresión de informes permite que un host omita el envío del ‘Membership Report’ si otro ya lo ha
enviado. Esto da al traste con el IGMP Snooping, los conmutadores ya no saben exactamente en que
puertos están los receptores multicast.
 Una solución es que los conmutadores propaguen los ‘Membership Report’ solo por los puertos por
donde recibieron los ‘Membership Query’ (que es donde está el router que preguntó).
 Pero los ‘Membership Report’ también se han de enviar a los demás routers, aunque no hayan lanzado la
pregunta. Los conmutadores pueden ‘descubrir’ a los routers por algunos mensajes característicos, o se
puede indicar en la configuración del conmutador.
 Todo esto complica el funcionamiento de IGMP Snooping.
 En IGMP v3 los ‘Membership Report’ se envían a la dirección 224.0.0.22, que solo es recibida por los
routers IGMP v.3 y no por los hosts. Por tanto en IGMPv3 no existe la supresión de informes, lo cual
simplifica el IGMP Snooping.
Routing Multicast – Funcionamiento.
 Una vez el router sabe (por IGMP) en que grupos multicast están interesados los hosts
de su LAN debe ‘conspirar’ con los demás routers para conseguir que dichos paquetes
le lleguen desde donde se estén produciendo
 El routing multicast funciona al revés que el unicast: se enruta en función de la
dirección de origen, no de la de destino.
 El receptor busca la ruta óptima para llegar al emisor. Cuando la encuentra solicita a
los routers del camino le hagan llegar los paquetes
 Condición: debe haber una ruta unicast viable emisor-receptor y dicha ruta debe ser
simétrica
Modo denso y modo disperso

 Modo denso: inicialmente los datagramas multicast se propagan por toda la red y
establecen un árbol óptimo sin bucles (spanning tree); si algún router no está
interesado en la emisión solicita cortar su rama del árbol enviando un mensaje
‘prune’ (prune = podar).
 Modo disperso: Se presupone que solo una minoría de los routers están
interesados en la emisión por lo que en principio no se le envía a ninguno; si a
alguno le interesa lo debe solicitar con un mensaje ‘join’ (unirse, apuntarse).
Modo denso
 Es el más antiguo y el más sencillo
 Se utiliza cuando hay un gran ancho de banda o cuando una mayoría de los
routers quieren recibir el grupo multicast
 No es eficiente cuando el número de receptores es minoritario
 No es escalable.
 Protocolos que utilizan el modo denso:
 DVMRP (Distance Vector Multicast Routing Protocol). RFC 1075 (11/1988)
 PIM-DM (Protocol Independent Multicast – Dense Mode). RFC 3973
(1/2005)
 MOSPF (Multicast OSPF) RFC 1584 (3/1994)
 Modo disperso

 Es preferible al modo denso cuando el número de receptores es

minoritario
 Es el más utilizado actualmente en Internet, pues es escalable
 Protocolos que utilizan el modo disperso:
 PIM-SM v2 (Protocol Independent Multicast – Sparse Mode) RFC 2362
(6/1998)
 CBT v2 (Core Based Trees) RFC 2189, 2201 (9/1997)
 BGMP (Border Gateway Multicast Protocol) RFC 3913 (9/2004)
 PIM-DM (Protocol Independent Multicast –
Dense Mode)
 Para calcular las rutas óptimas utiliza la tabla de routing unicast, independientemente del
protocolo utilizado para obtenerla (de ahí lo de ‘protocol independent’). Puede usar OSPF,
IS-IS, EIGRP e incluso rutas estáticas
 El tráfico se transmite inicialmente por inundación. Los bucles se evitan por la técnica
denominada ‘RPF Check’
 Los routers no interesados pueden enviar comandos ‘prune’ (podar); si cambian de opinión
pueden enviar comandos ‘graft’ (injertar)
 La inundación (y el consiguiente podado) se repite cada 3 minutos
 Ha sido estandarizado por el IETF en el RFC 3973
 Se utiliza en Internet junto con PIM-SM
 RPF check (Reverse Path Forwarding check)
• Es una forma de evitar los bucles por inundación que consiste en que antes de reenviar
por inundación un paquete el router realiza la siguiente comprobación:
– Analiza la interfaz de entrada del paquete y su dirección de origen (unicast)
– Consulta en la tabla de rutas la interfaz de la ruta óptima hacia la dirección de origen
– Si la interfaz de entrada coincide con la de la ruta óptima el paquete es aceptado y
redistribuido por inundación. En caso contrario el paquete se descarta ya que
probablemente se trata de un duplicado
• El RPF check se usa en PIM-DM y PIM-SM
• El RPF check es incompatible con rutas asimétricas
 Funcionamiento del RPF check
Rutas óptimas hacia A
Emisor multicast

M M
A S0 B S1 C M
S0 S0
S1 S2 S2 S1
M M M S0
G
S0
S1 S1
M M M S1
D E F S2 M
S1 S0 S2
S0
M M

En cada bucle se envían

E sabe que su interfaz óptima hacia dos paquetes de más,
A es S1 y no S0; por tanto descarta pero como los routers
el paquete recibido por S0 los descartan no hay
problema
 Funcionamiento de PIM-DM
Inundación inicial

Red 1.1.1.0/24
1.1.1.0/24 S0 1.1.1.0/24 S1 1.1.1.0/24 S1
S1 S2 S2
Emisor multicast
1.1.1.2

M M
A S0 B S1 C M
S0 S0
S1 S2 S2 S1
M M M S0
G
S0 S1 S1 M
M M M S1
D M M
E F S2
S1 S2 1.1.1.0/24 S1
S0 S0

1.1.1.0/24 S1 1.1.1.0/24 S0 1.1.1.0/24 S0

S2 S2

Los paquetes recibidos en estas interfaces no son propagados

por inundación porque no superan la prueba del RPF Check
Funcionamiento de PIM-DM (II)
Emisión broadcast y Podado (Pruning)
Emisor de 224.2.2.2 M
1.1.1.2 Podado en B
1.1.1.2, S1 Podado en C
224.2.2.2 1.1.1.2, S1
224.2.2.2 S2

Podado en A M E0
1.1.1.2, S1 M M P
A B C M
224.2.2.2 S0 S1
S0 S0
M S1 M S2 M S2 S1 P
P S0
G
P P P M
P S0 P P P
M S1 M S1 M
S1
M M
D E F S2
S1 S2
2.2.2.2 S0 S0
M E0 E0

Grupos de E
1: Inundación
(flooding) 224.2.2.2

2: Podado
(prune) 170.2.2.2 160.2.2.2
Miembro de 224.2.2.2
 Funcionamiento de PIM-DM (III)
Injerto (Grafting)
Emisor de 224.2.2.2 M
1.1.1.2 Podado en B
1.1.1.2, S1 Podado en C
224.2.2.2 1.1.1.2, S1
224.2.2.2 S2

Podado en A M E0
1.1.1.2, S1 M M G
224.2.2.2
A S0 B S1 C
S0 S0
S1 M S2 M S2 S1
S0
G
S0 G
S1 S1 S1
D E F S2
S1 S0 S2
2.2.2.2 S0
M E0 M E0

Grupos de E
224.2.2.2 Grupos de F
224.2.2.2

170.2.2.2 160.2.2.2
Miembro de 224.2.2.2 Miembro de 224.2.2.2
Funcionamiento de PIM-DM (IV)
Aparición de un segundo emisor
Emisor de 224.2.2.2 M
1.1.1.2 Podado en B 160.2.2.2
2.2.2.2, S1 Podado en C
224.2.2.2 1.1.1.2, S1
224.2.2.2 S2
Podado en A M E0 P P E0
1.1.1.2, S1 M M2 M M2
224.2.2.2 A S0 B S1 C
S0 S0
2.2.2.2, S0 P S1 Podado en D M S2 M S2 S1
224.2.2.2 S0
2.2.2.2, S0 G
224.2.2.2 P
M2 S0
S1 S1 S1
M2
M2 M2 M2
D E F S2
2.2.2.2 S1 S0 S2
S0 Podado en F
Emisor de 224.2.2.2 M2 M E0 M2 M E0 M2
2.2.2.2, S2
Grupos de E 224.2.2.2
224.2.2.2 Grupos de F
224.2.2.2

170.2.2.2 160.2.2.2
Árbol para
Miembro de 224.2.2.2 Miembro de 224.2.2.2
2.2.2.0/24
Problemas del modo denso
 Cada router de la red ha de mantener:
 La topología del SPT (la relación de las ‘ramas’ que cuelgan de él en el árbol).
Para cada red emisora y cada grupo hay un árbol diferente
 La relación de las ramas que han sido podadas para cada emisor y cada grupo
(cada par (S,G), Source, Group)
 La gran cantidad de información de estado hace difícil establecer un servicio
multicast en una red grande para un número elevado de emisores y grupos
 Para construir el SPT inicial se procede por inundación. Para adaptarse a cambios en
la red el proceso se repite cada 2-3 minutos, lo cual genera mucho tráfico.
 Funcionamiento de PIM-SM
 Se basa para construir árboles en la tabla de routing unicast (como
PIM-DM). Puede usar OSPF, IS-IS, EIGRP, etc., incluso rutas estáticas
 Al funcionar en modo disperso no se hace inundación de la información
 Problema: como localizamos a los emisores
 Solución: establecemos un punto de encuentro donde los emisores se
registren y los receptores vayan a preguntar. Ese punto de encuentro es
un router que denominamos Rendezvous Point
 Funcionamiento de PIM-SM (I)
Árbol compartido, receptores primero
3: Fuente F1 de
G (224.2.2.2) M Registro de
1.1.1.2 emisores
C Ent Sa
l (F1,G) S0
B Ent Sa
l (F1,G) S0 S1
A Ent Sa
l (F1,G) S0 S1 RP Ent Sa
l
(F1,G) E0 S0 M RS S0
E0 RS (*, G) S1
RM RM
RM J RM RM
J RM
A S0 B S1 C RS
M S0 M S0 S1 J Rendezvous
S1 S2 S2 M
Point (®)
S0
® RP
M
S0
S1 S1 J S1
J M
D M® S2
S1 E S2 F
S0 M S0 F Ent Sa
l
M ® E0 M M ® E0 M
(*, G) S2 E0
S0
E Ent Sal
(*,G) S2 E0
3.3.3.3 2.2.2.3

2: Membership Report 1: ‘Membership Report

224.2.2.2 EXCLUDE ()’ 224.2.2.2 EXCLUDE ()’
G
 Red
Funcionamiento de PIM-SM (II) es
Árbol compartido, emisor primero
1: Fuente F1 de
1-36
G (224.2.2.2) M Registro de
1.1.1.2 emisores
C Ent Sa
l (F1,G) S0
B Ent Sa
l (F1,G) S0 S1
A Ent Sa
l (F1,G) S0 S1 RP Ent Sa
S0 l
(F1,G) E0 M E0 RS
RS (F1, G) S0 S1
RM J RM
J RM
A S0 B S1 C RS
M S0 M S0 S1 Rendezvous
M J
S1 S2 S2
Point (®)
S0
RP
S0
S1 S1 J S1
J M
D E F S2
S1 S2 F Ent Sal
S0 M S0
E0 M E0 M (*,G) S2 E0
S0

E Ent Sa
l
3.3.3.3 2.2.2.3
(*, G) S2 E0
3: ‘Membership Report 2: ‘Membership Report
224.2.2.2 EXCLUDE ()’ 224.2.2.2 EXCLUDE ()’
 Funcionamiento de PIM-SM (III)
Dos fuentes, árbol compartido
Registro de
emisores
Fuente F1 de (F1,G) S0
G (224.2.2.2) M
1.1.1.2 C Ent Sal (F2,G) S1

liació
Rede

Amp
(F1,G) S0 S1

s 1-
B Ent Sa

37

n
l
A Ent Sa
l (F1,G) S0 S1
RP Ent Sa
(F1,G) E0 S0 M E0 l
(F1, G) S0 S1
A S0 B S1 C
M S0 M S0 S1 Rendezvous
S1 S2 S2 M
S0 Point (®)

M RP
S0 S1
S1 S1 M2
S1 S2 M R RS
D S0 S0 F S2
E
M2
E0 E0
E Ent Sal M2 M M2 M F Ent Sal

(*, G) S2 E0 (*, G) S2 E0,S

0
(F2,G) E0 S0

3.3.3.3 2.2.2.3
2.2.2.2
Miembro de (*,G) Fuente F2 de G Miembro de (*,G)
 Funcionamiento de PIM-SM (IV)
Árbol SPT (Shortest Path Tree)

C Ent Sa
Fuente F1 de G (224.2.2.2) M l Registro de
(F1,G) S0 S1 emisores
1.1.1.2 B Ent Sa S2

liació
Rede

Amp
l (F1,G) S0

s 1-
38

n
(F1,G) S0 S1
S2
A Ent Sa
l
RP Ent Sa
(F1,G) E0 S0 M E0 l
(F1,G) S0 S1
A S0 B S1 M C
M S0 S0 S1 P Rendezvous
S1 M S2 S2 M
Point (®)
M S0
RP
S0 J J
S1 S1 S1
P P
D E F S2 M
S1 S2 F Ent Sal
S0 M S0
M E0 M M E0 M (*,G) S2 E0
S1 S0
E Ent Sa
l
2: F crea SPT
(*, G) S2
S1 E0
3.3.3.3 2.2.2.3 para (F1,G)
1: E crea SPT
para (F1,G) Miembro de (*,G) Miembro de (*,G)
Leyenda de símbolos empleados en las diapositivas

M Datagrama multicast. Dirección de origen: 1.1.1.2.

Dirección de destino 224.2.2.2

M2 Datagrama multicast. Dirección de origen: 2.2.2.2.

Dirección de destino 224.2.2.2

P Mensaje ‘Prune’ (DVMRP, PIM-DM, PIM-SM y CBT)

G Mensaje ‘Graft’ (DVMRP y PIM-DM)

J Mensaje ‘Join’ (PIM-SM y CBT)

RM Mensaje ‘Register’ con datagrama multicast encapsulado (PIM-SM)

M® Datagrama multicast desencapsulado por un RP (PIM-SM)

RS Mensaje ‘Register Stop’ (PIM-SM)

 Mensajes PIM SM
 Los mensajes Join o Prune de PIM-SM se envían por la interfaz por la que apunta la
ruta unicast hacia el RP (o hacia la fuente, en caso de que se esté estableciendo el
árbol SPT)
 La dirección de destino de esos mensajes no es el RP o la fuente, sino la dirección
multicast 224.0.0.13; por tanto solo se mandan al siguiente router.
 El siguiente router, en función del mensaje recibido y su información de estado
multicast, decide si debe, o no, propagar el Join o Prune al siguiente router hacia el
RP (o hacia la fuente, en caso de que se esté estableciendo el árbol SPT)
 Los mensajes Register y Register Stop son mensajes unicast; se envían siempre a la
dirección unicast del RP y del emisor. Los routers intermedios no tienen ninguna
posibilidad de interceptarlos o modificar su contenido
 PIM-SM
 Es el más complejo de los protocolos de routing multicast en uso actualmente
 Los árboles compartidos minimizan la cantidad de información de estado en los
routers. Los árboles SPT optimizan el tráfico
 Se suele fijar un umbral de tráfico a partir del cual los routers conmutan de árbol
compartido a SPT. Si umbral=0 se conmuta con el primer paquete, si umbral=
siempre se usa el árbol compartido.
 Debido a su flexibilidad y escalabilidad PIM-SM es el protocolo que tiene más
futuro en Internet. MBone está evolucionando hacia PIM-SM
 Elección del RP
 El RP se puede asignar por configuración en cada router
 Es posible asignar un RP diferente para diferentes rangos de direcciones
multicast
 Se puede designar un RP backup por si falla el RP principal
 Dado que generalmente los árboles SPT desde la fuente se establecen con el
primer paquete enviado, la ubicación del RP no es crítica en lo que a
rendimiento se refiere. Sin embargo si el RP falla el multicast en la red deja de
funcionar.
 Descubrimiento del RP
 Para evitar la configuración manual la mayoría de las implementaciones utilizan un protocolo
de descubrimiento del RP que hace uso de dos grupos multicast para distribuir sus mensajes:
 RP Announce: 224.0.1.39
 RP Discovery: 224.0.1.40
 Para que el protocolo de descubrimiento del RP funcione los grupos 224.0.1.39 y 224.0.1.40
han de distribuirse en modo denso (PIM-DM)
 Esto da origen a lo que se conoce como el PIM-sparse-dense, que utiliza modo sparse
excepto para los dos grupos anteriores, para los que usa modo dense
 Multicast entre sistemas autónomos
 En PIM-SM el RP es imprescindible para el funcionamiento del protocolo
 Si el RP está en otro ISP (otro AS) y queda fuera de servicio los usuarios locales no
pueden utilizar multicast
 Para resolver este problema el IETF ha creado un protocolo llamado MSDP (Multicast
Source Discovery Protocol) (RFC 3618, 10/2003) que consiste en que:
 Cada AS tiene su propio RP
 Los RPs de distintos AS se ‘descubren’ mutuamente y una vez se conocen acuerdan
intercambiar información
 Para el tráfico multicast entre ASs se utiliza el protocolo BGMP (Border Gateway
Multicast Protocol) (RFC 3913, 9/2004)
Problemas del routing multicast en las redes
actuales
 Los principales problemas que tiene el multicast son los siguientes:
 Cortafuegos: no permiten el paso de paquetes multicast
 Rutas asimétricas: falla el RPF check y el multicast no funciona
 Soporte: algunos routers no soportan o no tienen configurado el routing multicast.
 Fiabilidad: aunque el fabricante lo soporte en general el software multicast está mucho
menos extendido, menos probado y por tanto es menos fiable que el unicast
 Rendimiento: determinados tipos de tráfico multicast pueden cargar mucho los routers.
 Seguridad: es muy fácil realizar ataques de denegación de servicio en una red con
mutlicast habilitado.
 Escalabilidad: algunos protocolos de multicast no han sido probados a gran escala,
especialmente entre diferentes sistemas autónomos.
 Unidad 2: STREAMING
 Introducción.
 Tipos de Streaming: Lineal (vivo) No Lineal (VoD).
 Arquitectura típica de Streaming y sus componentes.
 La metodología Pull y Push: protocolos relacionados.
 Familia de protocolos RTP (RTSP, RTCP, RTMP).
 Bit Rate Adaptativo
 Familia de protocolos adaptativos (DASH, HLS, HDS).
 Software de streaming.
 Multicast IGMP.
 Ley de Zipf
 Eficiencia P2P
 Servicios de streaming (Youtube, Netflix).
Ley de Zipf
 Se utiliza para saber la popularidad de algún contenido.
 La ley de Zipf expresa una relación exponencial entre la popularidad P (número de
veces que se repite la petición de dicho documento) y su ranking r (que se extrae de la
ordenación de los documentos según su popularidad). Esta relación se expresa en la
ecuación:

 donde c es una constante y alfa es un valor entre cero y uno.

 Este comportamiento típico puede describirse como una línea recta de pendiente negativa α si
representamos en unos ejes logarítmicos P frente a r. Este ajuste lineal suele ser casi perfecto para la parte
principal del cuerpo de la distribución.
 Ley de Zipf
 Un ejemplo de aplicación puede
ser la medición de eficiencia del
almacenamiento en un Origin
Server que concentra las
solicitudes de grandes
poblaciones de usuarios en una
pequeña fracción de contenido y
servicios muy populares, que
hacen que la implementación de
pequeños cachés sea rentable.
 Otro ejemplo puede ser utilizado
para dimensionar las VLAN de
clientes que piden determinados
contenidos en IGMP.
 Unidad 2: STREAMING
 Introducción.
 Tipos de Streaming: Lineal (vivo) No Lineal (VoD).
 Arquitectura típica de Streaming y sus componentes.
 La metodología Pull y Push: protocolos relacionados.
 Familia de protocolos RTP (RTSP, RTCP, RTMP).
 Bit Rate Adaptativo
 Familia de protocolos adaptativos (DASH, HLS, HDS).
 Software de streaming.
 Multicast IGMP.
 Ley de Zipf
 Eficiencia P2P
 Servicios de streaming (Youtube, Netflix).
Que es P2P (Peer to Peer)
 Modelos de comunicación:
 Cliente-Servidor: arquitectura centralizada donde hay un ordenador con altas
prestaciones que da servicio a las peticiones de una serie de clientes.
 Ej.: Webs, DNS,buscadores...
 Peer to Peer: arquitectura distribuida que busca una comunicación de igual a
igual, donde tenemos una compartición de recursos informáticos a través de
un intercambio directo entre ordenadores.
 Ej.:Sistemas de compartición de archivos ( uTorrent, Bit Torrent...), Sistemas de
cálculo(Seti@home para la búsqueda de vida extraterrestre)…
Caracteristicas y Modelos
 Características de los miembros de redes P2P:
 Disponibilidad de un ordenador funcional con calidad de servidor.
 Disponibilidad de un sistema de direccionamiento independiente de DNS.
 Capacidad de funcionar con conectividad variable.

 Modelos de redes P2P:

 Híbrido: Algunos nodos son terminales-routers que facilitan la interconexión entre Peers.
 Puros: Todos los nodos son Peers, y cada peer puede funcionar como router, cliente o servidor,
dependiendo de la consulta.
Qué aporta?
 La auto-organización de los nodos en una aquitectura P2P se debe a uno de los dos
motivos siguientes:
 Al añadir un nodo a la red se le da lo mismo que a los otros nodos de la red, por lo tanto no es
necesario reestructurar la red al añadir nodos.
 A gran escala la comunidad P2P puede organizarse de forma natural en millones de redes
virtuales de grupos pequeños agrupados según intereses especificos. Así, la organización de los
nodos es independiente de si un nodo esta conectado o no. Esto permite conectividad variable y
escalabilidad.
 Minimización de la congestión debido a que las conexiones se realizan punto a
punto, no existen cuellos de botella.
 Escalabilidad más sencilla al tener una menor congestión y auto-organización.
Desventajas

 El principal inconveniente del P2P es la seguridad. El P2P es un sistema de

comunicación totalmente libre y descentralizado. Al no necesitar un servidor
central, resulta muy difícil establecer sistemas de seguridad complejos, como
DMZs o “firewalls”.
 Al circular la información ordenador a ordenador, los sistemas de seguridad
deben estar en el mismo ordenador (software de antivirus muy potente)
Para que sirve?
 Expertos en tecnologías de la información y la comunicación aseguran que los
entornos p2p suponen un cambio radical de la manera de trabajar en Internet.
 Que puede aportar peer-to-peer en el futuro?
 A las grandes corporaciones, potenciar el teletrabajo y flexibilizar las relaciones internas
de las empresas, mejorando la gestión del conocimiento.
 A los usuarios, poder recoger y ofrecer información a un grupo de usuarios muy amplio.
 A los profesionales, utilizar la plataforma para trabajar como freelance con diversas
empresas.
 A las PYMES, mantener unas relaciones más fluidas y directas con proveedores, clientes,
otras “compañías” del sector, etc...
Funcionamiento Bit Torrent
 Peer-cliente: cualquier
miembro de la red que no
tenga el archivo completo
pero aun así comparte.
 Seed-semilla: es otro
cliente que tiene el archivo
completo, a mas semillas
mas rápido se baja el
archivo.
 Tracker-rastreador:
servidor que lleva un
registro de semillas y
clientes.
 Unidad 2: STREAMING
 Introducción.
 Tipos de Streaming: Lineal (vivo) No Lineal (VoD).
 Arquitectura típica de Streaming y sus componentes.
 La metodología Pull y Push: protocolos relacionados.
 Familia de protocolos RTP (RTSP, RTCP, RTMP).
 Bit Rate Adaptativo
 Familia de protocolos adaptativos (DASH, HLS, HDS).
 Software de streaming.
 Multicast IGMP.
 Ley de Zipf
 Eficiencia P2P
 Servicios de streaming (Youtube, Netflix).
YouTube
 Es una de las mas importantes plataformas de video a nivel mundial.
 Desde 2005 su crecimiento ha sido exponencial, tiene una red de distribución de
contenidos cuyo diseño es muy complejo.
 El mayor crecimiento lo tuvo en 2006 cuando Google tomó control de la plataforma
pasando a utilizar una infraestructura mundial con tráfico circulando por cientos de
ISP.
 La gran mayoría del contenido transmitido es generado por los usuarios, quienes
pueden subir a la plataforma en varios formatos utilizando muchos dispositivos que
luego son convertidos a formato de Flash. (Ahora utiliza HTML5).
Arquitectura típica
Funcionamiento
 Cuando un usuario va a las páginas de Youtube, como por ejemplo
www.youtube.com/watch?v=videoID, el browser inicialmente busca resolver el
dominio www.youtube.com usando su DNS local (LDNS).
 Se hace referencia a los servidores de Youtube, o direcciones IP, mapeadas a
www.youtube.com como los servidores web front-end.
 El requerimiento HTTP del usuario es entonces direccionado a uno de estos
servidores determinados por el sistema DNS de Youtube.
 Este DNS devuelve una página HTML, con una o más URL embebidas como
v23.lscache5.c.youtube.com, que apunta al video en Flash o videos relacionados en
los que el usuario estaría interesado.
Funcionamiento

 Luego, al dar click en el botón de reproducción de un objeto de video embebido en una página, o si el
video inicia automáticamente, otra secuencia de resolución DNS inicia resolviendo
v23.lscache5.c.youtube.com en uno de los muchos servidores de video Flash de Youtube, que luego
transmite el video al navegador del usuario.
 De hecho, el video server front-end de Youtube que primero resuelva puede redireccionar el
requerimiento de video hacia otro servidor usando mensajes de redireccionamiento (HTTP302).
 Este proceso se repetirá hasta que finalmente se alcance un servidor que pueda transmitir el video al
navegador del usuario. Se vuelve obvio que muchas rondas de resolución DNS, y las consecuentes
redirecciones HTTP, pueden darse antes de que el usuario finalmente reciba el video.
 Funcionamiento
 En cuanto a la arquitectura de la nube de
Youtube, se muestra un esquema de la
misma en la figura siguiente. El diseño
del sistema de entrega de video de
Youtube consta fundamentalmente de tres
componentes:
 ID de Video en el Espacio
 Organización Multinivel de Múltiples
Espacios de Nombres DNS Anycast (en
representación de los servidores de video
“lógicos”
 Jerarquía Física de Caché de Servidores
de 3 Niveles, con por lo menos 38
locaciones primarias, 8 secundarias y 5
terciarias.
Componentes
 ID de Video en el Espacio:
 Cada video de Youtube tiene un identificador “plano” único de 11 literales: letras de la A a la Z, números del 0 al 9 y
caracteres guión (–) o o sub-guión (_). El tamaño total de este ID es efectivamente 6411.
 Organización Multinivel de Múltiples Espacios de Nombres DNS:
 Los videos de Youtube tienen y la jerarquización de cachés están unidos tanto por un grupo de espacios de nombre de
difusión ilimitada como por un espacio de nombre de tipo unicast. Youtube define cinco DNS espacios de nombre
organizados en múltiples niveles, cada uno de los cuales representa una colección lógica de servidores de video con roles
definidos. Los servidores lógicos de video de cada capa son mapeados a direcciones IP físicas en varias localidades dentro
de una capa particular de jerarquía de caché físicos.
 Jerarquía Física de Servidores Caché de 3 Niveles
 Cada usuario que realiza un requerimiento recibe el video desde un nodo cache. Los nodos individuales se organizan en
clusters con una localización definida. El número de máquinas involucradas en cada cluster de cachés es variable y depende,
entre otras cosas, de la demanda de servicio en la región de localización y del espacio físico asignado. Estos cachés se han
localizado en más de 47 países en cuatro continentes pues Africa no los tiene.
Prestaciones hacia el cliente
 Hacia el cliente, los beneficios de utilizar Youtube se pueden percibir mayormente
desde el punto de vista del negocio, es decir, cuando se usa Youtube como
herramienta corporativa de marketing. Entre los principales tenemos:
 Acceder al inmenso tráfico de Youtube desarrollando videos o publicidad que se muestren
dentro de videos de terceros.
 Hacer marketing en Youtube ayuda a mejorar el posicionamiento de las empresas en Google.
 Reutilización de contenido, y disminución de costos, pues el mismo nunca se pierde.
 Crecimiento en audiencia a nivel mundial pues, con la inclusión de subtítulos o traducción,
barreras como la del idioma se eliminan.
Porque se pasó a HTML5?
 Html5 resolvió problemas de DRM. (se bloqueaban videos por derecho de autor).
 El contenido se ejecuta rápidamente reduciendo los tiempos de espera y posibilita la
compatibilidad entre distintos dispositivos, sean móviles, TV’s u otros.
 Los tiempos de almacenamiento en búfer se han reducido en un 50% a nivel mundial, lo que
permitirá ver un video de manera más fluida.
 Adaptative Bitrae: El reproductor puede modificar la resolución del video según la calidad de
conexión para que éste no se pause constantemente.
 Se permite la transmisión en vivo de gameplays desde consolas como PS4 o Xbox One.
 Una visualización de mejor calidad.
 Más opciones de encriptado.
 Reproducción a pantalla completa.
Netflix
 Se inició en Estados Unidos como un servicio de préstamo de DVD por correo en
1998, luego de que su dueño tuviera un impase con la empresa que por ese entonces
era la principal en este mercado, Blockbuster.
 Posteriormente, en 2007, comenzó la transmisión utilizando streaming. Actualmente
es uno de los referentes en esta línea con tiene operaciones en aproximadamente 190
países y, según información de abril 2016, la empresa cuenta con 81 millones de
suscriptores alrededor del mundo.
 Tiene soporte para videos en HD alcanzando tasas de bits de 3.6Mbps en promedio y
significa aproximadamente el 30% del tráfico de descarga en Estados Unidos.
 Arquitectura

 Como se observa, la
arquitectura de Netflix está
compuesta por cuatro
elementos fundamentales:
Netflix Data Centers, Nube
de Amazon, Redes de
Distribución de Contenidos
(CDNs) y reproductores.
Netflix Datacenters
 Netflix
utiliza su propio conjunto de direcciones IP para representar el
dominio www.netflix.com.
 El servidor primero gestiona dos funciones fundamentales:
 1) registro de cuenta de un nuevo usuario y captura de la forma de pago;
 2) redirecciona a los usuarios a movies.netflix.com o a signup.netflix.com, según
el usuario se haga loggeado o no. Luego de realizado este proceso, este servidor no
vuelve a interactuar con el usuario durante la transmisión de la película o serie.
Nube de Amazon
 Con excepción del dominio
www.netflix.com, que es hospedado
directamente por Netflix, muchos de los
otros dominios como movies.netflix.com se
gestionan desde la nube de Amazon y utiliza
varios de sus servicios de ‘cloud’ como EC2,
S3, SDB y VPC.
 Sus principales opciones, como la ingesta de
contenido, registro de grabación y análisis,
DRM, enrutamiento en CDN, registro de
usuarios, y soporte de dispositivos móviles
se realizan en la nube de Amazon.
CDN y app de reproducción.
 Para entregar su contenido Netflix utiliza múltiples CDN. Los videos codificados y protegidos por
DRM son provistos desde la nube de Amazon para luego copiarse a las CDN. Las principales CDN que
utiliza son: Akamai, Limelight y Level-3. Para un video determinado en el mismo nivel de calidad, se
envía el mismo contenido codificado a las tres CDN.

Aplicaciones de Reproducción
 Para descargar, decodificar y reproducir en computadores de escritorio, a través de web browsers, los
videos Netflix utiliza Silverlight, cuyo ambiente de tiempo de ejecución está disponible como un plug-
in para muchos browsers. De igual manera contamos con aplicaciones para otros dispositivos.
 Para el streaming, propiamente dicho, Netflix utiliza DASH (Dynamic Adaptive Streaming over
HTTP), lo que le permite poder cambiar condiciones de velocidad o calidad según la capacidad de la
red de distribución.
Prestaciones
 Las más importantes se analizan desde el punto de vista del usuario y su calidad de la experiencia o QoE:
 Actualización constante de contenidos de series completas, aun cuando hasta el momento se percibe un retraso de
aproximadamente 10 meses en obtener las temporadas actuales de las mismas.
 Producción de contenido original, que ha logrado una gran fidelización de usuarios.
 Constante mejora de la calidad de los videos transmitidos llegando a patentar su propia versión del 1080p HD al
que han llamado Super HD y que se considera un paso previo a la inclusión de videos en 4k.
 Contenido exclusivo según diferentes nichos de mercado
 Aplicaciones de gran compatibilidad y fácil uso que permiten, entre otras facilidades, la personalización de menús
de selección de películas incluyendo la creación de perfiles de usuario. Pero, si alguna selección no está de
acuerdo a nuestros criterios de preferencia, los procesos automáticos de selección son intuitivos permitiéndonos
elegir.
 No tiene anuncios publicitarios en pantalla durante la transmisión de contenidos.
 Menú de ayuda y soporte al usuario que es realmente eficiente.
Ejercicios:

Cada flujo multicast (P1, P2, P3 y P4)

genera 2 Mb/s.
Rellene la tabla indicando el flujo (entrante
y saliente) en los puertos indicados.
A implementa IGMP Snooping, B, C y D
no.

Conmutador Puerto Flujo entrante (Mb/s) Flujo saliente (Mb/s)

B 1
2
3
C 1
2
D 1
2
3
4
Ejercicio N°2

Indique que flujos pasan por cada una

de las interfaces del Router y que
flujos llegan a cada host.
Los conmutadores de primer nivel
implementan IGMP Snooping, los de
segundo nivel no.
Ejercicio N°3

H1 y H2 reciben audio, ningún host recibe vídeo (no tienen aplicación adecuada)
Si la emisión de vídeo cambia a la dirección 239.0.0.2, ¿Cómo cambia el tráfico?
Los conmutadores no implementan IGMP Snooping