Tema 1

Multicast
(versin 2010-2011)

Rogelio Montaana Departamento de Informtica Universidad de Valencia rogelio.montanana@uv.es http://www.uv.es/~montanan/

Universidad de Valencia

Ampliacin Redes 1-1

Rogelio Montaana

Sumario
Introduccin. Aspectos generales IGMP Routing Multicast

Universidad de Valencia

Ampliacin Redes 1-2

Rogelio Montaana

Direcciones multicast en Ethernet:

OUI Direccin

XX

XX

XX

XX

XX

XX

U/L I/G

I/G = 0 Direccin Individual (unicast) I/G = 1 Direccin de Grupo (multi./broad.) U/L = 0 Dir. nica (administrada globalmente IEEE) U/L = 1 Dir. Local (administrada localmente)

En Ethernet los bits dentro de cada byte se representan en orden inverso. Por tanto el bit I/G es el ltimo del primer byte. Regla: En Ethernet una direccin es multicast si y solo si el segundo dgito hexadecimal es impar. Ej.: la direccin AB-00-03-00-00-00 es multicast.
Universidad de Valencia

Ampliacin Redes 1-3

Rogelio Montaana

Multicast en LAN
El trfico multicast no es aislado normalmente por los conmutadores Muchos protocolos utilizan multicast en la LAN:
Spanning tree (direccin 01-80-C2-00-00-00) Protocolos de routing: OSPF, IS-IS, RIP, etc. Protocolos propietarios: Appletalk, IPX, CDP, etc.

El trfico multicast en una LAN puede ser importante aun cuando a nivel 3 (los routers) no est habilitado el multicast
Universidad de Valencia

Ampliacin Redes 1-4

Rogelio Montaana

Multicast en una LAN broadcast compartida

0000.102C.D832 Grupo Multicast 0100.5E00.0001 Dir.Origen: 0000.102C.D832 Dir.Destino: 0100.5E00.0001

Join 0100.5E00.0001

Join 0100.5E00.0001

En la LAN todos los equipos reciben todo el trfico multicast, estn o no interesados

Juan
Direcciones capturadas por la tarjeta de red
0000.E85A.CA6D FFFF.FFFF.FFFF 0100.5E00.0001

Rosa
0001.02CD.8397 FFFF.FFFF.FFFF 0100.5E00.0001

Luis
0001.02CC.4DD5 FFFF.FFFF.FFFF

Afortunadamente la tarjeta de red descarta el que no nos interesa

Universidad de Valencia

Ampliacin Redes 1-5

Rogelio Montaana

Multicast en una LAN broadcast conmutada

0000.102C.D832

Grupo Multicast 0100.5E00.0001

D.O.: 0000.102C.D832 D.D.: 0100.5E00.0001 El uso de un conmutador no mejora la situacin en lo que a trfico multicast se refiere. El trfico sigue llegando a todos los hosts

Ana
M M M

Join 0100.5E00.0001

Join 0100.5E00.0001

Juan
Direcciones capturadas por la tarjeta de red 0000.E85A.CA6D FFFF.FFFF.FFFF 0100.5E00.0001

Rosa
0001.02CD.8397 FFFF.FFFF.FFFF 0100.5E00.0001

Luis
0001.02CC.4DD5 FFFF.FFFF.FFFF

Universidad de Valencia

Ampliacin Redes 1-6

Rogelio Montaana

Emisin de un grupo multicast en una WAN

Receptor

Rosa

Juan

Ana
Receptor Emisor

Luis

Los routers replican los paquetes justo all donde se produce la bifurcacin Universidad de Valencia

Receptor

Ampliacin Redes 1-7

Pedro Rogelio Montaana

Emisin de dos grupos multicast

Receptor Vdeo

Rosa

Juan

Receptor Audio

Ana

Lnea de baja velocidad

Paquetes de vdeo Luis Paquetes de audio Normalmente cada grupo se identifica por una direccin multicast diferente Pedro recibe los dos grupos Universidad de Valencia Pedro

Receptor Vdeo

Receptor Audio/Video

Ampliacin Redes 1-8

Rogelio Montaana

Tipos de direcciones IPv4

Unicast (A, B o C): 0.0.0.0 223.255.255.255
Red Host

Multicast (D): 224.0.0.0- 239.255.255.255

1110 Grupo Multicast (28 bits)

Reservado (E): 240.0.0.0 255.255.255.254

1111 xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Broadcast (en la red actual): 255.255.255.255

11111111111111111111111111111111

Broadcast en una red (remota):

Red
Universidad de Valencia

111111....111111
Ampliacin Redes 1-9
Rogelio Montaana

Direcciones Multicast en IP
Las direcciones multicast tienen estructura plana (no jerrquica) Las direcciones multicast solo pueden aparecer como direcciones de destino, nunca de origen No pueden aparecer en los campos opcionales source route o record route ICMP y multicast: Los datagramas multicast no pueden dar lugar a mensajes ICMP DESTINATION UNREACHABLE Tampoco pueden dar lugar a mensajes ICMP TIME EXCEEDED. Sin embargo el TTL se decrementa normalmente y cuando vale cero el datagrama se destruye Los mensajes multicast ICMP ECHO REQUEST generan respuestas unicast de todos los miembros del grupo. Las respuestas, unicast, llevan como direccin de origen la del emisor y destino la del host que envi el ICMP multicast.
Universidad de Valencia

Ampliacin Redes 1-10

Rogelio Montaana

Resolucin de direcciones multicast IPEthernet

Se realiza por mapeo de la direccin IP en la direccin MAC. No se utiliza ARP. Para hacer un mapeo exacto de la IP en la MAC haran falta 28 bits, es decir los 4 ltimos bits de la OUI y los 24 siguientes. Esto requerira reservar 24 = 16 OUIs contiguos, que habran costado $16.000 dlares El IETF decidi comprar solo un OUI (01-00-5E) y dedicar solo la mitad inferior a multicast, reservando la otra para otros fines. Por tanto se dispone solo de 23 bits Por tanto en el mapeo se ignoran los cinco primeros bits de la direccin IP
Universidad de Valencia

Ampliacin Redes 1-11

Rogelio Montaana

Resolucin direcciones multicast IP-Ethernet

Bits ignorados Bits mapeados (23)

Direccin IP multicast: Direccin MAC:

Binario Hexadecimal

1110
OUI del IETF

xxxx xabcdefg hijklmno

pqrstuvw

00000001 00000000 01 00

01011110 5E

0abcdefg

hijklmno

pqrstuvw

