Juan Antonio GarcíaEl objetivo fundamental de este artículo es proporcionar una visión global de MBone, cuáles son sus ventajas y qué aporta al desarrollo de la Internet, sin pasar por alto la gran cantidad de conceptos de la tecnología de las telecomunicaciones subyacentes.Entre los conceptos explicados, se han intercalado las notas históricas más destacadas , para intentar situar al lector apropiadamente dentro del marco temporal en el que estos se han desarrollado.
El artículo concluye con un apartado de referencias bibliográficas, para que todo aquel que lo desee, pueda complementar la información sobre cualquiera de los aspectos abordados.
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.
2.- ¿Qué es y cómo funciona el IP Multicast?
Internet es una red en la que el intercambio de información entre equipos locales o remotos se hace a través de datagramas IP Internet Protocol). Un datagrama IP (o paquete IP) podríamos decir que es la unidad mínima de información en el lenguaje que hablan todos los equipos que forman parte de Internet. Estos datagramas IP están formados principalmente por una dirección origen y una dirección destino, y cada equipo de comunicaciones situado en la ruta entre ambos se encarga de enviar dicho datagrama por el camino adecuado. Esto implica que cada estación conectada a Internet debe tener una dirección que la identifique, lo que se llama dirección IP, y constituye un sello de identidad global y único para cada equipo en Internet.Pueden clasificarse en tres tipos en función de la dirección de destino:
- 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).
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 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.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.
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).Tipo Dirección en binario Rango en decimal ----------------------------------------------------------------------------------- Clase A 0bbbbbbb bbbbbbbb bbbbbbbb 0.0.0.0 a 127.255.255.255 Clase B 10bbbbbb bbbbbbbb bbbbbbbb 128.0.0.0 a 191.255.255.255 Clase C 110bbbbb bbbbbbbb bbbbbbbb 192.0.0.0 a 223.255.255.255 Clase D 1110bbbb bbbbbbbb bbbbbbbb 224.0.0.0 a 239.255.255.255 Clase E 11110bbb bbbbbbbb bbbbbbbb 240.0.0. a 247.255.255.255
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.
Un mrouter debe cumplir dos requisitos básicos:
- 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 Tipo especifica 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 checksum es 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:
El primero de ellos lo emplean los mrouters para consultar la filiación a cualquier grupo multicast, y lo envían periódicamente por a un determinado grupo multicast: el 224.0.0.1. En caso de que existan varios mrouters dentro de una determinada subred, será sólo uno de ellos el encargado de enviar los mensajes IGMP de consulta de filiación (querier mrouter),este será el que tenga una dirección IP menor.Valor (hex.) Tipo de mensaje Específico de... ------------------------------------------------------------------ 0x11 Consulta de filiación (Membership Query) IGMPv1,v2 y v3 0x12 Informe de filiación (Membership Report) IGMPv1 0x16 Informe de filiación (Membership Report) IGMPv2 0x17 Abandono de grupo (Leave group) IGMPv2 0x22 Informe de filiación (Membership Report) IGMPv3
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:
- Protocolos de vector distancia: Basados en el algoritmo de "camino más corto" del Bellman-Ford, en el que cada nodo distribuye todo el mapa de encaminamiento a sus vecinos de forma periódica, de tal forma que cada nodo se va haciendo una imagen de la red en su conjunto. Cada nodo asigna un "peso" o métrica a cada ruta en función de los saltos necesarios para alcanzar a otro nodo. Su principal ventaja es su sencillez de operación y por ende, de implementación. Mientras que su mayor desventaja es su problema de escalabilidad. A medida que la red se hace mayor y más compleja, el algoritmo se vuelve menos eficiente y se produce un mayor consumo de ancho de banda en los enlaces por la diseminación de las tablas de encaminamiento. Por otro lado también es posible la formación de bucles de encaminamiento (aunque existen implementaciones de este tipo de protocolo que evitan, en gran medida, este inconveniente).
- Protocolos de estado del enlace: Se basan en el concepto de un "mapa distribuido", es decir, que todos los nodos tienen una copia del mapa de la red, que se actualiza periódicamente. Se han desarrollado a partir de un algoritmo más eficiente que el de Bellman-Ford, propuesto por E.W. Dijkstra, llamado "el camino más corto primero" (shortest path first). Sin entrar en más detalles comentaremos que algunas de sus principales ventajas son: la rápida convergencia a la descripción real del estado de la red, la ausencia de creación de bucles, el soporte de métricas (costes asociados a un determinado enlace) múltiples, soporte de múltiples rutas a un mismo destino, etc.. Como contrapartida requieren mayor poder de procesamiento en los routers y son complejos de implementar y/o configurar.
- Basados en técnicas simples
- Inundación (flooding).
- MAC-layer Spanning Trees.
- Basados en técnicas de árboles centrados en la fuente
(Source-based trees)
- Reverse Path Broadcasting (RPB).
- Truncated Reverse Path Broadcasting (TRPB).
- Reverse Path Multicasting (RPM).
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 idmr del 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.
En la actualidad la mayor parte de estos protocolos cohabitan en el MBone y la tónica general es la implantación de PIM-DM, DVMRP o MOSPF en entornos corporativos, y la conexión de estas `islas' multicast a través de túneles DVMRP. Sin embargo, es preciso resaltar que la interrelacción de estos protocolos de encaminamiento multicast está aún en período de estudio y experimentación. Existe un trabajo en progreso dentro del grupo de trabajo idmr del IETF, que pretende definir los requisitos que se deben cumplir en la interacción de distintos protocolos de encaminamiento multicast.
4.- ¿Qué ventajas ofrece el IP multicast?
La ventaja del IP multicast frente a otros tipos de comunicaciones, es la transmisión de información en tiempo real para múltiples receptores. En estos casos la utilización del multicast permite un ahorro substancial de los recursos de red consumidos, y por ende una mejora en la transmisión de esta información y -¿porqué no?- una mejor relación calidad/costes. La ventaja de aprovechar el multicast para la transmisión de datos multimedia frente a las comunicaciones uno-a-uno, es el ahorro de recursos telemáticos y por tanto la eficiencia de las aplicaciones a iguales gastos en infraestructura. Pongamos un ejemplo sencillo: En una conferencia basada en comunicaciones uno-a-uno, la eficiencia de la misma es inversamente proporcional al número de receptores en un extremo dado de la red. Cada nuevo receptor en un mismo extremo de la red obliga a que los paquetes de información enviados por el emisor se dupliquen. En el caso de las comunicaciones uno-a-muchos (IP multicast o MBone) la eficiencia no se ve afectada por este factor. A cada extremo de la red en la que existen receptores de la misma, sólo llegan una vez los paquetes que contienen la información, independientemente del número de receptores. Los protocolos de encaminamiento subyacentes en MBone se encargan de asegurar que la información que viaja entre el emisor y los receptores no pase más de una vez por el camino entre ambos, y que sólo sea enviada en el caso de que existan receptores de la misma.
5.- ¿Cuáles son sus inconvenientes y cómo resolverlos?
MBone, como red experimental, existe desde 1992 y ha evolucionado hacia algo más que un simple experimento. De hecho es un experimento de dimensiones impresionantes que interconecta a decenas de miles de usuarios de todo el mundo. En todos los sentidos esto puede ser considerado como un enorme éxito. Por un lado hemos visto como existe una fuerte demanda por los tipos de aplicaciones que permiten las transmisiones multicast. Por otro lado es difícil la investigación cuando no se cuenta con usuarios e infraestructuras reales, pero si los experimentos resultan satisfactorios, los propios usuarios demandan su utilización como un servicio operativo.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.
En cuanto a los protocolos de encaminamiento y algoritmos de creación de árboles de distribución, existen ciertas deficiencias que deben ser corregidas antes de que se puedan considerar aptos para su implementación masiva. Cualquier protocolo escalable debe tender a minimizar los requisitos del estado de remisión (forwarding state). En el caso de protocolos orientados a distribuciones pobladas de fuentes/receptores (DVMRP, PIM-DM), los mrouters deben guardar la información de estado de remisión o `podado' para cada pareja {fuente,grupo} en la Internet. Es obvio que si el multicast se escala al tamaño de la Internet, el mantenimiento de tal información se hace insostenible.
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.
6.- ¿Cómo sacar provecho al MBone ?
Se han desarrollado gran cantidad de herramientas para experimentar diferentes intercambios multimedia a través de MBone ya sea en modo interactivo: editores de texto y pizarras electrónicas compartidas, intercambio de hipertextos; o de procesos no interactivos: sincronización de equipos (NTP multicast) o distribución de archivos a múltiples receptores simultáneamente (FTP multicast) por poner algunos ejemplos. Algunas de estas aplicaciones experimentales, como son las de transmisión de audio y vídeo, se han convertido prácticamente en estándares de facto y son ampliamente utilizadas por un elevado número de usuarios con cierta regularidad.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 SDR emplea 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.
Bibliografía
- W. Richard Stevens, "TCP/IP Illustrated, Volume 1", Addison-Wesley, 1994.
- Christian Huitema, "Routing in the Internet", Prentice Hall PTR, 1995.
- Vinay Kumar, "Mbone. Interactive Multimedia on the Internet", New Riders Publishing, 1996.
- Ignacio Martínez, "Multimedia I: Multicast IP y su aplicación en audio/vídeo conferencia en la Internet", Boletín de la red nacional de I+D, RedIRIS, 1993.
- D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, Standford University, Noviembre de 1988.
- Deering, "Host Extensions for IP Multicasting", RFC 1112, Stanford University, Agosto de 1989.
- W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, Noviembre de 1997.
- Andrew S. Tanenbaum, "Computer Networks", Prentice-Hall International, 1988.
- H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, Enero de 1996.
- Miguel A. Sanz Sacristán, "Evolución del servicio Internet de RedIRIS", Proyecto fin de carrera de la Escuela Técnica Superior de Ingenieros de Telecomunicación, ETSIT- UPM. Madrid 1997
- R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC 2205, Septiembre de 1997. Nota: además de estas referencias se han consultado gran número de borradores de los Grupos de Trabajo del IETF: MBoned, IDMR, MMUSIC.... Para más información consultar:
APÉNDICE: Algunas aplicaciones para MBone
- sdr: ftp://ftp.rediris.es/mirror/videoconference/sdr
Sesion Directory Tool. Desarrollado por el UCL (University College London) dentro del proyecto MERCI. Está basado en otro software anterior, llamado SD, original del grupo de Van Jacobson en el LBNL (Lawrence Berkeley National Laboratory). Es una herramienta que nos muestra un directorio de las sesiones de MBone activas y nos permite unirnos a una determinada sesión lanzando automáticamente las aplicaciones adecuadas.
- vat: ftp://ftp.rediris.es/mirror/videoconference/vat
Visual Audio Tool. Desarrollada por Van Jacobson en el LBNL. Aplicación para realizar conferencias de audio. Es una de las más utilizadas en Mbone junto con el rat.
- rat: ftp://ftp.rediris.es/mirror/videoconference/rat
Robust Audio Tool Desarrollada en el UCL de Londres dentro del proyecto MERCI. Es una aplicación para conferencias de audio.
- vic: ftp://ftp.rediris.es/mirror/videoconference/vic
VideoConferencing. Desarrollada por Van Jacobson y su grupo en el LBNL.
- wb: ftp://ftp.rediris.es/mirror/videoconference/wb
White Board. Desarrollada por Van Jacobson en el LBNL. Es una pizarra electrónica compartida.
- nt: ftp://ftp.rediris.es/mirror/videoconference/nt
Network Text Editor. Desarrollada en el UCL dentro del proyecto MERCI. Es un editor de textos compartido.
- ivs ftp://ftp.rediris.es/mirror/videoconference/deprecated/ivs
Desarrollado por el INRIA. Intregra el audio, vídeo y control de la sesión sobre una misma aplicación. Actualmente ha sido remplazado por el Rendez-Vous.
- nevot ftp://ftp.rediris.es/mirror/videoconference/nevot
Network Voice Terminal. Desarrollado por Henning Schulzrinne en la Universidad de Masachusets y en los Laboratorios Bell de AT&T. Es una aplicación para audio conferencias sobre máquinas UNIX .
- Rendez-Vous http://zenon.inria.fr/rodeo/rv/
Desarrollado por Frank Lyonnet del INRIA, como sustitución del ivs. Es una herramienta que integra audio, vídeo y control de la conferencia en una misma aplicación.
- FreePhone ftp://ftp.rediris.es/mirror/videoconference/freephone
Desarrollado por el INRIA dentro del proyecto MERCI (Multimedia European Research Conferencing Integration). Utilidad de audio de alta calidad (similar a la calidad del CD en estereo), unicast o multicast, sobre Internet.
Información sobre el proyecto MERCI:
http://www-mice.cs.ucl.ac.uk/merci/
Juan AntonioGarcía
Aplicaciones y Sistemas de Información
RedIRIS
juan [dot] garcia [at] rediris.es
Indice General
![[Índice General]](../logopuente_boletin.gif){kind=small}