La transmisión multicast aparece de la necesidad de hacer emisiones en las que pueda participar todo aquel que lo desee, ya sea a nivel de organización, nacional o mundial, pero además, hacerlo de una forma eficiente. Debemos de ser capaces de dirigirnos a un grupo de oyentes, no solamente a uno como ocurre en la transmisión unicast, y sin que el número sea un factor limitante.
Una forma de hacer emisiones multicast seria mediante el uso de varias conexiones unicast, una por cada oyente. El problema que tiene esto es que es demasiado costoso, ya que se envía una copia de cada paquete por cada uno de los destinos. Además, el número de hosts que podrían estar escuchando nuestra emisión estaría limitado por la velocidad de nuestro acceso físico.
Otra opción seria la de enviar paquetes broadcast que se difundieran por toda la red. Con esto salvamos los problemas anteriores, ya que sólo emitiríamos un paquete y serían los dispositivos de la red (ya sean de nivel 2 o de nivel 3) los que se encargarían de replicarlo por cada una de sus interfaces, a excepción de la interfaz por la que entró. La vida de cada paquete se podría limitar como ya se viene haciendo con el campo TTL de IP o de otras formas más elaboradas, como ya veremos más adelante.
Las primeras pruebas de transmisión multicast se hicieron en DARTNET, un red experimental financiada por DARPA. Más tarde aparecieron otros grupos de investigadores con sus propias redes multicast, pero que no podían participar en DARTNET por no tener una conexión física a dicha red, por lo que se pensó en unir todas estas islas a DARTNET por medio de túneles. Este fue el principio de la MBONE (Multicast Backbone), que en 1993 ya contaba con varias decenas de miles de usuarios.
En todo lo que sigue veremos la base de IP multicast : direcciones y protocolos, y también comentaremos algunas aplicaciones multicast de vídeo-conferencia .
El rango de direcciones o grupos que una emisión multicast puede utilizar está comprendido entre la dirección 224.0.0.0 y la dirección 239.255.255.255, esto es, la clase D. De todo este conjunto de grupos multicast, algunos tienen un uso específico y no deberían usarse para emisiones. Estos grupos son :
Si queremos conocer los hosts multicast que se encuentran en nuestra red, podríamos hacer un ping a la dirección 224.0.0.1 y obtendríamos un ICMP Echo Response por cada uno. De la misma forma, podríamos hacer lo mismo para cara mrouter, o para cada mrouter que hablase PIM, por ejemplo.
Otro aspecto importante en el direccionamiento multicast es su mapeo en direcciones de nivel 2. En Ethernet el mapeo se hace solapando los 23 bits menos significativos de la dirección IP a la parte baja de la dirección MAC 01-00-5E-00-00-00. Puesto que una dirección multicast podía tener 28 bits variables (los cuatro primeros eran siempre 1110), 32 direcciónes IP corresponderían con una misma dirección MAC, así que es posible que el nivel 2 pase al nivel 3 ciertos paquetes dirigidos a grupos en los que no estamos realmente interesados. Con este mapeo de direcciones de nivel 3 a direcciones de nivel 2, en multicast se evita tener que recurrir a protocolos como ARP, ya que la traducción es automática.
El campo TTL juega un papel muy importante en transmisiónes multicast. Dependiendo de su valor, el paquete IP tendrá un ámbito u otro :
| TTL | Ámbito |
| 0 | Restringido al mismo host. No saldrá a la red. |
| 1 | Restringido a la misma red. No será enrutado por ningún mrouter. |
| 32 | Restringido al propio departamento. |
| 64 | Restringido a la propia región. |
| 128 | Restringido al mismo continente. |
| 255 | Ámbito mundial. |
De esta forma podemos limitar nuestra emisión asignando a cada paquete IP del tráfico que generemos un TTL específico. El resto del trabajo lo hará el mrouter, ya que en su configuración es donde le diremos qué interfaces son las fronteras de nuestro departamento con otro, de nuestra región con otra, o de nuestro continente con otro. ¿Cómo hacemos esto?. Esto se puede realizar asignando un valor umbral (threshold) en cada uno de los interfaces del mrouter. Cuando el mrouter reciba un paquete y vea que tiene que reenviarlo por una o varias interfaces, comparará por cada interfaz el umbral que éste tiene asociado y el campo TTL del paquete, y lo reenviará sólo si el umbral es menor que el TTL. Pero el único uso que tiene el umbral es éste, el control del ámbito. Si el mrouter decide que el paquete ha de ser reenviado por uno o varios de sus interfaces, su TTL decrementará en 1, al igual que ocurría con los routers unicast.
Existe otra forma de realizar el control del ámbito, y es mediante el uso de las direcciones multicast. Como vimos en el apartado anterior, el rango comprendido entre la dirección 239.0.0.0 y la dirección 239.255.255.255 también se utilizaba para administrar el ámbito de la transmisión. Esto permite una mayor flexibilidad al no tener en cuenta la geografía a la hora de crear un ámbito de emisión.
Para que un host sea capaz de participar en una red multicast, ha de añadir funcionalidades a su pila de protocolos de red.
La primera es sin duda el soporte para transmisión y recepción usando direcciones de clase D. La transmisión requiere de pocas modificaciones, pero la recepción es más complicada. En un host con soporte multicast, el núcleo del sistema operativo debe ser capaz de recibir peticiones de los procesos interesados en un grupo multicast dado, y enviarle a esos procesos los paquetes destinados a ese grupo. El núcleo debe añadir ese grupo multicast en un filtro hardware situado en la tarjeta de red del equipo para que ésta sea la encargada de pasar a la capa de red aquellos paquetes dirigidos a grupos en los que hay procesos interesados. Pero como ya vimos antes, este filtro no es perfecto y tampoco está disponible en todas las tarjetas de red, por lo que debe haber otro filtro software en la capa de red que se encargue de la selección definitiva de paquetes de los grupos en los que estamos interesados.
La segunda extensión es el protocolo IGMP, encargado de notificar a nuestro mrouter los grupos en los que estamos interesados. Este protocolo lo veremos con más detalle en la sección siguiente.
Linux tiene estas extensiónes implementadas en su núcleo. Para añadirlas deberemos compilar el núcleo activando en ``Networking options'' la opción ``IP: multicasting''. Una vez compilado y cargado el núcleo, podremos comprobar que funciona haciendo un ping al grupo 224.0.0.1. Dependiendo de la configuración de rutas de nuestra máquina, es posible que tengamos que añadir una ruta a las direcciones de clase D por el interfaz eth0. Esto lo haremos de la siguiente forma:
#route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
Otra característica del software de red multicast es el loopback. Cuando una aplicación emite en un grupo multicast, cada paquete UDP que genera, al llegar a la cola de salida de la capa de red, por defecto es copiado a la cola de entrada de esta misma capa. Como consecuencia, el mismo flujo multicast que sale de la aplicación volverá de nuevo a la misma y será recibido también por otros procesos que se hayan unido a ese grupo multicast. Esto es muy cómodo, por ejemplo, cuando nuestra aplicación es multiproceso y debe mostrar de alguna forma lo que estamos enviando. No necesitamos ningún tipo de comunicación entre procesos, simplemente la capa de red se encargará de reenviarlo a las aplicaciones que lo necesiten. Pero otras veces este mecanismo no es necesario, por ejemplo, en el caso de que nuestra aplicación se base en un solo proceso, por lo que el lookback debería poder deshabilitarse a petición de la aplicación.
Por ejemplo, para suprimir el loopback que aparece en el comando ping, podemos añadirle la opción -L. Vemos que ahora ya no responde nuestra máquina a la dirección 224.0.0.1, puesto que el ICMP Echo Request nunca entra a nuestra capa de red, solamente sale de ella.
Como comentamos en la introducción, la MBONE estaba formada por islas multicast unidas entre sí mediante túneles. Estas islas multicast pueden ser tanto un grupo de hosts multicast en una red Ethernet o una red mas compleja formada por varias subredes y unidas por medio de mrouters. Para la explicación del IGMP trataremos con islas del primer tipo, donde hay uno o varios mrouters conectados por tuneles al resto de islas y todo el trafico multicast en nuestra isla se hace sin la necesidad de atravesar ningún mrouter.
El IGMP es el protocolo utilizado para la comunicación entre los hosts multicast y su mrouter. Viaja dentro de paquetes IP con el campo tipo de protocolo de 2. Cuando en un host multicast un proceso decide unirse a un grupo dado, el núcleo se encarga de avisar de esto a su interfaz física y a su capa de red para que dejen pasar estos paquetes, como ya hemos visto antes. Pero esto no es suficiente. Además, hemos de decirle a nuestro mrouter que estamos interesados en el trafico dirigido a ese grupo, puesto que es muy probable que esa emisión nazca de otra isla y el mrouter es nuestra puerta hacia el resto de islas multicast y el encargado de llevar una cuenta de los grupos en los que los hosts de su isla están interesados. El mrouter también preguntará periódicamente a los hosts de su isla en qué grupos están interesados. De esta forma, si un hosts desea abandonar una emisión o simplemente cae, si nadie mas estaba interesado en ese grupo, el mrouter dejará de enviar ese tráfico innecesario. De estos dos tipos de mensajes (host\rightarrow mrouter, mrouter\rightarrow host) se encarga IGMP. A continuación veremos sus tres versiónes.
En IGMP v.1 tenemos dos tipos de mensajes : IGMP Host Membership Query e IGMP Host Membership Report. El primero es enviado periódicamente por el mrouter al grupo 224.0.0.1 (donde se encuentran escuchando todos los hosts multicast de nuestra red) y con un campo de TTL igual a 1, lo que evita que este mensaje sea reenviado por algún mrouter y siempre sea local.
Un mensaje IGMP v.1 tiene la siguiente estructura:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Versión| Tipo | Código | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección del Grupo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Donde :
Cuando un host recibe un IGMP Query, responderá con un IGMP Report a la dirección del grupo del cual desea recibir el trafico y con el campo Dirección del grupo conteniendo también el grupo al que se quiere unir. De esta forma, toda aquella estación interesada también en este grupo, al estar escuchando ya de esa dirección, podrá ver que ya se le ha enviado al mrouter una petición a ese grupo multicast y no insistirá en lo mismo. Para que esto sea viable, después de recibir un IGMP Query, cada host esperará un tiempo aleatorio antes de enviar un IGMP Report, escuchando mientras tanto qué ocurre en la red.
También es posible para un host anunciar al mrouter que está interesado en un grupo específico sin necesidad de esperar la pregunta del mrouter. Esto se hace simplemente enviando un IGMP Report de la misma forma que hacíamos antes.
Cuando una estación deja de estar interesada en un grupo multicast, deja de responder a las preguntas del mrouter. Cuando el mrouter no recibe confirmación de un determinado grupo para un cierto número de preguntas, asume que no quedan miembros y deja de reenviar tráfico para ese grupo en su subred.
Recordemos que aunque nuestra red sea conmutada, los conmutadores reenvían por todos sus interfaces cualquier paquete multicast como si de un paquete broadcast se tratase, aunque, como veremos en IGMP v.3, actualmente existen conmutadores inteligentes capaces de reenviar paquetes multicast por sus puertos solo si detrás de éstos hay hosts interesados en esos grupos.
En IGMP v.2 un mensaje tiene el siguiente formato:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo |Max Tiempo Resp| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dirección del Grupo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vemos como el campo versión desaparece y el campo tipo pasa a tener 8 bits. Para que IGMP v.1 y IGMP v.2 fuesen compatibles, en IGMP v.2 se optó por que el campo tipo valiese 0x11 en un IGMP Query y 0x12 en un IGMP Report, de esta forma en ambas versiónes los 8 bits tienen la misma interpretación. El campo Máximo Tiempo de Respuesta indica en décimas de segundo el tiempo máximo que el mrouter esperará un mensaje IGMP Report por parte de los hosts interesados. Esto se usa como mecanismo de ajuste temporal en los hosts.
En IGMP v.2 aparece un nuevo tipo de mensaje, el IGMP Leave Gruop, con el tipo 0x17. Ahora, cuando una estación deja de estar interesada en un grupo multicast, envía este mensaje con el campo Dirección del grupo conteniendo el grupo que desea abandonar y con destino al grupo 224.0.0.2, que es donde todos los mrouters están escuchando. Esto se hace para evitar que el resto de hosts multicast de nuestra red tengan que recibir un mensaje que a ellos no les aporta ningún tipo de información.
Con el mensaje IGMP Leave Gruop se evita que un mrouter siga retransmitiendo a su LAN una emisión multicast en la cual nadie está interesado. Pero como es posible que hayan otros hosts multicast atendiendo a la emisión que abandona uno de los componentes de nuestra LAN, cuando el mrouter recibe un IGMP Leave Gruop, responde con un IGMP group-specific query al grupo 224.0.0.1, del mismo tipo que el IGMP Query pero con el campo Dirección del grupo conteniendo el grupo que se abandonó. Así, cualquiera que siga interesado en ese grupo respondera primero y el mrouter seguirá con la retransmisión de ese grupo a su LAN.
El problema de esta mejora recae en la posibilidad de que el IGMP group-specific query se pierda o que no llegue la respuesta del host al mrouter. Esto obliga al mrouter a insistir varias veces en su pregunta y esperar un tiempo antes de dar por terminada esa retransmisión, retardo que, aunque mayor, ya ocurría con IGMP v.1 sin esta complicación. Además, el IGMP group-specific query provoca incompatibilidad con los mrouters de la versión 1, haciendo que todos los mrouters IGMP v.2 tengan que reconfigurarse a usar IGMP v.1 si tan solo uno los mrouters de nuestra LAN usa la versión 1.
Esta nueva versión de IGMP incorpora varias mejoras respecto a las anteriores. Con la versión 3 es posible hacer una petición y especificar el conjunto de emisores de los que queremos recibir la emisión. Es posible decir: ``Quiero recibir tráfico de este grupo siempre que provenga de S1 y S2, pero que no venga de S3 o S4''.
En IGMP v.3 se cambia la dirección multicast de nivel 2 en la que los hosts envían su IGMP Report. En las versiónes anteriores, este mensaje se enviaba a la dirección de nivel 2 derivada de la IP 224.0.0.1. Sin embargo, en la versión 3 se decidió enviar este mensaje a una dirección multicast de nivel 2 distinta, por el siguiente motivo:
En la actualidad la LANs tienden a ser conmutadas, teniendo un host por cada puerto de conmutador o, a lo sumo, unos cuantos unidos por un hub. Se pensó que podría ser el switch el encargado de recoger los mensajes IGMP Report y ser él el encargado de mirar si los grupos a los que hacen referencia ya habían sido pedidos con anterioridad al mrouter. Si no fue así, el switch se encargaría de reenviar ese mensaje ICMP al mrouter. Pero, ¿como sabe el switch donde se encuentra el mrouter?. El switch debería fichar el puerto por el que le llegasen mensajes ICMP Query como el puerto por el que se accede al mrouter, y reenviar las peticiones de los hosts por ahí.
Si los mensajes IGMP Report se enviasen a la dirección multicast de nivel 2 mapeada directamente de la IP 224.0.0.1, el switch tendría primero que asegurarse de que ese mensaje va dirigido a la IP 224.0.0.1 comprobando la dirección destino del paquete IP contenido en esa trama, ya que, como vimos, el mapeo no es 1 a 1, sino 1 a 32, y una vez comprobado esto, pasaría a anotar el grupo multicast que se desea escuchar por ese puerto. Con una MAC fija de antemano, el primer paso se evita, identificando sin lugar a dudas cada mensaje IGMP Report.
A esta técnica implementada por los switches se la conoce como IGMP Snooping. Ellos son los encargados de repartir el trafico multicast dentro de una misma LAN, y lo pueden hacer según la dirección de nivel 2 que les llega (con probabilidad a retransmitir un grupo equivocado) o examinando la cabecera IP de las tramas multicast, asegurándose de que retransmiten el grupo correcto.
DVMRP es un protocolo de routing multicast basado en el algoritmo vector distancia. Sufre por ello el problema del conteo a infinito, que trata de evitar mediante la técnica de hold down timers: cuando la mejor ruta a D cae, se anuncia durante un determinado periodo de tiempo que el coste a D es infinito. Esta técnica espera que durante ese tiempo se recalculen las rutas en base a los enlaces activos.
DVMRP se parece a RIP-2: ambos se basan en una métrica expresada en el número de saltos y soportan máscaras. DVMRP, al estar basado en el algoritmo vector distancia, envía su tabla de rutas a sus nodos vecinos y de esta forma calcula las rutas óptimas, al igual que se hace en RIP y en RIP-2. Sin embargo, DVMRP hace uso del algoritmo reverse-path para enrutar paquetes multicast y además soporta la creación de túneles IP-IP. Vemos ahora como funciona este protocolo de routing multicast.
En la introducción vimos una forma de transmitir un paquete multicast a toda la red : se enviaba un paquete multicast a nivel 2 y a nivel 3 y en el campo TTL de IP se ponía un valor suficientemente grande para que ese paquete llegara a cada rincón de la red. Las estaciones que estaban escuchando de ese grupo multicast recogerían ese paquete y lo pasarían a la aplicación. El problema es que hay muchos paquetes que llegarían duplicados a los hosts, y los mrouters tendrían que ser capaces de anotar cada paquete recibido y descartar duplicados, pero no es esta la técnica que DVMRP utiliza.
La forma que utiliza DVMRP para transmitir sus paquetes multicast es mediante el algoritmo reverse-path, que funciona de la siguiente forma: cuando un paquete multicast entra por un interfaz i, DVMRP mira la dirección origen de éste, S. Si en su tabla de rutas aparece el interfaz i como el óptimo para llegar a S,entonces ese paquete ha recorrido la ruta óptima, por lo que deberá ser reenviado por el resto de sus interfaces. Por el contrario, si i no es la ruta óptima para llegar a S, el paquete será descartado por tratarse de un duplicado. Si no hemos recibido todavía el original se deberá a una falta de correspondencia entre la métrica que DVMRP usa (el número de saltos) y el retraso real del paquete, o a un fallo en la ruta óptima a S, por lo que la tabla de rutas se reconfigurará y la emisión volverá a llegar a nosotros.
La creación de túneles es, como vimos, la solución al problema de unir islas multicast sobre redes unicast. Un mrouter de una isla se unirá con otro de otra isla estableciendo un túnel IP-IP. Este túnel va a tener tres parámetros: el mrouter destino, el coste y el umbral o threshold. Este umbral, como ya comentamos antes, se utiliza para controlar el ámbito de la emisión. Cuando un mrouter recibe por uno de sus interfaces un paquete multicast, si el algoritmo reverse-path le dice que debe reenviarlo, lo reenviará por el resto de sus interfaces y tuneles siempre y cuando el umbral asociado a éstos sea menor que el campo TTL del paquete.
Pero según todo esto, ¿qué ocurre cuando alguien inicia una nueva transmisión a la que nadie se ha unido?. Los mrouters retransmitirán paquetes aunque detrás no haya nadie interesado. Esto se soluciona con los mensajes de poda. Estos mensajes se inician en los mrouters que están en contacto con hosts multicast: cuando no recibe ninguna petición por IGMP de unión a un grupo dado, este mrouter envía mensajes de poda al mrouter por donde le llega esa transmisión. Este segundo mrouter hará lo mismo si por todos los interfaces por los que retransmite ese grupo le llegan mensajes de poda, y así sucesivamente. Los mrouters han de recordar los mensajes de poda que envían. Esto se puede hacer en una tabla de mensajes de poda con tres columnas: grupo, interfaz por el que se envió el mensaje de poda, tiempo. El tiempo es necesario puesto que los mensajes de poda caducan cada 2 horas, por lo que tendremos que volver a enviarlos pasado este tiempo.
Los mensajes de poda no evitan que el primer paquete de un grupo se propague por todo el ámbito de la transmisión, y solo después será cuando se empiecen a enviar mensajes de poda.
Cuando un mrouter reciba de algunos de los hosts de su isla un IGMP Report uniéndose a un grupo del que antes se hizo una poda, se enviará un mensaje de unión a aquellos mrouters a los que se envió la poda. Este mensaje de unión debe esperar reconocimiento por parte del otro mrouter. Si el otro mrouter recibe este mensaje de unión y también envió mensajes de poda, enviará mensajes de unión por cada interfaz que antes había podado.
DVMRP tiene problemas de escalabilidad: los mensajes de poda necesitan que los mrouters tengan estado, recordando cada grupo e interfaz del que no quieren recibir. Si la transmisión multicast se hiciese realmente popular los mrouters tendrían problemas para almacenar estas tablas. Sin embargo, para transmisiónes en las que la densidad de los hosts es grande y la inundación es parecida al camino óptimo, DVMRP es un buen protocolo multicast.
Mrouted es una implementación para UNIX de DVMRP con algunos añadidos. Podemos encontrar la página del manual en http://mice.ed.ac.uk/mice/archive/mrouted.html.
En este apartado veremos unas cuantas aplicaciones de conferencia para la MBONE. Se puede obtener más información en http://www-mice.cs.ucl.ac.uk/multimedia/software/
SDR nos permite anunciar nuestras sesiones multicast y unirnos a otras que esten dentro de nuestro ambito. Permite el uso de criptografía de clave pública para autenticar y/o encriptar sesiónes. Usa para ello PGP.
Para crear una nueva sesión multicast pulsaremos New\rightarrow Create Adversite Session. Una vez dados todos los datos, pulsamos el boton de aceptar y podremos ver el nombre de nuestra sesión en el SDR. Hemos enviado también un mensaje de anuncio a toda el ambito de la sesión. Este anuncio de sesión se reenvía periódicamente. Para empezar a transmitir deberemos pinchar sobre nuestra sesión y hacer click en 'Join'. Si cuando la creamos le dijimos que soportaba varios medios (audio y video, por ejemplo), automáticamente se une a los dos. Si solo queremos unirnos al video, por ejemplo, pincharemos el botón de 'Video'.
SDR lanza automaticamente el programa VIC para video y RAT para el audio.
Esta aplicación permite realizar conferencias de audio. Para la comunicación entre dos personas únicamente no se necesita soporte multicast, simplemente una conexión de red y tarjeta de sonido. Para la comunicación de más de dos personas, RAT utiliza IP multicast y todos los miembros deben estar dentro de una red que lo soporte. Usa RTP sobre paquetes UDP, e implementa gran variedad de codecs.
VIC es una aplicación para el envío de video en la MBONE.
Es lanzada automáticamente por SDR, pero también la podemos lanzar nosotros con los parámetros grupo multicast/puerto. Para empezar a transmitir pulsaremos Menu y después Transmit.
Un aspecto importante de este programa (sobre todo a la hora de hacer pruebas) es que esta aplicación desactiva el loopback del socket UDP, por lo que el tráfico que envia no vuelve a la capa de red de la máquina. ¿Cuando puede ser esto problemátco?. Supongamos que tenemos una maqueta de la MBONE con dos islas, cada una formada por un PC que hace a la vez de mrouter y de host multicast. Las dos islas esta unidas por medio de dos routers unicast y tienen configurado un tunel entre los dos mrouters. Nos podemos volver locos al ver que, entre estas dos islas, el RAT funciona y el VIC no. ¿Por qué?. Porque el RAT no desactiva el loopback del socket, por lo que el trafico que genera es inyectado a la Ethernet y pasado de nuevo a la capa de red de la máquina, y de ahi al mrouted, que lo enviará por el tunel hasta la otra isla. Sin embargo, como el VIC elimina la opción de lookback, el mrouted no recibe este tráfico y tampoco lo enruta.
[1]``Multicast over TCP/IP HOWTO''. Juan Mariano de Goyeneche. 1998.
[2]``Routing in the Internet''. Chirstian Huitema. Prentice-Hall. 1995.
[3]``Interconnections - 2nd ed.''. Radia Perlman. Addison Wesley Longman. 2000.