Correspondencia no biunvoca:
224.0.0.1 224.128.0.1 225.0.0.1 225.128.0.1 . . 239.0.0.1 239.128.0.1

Mitad inferior

32 direcciones IP

0100.5E00.0001

1 direccin MAC

Universidad de Valencia

Ampliacin Redes 1-12

Rogelio Montaana

Resolucin direcciones multicast

Cuando en una LAN corresponde la misma MAC a dos direcciones IP multicast la tarjeta LAN pasa los dos grupos al nivel de red El nivel de red filtra los paquetes que no son suyos. El protocolo funciona pero el trabajo extra del nivel de red produce un consumo adicional de CPU. Algunas tarjetas de red aceptan un nmero muy limitado de grupos multicast; cuando se supera este lmite se ponen en modo aceptar todo el multicast. El nivel de red ha de realizar el filtrado. Es como un modo promiscuo para el trfico multicast

Universidad de Valencia

Ampliacin Redes 1-13

Rogelio Montaana

Resolucin de direcciones multicast

Grupo Multicast 224.128.0.1 Grupo Multicast 225.0.0.1

D.D.: 0100.5E00.0001
M M

Join 224.128.0.1

Join 224.128.0.1

Join 225.0.0.1

Juan
Direcciones capturadas por la tarjeta de red Universidad de Valencia 0000.E85A.CA6D FFFF.FFFF.FFFF 0100.5E00.0001

Rosa
0001.02CD.8397 FFFF.FFFF.FFFF 0100.5E00.0001

Luis
0001.02CC.4DD5 FFFF.FFFF.FFFF 0100.5E00.0001 Rogelio Montaana

Ampliacin Redes 1-14

Rangos de direcciones multicast IPv4 reservadas o especiales

Rango 224.0.0.0/24 224.0.1.0/24 224.0.2.0/24 224.0.255.0/24 224.1.0.0/16 224.2.0.0/16 232.0.0.0/8 233.0.0.0/8 239.0.0.0/8 255.255.255.255/32 Uso Direcciones locales asignadas por la IANA. No propagadas por los routers. Direcciones globales asignadas por la IANA. Propagadas por los routers Bloque para asignaciones ad-hoc. Probablemente el ms utilizado Grupos multicast para Stream Protocol Bloque SAP/SDP (MBone) Multicast especfico de la fuente (SSM) Reservado para glop addressing Multicast con mbito limitado por la direccin Broadcast confinado a la LAN

Los rangos no incluidos en esta tabla estn reservados por la IANA (Internet Assignment Numbers Authority) y no deberan utilizarse
Universidad de Valencia

Ampliacin Redes 1-15

Rogelio Montaana

Algunas direcciones IPv4 multicast reservadas

Locales
Direccin 224.0.0.0 224.0.0.1 224.0.0.2 224.0.0.4 224.0.0.5 224.0.0.6 224.0.0.9 224.0.0.10 224.0.0.11 Uso Reservada Hosts con soporte multicast Routers con soporte multicast Routers DVMRP (routing multicast) Routers OSPF Routers OSPF designados Routers RIP v2 Routers IGRP Agentes mviles 224.0.1.7 224.0.1.12 224.0.1.16 224.0.1.39 224.0.1.40 224.0.1.41 224.0.1.52 Direccin 224.0.1.1

Globales
Uso NTP Network Time Protocol Audio News IETF-1-Video Music-Service RP Announce (PIM) RP Discovery (PIM) Gatekeepers (H.323) Directorio VCR de MBone

224.0.0.12
224.0.0.13 224.0.0.15 224.0.0.22 255.255.255.255

Agentes DHCP server/relay

Routers PIMv2 (routing multicast) Routers CBT (routing multicast) Routers IGMP v3 (Memb. Report) Todos los hosts

224.0.1.68
224.2.127.254

Protocolo MADCAP
Anuncio de sesiones SAP (SDR)

Las direcciones multicast reservadas se resuelven al nombre correspondiente en el dominio mcast.net, p. ej. 224.0.1.7 es audionews.mcast.net
Universidad de Valencia

Ampliacin Redes 1-16

Rogelio Montaana

Envos broadcast en Internet

En Internet no es posible hacer un envo broadcast. Si utilizamos la direccin 255.255.255.255 el envo se difunde en la red local nicamente, no pasa ms all. Dicho de otro modo, el paquete broadcast es tratado como si tuviera TTL=1, cualquiera que sea el valor de TTL que realmente tenga Esto se hace para preservar la salud de la red. De lo contrario cualquier usuario desaprensivo o despistado podra saturar la red
Universidad de Valencia

Ampliacin Redes 1-17

Rogelio Montaana

Diferencia entre envos a 255.255.255.255 y a 224.0.0.1

Router IP
(con soporte multicast)

255.255.255.255

224.0.0.1 255.255.255.255 224.0.0.1

255.255.255.255

255.255.255.255

224.0.0.1

IP W 3.11

IP W 95

IPX Linux

Juan
El kernel de Windows 3.11 no tiene soporte multicast

Rosa

Luis

Ninguno de los dos datagramas se transmite al exterior (independientemente de cual sea su TTL)

Universidad de Valencia

Ampliacin Redes 1-18

Rogelio Montaana

Broadcast dirigido
En Internet cuando se define una red automticamente se define una direccin broadcast en dicha red. Dicha direccin es la ms alta existente en esa red (parte host toda a unos). Por ejemplo si definimos la red 130.206.4.0/23 su direccin de broadcast es 130.206.5.255 En principio cualquier host puede hacer un envo broadcast a una red remota utilizando dicha direccin; esto se conoce como broadcast dirigido
Universidad de Valencia

Ampliacin Redes 1-19

Rogelio Montaana

Ataques con broadcast dirigido

A finales de los 90 se produjeron diversos ataques utilizando broadcast dirigido. La tcnica consista en enviar un paquete a la direccin broadcast de una red grande poniendo una direccin de origen falsa (la del host a atacar). Cuando ese host reciba las respuestas de los pings su consumo de CPU creca enormemente Como consecuencia hoy en da es normal no permitir el broadcast dirigido. Si se recibe un ping broadcast dirigido solo lo responde el router que da acceso a esa red En los routers cisco el broadcast dirigido se controla con el comando ip directed-broadcast a nivel de interfaz. Por defecto este comando est puesto a no en todas las interfaces (por tanto por defecto no se permite)
Universidad de Valencia

Ampliacin Redes 1-20

Rogelio Montaana

Broadcast en IP
ping 147.156.1.255
C recibe un ICMP echo reply (de X) C 147.156.2.2/24 147.156.2.1/24 Y D A ping 147.156.1.255 A recibe 199 ICMP echo reply 147.156.1.2/24

