Documentos de Académico
Documentos de Profesional
Documentos de Cultura
RSVP puede ser utilizado tanto por hosts como por routers para pedir o entregar niveles
específicos de calidad de servicio (QoS) para los flujos de datos de las aplicaciones. RSVP
define cómo deben hacer las reservas las aplicaciones y cómo liberar los recursos
reservados una vez que han terminado. Lasoperaciones RSVP generalmente dan como
resultado una reserva de recursos en cada nodo a lo largo de un camino.
RSVP por sí mismo rara vez es desplegado en redes de telecomunicaciones hoy en día pero
para RSVP-TE, está comenzando a aceptarse de forma más común en muchas redes con
QoS.
Mensajes
Los datos sobre los mensajes RSVP se pueden transmitir en cualquier orden. Para la lista
completa de los mensajes RSVP y fecha objetos consulte RFC 2205.
[editar] Operaciones
Es necesario que una acogida envie un flujo de datos específicos con QoS transmitirá a
RSVP una vía mensaje que viajará a lo largo de las rutas de unidifusión y multidifusión
previamente establecido por elprotocolo de enrutamiento de trabajo. Si la ruta mensaje
llega a un router que no entiende RSVP, el router envía el mensaje sin interpretar el
contenido del mensaje y la no reserva de los recursos para la corriente.
anfitriones y adyacente multicast rebajadoras para establecer calidades de miembro de grupo del
multicast.
Es una parte integral de Multicast del IP especificación, funcionando sobre capa de red, aunque no
actúa realmente como a protocolo del transporte[1]. Es análogo a ICMP para unicastconexiones.IGMP
se puede utilizar para en línea vídeo que fluyey el juego, y permite un uso más eficiente de recursos al
apoyar estos tipos de usos.IGMP permite algunos ataques[2] , y los cortafuegos permiten
[3] [4] [5]
IGMP es un protocolo estándar con un número STD de 5 que incluye además a IP(ver
IP("Internet Protocol")) e ICMP (ver ICMP("Internet Control Message Protocol")). Su
status es recomendado y el RFC 1112 lo describe.
IGMPse considera más bien como una extensión de ICMP y ocupa el mismo lugar en la
pila de protocolos IP. (3)
Los mensajes ICMP se envían en datagramas IP. La cabecera IP siempre tendrá un número
de protocolo igual a 2, indicando IGMP y un tipo de servicio cero(rutina). El campo de
datos IP contendrá el mensaje IGMP de ocho bytes mostrado en Figura - Formato del
mensaje ICMP.
Donde:
Vers
Type
Checksum
Un checksum de 16 bits calculado de igual forma que con ICMP.
Class D Address
Los sistemas que participan en IGMP se clasifican en dos tipos: host y "routers" multicast.
Para unirse a un grupo, el host envía un informe acerca de una interfaz. El informe se dirige
al grupo multicast interesado. Los "routers" multicast de la misma red reciben el informe y
activan un flag para indicar que al menos un host de esa red es miembro de ese grupo. Todo
host pertenece al grupo 224.0.0.1 de forma automática. Los "routers" multicast tienen que
escuchar a todas las direcciones de multicast(todos los grupos) con el fin de detectar tales
informes. Las alternativas serían el uso del broadcast para los informes o para configurar
host con direcciones unicast para "routers" multicast.
2+
Todos los hosts que sean miembros del grupo y todos los "routers"
multicast reciben el datagrama. La acción de los "router" depende de la
dirección del grupo multicast.
224.0.0.0 - 224.0.0.255
Este rango se emplea sólo para aplicaciones multicast que hagan uso de
un único salto. Los "routers" multicast no retransmitirán datagramas con
direcciones IP en este rango.
other
1.- Introducción
MBone (Multicast Backbone On Internet) existe desde 1992 como una red virtual para la
experimentación del uso del IP Multicast en Internet. Esta red se ha empleado mayoritariamente para el
estudio de herramientas de audio/vídeo conferencias multipunto, aunque en principio puede ser
empleada para el intercambio de cualquier tipo de información multimedia. Su principal ventaja, o
debiéramos decir característica, es la de proporcionar el intercambio de información de uno a muchos,
pero sin los inconvenientes de tener que duplicar dicha información para cada uno de los receptores y
en función del número de ellos.
Si esta red virtual se implantó inicialmente hace bastantes años, ¿Por qué no ha abandonado aún su
calidad de experimental y se ha convertido en un servicio operativo? Pues principalmente por ser una
`red virtual'; una red creada como la unión de múltiples `islas' interconectadas entre sí. Esto es así
debido bien a que la mayor parte de equipos de comunicaciones que interconectan la infinidad de redes
que forman Internet aun no hablan el lenguaje del MBone, es decir, el IP Multicast, o lo hacen de forma
incompatible con otros. Pese a que el panorama está cambiando muy rápidamente y que un gran
número de ingenieros, tanto de empresas privadas como pertenecientes al ámbito académico y/o
investigador, se están esforzando conjuntamente para convertir este experimento global en un servicio
operativo, aún existen ciertas complicaciones que apuntan a que MBone seguirá siendo por el momento
una red experimental en la Internet. Esto, evidentemente, no quiere decir que los conceptos de MBone
no puedan ser empleados con éxito y de manera totalmente funcional dentro de redes corporativas o
incluso entre distintas intranets, sino que el objetivo final, el hacer de las comunicaciones multicast algo
inherente a Internet, es algo que aún está lejano. Más adelante volveremos sobre este tema, pero antes
debemos presentar ciertos conceptos que forman la base tecnológica de MBone.
• 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).
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.
El concepto de direcciones multicast fue una idea original de Steve Deering que describió en su tesis
doctoral en la Universidad de Stanford, y que más tarde continuó desarrollando en el Centro de
Investigación de Xerox en Palo Alto (Xerox PARC). Van Jacobson, de los laboratorios Lawrence
Berkeley (LBL), Steve Casner, del ISI (Information Science Institute) así como varios ingenieros más, se
interesaron por continuar el estudio iniciado por Steve Deering y su implantación experimental en
Internet. Resultado de estas investigaciones fue la publicación del RFC 1112, en el que se definen los
requisitos necesarios que debe cumplir un equipo para poder `hablar' IP multicast.
En 1992, durante una de las reuniones periódicas de coordinación del grupo de trabajo de redes
(Network Working Group) del IETF (Internet Engineering Task Force), se adoptó la implantación
experimental del IP multicast en Internet, reservándose un rango de direcciones IP para el mismo (clase
D de direcciones). Este fue el nacimiento del MBone.
En los comienzos del MBone, pocos ordenadores eran capaces de entender dichas direcciones
multicast. La mayor parte de estos equipos han sido aquellos basados en el sistema operativo UNIX (en
cualquiera de sus variantes) dada la gran flexibilidad del mismo para realizar modificaciones a bajo nivel,
al ser este un sistema operativo compilado del que se puede disponer de los códigos fuentes con cierta
facilidad, o al menos las partes necesarias para acceder directamente a los dispositivos de
comunicaciones. En la actualidad, estos requisitos están implementados (o al menos están disponibles
las herramientas para activarlos) en la gran mayoría de sistemas operativos que incluyen soporte de
comunicaciones para redes TCP/IP: Windows95, WindowsNT, UNIX (todas sus variantes), MacOS, etc.
Es muy probable que, en un futuro no muy lejano, la posibilidad multicast sea un requerimiento básico
de cualquier equipo conectado a Internet.
Volviendo al tema de cómo funciona el IP multicast, decíamos que cuando un ordenador envía un
datagrama IP multicast, este sólo lo recibe un grupo determinado de equipos, mientras que el resto
sencillamente lo ignoran. Para ello es necesario que el ordenador permita, a las aplicaciones que hacen
uso del multicast, configurar el dispositivo de red para recibir, no sólo los datagramas que van
destinados a su dirección IP, como es habitual, sino también aquellos que van destinados a una
determinada dirección multicast. Del mismo modo, se debe poder indicar al dispositivo de red, que deje
de recibir los datagramas de una determina dirección multicast. Estas acciones de unirse (join) o
abandonar (leave) una determinada dirección multicast, también son significativas para los dispositivos
que encaminan los datagramas multicast entre varias subredes (mrouters) y son realizadas por medio
de un protocolo sencillo llamado IGMP (Internet Group Management Protocol), del que hablaremos más
adelante.
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. Por otro lado,
no es necesario que un equipo pertenezca a un grupo concreto multicast para enviar datagramas al
mismo.
Las direcciones IP multicast, que todo equipo conectado a MBone debe saber reconocer (además de
ser capaces de hablar IGMP, que describiremos más adelante, y de poder enviar y recibir datagramas
UDP a una dirección multicast), forman una clase de direccionamiento llamada clase D, que se
caracteriza porque todas estas direcciones comienzan con el prefijo binario 1110. La siguiente tabla
muestra las diferentes clases de direcciones IP en Internet tanto en binario como en la clásica notación
decimal de cuatro octetos decimales separados por puntos
De todas las direcciones IP multicast posibles, algunas están reservadas para uso interno por equipos
de comunicaciones que intercambian información sobre multicast (u otros usos), otras para uso local
dentro de Intranets, otras para controlar el alcance de distribución de multicast en base a criterios
administrativos, y las comprendidas en el rango: 224.2.0.0.0 - 224.2.255.255 son las que forman el
conjunto de direcciones IP multicast usadas en el MBone para las conferencias globales multimedia.
Dentro de este rango hay ciertas direcciones reservadas para los anuncios de sesiones multimedia (de
las que hablaremos cuando expliquemos el funcionamiento del SDR o directorio de sesiones MBone).
Una lista completa de las asignaciones de direcciones multicast se puede encontrar en el RFC 1700
sobre asignación de números en Internet publicado por la IANA (Internet Asigned Numbers Authority), o
sus sucesores. También se puede consultar en la siguiente dirección:
http://www.iana.org/iana/assignments.html
Los datagramas multicast son enviados hacia los miembros del grupo destino usando la misma fiabilidad
`best effort' que los datagramas IP unicast. Esto quiere decir que 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 es el UDP (User Datagram Protocol) que ofrece la ventaja de que al ser un protocolo ligero,
los datagramas sufren menos retrasos en alcanzar su destino. Sin embargo 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. Más adelante veremos como
se ha resuelto este problema en MBone.
Hasta ahora nos hemos podido hacer una idea de cómo funciona el IP multicast dentro de un segmento
de red local, pero ¿Cómo se propaga esta información a través de distintos tramos de red? o ampliando
el concepto ¿Cómo se aplica esto a la Internet dando forma a lo que se llama MBone?. Pues bien, esto
se realiza a través de los encaminadores (routers) que interconectan tanto múltiples segmentos de red,
como las múltiples redes que forman la Internet. Cuando un router esta cualificado para intercambiar
datagramas IP multicast con otro u otros, decimos que es un router multicast, o abreviadamente un
mrouter.
• Debe tener un mecanismo para conocer en todo momento los equipos que pertenecen a un
determinado grupo multicast en cada una de las redes que interconecta.
• Para cada pareja {dirección IP origen (o fuente), grupo multicast} debe saber cómo encaminar
los datagramas, originados en esa dirección IP, a los segmentos de red donde haya otros
miembros de ese grupo multicast.
Lo segundo se refiere a los criterios de encaminamiento multicast (multicast routing protocol) de los que
debe disponer el mrouter, y que presentaremos en la siguiente sección.
La primera implementación del IGMP fue publicada por Steve Deering en el RFC 1112 que hemos
mencionado antes, a mediados de 1989. Este fue remplazado, en noviembre de 1997, por el RFC 2236
que define la versión 2 del protocolo (IGMPv2), y en la actualidad el grupo de trabajo idmr (Inter-
Domain Multicast Routing) del IETF está trabajando en una nueva versión del mismo (versión 3).
Del mismo modo que el ICMP (Internet Control Message Protocol )(RFC 792), el IGMP (Internet Group
Membership Protocol) es una parte integral del IP. Los mensajes IGMP son transmitidos en datagramas
IP y tienen un tamaño fijo de 8 bytes. La siguiente figura muestra el formato de los mensajes IGMP.
El campo Tipoespecifica los diferentes mensajes IGMP posibles. El campo MRT(Maximun Response
Time) ha sido introducido en el IGMPv2 e indica el tiempo máximo de respuesta permitido a ciertos
mensajes. El checksumes un valor calculado en función de los valores de el mensaje IGMP en su
conjunto y se emplea para comprobar que no se hayan producido errores en la transmisión del mismo.
El último campo es la dirección del grupo multicast.
Los tipos de mensajes IGMP que utilizan ordenadores y mrouters para mantener informados a estos
últimos de la permanencia de los primeros dentro de cada grupo multicast, son los siguientes:
La dirección multicast 224.0.0.1 es una dirección reservada (asignada por la IANA), que se refiere a
todos los equipos multicast dentro de una misma subred, a la que pertenecen por defecto todos los
equipos que `hablan' multicast.
El resto de los mensajes son enviados por los ordenadores con destino a cada grupo multicast al que
pertenecen, para informar de su filiación a ese determinado grupo. Para evitar una avalancha de
respuestas por parte de los ordenadores miembros de cada grupo, se utiliza una técnica que consiste en
emplear una serie de temporizadores, inicializados a un valor aleatorio, que cada ordenador mantiene
para cada uno de los grupos multicast a los que pertenece. Sólo se responderá a las consultas de
filiación enviadas por los mrouters cuando dichos temporizadores se anulen, y en caso de que otro
ordenador responda antes, el resto de los que pertenecen a dicho grupo volverán a inicializar sus
temporizadores a unos valores aleatorios. De esta forma se consigue, sin colapsar la subred, que el
mrouter conozca si existen miembros activos en la misma.
En caso de que el ordenador no pertenezca a ningún grupo multicast, sencillamente ignora todos los
mensajes IGMP.
Para eludir prolongados tiempos de espera entre la emisión de las consultas de filiación por parte de los
mrouters y su correspondientes respuestas por parte del resto de los equipos, en la versión 2 del IGMP
se introdujo en los mensajes el valor MRT, o tiempo de respuesta máximo para cada consulta. Esto
evita, por otro lado, que se prolongue el tiempo que continúan enviándose datagramas multicast a un
segmento de red en el que no permanecen receptores activos.
En la versión 3 de este protocolo, que actualmente está en fase de estudio por parte del grupo de
trabajo idmr del IETF, se añade la funcionalidad de filtrado por origen, es decir, se permite la opción de
que los equipos multicast puedan expresar su interés en recibir datagramas multicast que provienen
sólo desde determinadas direcciones IP, o de cualquiera excepto de un número limitado de ellas.
Hay que remarcar que los mensajes IGMP se envían dentro de los datagramas IP con un valor de TTL
(Time To Live) igual a 1, para evitar que sean propagados por otros routers tradicionales (routers
unicast) más allá de la subred en la que se emiten, dado que por su definición, su utilidad es mantener
informados a los mrouters de los miembros activos dentro de una subred.
Los detalles de cómo se comportan ordenadores y mrouters en el diálogo IGMP están especificados en
las referencias [6] y [7] de las notas bibliográficas de este documento.
3.- ¿Cómo se encaminan los datagramas multicast?
Las ventajas de la idea del IP multicast se hacen patentes cuando podemos extender el esquema de
funcionamiento entre varias subredes, es decir, cuando los miembros de un determinado grupo multicast
están distribuidos en varios segmentos de red distintos, interconectados a través de mrouters. Para que
el concepto multicast funcione, no basta con que los routers multicast conozcan, por medio del IGMP
(como se ha explicado antes), qué equipos pertenecen a un determinado grupo multicast en los
segmentos de red que este conecta, sino que deben saber tomar las decisiones necesarias para
encaminar los datagramas multicast entre dichas subredes, asegurando que los enviados por un
determinado equipo lleguen a todos los miembros de cada grupo multicast, y procurar, por otro lado, que
no se produzcan bucles, esto es, que cada datagrama llegue a sus destinatarios sólo una vez (y,
preferiblemente, por el camino más corto). Es decir, debe existir una determinada política de
encaminamiento multicast, o dicho de otra forma, estos routers deben implementar un protocolo de
encaminamiento (routing) multicast. Un protocolo de encaminamiento multicast es el que se encarga de
la construcción de los árboles de distribución (delivery trees) y habilitar la remisión (forwarding) de
datagramas multicast. La característica diferencial entre el encaminamiento unicast y el multicast, es
que los datagramas multicast deben ser remitidos acullá de su origen. Si un datagrama IP multicast es
remitido hacia su origen, se podría producir un bucle de remisión, que podría dar lugar a una `avalancha'
multicast.
Todos los protocolos de encaminamiento multicast hacen uso del protocolo IGMP para conocer la
filiación de los equipos finales a cada determinado grupo multicast, pero difieren en la forma de
intercambiar dicha información entre mrouters vecinos, así como en las técnicas empleadas en la
construcción de los árboles de distribución.
En cuanto a los tipos de protocolos de encaminamiento podemos distinguir, del mismo modo que para el
encaminamiento unicast, dos grandes familias:
En cuanto a los algoritmos empleados por los protocolos de encaminamiento multicast, su descripción
es compleja y está fuera del propósito de este artículo el proporcionar una explicación de los mismos.
Se puede hallar esta información en las referencias [2] y [8]de la bibliografía. Tan sólo indicaremos que
se podrían dividir en dos grandes categorías:
Hay que resaltar que los protocolos de encaminamiento multicast son, por lo general, bastante más
complejos que sus homólogos en unicast, y por otro lado su desarrollo ha sido más tardío, por lo que
aún presentan mayores deficiencias, sobre todo cuando se aplican a redes complejas y no digamos a
toda la Internet. Sin embargo su evolución ha sido más rápida, debido en gran medida, al gran interés
que ha despertado, en función de sus enormes posibilidades de aplicación, tanto en redes académicas
como entre las grandes y pequeñas empresas relacionadas con el sector de las telecomunicaciones.
También, por qué no, por la presión de usuarios finales y empresas que hacen uso de Internet en
demanda de un medio multicast que permita ampliar sus horizontes de oferta de servicios multimedia de
forma eficaz y económica.
Uno de los primeros protocolos de encaminamiento multicast fue el DVMRP (Distance Vector Multicast
Routing Protocol), desarrollado por Steve Deering en la Universidad de Stanford en 1988, y que se
encuentra definido en el RFC 1075.
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. Tras recibir
estos datagramas, los mrouters de los extremos del árbol de distribución, o mrouters 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 mrouter 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), que es un protocolo unicast, también
del tipo vector distancia. Con esta tabla de encaminamiento guarda la información de la interfaz que
conduce a la fuente de un determinado datagrama 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 mrouter decrementa el valor del TTL del mismo y posteriormente lo
compara con los umbrales definidos en sus túneles. 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. 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 aún están en proceso de desarrollo dentro del grupo de trabajo mboned del IETF (en
el momento de escribir este artículo el último borrador databa de noviembre de 1997).
La primera implementación de este protocolo fue desarrollada por el grupo de Van Jacobson del LBL
(Lawrence Berkeley Laboratoy, USA) en 1992, como una aplicación diseñada para funcionar en
máquinas UNIX (mrouted). Esta primera implementación del protocolo DVMRP sólo comprobaba la
filiación de miembros a un determinado grupo multicast en los extremos de la red. Como consecuencia
de ello, los datagramas multicast eran distribuidos por toda la red. En 1993 salió a la luz una nueva
versión del mrouted que implementaba correctamente los mecanismos de podado de ramas (pruning).
De hecho, múltiples variaciones se han desarrollado sobre la implementación del mrouted hasta el
momento, alejándose ligeramente de las especificaciones definidas en el RFC 1075, en gran parte para
solventar ciertas deficiencias que la implementación de la definición original presentaba, y en parte para
adaptarlo a nuevas extensiones al protocolo IGMP.
Esta implementación convierte a la computadora en la que opera, en un router multicast que puede
intercambiar información DVMRP con otros routers multicast similares a través de túneles definidos por
los administradores de los mismos. Estos túneles encapsulan los datagramas IP multicast en otros
datagramas IP unicast que son enviados por los caminos habituales y a través de routers
convencionales desde el mrouter origen al destino. Cuando el mrouter destino recibe un datagrama IP
de estas características, se encarga de eliminar las cabeceras sobrantes, obteniendo el datagrama IP
multicast original, e inyectarlo en la red local o re-enviarlo a través de otros túneles en función de los
algoritmos de distribución implementados en el protocolo DVMRP antes mencionados. Estos túneles
constan de cuatro variables a configurar por el administrador: La dirección de destino del túnel (y la
origen, en el caso de que la estación disponga de varias interfaces de red); la métrica, que asocia un
coste a cada uno de los caminos alternativos que tenga el mrouter definidos (otros túneles, si los hay); el
threshold (umbral), que establece una barrera para limitar el ámbito de distribución de los datagramas
en función del TTL asociado a los mismos; y el rate_limit, o ancho de banda máximo permitido a través
de dicho túnel.
El desarrollo de esta primera implementación del DVMRP fue la que permitió el nacimiento de lo que
hoy es MBone. En marzo de 1992 se produjo la primera transmisión de audio y vídeo en tiempo real a
través del recién creado troncal experimental multicast. Desde las apenas 40 redes conectadas en
1992, MBone ha experimentado un crecimiento sin precedentes hasta las más de 4.300 redes
conectadas, a lo ancho del mundo, en 1997.
La interconexión de estos mrouters de fácil instalación, ha ido incrementándose con el paso del tiempo
dando lugar al entramado de routers multicast que forman el MBone. La ventaja de disponer de túneles
de multicast corriendo sobre estaciones de trabajo, es el no comprometer las comunicaciones de cada
centro, de tal forma que cualquier mal funcionamiento de dichos equipos no suponga un detrimento
grave de las comunicaciones del mismo, sino tan sólo de aquellas referentes al tráfico multicast.
Aparte del DVMRP existen otros protocolos de encaminamiento multicast, que han ido surgiendo con el
tiempo en la búsqueda de una solución de más fácil implementación y que resolviese los problemas de
escalabilidad de que adolece el DVMRP (como cualquier protocolo de vector distancia).
El MOSPF (Multicast Open Shortest Path First), definido en el RFC 1584, es una extensión al protocolo
de encaminamiento unicast OSPF (RFC 1583). Este último es 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. 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}. 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.
Otros dos protocolos más han sido definidos por el grupo de trabajo idmrdel IETF: el PIM-DM (Protocol
Independent Multicast-Dense Mode) y el 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. Sencillamente asume que estos mecanismos existen y delega en
ellos 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}.
PIM-DM usa, del mismo modo que el DVMRP, el algoritmo de `Reverse Path Multicasting', pero a
diferencia de este último, 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.
La razón principal del desarrollo del PIM-SM, ha sido el intentar paliar las deficiencias presentadas por el
DVMRP y MOSPF en los casos en que los enlaces entre mrouters 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
mrouters, situación que se presenta en las topologías de red extensa (WAN).
Todos los protocolos mencionados hasta el momento (a excepción del PIM-SM), se comportan más o
menos eficientemente en condiciones de una distribución poblada de receptores dentro de la intranet.
Sin embargo, fallan cuando se aplican a entornos de red extensa o de población esparcida, en las que el
número de receptores puede considerarse, en términos generales, escaso. Para cubrir estos supuestos,
están en desarrollo dos nuevos protocolos de encaminamiento multicast: el PIM-SM (PIM Sparse mode)
y los de árbol basado en el núcleo o `Core-based trees' (CBT).
El protocolo PIM-SM (documentado en el RFC 2117), puede usar simultáneamente las técnicas de árbol
basado en la fuente (source-based tree) o de árbol compartido (shared tree). Por defecto se utilizan
diagramas de árbol compartido centrados en un mrouter principal o `Rendezvous Point', pero con
independencia de la técnica en uso, no se produce la remisión, por defecto, de datagramas multicast.
Para que esto ocurra es necesario que estos RP reciban un mensaje de sus mrouters vecinos con una
petición explícita de filiación a un determinado grupo.
Existen un cierto número de inconvenientes que impiden hacer de MBone un servicio operativo en la
actualidad. Algunos de ellos constituyen un defecto intrínseco de la propia filosofía de diseño de MBone
como un experimento en nuevos protocolos de comunicaciones. Otros, por el contrario, son resultado
del estado primitivo aún de estos protocolos, o de la falta de algunas piezas en este complejo
rompecabezas.
La implementación real del MBone como un servicio operativo global, requerirá un cambio topológico
esencial en el que, las cada vez más numerosas islas multicast interconectadas entre sí, dejen paso a
un medio completamente multicast integrado dentro del encaminamiento IP. Esto no implica que se
deba producir de una forma radical, sino más bien tendrá lugar de una forma progresiva. Para que esto
pueda tener lugar, se requieren muchos esfuerzos encaminados a acabar de perfilar los protocolos
existentes hasta adaptarlos a un modelo que ofrezca las cualidades de escalabilidad que una red tan
compleja como la Internet requiere, o descubrir otras vías alternativas que ofrezcan una solución global
a la integración del encaminamiento unicast y multicast. Mientras tanto, MBone ofrece numerosas
ventajas dentro de cada una de estas `islas' multicast que lo forman.
Los protocolos de árbol compartido (PIM-SM, CBT) carecen de este problema, pero sin embargo,
pueden dar lugar a la remisión de datagramas por parte de Rendezvous Points o Cores situados en las
fronteras de áreas que se solapan y que están dentro del árbol compartido para las mismas, aún cuando
no haya receptores en su propia subred. También pueden presentar problemas de congestión de red
debido a las concentraciones de tráfico en los árboles compartidos, lo que da lugar a un incremento de
la latencia o pérdida de paquetes.
En cuanto al nivel de transporte, en el primer apartado de este artículo, habíamos indicado que una de
las grandes desventajas del uso del protocolo UDP para el transporte de contenidos multimedia en
tiempo real, es la imposibilidad de garantizar la llegada ordenada de los paquetes de información a sus
destinos. Este problema, inherente a la propia tecnología empleada, ha sido resuelto con la definición de
un nuevo protocolo orientado a este tipo de transmisiones. Este es el protocolo de transporte en tiempo
real o RTP (Real Time Protocol). La implementación de este protocolo está documentada en el RFC
1889, publicado por el IETF en enero de 1996.
El RTP fue pensado para satisfacer las necesidades de multi-conferencias multimedia, sin embargo su
uso no esta limitado a estas aplicaciones. Puede emplearse del mismo modo en el almacenamiento
continuo de datos, la simulación distribuida, control y medida en tiempo real, etc. El RTP permite la
distribución de información a múltiples receptores usando multicast si este modo de distribución es
soportado por la infraestructura de red subyacente. Sin embargo, el protocolo RTP, no garantiza la
entrega a tiempo de la información, sino que confía en el medio subyacente para este propósito. Por
otro lado incluye su propia secuenciación de fragmentos que permite reconstruir ordenadamente la
información en su destino, con independencia de que exista un medio fiable o no de transmisión.
El problema que se presenta entonces es el de poder garantizar una calidad de servicio aceptable en las
transmisiones multimedia. Esta quizás sería una de las últimas piezas que harían funcionar el engranaje
de MBone como un servicio operativo, en cuanto a nivel de transporte se refiere, es decir, sin tener en
cuenta la problemática del encaminamiento multicast descrita anteriormente. Para poder garantizar la
calidad del servicio es necesario disponer de un mecanismo que nos permita reservar los recursos
necesarios, tanto a nivel del equipo transmisor (tiempo de CPU, ancho de banda de acceso a disco,
etc.), como en el camino entre éste y el(los) receptores (ancho de banda mantenido en la ruta entre
ellos). Gran parte de estas características se han definido dentro de un protocolo llamado `Resource
ReSerVation Protocol' (RSVP), documentado en sus múltiples aspectos en los RFCs 2205 a 2216.
El RSVP lo usan los equipos finales para solicitar una determinada calidad de servicio de la red, para un
flujo de datos de una aplicación específica. También lo emplean los routers para distribuir estas
peticiones de calidad de servicio a todos los nodos intermedios en el camino de dicho flujo y para
establecer y mantener el estado que permita prever el servicio solicitado. Este protocolo no se encarga
de transmitir la información, sino que es un protocolo de control como el ICMP, IGMP o los de
encaminamiento.
Las misiones del transbordador de la agencia espacial americana (NASA), las reuniones periódicas de
los grupos de trabajo del IETF, así como emisiones de radio por multicast, son algunas de las sesiones
disponibles con regularidad en MBone y seguidas por un gran número de usuarios en todo el mundo.
Gran parte de las aplicaciones aquí enumeradas están disponibles para casi cualquier plataforma
informática: desde un simple PC con Windows95, hasta una estación de trabajo con UNIX (en casi
cualquiera de sus variantes), lo cual ha contribuido a la popularidad de las mismas. De este modo
cualquier PC multimedia básico, es decir, que disponga de una tarjeta de audio y un micrófono, nos
permitirá convertirnos en un nodo receptor de MBone y ser capaces de bien asistir a cualquiera de las
videoconferencias que se emiten, o intervenir en aquellas en las que se permita la participación remota.
Con una pequeña inversión, que consistirá en adquirir una cámara digital de bajo coste, podremos
convertirnos en una estación de emisión y recepción de videoconferencias. No es necesario decir que
ésto ofrece unas ventajas substanciales en el desempeño de nuestras actividades profesionales y/o
académicas. Siguiendo esta línea se están produciendo estudios a varios niveles, como es en el campo
de la educación y la medicina, sobre la viabilidad y el impacto social y/o laboral de estas nuevas
tecnologías.
Dentro del amplio abanico de aplicaciones que han aparecido en estos últimos años (gran parte de ellas
continúan en desarrollo), las más populares en MBone han sido las que permiten la realización de
conferencias de audio y vídeo. Dentro de este grupo el rat y el vat son las más empleadas para la
transmisión/recepción de audio, y el vic para la transmisión/recepción de vídeo. En el apéndice
describiremos brevemente estas y otras herramientas existentes, e indicaremos los localizadores en
Internet (URLs) para conseguirlas.
Una utilidad fundamental en MBone, que permite la integración de todas las anteriores, es el SDR
(Session Directory Tool), o directorio de sesiones MBone que nos permite conocer las sesiones que
están activas en todo momento, conectarnos a cualquiera de ellas, o definir nuestra propia sesión
MBone.
La primera implementación del SDR, llamado SD, fue desarrollada por Van Jacobson en el LBNL
(Lawrence Berkeley National Laboratory). El desarrollo posterior de la misma ha sido llevado a cabo
dentro del proyecto europeo de investigación en herramientas multimedia MERCI (antes MICE), dando
lugar al actual SDR. Ciertos cambios en fundamentales en su estructura han hecho que ambas
versiones sean incompatibles y en la actualidad los anuncios de sesiones, se hacen de forma
generalizada con la nueva versión desarrollada por el MERCI, el SDR.
El SDRemplea una dirección multicast asignada por la IANA, la 224.2.127.254 y un puerto UDP
específico (el 9875) para retransmitir los anuncios de sesiones multimedia. Esto se implementa por
medio de un protocolo muy simple, en el que los datos de la sesión van incluidos en forma de texto
ASCII tras una breve cabecera UDP.
Esta simple implementación, permite que estos datos puedan ser capturados fácilmente por una
aplicación y puedan emplearse para lanzar las aplicaciones necesarias para unirse a una determinada
conferencia.
Otras aplicaciones de gran utilidad, y empleadas principalmente como complemento a las anteriores, en
la realización de videoconferencias, son la pizarra electrónica (wb) y el editor de textos compartido. Con
la primera de ellas nos encontramos ante una aplicación que nos proporciona el acceso a una pizarra en
la que disponemos de una serie de utilidades tanto para escribir textos con varios tamaños y formas,
como para realizar dibujos a mano alzada y formas geométricas sencillas. Cualquier diseño que
creemos en esta pizarra virtual, será automáticamente visto por todos los participantes en la sesión, y
cualquiera podrá hacer modificaciones sobre dichas imágenes. También tenemos la posibilidad de
incorporar archivos en formato PostScript a dicha pizarra.
Por otro lado, el editor de texto compartido (Network Text editor) o nt, permite a múltiples usuarios
trabajar en tiempo real sobre un mismo documento de texto: crear nuevos párrafos, borrar, cambiar y
mover los existentes, etc.
El ivs (INRIA Videoconference System), desarrollado por el INRIA (Institut National de Recherche en
Informatique et en Automatique), permite la integración de los canales de audio y vídeo sobre una
misma aplicación. Esta aplicación fue desarrollada en 1992 y actualmente ha dejado de ser mantenida
para dar paso a otras nuevas aplicaciones como el Rendez Vous (nueva generación del ivs) y
FreePhone .
Todas las aplicaciones que hemos descrito aquí son fruto del trabajo desarrollado por varios grupos de
investigación y han sido puestas a disposición de todos los pobladores de Internet como software de
dominio público. Muchas de ellas están aún en fase de desarrollo, pero aún así permiten obtener unos
resultados cuando menos sorprendentes.
Mensajes de Error
Contenido
• 1 Arquitectura
• 2 Estándares
• 4 Vea también
• 5 Referencias
• 6 Acoplamientos externos
Arquitectura
Una red diseñó entregar un servicio del multicast (como el vídeo) que usabaIGMP pudo utilizar esta
arquitectura básica:
IGMP es utilizado por la computadora del cliente y el adyacente interruptores de la red para conectar a
cliente con una rebajadora local del multicast. Multicast de la independiente delprotocolo (PIM)
entonces se utiliza entre las rebajadoras locales y alejadas del multicast, dirigir tráfico del multicast
Estándares
Hay tres versiones deIGMP, según lo definido por “Request For Comments“Documentos (RFC) del
Internet Engineering Task Force(IETF).IGMP v1 se define cerca RFC 1112,IGMP v2 se define cerca RFC
Elprotocolo deIGMP se pone en ejecución como un lado del anfitrión y lado de la rebajadora. Un lado
Linux sistema operativoayudasIGMP. Núcleo de Linuxen la base del sistema operativo pone
solamenteIGMP en ejecución como lado del anfitrión, no lado de la rebajadora, al menos a demoniopor
ejemplo mrouted puede ser utilizado actuar como rebajadora deIGMP Linux. Hay también habitaciones
enteras de la encaminamiento (por ejemplo XORP), que dan vuelta a una computadora ordinaria en
Vea también
• IGMP snooping
Referencias
3. ^ Paquete hecho fragmentos deIGMP puede promover la “negación ataque del servicio”.
Acoplamientos externos
• -1-
• CabeceraIGMPDatosCabeceraIPCabeceraIPCabeceratrama MENSAJE IGMP DE DIFUSIÓNDATAGRAMA IPDatosDatosTRAMA
MAC Ethernet
• Figura 2.- Encapsulación de un mensaje IGMP.
• Según se describe en la anterior Figura 2, el protocolo IGMP encapsula un mensaje
IGMP en un datagrama IP. De ahí que IGMP ocupe un subnivel superior al
ocupado por el protocolo IP en el mismo nivel de Internet o red de la arquitectura
TCP/IP. Se resalta que las direcciones de multidifusión (clase D) sólo pueden
emplearse como direcciones IP de destino. Éstas nunca aparecen en el campo de
dirección del origen de un datagrama. Asimismo, no se generan mensajes de error
ICMP relacionados con datagramas de multidifusión. Cuando se encapsula un
mensaje IGMP en un datagrama IP para su transmisión, la dirección de destino en
la cabecera IP es la dirección de multidifusión del grupo, por ejemplo, 224.0.0.14,
224. 0.1.75, etc. MAC Ethernetde
unidifusiónTCP/UDPAplicaciónAplicaciónmultidifusiónmultidifusiónGrupo 1Grupo
1AplicaciónAplicaciónmultidifusiónmultidifusiónGrupo 2Grupo 2Direcciones IP de unidifusiónde redes y máquinas conocidas
(incluida M1)Hardware EthernetMAC Ethernetde difusión……
Aplicaciónunidifusión1Aplicaciónunidifusiónn……Máquina M1Direcciones IP de difusión conocidas (limitada y dirigida(s)
MAC EthernetEthernetde de multidifusiónmultidifusiónDirecciones Direcciones IP de multidifusiónmultidifusiónconocidas
conocidas (incluidas las de Grupo 1 y Grupo 2)
• Figura 3.- Un ejemplo de correspondencias de direcciones IP y MAC.
• Los datagramas IP que transportan mensajes IGMP o mensajes especifícos de una
aplicación de multidifusión se transmiten finalmente por la red de acceso a través de
• 4 Asignada permanentemente a todas las máquinas en esta red de área local.
• 5 Asignada permanentemente para noticias de audio (audionews).
• -2-
• tramas MAC Ethernet6 mediante el correspondiente software de multidifusión del
interfaz de la red de acceso. Dicho software transforma o adapta una dirección IP
de multidifusión en la correspondiente dirección MAC de multidifusión (ver niveles
implicados en la anterior Figura 3). Consecuentemente, aquellas máquinas que no
soporten el software de multidifusión IP en el nivel del interfaz de la red de acceso
de la arquitectura TCP/IP, nunca transmitirán ni recibirán mensajes de
multidifusión.
• En este contexto, es importante resaltar que toda máquina TCP/IP conectada, por
ejemplo, a la clásica red de acceso de área local del tipo Ethernet; tiene que tener
potencialmente la capacidad de transmitir y recibir tanto tramas de unidifusión
como de difusión (limitada y dirigida) y, obviamente, de multidifusión. Para ello, es
imprescindible que los datagramas IP que transportan, por ejemplo, mensajes de
unidifusión se transmitan, finalmente, por la red de acceso a través de tramas MAC
Ethernet de unidifusión mediante el correspondiente software de unidifusión del
interfaz de la red de acceso. Dicho software transforma una dirección IP de
unidifusión en la correspondiente dirección MAC de unidifusión. En la siguiente
Figura 4 se muestra el envío de una trama de unidifusión (encapsulando al
pertinente datagrama IP de unidifusión 128.1.1.2), a la máquina cuya dirección IP es
128.1.1.2 y cuya dirección MAC Ethernet de destino comienza con los tres
primeros octetos (en hexadecimal) 08-00-4E7.
• 6 Suponiendo que la red de acceso es una red de área local del tipo Ethernet. Por consiguiente, una
red de área local del tipo Ethernet (IEEE 802.3) soporta multidifusión en el protocolo del interfaz de
acceso a dicha red.
• 7 Propios, en este ejemplo, del fabricante 3COM EUROPE LTD de tarjetas de red Ethernet, según la
normalización realizada por IEEE al respecto para distinguir a un fabricante de otro. Se resalta que el
bit menos significativo del primer octeto si es un 0 denota una dirección Ethernet y si es un 1 una
dirección de multidifusión. A continuación de esos tres primeros octetos seguirían los restantes tres
octetos asignados por 3COM a la tarjeta en cuestión y que identifica a ésta de cualquier otra tarjeta
de dicho fabricante y, obviamente, de otros fabricantes.
• -3-
• 128.1.1.0/255.255.255.0Origen1Dirección destino MAC=08004E08004E…Trama Ethernet……
……DatagramaIPDirección Ethernet………
Dirección destino IP=128128.1.1.2.1.1.2
128128.1.1.2.1.1.2 ………DatagramaIP128.1.1.2
• Figura 4.- Ejemplo de unidifusión mediante tramas.
• A su vez, los datagramas IP que transportan mensajes de difusión han de
transmitirse, finalmente, por la red de acceso a través de tramas MAC Ethernet de
difusión mediante el correspondiente software de difusión del interfaz de la red de
acceso. Dicho software transforma, en este caso, una dirección IP de difusión en la
correspondiente dirección MAC de difusión. En la siguiente Figura 5 se muestra el
envío de una trama de difusión limitada (encapsulando al pertinente datagrama IP
de difusión limitada 255.255.255.255), a todas las máquinas de la red 128.1.1.0
cuyas direcciones MAC Ethernet de destino constan siempre de los mismos 6
octetos o 48 bits todos a unos en binario (FFFFFFFFFFFF en hexadecimal).
128.1.1.0/255.255.255.0Origen1Dirección destino MAC=FFFFFFFFFFFFFFFFFFFFFFFFTrama
Ethernet……Dirección destino IP=255255.255.255.255.255.255.255……DatagramaIPDirección
Ethernet………255255.255.255.255.255.255.255………DatagramaIP
• Figura 5.- Ejemplo de difusión limitada mediante tramas
• En la siguiente Figura 6 se muestra el envío de una trama de difusión dirigida
(encapsulando al pertinente datagrama IP de difusión dirigida 128.1.255.255), a
todas las máquinas de las redes 128.1.1.0 y 128.1.2.0 cuyas direcciones MAC
Ethernet de destino constan siempre de los mismos 6 octetos o 48 bits todos a unos
en binario (FFFFFFFFFFFF en hexadecimal).
• -4-
• 128.1.1.0255.255.255.0128.1.2.0255.255.255.0OrigenRouter1Router3Router2Dirección destino
Ethernet……Dirección destino IP=128128.1.255.255.1.255.255……
MAC=FFFFFFFFFFFFFFFFFFFFFFFFTrama
DatagramaIPDirección Ethernet………128128.1.255.255.1.255.255………DatagramaIP
• Figura 6.- Ejemplo de difusión dirigida mediante tramas-
• Para terminar, los datagramas IP que transportan mensajes de multidifusión deben
enviarse, finalmente, por la red de acceso a través de tramas MAC Ethernet de
multidifusión mediante el correspondiente software de multidifusión del interfaz de
la red de acceso. Dicho software transforma, en este último caso, una dirección IP
de multidifusión en la correspondiente dirección MAC de multidifusión. En la
siguiente Figura 7 se muestra el envío de una trama de multidifusión (encapsulando
al pertinente datagrama IP de multidifusión para el grupo 224.0.1.7), a todas las
máquinas de las redes 128.1.1.0 y 128.1.2.0 cuyas direcciones MAC Ethernet de
destino comienzan siempre con los tres primeros octetos (en hexadecimal) 01-00-
5E. 128.1.1.0255.255.255.0128.1.2.0255.255.255.0OrigenRouter1Router3Router2Dirección destino
Ethernet……Dirección destino IP=224224.0.1.7.0.1.7……DatagramaIPDirección
MAC=01005E01005E…Trama
Ethernet………224224.0.1.7.0.1.7………DatagramaIP
• Figura 7.-Ejemplo de multidifusión mediante tramas
• En la siguiente Figura 8 se muestra, más en concreto, la transformación, traslación
o correspondencia (mapping) de una dirección IPv4 clase D de multidifusión en una
dirección de trama de multidifusión MAC Ethernet o IEEE 8028. La citada
transformación o adaptación se ajusta al siguiente procedimiento:
• 8 Una dirección MAC Ethernet o IEEE 802 consta de 48 bits.
• -5-
• � Se incluyen los 23 bits de menor orden o menos significativos de la dirección IP
de multidifusión9 en los 23 bits de menor orden de la dirección MAC Ethernet de
multidifusión. En este contexto, los diseñadores utilizaron 23 de los 28 bits para una
dirección MAC porque en este conjunto de bits se incluyen la mayor parte de las
direcciones de multidifusión. Por consiguiente, el conjunto de direcciones IP
definidos en esos 23 bits es lo suficientemente extenso10 como para que la
posibilidad de coincidencia11 en el nivel IP sea muy pequeña. Por otro lado, dicha
coincidencia será resuelta en el nivel de red ya que IP sabe qué direcciones de
multidifusión están activas en su máquina. La consecuencia de este diseño es que
algunos datagramas IP de multidifusión pueden recibirse en una máquina, aunque
dichos datagramas no estén destinados a tal máquina. Será la entidad IP quien
verifique cuidadosamente las direcciones en todos los datagramas IP de
multidifusión entrantes y elimine cualquier datagrama IP de multidifusión no
esperado perteneciente a un grupo inexistente en la propia máquina.
00000001000000000 010111101110xxxxxxxxxxxxxxxxxxxxxxxxxxxx23 bits de menor orden de la dirección
IP de multidifusióncopiados en la dirección Ethernet5 bits de la dirección IP de multidifusiónno usados en la dirección
• -6-
• (00000001 00000000 01011110) es la notación en hexadecimal de los tres primeros
octetos que se correponden con el identificador12 único del fabricante de la tarjeta.
El bit a continuación, que siempre está a cero, pertenece en direcciones de
unidifusión al siguiente bloque de 24 bits que identifican a la tarjeta del fabricante
en cuestión. Por consiguiente, el rango completo de direcciones MAC Ethernet o
IEEE 802 de multidifusión es de 01:00:5e:00:00:00 a 01:00:5e:7f:ff:ff. Se resalta
que la correspondencia entre las direcciones IP clase D de multidifusión y las
dirección de trama de multidifusión MAC Ethernet o IEEE 802 no es biunívoca, ya
que existen 32 direcciones IP de multidifusión diferentes por cada dirección MAC
de multidifusión. Así, por ejemplo, las direcciones IP de multidifusión 224.0.0.1 y
224.128.0.1 tienen iguales los 23 últimos bits y se corresponden ambas con la
dirección MAC de multidifusión 01.00.5E.00.00.8013. Por consiguiente, puede
suceder que, por ejemplo, en una misma red Ethernet, al menos dos grupos de
multidifusión diferentes utilicen la misma dirección MAC Ethernet de multidifusión;
en este caso, algunas máquinas capturarán tramas MAC de multidifusión que luego
al examinar la cabecera IP, descubrirán que no iban dirigidas a ellas.
Evidentemente, hay una pequeña pérdida de eficiencia por el tiempo que el nivel de
red emplea en analizar una información de control que no iba dirigida al nivel IP de
dicha máquina; pero la probabilidad de que esto ocurra en la práctica es tan pequeña
que la pérdida de eficiencia es despreciable14.
• Obviamente, se recuerda que para poder participar en una multidifusión IP, una
máquina debe poseer el software que le permita enviar y recibir datagramas IP de
multidifusión. El software de IP debe permitir a una aplicación especificar una
dirección de multidifusión como una dirección IP de destino. Asimismo, como ya se
ha indicado, el software del interfaz de la red de acceso debe ser capaz de
transformar una dirección IP de multidifusión en la correspondiente dirección MAC
de multidifusión15.
• En el escenario de IPv6; actualmente, para transformar una dirección IPv6 de
multidifusión en una dirección MAC Ethernet o IEEE 802, se cogen los 32 bits de
menor orden de dicha dirección IPv6.
• 12 OUI (Organizationally Unique Identifier).
• 13 Se resalta que las direcciones MAC en Ethernet se representan empezando por el bit menos
significativo de cada octeto.
• 14 Suponiendo un reparto aleatorio, la probabilidad de coincidencia entre dos grupos de multidifusión
será de 25/228 = 0,0000001.
• 15 O utilizar la difusión si el software del interfaz de la red de acceso no soporta multidifusión.
• -7-
• Bits11111111000 TAlcance44Identificador de grupo808T (transitorio o transient) = 0: Dirección no
transitoriao asignada permanentemente por IANA/ICANNT (transitorio o transient) = 1:Dirección transitoriao no
asignada permanentementeAlcance o límite del grupo de multidifusión: Número entero de 4 bits.0: reservado; 1: Nodo
local o en la propia máquina; 2: enlace local; …; 5: sitio local;…; 8: organización local (compuestas de varios sitios); …
000………………..032Todo a ceros
• Figura 9.- Formato actual de la dirección IPv6 de multidifusión.
• Pero de esos 32 bits, sólo se puede incluir los 23 bits16 anteriormente citados en la
dirección MAC Ethernet de multidifusión. Como ya se ha indicado, será la entidad
IP quien verifique cuidadosamente las direcciones de grupo de todos los datagramas
IP de multidifusión entrantes y elimine cualquier datagrama perteneciente a grupos
de multidifusión inexistentes en la correspondiente máquina.
• Antes de seguir avanzando, es importante diferenciar entre el protocolo de
distribución y actualización de la información de pertenencias a grupos de
multidifusión17 empleado entre routers de multidifusión locales e intermedios18 en
Internet y el protocolo IGMP utilizado, como ya se ha indicado, en la red de área
local (Ethernet o IEEE 802) de una organización entre el router de multidifusión
local y los sistemas finales vecinos.
• Concretamente, los mecanismos de IGMP permiten llevar a cabo dos acciones
fundamentales:
• 1. Que las máquinas destinatarias o sistemas finales de una red de área local
(Ethernet o IEEE 802) informen a su router de multidifusión local de que desean
unirse a un grupo específico de multidifusión; es decir, desean recibir datagramas IP
de multidifusión dirigidas a dicho grupo.
• 16 Por consiguiente, al igual que con IPv4, quedan 5 bits sin usar; quiere decir esto, que
potencialmente puede haber 25 ó 32 grupos potenciales que selecciones idénticas direcciones MAC.
• 17 Como ya se estudiará más adelante, también, denominado protocolo de encaminamiento dinámico
de multidifusión, el cual se utiliza en Internet por los propios routers de multidifusión. Se resalta que
IGMP es un estándar en Internet, no ocurre lo mismo con los protocolos de encaminamiento
dinámico de multidifusión existentes y que ya se analizarán.
• 18 O directamente con routers de multidifusión locales de otras organizaciones si entre medias no hay
routers de multidifusión intermedios.
• -8-
• 2. Que el router de multidifusión local19 interrogue o sondee periódicamente a los
sistemas finales de su red de área local (Ethernet o IEEE 802) para saber si los
miembros, de un grupo conocido, continúan aún activos.
• En este contexto, el protocolo IGMP consta de dos fases:
• • Fase I.- Cuando una máquina o sistema final se une a un nuevo grupo de
multidifusión, envía un mensaje o informe IGMP (tipo 2) de pertenencia a grupo
(Host Membership Report) con la dirección de destino IP conteniendo la dirección
de multidifusión del grupo al que pertenece la máquina de origen. Este mensaje
IGMP también lo escucha el router de multidifusión local, que está conectado a la
misma red, para realizar el correspondiente registro de pertenencia. Asimismo, el
datagrama IP que encapsula dicho informe lleva un TTL = 1 para indicar
expresamente que este tipo de mensaje IGMP se transmite directamente a la red de
acceso y no debe ser reenviado por ningún otro router de multidifusión. A su vez, el
router de multidifusión local se pone en contacto con otros routers de multidifusión
vecinos por Internet, pasando20 la correspondiente información y registrando, en sus
tablas, las oportunas rutas en función de dichas pertenencias para la posterior fase
de transferencia de datos. Un sistema final sólo tiene que emitir un informe IGMP
de pertenencia por cada grupo al que pertenezca. Cuando una máquina final o
destinataria se une a un determinado grupo de multidifusión, envía inmediatamente
un informe de pertenencia sin esperar al siguiente sondeo.
• • Fase II.- Debido a que la pertenencia es dinámica, el router de multidifusión local
sondea de forma periódica, mediante un mensaje IGMP (tipo 1) de solicitud de
pertenencia a grupos (Host Membership Query message) a las máquinas vecinas de
su red de área local para determinar aquéllas que se mantienen como miembros
activos de grupos. Este mensaje IGMP de solicitud o sondeo se envía en un
datagrama IP con la dirección de destino conteniendo la dirección reservada de
multidifusión, 224.0.0.1, que semánticamente quiere decir “a todas las máquinas
en esta red de área local”. Asimismo, dicho datagrama IP lleva un TTL = 1 para
indicar que este tipo de mensaje IGMP no debe ser reenviado a ninguna otra red por
ningún otro router de multidifusión local que pudiera haber. En este
• 19 Sihay más de un router de multidifusión, uno de ellos se selecciona como emisor de este tipo de
mensajes.
• 20 Mediante otro protocolo diferente a IGMP, denominado protocolo de distribución y actualización
de la información de pertenencias a grupos de multidifusión o de encaminamiento dinámico de
multidifusión.
• -9-
• escenario, para que un router de multidifusión local pueda difundir alguna
información de pertenencia a otros routers de multidifusión intermedios por
Internet, debe determinar si una o más máquinas, en su red de área local, han
decidido unirse a un grupo de multidifusión. Si para un determinado grupo, no se
reciben informes de miembros después de varios sondeos, el router de multidifusión
asume que no hay destinatarios activos en su red y deja de anunciar miembros del
grupo a otros routers de multidifusión vecinos en Internet. Cuando una máquina
destinataria recibe una solicitud, debe responder con un informe por cada grupo al
que pertenece. Asimismo, una máquina destinataria no emite ningún informe si
quiere abandonar21 el grupo. Se resalta, además, que un router de multidifusión
local no tiene porqué conocer cuántas máquinas pertenecen a un grupo particular;
sólo le debe interesar saber que al menos una máquina pertenece a un determinado
grupo.
• Como se puede ver, intercambiando solicitudes IGMP (entre routers y máquinas
destinatarias en la misma red) e informes IGMP (entre máquinas destinatarias y
routers en la misma red), un router de multidifusión local puede conocer los grupos
de multidifusión que están activos en su propias redes. De esta manera, dicho router
puede reenviar un datagrama IP de multidifusión entrante a la máquina o máquinas
destinatarias, pertenecientes al grupo en cuestión. Versión4Bits16Suma de
comprobaciónTipoDirección de grupo clase D (cero en solicitud)031
• Sin uso8
• Figura 10.- Formato de un mensaje IGMP.
• Como se puede apreciar en la anterior Figura 10, el formato de un mensaje
IGMPv2 (8 octetos) es muy simple:
• � Versión (4 bits).- Identifica el número de versión22.
• 21 Cuando una máquina desea darse de baja de un grupo, simplemente desactiva la aplicación.
• 22 Actualmente, existen tres versiones (1, 2 y 3), de las cuales, la versión 1 es la base fundamental de
las otras dos que se mencionan más adelante en este libro. Las versiones 2 y 3 son las versiones
incorporadas en la mayoría de los sistemas operativos. Por tanto, la última versión de IGMP es la 3
que se apoya en las versiones anteriores, fundamentalmente en la 2 (la más extendida), incorporando
nuevas funcionalidades que se comentarán más adelante. Consecuentemente, para centrarse en lo
fundamental de IGMP, éste libro describe la versión 2.
• - 10 -
• � Tipo (4 bits).- Indica el tipo de mensaje. Existen dos tipos de mensaje:
• �Tipo 1.- Indica un mensaje, de solicitud de pertenencia a grupo, enviado por un
router de multidifusión local a todas las máquinas vecinas conectadas a la misma
red de acceso.
• � Tipo 2.- Indica un informe de pertenencia a grupo enviado por una máquina
destinataria incluida en dicho grupo al resto de máquinas, también, pertenecientes al
citado grupo en la misma red de acceso.
• � Sin uso (8 bits).- Todo a ceros.
• � Suma de comprobación (16 bits).- Se aplica a todo el mensaje IGMP (8 octetos).
Se aplica el mismo algoritmo utilizado por IP.
• � Dirección de grupo (32 bits).- Esta es la dirección IPv4 de la clase D. Contiene
todo a ceros en un mensaje de solicitud, o bien una dirección de grupo en un
mensaje de informe.
• Asimismo, el protocolo IGMP se ha diseñado con el objetivo de evitar congestiones
en una red de área local en función de los siguientes apartados:
• � Toda la comunicación entre máquinas destinatarias y el router de multidifusión
local utiliza multidifusión IP.
• � Un router de multidifusión local no envía mensajes de solicitudes individuales
para cada grupo de multidifusión, sino un mensaje de solicitud (sondeo) para
solicitar información relacionada con la pertenencia en todos los grupos.
• � Las máquinas que son miembros de varios grupos no envían respuestas múltiples
al mismo tiempo. Cuando un mensaje de solicitud de IGMP llega desde un router
de multidifusión local, la máquina asigna un retardo23 aleatorio entre 0 y 10
segundos para cada grupo, y envía una respuesta al correspondiente grupo después
del retardo. Así, una máquina separa sus respuestas aleatoriamente dentro de un
lapso de 10 segundos. Resumiendo, cuando un router de multidifusión local envía
un mensaje de solicitud, todas las máquinas destinatarias, en la misma red de área
local, asignan un retardo aleatorio para las respuestas.
• � Mediante una técnica de supresión de informes IGMP de pertenencias a grupos,
las máquinas escuchan las respuestas o informes de otras máquinas y
• 23 Para dar tiempo a que responda la máquina que haya recibido antes el sondeo.
• - 11 -
• no envían respuestas innecesarias. Es importante resaltar que un router de
multidifusión local no necesita conservar un registro exacto de los miembros de un
grupo porque todas las transmisiones hacia el grupo se envían mediante el software
de multidifusión del interfaz de la red de acceso. El router de multidifusión local
sólo tiene que saber si existe al menos una máquina de un grupo en particular.
Cuando la máquina con el retardo más pequeño24 envía su respuesta mediante
multidifusión, otras máquinas participantes reciben una copia. Cada máquina asume
que el router de multidifusión local también recibió una copia de la primera
respuesta y cancela su respuesta. Resumiendo, se puede mejorar la eficiencia si las
máquinas monitorizan si otra envía el mismo informe antes de la transmisión
programada. Si otra máquina ha enviado el mismo informe, la primera cancela el
suyo. Así en la práctica, sólo una máquina de cada grupo responde a un mensaje de
solicitud enviado por el router de multidifusión local. R1R1M3G3M1G1Solicitud de pertenencia a
gruposOrigen IP=R1Destino IP=224.0.0.1TTL=1Grupo IGMP=0M4M2G1G2Me callo porque he escuchado el informe de M1Informe de pertenencia a
G1Origen IP=M1Destino IP=G1TTL=1Grupo IGMP=G1
• Figura 11.- Envío de solicitudes e informes de pertenencias a grupos.
• En el ejemplo de la anterior Figura 11, el router de multidifusión local R1 envía un
mensaje IGMP de solicitud de pertenencia a grupos. Suponiendo que M1 dispone
de un retardo de respuesta inferior a M4, M1 responde con un mensaje IGMP que
contiene un informe de pertenencia al grupo G1. Este último mensaje se transmite
sólo al grupo G125, al que pertenece la máquina de origen, con el objetivo de que el
resto de máquinas de dicho grupo escuchen el mensaje y desactiven sus
temporizadores de respuesta para no tener que mandar otro
• 24 O lo que es lo mismo, la primera máquina que recibe un mensaje Tipo 1 de sondeo es la primera en
responder.
• 25 En el campo destino de la cabecera IP se pone la dirección IP de multidifusión del grupo G1.
• - 12 -
• informe repetido. Por consiguiente, aparte de R1, este último mensaje también lo
escucha la máquina M4; pero ésta no transmite otro mensaje similar ya que a R1 le
basta con saber26 que al menos una máquina (en este caso M1) pertenece a G1.
• Actualmente, existen tres versiones del protocolo IGMP:
• • IGMP Versión 1 (RFC-1112).- Recoge todo lo que se ha estudiado hasta el
momento.
• • IGMP Versión 2 (RFC-2236).- Es la versión actualizada y mejorada de IGMPv1.
Mantiene la compatibilidad con IGMPv1.
• • IGMP Versión 3 (RFC-3376).- Es la versión actualizada y mejorada de IGMPv1 e
IGMPv2. Aborda algunas debilidades de anteriores versiones como, por ejemplo, la
transmisión de información no deseada a grupos de multidifusión. Para ello, permite
a los sistemas finales especificar la lista de máquinas desde las que quieren recibir
datagramas IP de multidifusión y que dicho tráfico sea bloqueado por los routers27
de multidifusión locales.
• Finalmente, conviene recordar que IGMP se diseñó para operar con IPv4.
Obviamente, IPv6 requiere también las mismas funcionalidades, las cuales se han
añadido, no en otro IGMP para IPv6, sino en los correspondientes mensajes del
protocolo ICMPv6. Por consiguiente, el protocolo de envío de mensajes de control
en Internet, ICMPv6, incluye toda la funcionalidad del protocolo IGMP a través de
los dos mensajes fundamentales que se han estudiado para IGMP: un mensaje de
sondeo o consulta de pertenencia a grupos y otro de informe de pertenencia a
grupo. Dichos mensajes ICMPv6, se usan de la misma manera que en IGMP.
• 26 Elcontenido del campo dirección de grupo clase D (Grupo IGMP en la anterior Figura 11).
• 27 Y como alternativa por los propios sistemas finales.
• - 13 –
Sho Suppo Commun Principio del form
p rt ity
Manuals
Configuraciónde la multidifusión IP
DVMRP
IGMP
Multidifusión
PIM-DM
PIM-SM
Los enrutadores que admiten la multidifusión o que la tienen activada reenvían paquetesde
multidifusión según las rutas especificadas en la basede datosde informaciónde enrutamientod
multidifusión (MRIB). Losprotocolosde multidifusión que se ejecutan en el enrutador crean estas
rutas en la MRIB durante el procesode creaciónde árbolesde distribuciónde multidifusión. Los
distintosprotocolosde enrutamientode multidifusión IP utilizan técnicas diferentes para crear
dichos árboles.
Para ver la páginade menú IP Multicast (Multidifusión IP), haga clic en IP Multicast(Multidifusión
en la vistade árbol. La páginade menú IP Multicast (Multidifusión IP) contiene enlaces a los
procedimientos siguientes:
DVMRP
IGMP
Multidifusión
PIM-DM
PIM-SM
DVMRP
DVMRP intercambia paquetes sonda con todos los enrutadores que lo tienen activado, establec
relaciones bidireccionales entre vecinos y genera una tablade vecinos. Intercambia paquetesde
informe y crea una tablade topologíade difusión única, con la que genera la tablade
enrutamientode multidifusión. Esta tabla se utiliza para direccionar los paquetesde multidifusió
Dado que todos los enrutadores DVMRP utilizan el mismoprotocolo de enrutamientode difusión
única, se evitan los buclesde enrutamiento.
La páginade menú DVMRPcontiene enlaces a páginas web que permitendefinir y visualizar los
parámetros y datosde DVMRP. Para visualizar esta página, haga clic en IP Multicast (Multidifusió
IP)® DVMRP en la vistade árbol.
A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:
Resumende poda
Resumende rutas
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Global
Configuration(Configuración global) en la vistade árbol.
Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivar DVMRP.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde DVMRP
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Interface
Configuration(Configuraciónde interfaz) en la vistade árbol.
Comandosde DVMRP
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Configuration
Summary(Resumende la configuración) en la vistade árbol.
Parámetrosde interfaz
Local Address(Dirección local): muestra la dirección IP que se utiliza como direcciónde origende
los paquetes enviadosdesde la interfaz seleccionada.
Interface Metric(Métricade la interfaz): muestra la métrica que se utiliza para calcular los
vectoresde distancia correspondientes a la interfaz seleccionada.
Estadísticasde la interfaz
Generation ID(IDde generación): muestra la IDde generaciónde DVMRP que el enrutador utiliza
para la interfaz seleccionada. Este valor se restablece cada vez que se inicia o se reinicia una
interfaz y se coloca enmensajes de poda. Si se produce un cambio en una IDde generación, se
informa a los enrutadores vecinosde quedebedescartarse cualquier información previa sobre es
enrutador.
Parámetrosde vecinos
Received Bad Routes(Rutas erróneas recibidas): númerode rutas no válidas recibidas para el
vecino especificado en la interfaz seleccionada.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde DVMRP
Utilice la página Next Hop Summary(Resumendel siguiente salto) para ver o imprimir el
resumendel siguiente salto por la IPde origen.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Next Hop
Summary(Resumendel siguiente salto) en la vistade árbol.
Source IP(IPde origen): muestra la dirección IP que se utiliza con la máscarade origen para
identificar la redde origen correspondiente a esta entradade la tabla.
Source Mask(Máscarade origen): muestra la máscarade red que se utiliza con la dirección IPde
origen.
Type(Tipo): muestra el tipodel siguiente salto. Leaf (Hoja) significa que no existen
vecinosdependientesdescendentes en la interfazde salida.De lo contrario, el tipo es Branch
(Rama).
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde DVMRP
Resumende poda
Utilice la página Prune Summary(Resumende poda) para ver o imprimir el resumende poda por
IPde grupo.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Prune
Summary(Resumende poda) en la vistade árbol.
Source IP(IPde origen): direccióndel origen ode la redde origen que se ha podado.
Source Mask(Máscarade origen): máscarade subred que se combinará con la dirección IPde orig
para identificar el origen o la redde origen que se ha podado.
Expiry Time (secs)(Tiempode caducidad [seg.]): tiempo restante antesde que caduque esta pod
en el vecino ascendente. Si no se han recibidomensajes de podade los vecinosdescendentes, se
establece en el valordel temporizadorde duraciónde poda predeterminado;de lo contrario, se
establece en el valor más pequeño recibido o en valordel temporizador predeterminado, el que
sea inferiorde los dos.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde DVMRP
Resumende rutas
Utilice la página Route Summary(Resumende rutas) para ver o imprimir el resumende rutasde
DVMRP.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Route
Summary(Resumende rutas) en la vistade árbol.
Source Address(Direcciónde origen): direcciónde red que se combina con la máscarade origen
para identificar los orígenesde esta entrada.
Source Mask(Máscarade origen): máscarade subred que se combinará con la direcciónde origen
para identificar los orígenesde esta entrada.
Interface(Interfaz): interfaz en la que se reciben los datagramas IP que estos orígenes han
enviado. Un valorde 0 suele indicar que la ruta es un conjunto para el que no existe una
interfazdel siguiente salto.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde DVMRP
IGMP
La serie 6200 admite la versión 3deIGMP. Esta versión es compatible con el filtradode orígenes,
que es la capacidad que tiene un sistema para notificar su interés en recibir paquetes
únicamentede direccionesde origen específicas, necesario para admitir la multidifusión
específicade origen (SSM), ode todas las direccionesde origen que no sean específicas enviadas
unadeterminada direcciónde multidifusión. Está diseñada para que pueda interoperar con las
versiones 1 y 2.
La páginade menú IGMPcontiene enlaces a páginas web que permitendefinir y visualizar los
parámetros y datosdeIGMP. Para visualizar esta página, haga clic en IP Multicast (Multidifusión
IP)®IGMP en la vistade árbol.
A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:
Configuración globaldeIGMP
Interfazde enrutamiento
Interfazde proxy
Configuración globaldeIGMP
Definicióndel mododeIGMP
Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivarIGMP.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
ComandosdeIGMP
Interfazde enrutamiento
La páginade menú Routing Interface(Interfazde enrutamiento) contiene enlaces a páginas web
que permiten configurar y visualizar los parámetros y datosdel enrutamientoIGMP. Para visualiz
esta página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Routing Interface(Interfazde
enrutamiento) en la vistade árbol. A continuación figuran las páginas web a las que se puede
accederdesde esta páginade menú:
Configuraciónde interfazIGMP
Resumende la configuracióndeIGMP
Configuraciónde interfazIGMP
Query Max Response Time (1/10 of a second)(Tiempo máximode respuesta a consulta [1/10de
segundo]): introduzca el tiempo máximode respuesta a consulta que se anunciará en las
consultasIGMPv2 en esta interfaz, expresado en décimasde segundo. El valor predeterminado e
100. Los valores válidos están comprendidos entre 0 y 255.
Last Member Query Interval (1/10 of a second)(Intervalode consultade último miembro [1/10de
segundo]): introduzca el intervalode consultade último miembro, expresado en décimasde
segundo. Se tratadel tiempo máximode respuesta que se insertará en consultas específicasde
grupo que se envían como respuesta amensajes de grupode cese. Asimismo, es el tiempo que
transcurre entremensajes de consultas específicasde grupo. Los valores válidos están
comprendidos entre 0 y 255. El valor predeterminado es 10, que no se utiliza en la versión
1deIGMP.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
ComandosdeIGMP
Resumende la configuracióndeIGMP
Parámetrosde interfaz
Query Interval (secs)(Intervalode consulta [seg.]): frecuencia con la que se transmiten los
paquetesde consulta al hostIGMP en la interfaz seleccionada.
Query Max Response Time (1/10 of a second)(Tiempo máximode respuesta a consulta [1/10de
segundo]): tiempo máximode respuesta a consulta que se anuncia en las consultasIGMPv2
enviadasdesde la interfaz seleccionada.
Startup Query Interval (secs)(Intervalode consultade inicio [seg.]): intervalo en el que se envían
consultasde inicio en la interfaz seleccionada.
Last Member Query Interval (1/10 of a second)(Intervalode consultade último miembro [1/10de
segundo]): tiempo máximode respuesta que se inserta en consultas específicasde grupo enviad
en respuesta amensajes de grupode cese. También se tratadel tiempo que transcurre
entremensajes de consultas específicasde grupo. Es posible ajustar este valor para modificar la
latenciade cesede la red. Si se introduce un valor pequeño, se reduce el tiempo paradetectar la
pérdidadel último miembrode un grupo. Este valor no se utiliza en la versión 1deIGMP.
Last Member Query Count(Recuentode consultasde último miembro): númerode consultas que
enviarán al recibir un informede grupode cese.
Estadísticasde la interfaz
Querier Expiry Time (secs)(Tiempode caducidaddel solicitante [seg.]): tiempo restante, expresa
en segundos, antesde que caduque el otro temporizador actualdel solicitante. Si el sistema loca
es el solicitante, el valor es cero.
Wrong Version Queries(Consultasde versión errónea): númerode consultas que se han recibido
la interfaz seleccionada con una versióndeIGMP que no coincide con la configurada para la
interfaz durante la duraciónde la entrada.IGMP requiere que todos los enrutadoresde una LAN
estén configurados para que ejecuten la misma versióndeIGMP. Por lo tanto, se indica unerrorde
configuración si se reciben consultas con un númerode versión erróneo.
Number of Joins(Númerode uniones): númerode veces que se ha añadido una pertenencia a gru
en la interfaz seleccionada, esdecir, el númerode veces que se ha añadido una entradade esta
interfaz a la tablade caché. Esto indica la cantidadde actividaddeIGMP que hay en la interfaz.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
ComandosdeIGMP
Utilice la página IGMP Cache Information(Información sobre cachédeIGMP) para ver los datos y
parámetrosde caché correspondientes a una direcciónde grupode multidifusión IP.Debe configu
como mínimo una interfazde enrutadorIGMP para acceder a esta página. Asimismo, sedeben
haber recibido los informesde pertenencia a grupo en la interfaz seleccionada para que los dato
se muestren en esta página.
Last Reporter(Último informador): dirección IPdel origendel último informede pertenencia recibi
para la direccióndel grupode multidifusión IP en la interfaz seleccionada.
Expiry Time(Tiempode caducidad): tiempo mínimo restante antesde que caduque esta entrada.
Version 1 Host Timer(Temporizadorde host versión 1): tiempo restante hasta que el enrutador
local asuma que ya no hay miembrosde la versión 1deIGMP en la subred IP conectada a esta
interfaz. Cuando se recibe un informede pertenencia aIGMPv1, este temporizador se restablece
temporizadorde pertenencia a grupo. Mientras este temporizador no esté en cero, el enrutador
local ignora losmensajes de cesedeIGMPv2de este grupo que recibe en la interfaz seleccionada.
Este campo sólo aparece si la interfaz está configurada para la versión 1deIGMP.
Version 2 Host Timer(Temporizadorde host versión 2): tiempo restante hasta que el enrutador
local asuma que ya no hay miembrosde la versión 1deIGMP en la subred IP conectada a esta
interfaz. Cuando se recibe un informede pertenencia aIGMPv2, este temporizador se restablece
temporizadorde pertenencia a grupo. Mientras este temporizador no esté en cero, el enrutador
local ignora losmensajes de cesedeIGMPv1 eIGMPv3de este grupo que recibe en la interfaz
seleccionada. Este campo sólo aparece si la interfaz está configurada para la versión 2deIGMP.
Filter Mode(Modode filtrado): modode filtradode origen (con los valores Include [Incluir], Exclude
[Excluir] y NA [ND]) correspondiente al grupo especificado en esta interfaz. Si el modo NA (ND)
está activo, el campo aparece en blanco.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
ComandosdeIGMP
Source Hosts(Hostsde origen): direccionesde origen que son miembrosde esta direcciónde
multidifusión.
Expiry Time(Tiempode caducidad): intervalode tiempode caducidad para cada direcciónde orige
que es miembrode este grupode multidifusión. Se tratadel tiempo tras el que caduca la entrada
origen especificada.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
ComandosdeIGMP
Interfazde proxy
La páginade menú Proxy Interface(Interfazde proxy) contiene enlaces a páginas web que
permitendefinir y visualizar los parámetros y datosde la interfazde proxy. Para visualizar esta
página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Proxy Interface(Interfazde proxy) en
vistade árbol. A continuación figuran las páginas web a las que se puede accederdesde esta
páginade menú:
El enrutadorIGMP (sistema IPv4) utiliza el proxyIGMP para activar el sistema para que
emitamensajes de hostIGMP en nombrede los hosts que el sistema hadetectado mediante
interfacesdel enrutadorIGMP estándar. Por consiguiente, esta función actúa como proxyde todo
los hosts que residen en las interfacesdel enrutador.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Interface Configuration (Configuraciónde interfaz) en la vistade
árbol.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosdel proxyIGMP
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Configuration Summary (Resumende la configuración) en la vistad
árbol.
Interface(Interfaz): muestra la interfaz en la que está activado el proxyIGMP. Sólo puede haber
una interfazde proxyIGMP.
Unsolicited Report Interval(Intervalode informe no solicitado): tiempo que transcurre entre las
repeticionesde un informe inicialdel host sobre pertenencia a un grupo. Valor predeterminado: 1
segundo.
Proxy Start Frequency(Frecuenciade iniciode proxy): númerode veces que se ha activado el pro
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosdel proxyIGMP
Utilice la página IGMP Proxy Interface Membership Info (Informaciónde pertenencia a la interfaz
proxyIGMP) para ver los datosde pertenencia a una interfaz correspondientes a una direcciónde
grupode multidifusión IP específica.Debe haber configurado como mínimo una interfazde
enrutador para poder ver la informaciónde pertenencia a interfaz y nodebe ser una interfazde
enrutamientoIGMP. Asimismo, si no se han recibido informesde pertenencia a grupo en la interf
seleccionada, no se mostrarán datos en esta página.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Interface Membership Info (Informaciónde pertenencia a interfaz)
la vistade árbol.
Last Reporter(Último informador): dirección IPdel origendel último informede pertenencia recibi
para la direccióndel grupode multidifusión IP en la interfazde proxyIGMP.
State(Estado): estadode la entradade host. Un host puede tener unode los estados que se indic
a continuación. Non-member state (Estado no miembro): no pertenece al grupode la
interfaz.Delaying member state (Estado miembro condemora): el host pertenece al grupode la
interfaz y se ejecuta el temporizadorde informes. El temporizadorde informes se utiliza para
enviar los informes. Idle member state (Estado miembro inactivo): el host pertenece al grupode
interfaz y no se ejecuta el temporizadorde informes.
Comandosdel proxyIGMP
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Interface Membership InfoDetailed (Informacióndetalladade
pertenencia a interfaz) en la vistade árbol.
Source IP(IPde origen): muestra las direccionesde origen que son miembrosde esta direcciónde
multidifusión.
Last Reporter(Último informador): dirección IPdel origendel último informede pertenencia recibi
para la direccióndel grupode multidifusión IP en la interfaz seleccionada.
State(Estado): estadode la entradade host. Un host puede tener unode los estados siguientes:
Filter Mode(Modode filtrado): modode filtradode grupo (con los valores Include [Incluir], Exclude
[Excluir] y None [Ninguno]) correspondiente al grupo especificado en la interfazde proxyIGMP.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosdel proxyIGMP
Multidifusión
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Global Configuration(Configuración global) en la vistade árbol.
Number Of Packets For Which Source Not Found(Númerode paquetes cuyo origen no se ha
encontrado): númerode paquetesde multidifusión quedebían direccionarse pero que no han
superado la comprobación RPF.
Number Of Packets For Which Group Not Found(Númerode paquetes cuyo grupo no se ha
encontrado): númerode paquetesde multidifusión quedebían direccionarse pero cuya rutade
multidifusión no se ha encontrado.
Table Highest Entry Count(Recuento más altode entradasde la tabla): número más altode
entradasde rutasde multidifusión que ha habido en la tablade rutasde multidifusión.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde multidifusión
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Interface Configuration(Configuraciónde interfaz) en la vistade árbol.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde multidifusión
Utilice la página Multicast MRoute Summary (Resumende rutasde multidifusión) para ver
información sobre las rutasde multidifusión.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
MRoute Summary(Resumende rutasde multidifusión) en la vistade árbol.
Source IP(IPde origen): dirección IPdel origendel paquetede multidifusión que, junto con la IPde
grupo, identifica una entradade la tablade rutasde multidifusión.
Outgoing Interfaces(Interfacesde salida): listade interfacesde salida en las que se reenvían los
paquetesde multidifusiónde este origen o grupo.
Expiry Time (secs)(Tiempode caducidad [seg.]): tiempo, expresado en segundos, que falta para
que esta entrada caduque y se eliminede la tabla.
PIM-DM
PIM-SM
DVMRP
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde multidifusión
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Static Routes Configuration (Configuraciónde rutas estáticas) en la vistade árbol.
Source (Origen): seleccione Create Static Route(Crear ruta estática) para configurar una entrad
estática nueva en la tablade rutasde multidifusión o bien seleccione unade las entradas
existentes en el menúdesplegable.
RPF Neighbor(Vecino RPF): introduzca la dirección IPdel enrutador vecino en la rutade acceso al
origen.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde multidifusión
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Static Routes Summary (Resumende rutas estáticas) en la vistade árbol.
Source IP(IPde origen): dirección IP que identifica el origendel paquetede multidifusión para esta
ruta.
Source Mask(Máscarade origen): máscarade subred que se aplica a la dirección IPde origen.
VLANID(IDde VLAN): númerode la VLANde entrada cuya dirección IP se utiliza como RPF para la
dirección IPde origen especificada.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde multidifusión
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Admin Boundary Configuration(Configuracióndel límitede administración) en la vistade árbol.
Group IP(IPde grupo): introduzca la direccióndel grupode multidifusión para el iniciodel intervalo
direcciones que se van a excluir. La direccióndebe estar comprendida en el intervalode 239.0.0
a 239.255.255.255.
Seleccione Create Boundary (Crear límite) en el campo Group IP(IPde grupo) para configurar un
límitede ámbitode administración nuevo o bien seleccione unade las entradas existentes.
Modifique los campos restantes según sea necesario.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde multidifusión
Utilice la página Multicast Admin Boundary Summary (Resumende los límitesde administraciónd
multidifusión) para ver los límitesde ámbitode administración existentes.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Admin Boundary Summary(Resumende los límitesde administración) en la vistade árbol.
Group IP(IPde grupo): direccióndel grupode multidifusión para el iniciodel intervalode direccione
que se van a excluir.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde multidifusión
PIM-DM
PIM-DM tiene dos versiones. La versión 2 no utiliza el mensajeIGMP, sino un mensaje encapsula
en el paquete IP con el númerodeprotocolo 103. En esta versión, se introduce un mensajede
saludo en lugardel mensajede consulta.
Receptoresdensamente distribuidos
La páginade menú PIM-DMcontiene enlaces a páginas web que permitendefinir y visualizar los
parámetros y datosde PIM-DM.? Para visualizar esta página, haga clic en IP Multicast (Multidifus
IP)® PIM-DM en la vistade árbol.
A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:
Utilice la página PIM-DM Global Configuration (Configuración globalde PIM-DM) para configurar e
estadode administraciónde PIM-DM en este sistema.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® PIM-DM® Global
Configuration (Configuración global) en la vistade árbol.
Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivar PIM-DM.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde PIM-DM
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® PIM-DM® Interface
Configuration (Configuraciónde interfaz) en la vistade árbol.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde PIM-DM
Utilice la página PIM-DM Interface Summary (Resumende interfaces PIM-DM) para mostrar una
interfaz PIM-DM y su configuración. Como mínimodebe haber una interfaz configurada como PIM
DM en este enrutador para que se muestre la página.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® PIM-DM® Interface
Summary (Resumende interfaces) en la vistade árbol.
Interface(Interfaz): seleccione la interfaz cuyos datos se van a mostrar.Debe haber como mínim
una interfazde enrutador configurada para poder mostrar datosde una interfaz PIM-DM;de lo
contrario, se muestra un mensajede error.
Parámetrosde interfaz
Hello Interval (secs)(Intervalode saludo [seg.]): frecuencia con la que se transmiten losmensaje
de saludode PIM en la interfaz seleccionada.
Estadísticasde la interfaz
Vecinosde la interfaz
Neighbor IP(IPde vecino): dirección IPdel vecino PIM sobre el que esta entrada contiene
información.
Expiry Time (hh:mm:ss)(Tiempode caducidad [hh:mm:ss]): tiempo mínimo restante antesde que
caduque este vecino PIM.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde PIM-DM
PIM-SM
A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:
Resumende componentes
Resumende conjuntosde RP
Resumende RP candidatos
Configuraciónde RP estático
Utilice la página PIM-SM Global Configuration (Configuración globalde PIM-SM) para configurar lo
valores globalesde PIM-SM para este sistema.
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Global Configuration
(Configuración global) en la vistade árbol.
Configuraciónde PIM-SM
Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivar PIM-SM.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM
Utilice la página PIM-SM Global Status (Estado globalde PIM-SM) para ver los valores globales
seleccionados en la página PIM-SM Global Configuration(Configuración globalde PIM-SM).
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Global Status (Estado
global) en la vistade árbol.
La página PIM-SM Global Status(Estado globalde PIM-SM) contiene los campos siguientes:
Data Threshold Rate (Kbps)(Velocidadde umbralde datos [Kbps]): velocidad mínimade datosde
origen en kilobits/segundo por encimade la cual el enrutadorde último salto cambia a un árbold
rutade acceso más corta específicodel origen.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Interface Configuratio
(Configuraciónde interfaz) en la vistade árbol.
CBSR Preference(Preferencia CBSR): introduzca el valorde preferencia para la interfaz local com
enrutadorde inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local n
es una interfaz BSR candidata. Los valores válidos están comprendidos entre -1 y 255. El valor
predeterminado es 0.
CBSR Hash Mask Length(Longitudde la máscara hash CBSR): introduzca la longitudde la máscar
hash CBSR que se anunciará en losmensajes de inicio automático si esta interfaz se elige como
enrutadorde inicio automático. Esta longitudde máscara hash se utiliza en el algoritmo hash par
seleccionar el RPde un grupodeterminado. Los valores válidos están comprendidos entre 0 y 32
El valor predeterminado es 30.
CRP Preference(Preferencia CRP): introduzca el valorde preferencia para la interfaz local como
enrutadorde inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local n
es una interfaz BSR candidata. Los valores válidos están comprendidos entre -1 y 255. El valor
predeterminado es 0.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM
Utilice la página PIM-SM Interface Summary (Resumende interfaces PIM-SM) para mostrar una
interfaz PIM-SM y su configuración. Como mínimodebe haber una interfaz configurada como PIM
SM en este enrutador para que se muestre la página.
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Interface Summary
(Resumende interfaces) en la vistade árbol.
Mode(Modo): estadode administraciónde PIM-SM en el enrutador con los valores Enable (Activar
Disable (Desactivar).
Net Mask(Máscarade red): máscarade red correspondiente a la dirección IPde la interfaz PIM
seleccionada.
Hello Interval (secs)(Intervalode saludo [seg.]): frecuencia con la que se transmiten losmensaje
de saludode PIM en la interfaz seleccionada.
CBSR Preference(Preferencia CBSR): valorde preferencia para la interfaz local como enrutadord
inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local no es una
interfaz BSR candidata.
CBSR Hash Mask Length(Longitudde la máscara hash CBSR): longitudde la máscara hash CBSR
que se anunciará en losmensajes de inicio automático si esta interfaz se elige como enrutadord
inicio automático. Esta longitudde máscara hash se utiliza en el algoritmo hash para selecciona
RPde un grupodeterminado.
CRP Preference(Preferencia CRP): valorde preferencia para la interfaz local como enrutadorde
inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local no es una
interfaz BSR candidata.
Expiry Time (hh:mm:ss)(Tiempode caducidad [hh:mm:ss]): tiempo mínimo restante antesde que
caduque este vecino PIM.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM
Resumende componentes
Utilice la página Component Summary (Resumende componentes) para ver información sobre l
componentes PIM-SM.
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Component Summary
(Resumende componentes) en la vistade árbol.
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM
Resumende conjuntosde RP
Utilice la página PIM-SM RP Set Summary (Resumende conjuntosde RPde PIM-SM) para ver
información sobre el RP estático correspondiente al enrutador PIM-SM.
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® RP Set Summary
(Resumende conjuntosde RP) en la vistade árbol.
Expiry Time (hh:mm:ss)(Tiempode caducidad [hh:mm:ss]): tiempo mínimo restante antesde que
sedeclare el RP candidato como fuerade servicio.
Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM
Resumende RP candidatos
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Candidate RP Summa
(Resumende RP candidatos) en la vistade árbol.
Comandosde PIM-SM
Configuraciónde RP estático
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Static RP Configuratio
(Configuraciónde RP estático) en la vistade árbol.
Configuraciónde un RP estático
Abra la página Static RP Configuration (Configuraciónde RP estático).
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM
Community Home
Large Text
snWEB4