Internet

147.156.1.1/24 147.156.1.3/24

ping 147.156.2.255 X 147.156.255.1/24 B ping 147.156.1.255 B recibe un ICMP echo reply (de X) 147.156.255.2/24 D recibe un ICMP echo reply (de Y) ping 147.156.255.255

D recibe un ICMP echo reply (de X)

147.156.1.200/24

Se supone que los routers X e Y tienen todas sus interfaces con la configuracin por defecto, es decir con no ip directed-broadcast

Universidad de Valencia

Ampliacin Redes 1-21

Rogelio Montaana

mbito de una emisin multicast

En multicast es fundamental disponer de mecanismos que permitan limitar el mbito de difusin de los grupos multicast. Esto puede conseguirse de tres formas:
Ajustando el valor del TTL (obsoleto) Asignando rangos de direcciones a determinados mbitos Utilizando el protocolo de anuncio de mbitos MZAP (Multicast Zone Announcement Protocol, RFC 2776). Poco extendido.
Universidad de Valencia

Ampliacin Redes 1-22

Rogelio Montaana

Delimitacin de mbito por direccin (RFC 2365)

Se asigna un significado especial a determinados rangos de direcciones multicast. El router, mediante ACLs, realiza un filtrado de los paquetes multicast que no deben salir (este filtrado es independiente del descarte por TTL=0
Rango 224.0.0.0/24 (224.0.0.0-224.0.0.255) 224.0.1.0-238.255.255.255 239.0.0.0 239.191.255.255 239.192.0.0/14 (239.192.0.0-239.195.255.255) 239.196.0.0 239.254.255.255 239.255.0.0/16 (239.255.0.0-239.255.255.255) Universidad de Valencia mbito Nivel de enlace (LAN) Global. Reservado para usos futuros Organizacin Reservado para usos futuros Nivel de enlace (LAN)

Ampliacin Redes 1-23

Rogelio Montaana

Delimitacin del mbito por direccin (RFC 2365, 7/1998)

224.0.1.0-238.255.255.255

Red de la Univ. de Murcia

RedIRIS Europa

Filtra 239.192.0.0/14 Mundo Red de la Univ. de Valencia Filtra 239.255.0.0/16 239.255.0.0/16 239.192.0.0/14

Universidad de Valencia

Ampliacin Redes 1-24

Rogelio Montaana

Delimitacin de ambito multicast por direccin en IPv6

Formato de las direcciones IPv6 multicast:
Bits 8 4 4 112

1111 1111

Flags

Scope

Grupo Multicast

Flags: 000T, donde: T = 0: direccin asignada de forma global y permanente (IANA) T = 1: direccin asignada de forma local y temporal Scope (0-F): valor que indica el mbito o alcance de la emisin. Puede haber 16 mbitos diferentes. El grupo multicast puede ser cualquiera.

Universidad de Valencia

Ampliacin Redes 1-25

Rogelio Montaana

Equivalencia de mbitos IPv4-IPv6

Scope IPv6 0 1 2 3 4 5 6 7 8 mbito Reservado Nodo Nivel de enlace (LAN) (sin asignar) (sin asignar) Ubicacin (ej. Campus) (sin asignar) (sin asignar) Organizacin 239.192.0.0/14 224.0.0.0/24 239.255.0.0/16 Direcciones IPv4 (RFC 2365)

9
A B C D E F Universidad de Valencia

(sin asignar)
(sin asignar) (sin asignar) (sin asignar) (sin asignar) Global Reservado 224.0.1.0-238.255.255.255

Ampliacin Redes 1-26

Rogelio Montaana

Asignacin de direcciones multicast

Actualmente en Internet las direcciones multicast se asignan normalmente mediante el protocolo SAP (Session Announcement Protocol, RFC 2974, 10/2000). El rango de direcciones que utiliza SAP es el 224.2.0.0/16. El SAP presenta varios inconvenientes: Tiene una estructura plana, no jerrquica. Por tanto no es escalable Esta pensado especficamente para aplicaciones multimedia La asignacin se realiza dinmicamente. No es posible efectuar asignaciones estticas (permanentes) Se han propuesto otros protocolos ms avanzados pero hasta la fecha no han tenido xito
Universidad de Valencia

Ampliacin Redes 1-27

Rogelio Montaana

Glop addressing
Para asignar direcciones IP multicast estticas se utiliza actualmente el denominado Glop addressing (RFC 3180, 9/2001), que funciona as:
Se utiliza el rango 233.0.0.0/8 (233.0.0.0 233.255.255.255) Se asigna a los dos bytes centrales el valor del AS correspondiente. Ej.: a RedIRIS (AS 766) le corresponde el rango 233.2.254/24 (2.254 equivale a 766 expresado en dos bytes) Dentro de cada AS el ISP asigna las direcciones como le parece.

Universidad de Valencia

Ampliacin Redes 1-28

Rogelio Montaana

Sumario
Introduccin. Aspectos generales IGMP Routing Multicast

Universidad de Valencia

Ampliacin Redes 1-29

Rogelio Montaana

IGMP = Internet Group Management Protocol

Objetivo: permite a los routers averiguar los grupos multicast presentes en sus interfaces LAN Utiliza el valor 2 del campo protocolo en la cabecera IP Todos los mensajes IGMP se emiten con TTL=1, por lo que solo son recibidos en la LAN correspondiente a la interfaz por la que se emiten Existen tres versiones de IGMP:
V1: RFC 1112 (8/1989): Ej. W95, NT 4.0 SP3 V2: RFC 2236 (11/1997): W98, NT 4.0 SP 4, W2000 V3: RFC 3376 (10/2002): XP Prof., W2003

Universidad de Valencia

Ampliacin Redes 1-30

Rogelio Montaana

Tipos de mensajes en IGMPv1

Tipo Emitido por Routers Funcin Direccin de destino 224.0.0.1

Consulta de miembros (Membership Query) Informe de Pertenencia (Membership Report)

Preguntar a los hosts si estn interesados en algn grupo multicast Informar a los routers que el host est interesado en un determinado grupo multicast

Hosts

La del grupo en cuestin

Universidad de Valencia

Ampliacin Redes 1-31

Rogelio Montaana

Proceso presentarse de IGMPv1

A decide unirse a 224.2.2.2 A Enva un IGMP Membership Report a 224.2.2.2 Enva un IGMP Membership Report a 224.1.1.1 B decide unirse a 224.1.1.1 B Enva un IGMP Membership Report a 224.2.2.2 C decide unirse a 224.2.2.2 C

El mensaje no lo recibe nadie

El mensaje no lo recibe nadie

Este mensaje lo recibe A

Cuando un host quiere entrar a formar parte de un grupo multicast enva un mensaje IGMP de saludo llamado Membership Report. Estos mensajes se envan al mismo grupo multicast al que se quiere unir el host

Universidad de Valencia

Ampliacin Redes 1-32

Rogelio Montaana

Proceso pregunta-respuesta de IGMPv1

Miembro de 224.2.2.2 Miembro de 224.1.1.1 2: B se reporta (mensaje a 224.1.1.1) 2 5: X sabe que en la LAN hay miembros de 224.1.1.1 y de 224.2.2.2, pero no sabe cuantos ni quienes Y Router multicast (no es Query Router) Grupos de Y 224.1.1.1 224.2.2.2 B Miembro de 224.2.2.2 3: C se reporta (mensaje a 224.2.2.2) 3 6: Y tiene la misma informacin que X pues recibe todos los mensajes C

4: A no se reporta (sabe que ya lo ha hecho C)

4

1: Cada 60 seg. X enva un mensaje query a 224.0.0.1

X Grupos de X 224.1.1.1 224.2.2.2

Router multicast Es el Query Router

Los routers multicast son siempre miembros de todos los grupos multicast de su LAN

Universidad de Valencia

Ampliacin Redes 1-33

Rogelio Montaana

Proceso apuntarse (join) de IGMPv1

Miembro de 224.2.2.2 A Miembro de 224.1.1.1 B Miembro de 224.2.2.2 C 1: D se apunta a 224.3.3.3 2: D se reporta (mensaje a 224.3.3.3) 2 D

Grupos de X 224.1.1.1 224.2.2.2

X Router multicast

Y Router multicast

Grupos de Y

224.1.1.1
224.2.2.2 224.3.3.3

224.3.3.3

3: Los routers toman nota de que hay presente un miembro de un nuevo grupo multicast, el 224.3.3.3

Universidad de Valencia

Ampliacin Redes 1-34

Rogelio Montaana

Proceso abandonar (leave) de IGMPv1

1: D decide abandonar 224.3.3.3 Miembro de 224.2.2.2 A Miembro de 224.1.1.1 B Miembro de 224.2.2.2 C Miembro de 224.3.3.3 D

Grupos de X 224.1.1.1 224.2.2.2 224.3.3.3

2: X enva el query una vez por minuto y no recibe respuesta de 224.3.3.3. Cuando esto ocurre tres veces seguidas decide borrar 224.3.3.3 de sus tablas

3: Al pasar 3 minutos sin or informes de 224.3.3.3 Y tambin le borra de sus tablas Y Grupos de Y 224.1.1.1

Router multicast Query router

Router multicast

224.2.2.2
224.3.3.3

Universidad de Valencia

Ampliacin Redes 1-35

Rogelio Montaana

Problemas de IGMP v1
Cuando un host abandona un grupo el trfico multicast puede seguir inundando esa LAN durante un tiempo largo (tres minutos). Si el usuario hace zapping esto consume mucho ancho de banda intilmente y puede suponer un problema en la red. 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 recepcin de informes no se pueden configurar dinmicamente
Universidad de Valencia

Ampliacin Redes 1-36

Rogelio Montaana

Mejoras introducidas por IGMPv2

Hay un mensaje Leave Group que permite a los hosts notificar al router de forma explcita cuando abandonan un grupo Existen dos tipos de Query: Query General Query especfico de grupo La eleccin del Query router se realiza de forma independiente al protocolo de routing. Se elige el de direccin IP ms baja. Los timeouts para la recepcin de informes se pueden modificar dinmicamente y anunciarse en los mensajes IGMP de Query
Universidad de Valencia

Ampliacin Redes 1-37

Rogelio Montaana

Tipos de mensajes en IGMPv2

Tipo Emitido por Routers Funcin Direccin de destino 224.0.0.1

Consulta General (General Query) Consulta especfica de grupo (Group-Specific Query) Informe de Pertenencia (Membership Report) Abandono de Grupo (Leave Group)

Preguntar a los hosts si estn interesados en algn grupo multicast Preguntar a los hosts si estn interesados en un determinado grupo multicast Informar a los routers que el host est interesado en un determinado grupo multicast Informar a los routers que el host deja de estar interesado en un grupo multicast

Routers

Nuevo

La del grupo en cuestin La del grupo en cuestin 224.0.0.2

Hosts

Hosts

Nuevo

Universidad de Valencia

Ampliacin Redes 1-38

Rogelio Montaana

Proceso abandonar (leave) de IGMPv2 (I)

1: La aplicacin de C decide abandonar 224.2.2.2 Miembro de 224.2.2.2 4: A enva Membership Report a 224.2.2.2 4 5: X decide mantener activo el grupo 224.2.2.2 ya que aun tiene miembros X Router multicast Query router Y Router multicast A Miembro de 224.1.1.1 B Miembro de 224.2.2.2 2: C enva Leave Group a 224.0.0.2 2 6: Y, que lo ha oido todo, decide tambin mantener activo el grupo 224.2.2.2 Grupos de Y 224.1.1.1 224.2.2.2 C

3: X enva un GroupSpecific Query a 224.2.2.2 Grupos de X

224.1.1.1
224.2.2.2

Universidad de Valencia

Ampliacin Redes 1-39

Rogelio Montaana

Proceso abandonar (leave) de IGMPv2 (II)

1: La aplicacin de A decide abandonar 224.2.2.2 Miembro de 224.2.2.2 2: A enva Leave Group a 224.0.0.2 2 4: como no recibe respuesta X decide eliminar el grupo 224.2.2.2 de esa interfaz X Router multicast Query router Y Router multicast 5: Y, que lo ha oido todo, decide tambin eliminar el grupo 224.2.2.2 Grupos de Y 224.1.1.1 224.2.2.2 A Miembro de 224.1.1.1 B C

3: X enva un GroupSpecific Query a 224.2.2.2 Grupos de X

224.1.1.1
224.2.2.2

Universidad de Valencia

Ampliacin Redes 1-40

Rogelio Montaana

Compatibilidad IGMP v1-v2

En general cuando en una red hay algn router o algn 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)
Universidad de Valencia

Ampliacin Redes 1-41

Rogelio Montaana

Mejoras introducidas por IGMP v3

La aportacin de IGMPv3 es que la eleccin de los flujos multicast ya no se limita solo a la direccin de destino; tambin se puede especificar la direccin de origen Esto permite aislar a saboteadores o indeseables. Evita que se puedan producir ataques de denegacin de servicio en emisiones multicast. A la funcionalidad aportada por IGMPv3 se la denomina SSM, Source Specific Multicast.

Universidad de Valencia

Ampliacin Redes 1-42

Rogelio Montaana

Mensajes nuevos de 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 () Abandonar (Leave): Membership Report 224.1.1.1 INCLUDE () El comando Query tiene ahora tres modalidades: General Query (v1) Group-Specific Query (v2) Group-and-Source-Specific Query (v3)

Universidad de Valencia

Ampliacin Redes 1-43

Rogelio Montaana

Tipos de mensajes en IGMPv3

Tipo Emitido por Routers Funcin Direccin de destino 224.0.0.1

Consulta General (General Query) Consulta especfica de grupo (Group-Specific Query) Consulta especfica de grupo y fuente (Groupand-Source-Specific Query) Informe de Pertenencia (Membership Report)
Modificado

Preguntar a los hosts si estn interesados en algn grupo multicast Preguntar a los hosts si estn interesados en un determinado grupo multicast Preguntar a los hosts si estn interesados en un determinado grupo multicast de una serie de fuentes determinada Informar a los routers que el host est interesado en un determinado grupo multicast (indicando una serie de fuentes a incluir o a excluir)

Routers

La del grupo en cuestin La del grupo en cuestin 224.0.0.22

Routers

Nuevo

Hosts

Universidad de Valencia

Ampliacin Redes 1-44

Rogelio Montaana

Suscripcin selectiva de IGMP v3

B Y 130.206.1.1 Emisor de 224.1.1.1 Z

140.34.1.1 Emisor de 224.1.1.1

Grupos de X 224.1.1.1 EXCLUDE (140.34.1.1) 224.1.1.1 exclude ()

X 3 Group-and-Source-Specific Query: 224.1.1.1, 140.34.1.1

Membership Report: 224.1.1.1 EXCLUDE ()

1 A

Membership Report: 224.1.1.1 EXCLUDE (140.34.1.1)

Miembro de 224.1.1.1
Universidad de Valencia

Ampliacin Redes 1-45

Rogelio Montaana

Multicast en una LAN conmutada

Servidores de vdeo MPEG-2 multicast
P1: 239.192.0.1 P2: 239.192.0.2 P3: 239.192.0.3 P4: 239.192.0.4

WAN
P4

P1

P2

P3

4 x 3 Mb/s
12 Mb/s

1 Gb/s

100 Mb/s

10 Mb/s

P3 P1 P1

P4

Universidad de Valencia

Ampliacin Redes 1-46

Rogelio Montaana

Multicast con router en medio

P1 P2 P3 P4

El router tiene que procesar todo el trfico de vdeo

WAN
6 Mb/s 39Mb/s

Servidores de vdeo MPEG-2 multicast

P3 P1 P1

P4

Universidad de Valencia

Ampliacin Redes 1-47

Rogelio Montaana

Multicast con VLANs

Servidores de vdeo MPEG-2 multicast

WAN
El router tiene que procesar todo el trfico de vdeo Enlaces Trunk

VLAN Servidores

P1

P2

P3

P4

P3 P1 P1

P4

VLAN A Universidad de Valencia

VLAN B Ampliacin Redes 1-48

VLAN C Rogelio Montaana

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 podra saber por que puertos debe distribuir cada grupo multicast, y filtrar el trfico innecesario Esto se conoce como IGMP snooping (snooping = husmear)
Universidad de Valencia

Ampliacin Redes 1-49

Rogelio Montaana

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 = x0800) 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 trfico multicast
Universidad de Valencia

Ampliacin Redes 1-50

Rogelio Montaana

Multicast en LAN con IGMP snooping

El router no reenva el trfico multicast, pero ha de procesar todos los paquetes por si contuvieran mensajes IGMP Servidores de vdeo MPEG-2 multicast P4 P3 P2 P1

WAN

Conmutador con IGMP Snooping por hardware

Conmutadores con IGMP Snooping por software

P3 P1 P1

P4

Universidad de Valencia

Ampliacin Redes 1-51

Rogelio Montaana

Supresin de informes con IGMP Snooping

La supresin de informes permite que un host omita el envo 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 estn los receptores multicast. Una solucin 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 tambin se han de enviar a los dems routers, aunque no hayan lanzado la pregunta. Los conmutadores pueden descubrir a los routers por algunos mensajes caractersticos, o se puede indicar en la configuracin del conmutador. Todo esto complica el funcionamiento de IGMP Snooping. En IGMP v3 los Membership Report se envan a la direccin 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 supresin de informes, lo cual simplifica el IGMP Snooping.

Universidad de Valencia

Ampliacin Redes 1-52

Rogelio Montaana

Sumario
Introduccin. Aspectos generales IGMP Routing Multicast

Universidad de Valencia

Ampliacin Redes 1-53

Rogelio Montaana

Funcionamiento del routing multicast

Una vez el router sabe (por IGMP) en que grupos multicast estn interesados los hosts de su LAN debe conspirar con los dems routers para conseguir que dichos paquetes le lleguen desde donde se estn produciendo El routing multicast funciona al revs que el unicast: se enruta en funcin de la direccin 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 Condicin: debe haber una ruta unicast viable emisorreceptor y dicha ruta debe ser simtrica

Universidad de Valencia

Ampliacin Redes 1-54

Rogelio Montaana

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 algn router no est interesado en la emisin solicita cortar su rama del rbol enviando un mensaje prune (prune = podar). Modo disperso: Se presupone que solo una minora de los routers estn interesados en la emisin por lo que en principio no se le enva a ninguno; si a alguno le interesa lo debe solicitar con un mensaje join (unirse, apuntarse).

Universidad de Valencia

Ampliacin Redes 1-55

Rogelio Montaana

Modo denso
Es el ms antiguo y el ms sencillo Se utiliza cuando hay un gran ancho de banda o cuando una mayora de los routers quieren recibir el grupo multicast No es eficiente cuando el nmero 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)

Universidad de Valencia

Ampliacin Redes 1-56

Rogelio Montaana

Modo disperso
Es preferible al modo denso cuando el nmero de receptores es minoritario Es el ms 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)
Universidad de Valencia

Ampliacin Redes 1-57

Rogelio Montaana

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 estticas El trfico se transmite inicialmente por inundacin. Los bucles se evitan por la tcnica denominada RPF Check Los routers no interesados pueden enviar comandos prune (podar); si cambian de opinin pueden enviar comandos graft (injertar) La inundacin (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

Universidad de Valencia

Ampliacin Redes 1-58

Rogelio Montaana

RPF check (Reverse Path Forwarding check)

Es una forma de evitar los bucles por inundacin que consiste en que antes de reenviar por inundacin un paquete el router realiza la siguiente comprobacin: Analiza la interfaz de entrada del paquete y su direccin de origen (unicast) Consulta en la tabla de rutas la interfaz de la ruta ptima hacia la direccin de origen Si la interfaz de entrada coincide con la de la ruta ptima el paquete es aceptado y redistribuido por inundacin. 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 asimtricas

Universidad de Valencia

Ampliacin Redes 1-59

Rogelio Montaana

Funcionamiento del RPF check

Emisor multicast
Rutas ptimas hacia A

A
S1
M

S0

B
S0 S2
M

S1

S0
M

C
S2 S1 S0

G
S1 S1 S2

S0

S1 S0
M

S1

S2

S0
M

E sabe que su interfaz ptima hacia A es S1 y no S0; por tanto descarta el paquete recibido por S0

En cada bucle se envan dos paquetes de ms, pero como los routers los descartan no hay problema

Universidad de Valencia

Ampliacin Redes 1-60

Rogelio Montaana

Funcionamiento de PIM-DM
Inundacin inicial
Red 140.2.2.0/24 1.1.1.0/24 Emisor multicast 140.2.2.2
M

S0 S1

1.1.1.0/24

S1 S2

1.1.1.0/24

S1 S2

A
S1
M

S0

B
S0
M

S1 S2

C
S0
M

S2 S1 S0 S1 S1 S2 1.1.1.0/24 S1

S0

S1
M M M

S1

S0

E
1.1.1.0/24

S2

S0

1.1.1.0/24

S1

S0 S2

1.1.1.0/24

S0 S2

Los paquetes recibidos en estas interfaces no son propagados por inundacin porque no superan la prueba del RPF Check

Universidad de Valencia

Ampliacin Redes 1-61

Rogelio Montaana

Funcionamiento de PIM-DM (II)

Emisin broadcast y Podado (Pruning)
Emisor de 224.2.2.2 M 1.1.1.2 Podado en B 1.1.1.2, 224.2.2.2
M

S1

Podado en C 1.1.1.2, 224.2.2.2 S1 S2

Podado en A 1.1.1.2, 224.2.2.2 S1

E0
M M

A
M

S0 S1

B
S0
M

S1 S2
P

S0
M

C
S2 S1 S0

S0

P M P M

G
P M P

S1

S1

S1 S2

D
2.2.2.2

S1

S0
M

E
E0

S2

S0

F
E0

1: Inundacin (flooding) 2: Podado (prune)

Universidad de Valencia

Grupos de E 224.2.2.2 160.2.2.2 Rogelio Montaana

170.2.2.2 Miembro de 224.2.2.2 Ampliacin Redes 1-62

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, 224.2.2.2
M

S1

Podado en C 1.1.1.2, 224.2.2.2 S1 S2

Podado en A 1.1.1.2, 224.2.2.2 S1

E0
M M

A
S1 S0

S0

B
S0
M

S1 S2

S0
M

C
S2 S1 S0

G
S1 S1 S0
M G

S1

S1 S2

D
2.2.2.2

E
E0

S2

F
S0
M

E0

Grupos de E 224.2.2.2 Grupos de F 224.2.2.2 170.2.2.2 Miembro de 224.2.2.2 Ampliacin Redes 1-63 160.2.2.2 Miembro de 224.2.2.2 Rogelio Montaana

Universidad de Valencia

Funcionamiento de PIM-DM (IV)

Aparicin de un segundo emisor
Emisor de 224.2.2.2 M 1.1.1.2 Podado en B 2.2.2.2, 224.2.2.2 Podado en A 1.1.1.2, 224.2.2.2 2.2.2.2, 224.2.2.2 S1
M

160.2.2.2

S1

Podado en C 1.1.1.2, 224.2.2.2 S1 S2

E0
M

A
S0
P

P M2

S0

B
S0
M

P M2

E0

S1 S2

S0
M

C
S2 S1 S0

S1 Podado en D S0
2.2.2.2, 224.2.2.2 M2 S0

G
S1
M2

M2
M2

S1 S2 S0
M

S1 S2 Podado en F 2.2.2.2, 224.2.2.2 S2

D
2.2.2.2 Emisor de 224.2.2.2 M2

S1

S0
M

E
E0 M2

E0 M2

Grupos de E 224.2.2.2 Grupos de F 224.2.2.2 rbol para 2.2.2.0/24 Universidad de Valencia 170.2.2.2 Miembro de 224.2.2.2 Ampliacin Redes 1-64 160.2.2.2 Miembro de 224.2.2.2

Rogelio Montaana

Problemas del modo denso

Cada router de la red ha de mantener: La topologa del SPT (la relacin de las ramas que cuelgan de l en el rbol). Para cada red emisora y cada grupo hay un rbol diferente La relacin de las ramas que han sido podadas para cada emisor y cada grupo (cada par (S,G), Source, Group) La gran cantidad de informacin de estado hace difcil establecer un servicio multicast en una red grande para un nmero elevado de emisores y grupos Para construir el SPT inicial se procede por inundacin. Para adaptarse a cambios en la red el proceso se repite cada 2-3 minutos, lo cual genera mucho trfico.
Universidad de Valencia

Ampliacin Redes 1-65

Rogelio Montaana

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 estticas Al funcionar en modo disperso no se hace inundacin de la informacin Problema: como localizamos a los emisores Solucin: 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

Universidad de Valencia

Ampliacin Redes 1-66

Rogelio Montaana

Funcionamiento de PIM-SM (I)

rbol compartido, receptores primero
3: Fuente F1 de G (224.2.2.2) 1.1.1.2 M C B A (F1,G) Ent E0 Sal S0 M (F1,G) RS RM RM S0 S1 M J RM RM Ent S0 Sal S1 (F1,G) Ent S0 Sal S1 Registro de emisores (F1,G) S0

RP

Ent
S0

Sal
S1

E0 A

RS J S0 S2

(*, G)

B
S0

S1

C
S1 S0 Rendezvous Point ()

S2

RP
S0 S1 J S1 S1 M M S0 M E0 M S2 S1 S2 F (*, G) Ent S2 Sal E0 S0

E
S0 M E0 M

E (*,G)

Ent S2

Sal E0 3.3.3.3 2: Membership Report 224.2.2.2 EXCLUDE () 2.2.2.3 1: Membership Report 224.2.2.2 EXCLUDE () G

Universidad de Valencia

Ampliacin Redes 1-67

Rogelio Montaana

Funcionamiento de PIM-SM (II)

rbol compartido, emisor primero
1: Fuente F1 de G (224.2.2.2) 1.1.1.2 B A (F1,G) Ent E0 Sal S0 M E0 RM RS J RM S0 S1 RS (F1,G) Ent S0 Sal S1 M C (F1,G) Ent S0 Sal S1 Registro de emisores (F1,G) S0

RP
(F1, G)

Ent
S0

Sal
S1

B
M S0

J S0

S1

C
S2 S1 S0

S2

Rendezvous Point ()

RP
S0 S1 J S1 S1 S2 S1 S2 F E0 M (*,G) Ent S2 Sal E0 S0

E
S0

F
M S0

E0 M

E (*, G)

Ent S2

Sal E0 3.3.3.3 3: Membership Report 224.2.2.2 EXCLUDE () 2.2.2.3 2: Membership Report 224.2.2.2 EXCLUDE ()

Universidad de Valencia

Ampliacin Redes 1-68

Rogelio Montaana

Funcionamiento de PIM-SM (III)

Dos fuentes, rbol compartido
Fuente F1 de G (224.2.2.2) 1.1.1.2 M C B A (F1,G) Ent E0 Sal S0 M E0 (F1,G) Ent S0 Sal S1 RP (F1, G) S0 S1 Ent S0 Sal S1 (F1,G) Ent S0 Sal S1 Registro de emisores (F1,G) (F2,G) S0 S1

B
M S0

S1

C
S0 S2 S1

S2

S0
S1

Rendezvous Point ()

RP
S0 S1 S1 S0 E0 M S1 S2 M2 E0 M2 M F (*, G) (F2,G) 3.3.3.3 Miembro de (*,G) 2.2.2.2 Fuente F2 de G 2.2.2.3 Miembro de (*,G) Ent S2 E0 Sal E0,S0 S0 E (*, G) Ent S2 Sal E0 M2 M S0

S2

Universidad de Valencia

Ampliacin Redes 1-69

Rogelio Montaana

Funcionamiento de PIM-SM (IV)

rbol SPT (Shortest Path Tree)
C Fuente F1 de G (224.2.2.2) M 1.1.1.2 B (F1,G) A (F1,G) Ent E0 Sal S0 M Ent S0 Sal S1 S2 RP Ent S0 (F1,G) Ent S0 Sal S1 S2 Registro de emisores (F1,G) S0

Sal S1

E0 A S1 S0 S0 B
M

(F1,G)

S0
M

S1 M S2

C S0
M

S2

S1 S0 RP S1 S2 E0 M
F (*,G)

Rendezvous Point ()

S1 E

J P

S1 F

S1

S0
M

S2

S0
M

Ent S2 S1

Sal E0 S0

E0 M

E (*, G) 1: E crea SPT para (F1,G)

Ent S2 S1

Sal E0 3.3.3.3 Miembro de (*,G) 2.2.2.3 Miembro de (*,G)

2: F crea SPT para (F1,G)

Universidad de Valencia

Ampliacin Redes 1-70

Rogelio Montaana

Leyenda de smbolos empleados en las diapositivas

M

Datagrama multicast. Direccin de origen: 1.1.1.2. Direccin de destino 224.2.2.2 Datagrama multicast. Direccin de origen: 2.2.2.2. Direccin de destino 224.2.2.2 Mensaje Prune (DVMRP, PIM-DM, PIM-SM y CBT) Mensaje Graft (DVMRP y PIM-DM) Mensaje Join (PIM-SM y CBT) Mensaje Register con datagrama multicast encapsulado (PIM-SM) Datagrama multicast desencapsulado por un RP (PIM-SM) Mensaje Register Stop (PIM-SM)

M2

J RM M

RS

Universidad de Valencia

Ampliacin Redes 1-71

Rogelio Montaana

Mensajes PIM SM
Los mensajes Join o Prune de PIM-SM se envan 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 direccin de destino de esos mensajes no es el RP o la fuente, sino la direccin multicast 224.0.0.13; por tanto solo se mandan al siguiente router. El siguiente router, en funcin del mensaje recibido y su informacin 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 envan siempre a la direccin unicast del RP y del emisor. Los routers intermedios no tienen ninguna posibilidad de interceptarlos o modificar su contenido
Universidad de Valencia

Ampliacin Redes 1-72

Rogelio Montaana

PIM-SM
Es el ms complejo de los protocolos de routing multicast en uso actualmente Los rboles compartidos minimizan la cantidad de informacin de estado en los routers. Los rboles SPT optimizan el trfico Se suele fijar un umbral de trfico 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 ms futuro en Internet. MBone est evolucionando hacia PIM-SM
Universidad de Valencia

Ampliacin Redes 1-73

Rogelio Montaana

Eleccin del RP
El RP se puede asignar por configuracin 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 ubicacin del RP no es crtica en lo que a rendimiento se refiere. Sin embargo si el RP falla el multicast en la red deja de funcionar.
Ampliacin Redes 1-74

Universidad de Valencia

Rogelio Montaana

Descubrimiento del RP
Para evitar la configuracin manual la mayora 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

Universidad de Valencia

Ampliacin Redes 1-75

Rogelio Montaana

Multicast entre sistemas autnomos

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 informacin Para el trfico multicast entre ASs se utiliza el protocolo BGMP (Border Gateway Multicast Protocol) (RFC 3913, 9/2004)

Universidad de Valencia

Ampliacin Redes 1-76

Rogelio Montaana

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 asimtricas: 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 trfico multicast pueden cargar mucho los routers. Seguridad: es muy fcil realizar ataques de denegacin de servicio en una red con mutlicast habilitado. Escalabilidad: algunos protocolos de multicast no han sido probados a gran escala, especialmente entre diferentes sistemas autnomos.

Universidad de Valencia

Ampliacin Redes 1-77

Rogelio Montaana

Aplicaciones Multicast
Todas las aplicaciones multicast utilizan UDP como protocolo de transporte No hay control de congestin No hay control de datagramas errneos, duplicados, descartados, etc. Todas estas tareas quedan a cargo de la aplicacin, que recibe informacin de la situacin a travs de los protocolos RTP y RTCP. La inmensa mayora de las aplicaciones disponibles para multicast son herramientas de comunicacin multimedia (vdeoconferencia, distribucin de vdeo, etc.).

Universidad de Valencia

Ampliacin Redes 1-78

Rogelio Montaana

RFCs sobre multicast

Protocolo mbito Direcc. MZAP SAP MADCAP MASC Glop addressing IGMP v1 IGMP v2 IGMP v3 DVMRP (v1) DVMRP v3 PIM-DM MOSPF PIM-SM v1 PIM-SM v2 RFC 2365 2776 2974 2730 2909 3180 1112 2236 3376 1075 Draft 3973 1584 2362 Draft Fecha 07/1998 02/2000 10/2000 12/1999 09/2000 09/2001 08/1989 11/1997 10/2002 11/1988 05/2004 01/2005 03/1994 06/1998 03/2006 Pg. 8 27 18 53 56 5 5 (17) 24 53 24 49 61 102 66 148 Experimental Estndar Experimental Estado Best current practice Estndar Experimental Estndar Experimental Best current practice Estndar Estndar Estndar Experimental Grado Implement. Alto Muy bajo Alto Muy bajo Muy bajo Alto Muy bajo Medio Alto Muy bajo Muy bajo Alto Muy bajo Medio Alto

CBT v2
BGMP MSDP

2189
3913 3618

09/1997
09/2004 10/2003

23
41 19

Experimental
Informativo Experimental

Muy bajo
Alto Muy bajo

Universidad de Valencia

Ampliacin Redes 1-79

Rogelio Montaana

Problema examen Febrero 2002

Dada la red multicast PIM-SM de la figura dibuje cual sera el rbol de distribucin multicast en caso de que el RP se site en cada uno de los siete routers de la red. Diga cual o cuales ubicaciones hacen un uso ms eficiente de la red, usando como criterio de optimizacin minimizar el trfico total en el conjunto de enlaces WAN. Se supone que la mtrica utilizada es nicamente el nmero de saltos.
Receptor Receptor

Emisor

Receptor

Universidad de Valencia

Ampliacin Redes 1-80

Rogelio Montaana

Solucin:
A C B D F
R R

A B D F
R R

C
E G
R

B D F
R

E
G
R

E
G
R

RP en A: 6 enlaces
E E

RP en B: 4 enlaces
E

RP en C: 5 enlaces
E

A C E G
R

A B D F
R R

B
D F
R

C E G
R

B
D F
R

C E G
R

C E G
R

B
D F
R

RP en D: 4 enlaces
Universidad de Valencia

RP en E: 5 enlaces

RP en F: 4 enlaces

RP en G: 6 enlaces
Rogelio Montaana

Ampliacin Redes 1-81

Junio 2004. Problema 2.2

2

P1

P2

P3

P4
A

B 3 P1

Servidores de vdeo multicast

1 C

1 D 2 4

2 P4

P3

Router multicast

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 B Puerto 1 2 3 1 2 1 2 3 4 Flujo entrante (Mb/s) 2 0 0 8 0 4 0 0 0 Flujo saliente (Mb/s) 0 2 2 0 8 0 4 4 4

C D

A enva por cada puerto solo las emisiones multicast que tienen algn suscriptor: Hacia B P1 Hacia D P3 y P4 Hacia C todos (router en modo promiscuo)
Rogelio Montaana

Universidad de Valencia

Ampliacin Redes 1-82

Febrero 2005. Problema 3.1

P1

P2

P3

P4

Routers: Eth0 recibe los cuatro grupos (modo promiscuo) Eth1 enva P1 y P3 Eth2 enva P1 Eth3 enva P4 Hosts: H1 y H2 reciben P1 H3 y H4 reciben P3 H5 y H6 no reciben nada H7 y H8 reciben P1 H9 y H10 no reciben nada H11 y H12 reciben P4

Servidores multicast

Eth0 Conmutadores con IGMP Snooping Eth2 Eth3

Eth1

P3 P1 H1 H2 H3 H4 H5 H6 H7 P1 H9 H10 P4

H8

H11

H12

Indique que flujos pasan por cada una de las interfaces del router y que flujos llegan a cada host. Los conmutadores de primer nivel implementanIGMP Snooping, los de segundo nivel no

Universidad de Valencia

Ampliacin Redes 1-83

Rogelio Montaana

Junio 2007. Problema 2.1

Receptor P3 Receptor P1

P1 genera 500 Kb/s de trfico entrante en E0 de A

P2 no genera ningn trfico en A

Emisor P1 E0

P3 genera 500 Kb/s de trfico que entra por S1 y sale por E0 . Adems salen 500 Kb/s por S0 hacia B
A
S1

S0

2048 Kb/s
B 64 Kb/s

2048 Kb/s
C

Interfaz E0 S0 S1

Entrante 500 Kb/s (P1) 0 Kb/s 500 Kb/s (P3)

Saliente 500 Kb/s (P3) 500 Kb/s (P3) 0 Kb/s

Emisor P2 Receptor P3 Receptor P3

Emisor P3

Routing unicast: OSPF (mtrica basada en ancho de banda) Routing multicast: PIM-SM con RP en A. Se revierte al SPT de forma inmediata Los conmutadores tienen IGMP Snooping Cada emisor genera 500 Kb/s de trfico Calcule el flujo entrante y saliente en cada interfaz del router A
Universidad de Valencia

Ampliacin Redes 1-84

Rogelio Montaana

Febrero 2007. Problema 2.1

Servidor 192.168.1.1/24 Emisin de vdeo (10 Mb/s) 239.0.0.1

Servidor 192.168.1.2/24 Emisin de audio (50 Kb/s) 239.128.0.1

H1 192.168.1.3/24

H2
192.168.1.4/24

H3
192.168.1.5/24

H4
192.168.1.6/24

H1 y H2 reciben audio, ningn host recibe vdeo (no tienen aplicacin adecuada) Si la emisin de vdeo cambia a la direccin 239.0.0.2, Cmo cambia el trfico? Los conmutadores no implementan IGMP Snooping
R: Al no tener IGMP Snooping en los conmutadores el trfico multicast es inundado en toda la red, todos los hosts reciben el audio y el vdeo, antes y despus del cambio de direccin en el flujo de vdeo En H3 y H4, que no se han asociado a ninguna emisin, la tarjeta de red filtra todo el trfico multicast por lo que este no consume ciclos de CPU ni antes ni despus del cambio. En H1 y H2 con la direccin 239.0.0.1 el vdeo utiliza la misma direccin MAC que el audio, por lo que no es posible filtrar el trfico de vdeo que consumir ciclos de CPU. Con la nueva direccin la MAC es diferente y por tanto es posible el filtrado.
Universidad de Valencia

Ampliacin Redes 1-85

Rogelio Montaana