A. F. Gómez, A. L. Mateo y P.M. Ruíz
A lo largo de estos últimos años, se han ido desarrollando y mejorando multitud de herramientas multimeda basadas en IP multicast sobre MBone. Aunque MBone permite la transmisión de audio y vídeo sobre Internet, hoy por hoy está siendo infrautilizado ya que sólo lo suelen emplear desarrolladores e investigadores cuyas áreas de trabajo están muy extrechamente ligadas a esta tecnología. Esto es así debido principalmente a que IP multicast presenta una serie de problemas que aún no han sido resueltos: desaprovechamiento de ancho de banda, imposibilidad de controlar quién participa en una sesión, alta vulnerabilidad a usuarios malintencionados, falta de control del TTL asociado a los paquetes, etc. Este tipo de problemas hacen que los ISPs (Internet Service Providers) sean reacios a ofrecer IP multicast como un nuevo servicio por el riesgo que les podría suponer.
Nuestra meta va a ser tratar de resolver este tipo de problemas y particularmente nos vamos a centrar en modificar los esquemas de enrutamiento multicast para permitir el control de los emisores multicast.
1.- Introducción
Internet ha evolucionado muchísimo desde sus inicios hasta ahora. El mismo protocolo IP sigue siendo empleado para la transmisión de contenidos que en un principio ni se imaginaba que podrían circular por la red tales como audio y video.
Las soluciones actuales más populares para el transporte de este tipo de contenidos se basan en el empleo de "reflectores" o nodos en la red que se encargan de replicar flujos multimedia para permitir videoconferencias entre varios participantes.
Frente a este enfoque, surge la idea de emplear IP multicast que está basado en las siguientes premisas que dadas por S. Deering [2]:
- Un emisor multicast(EM) podrá enviar datagramas a un grupo multicast sin necesidad de unirse a ese grupo.
- Un receptor multicast deberá unirse al grupo para poder recibir el tráfico multicast dirigido a ese grupo.
- Los enrutadores multicast o "mrouters" se encargarán de hacer que los flujos emitidos lleguen desde los emisores hasta los receptores.
Si bien este enfoque añade la complejidad de necesitar unos enrutadores con capacidad para gestionar flujos multicast, también es cierto que permite una redución muy significativa del ancho de banda consumido y de la capacidad de cómputo de los equipos finales. De este modo se puede conseguir que un simple PC pueda emplearse para videoconferencias con miles de participantes.
Con IP multicast la complejidad recae en los enrutadores multicast que serán los encargados de replicar los datagramas multicast por sus diferentes interfaces sólo cuando sea necesario. De un modo general podríamos decir que los enrutadores multicast se encargan de determinar las interfaces por las que tendrá que reenviar un determinado datagrama multicast en función de la interfaz de entrada así como de algunos datos que obtiene mediante la ejecución de algún algoritmo de enrutamiento multicast.
Actualmente existen dos tipos de enrutadores multicast, los routers con soporte multicast y las estaciones de trabajo ejecutando algún demonio de enrutamiento multicast (DEM).
Debido a que hoy por hoy no todos los routers de Internet incorporan soporte multicast, los equipos que hacen enrutamiento suelen comunicarse muchas veces mediante el empleo de túneles IPIP por los que se encapsulan los datagramas multicast. A toda esta nube de túneles es a lo que se le ha llamado Multicast Backbone (MBone[1]).
Últimamente la mayor parte de los esfuerzos han ido encaminados a la creación de nuevas aplicaciones, protocolos de tiempo real, estudiar técnicas de Feedback Error Correction (FEC) para RTP, etc. Sin embargo, no deben descuidarse otra serie de aspectos que quizás no son tan espectaculares pero sí son igual de necesarios e importantes para conseguir que IP multicast se asiente como una tecnología que pueda ser ofrecida por los ISPs. Estos aspectos tienen que ver con el control de los usuarios que hay en un determinado grupo, el ámbito o Time To Live (TTL) usado por los emisores, etc.
Los algoritmos de enrutamiento multicast están siendo cada vez más estables, aunque haya aún una cierta carencia en lo referente a herramientas de monitorización. El problema es que al no tener control sobre los clientes de este servicio potencial los ISPs comerciales no pueden ofrecerlo ya que sólo tendrían dos opciones: ofrecerlo a todos los clientes o no ofrecerlo a ninguno.
Por lo tanto uno de los principales problemas que está frenando el asentamiento final de IP multicast tiene que ver con el control de acceso y es precisamente lo que pretendemos resolver. Éste sistema debería proporcionarnos la posibilidad de controlar qué usuario recibe o envía a un determinado grupo multicast. De momento, en este paper nos vamos a centrar en el control de los emisores ya que éstos pueden suponer el principal problema.
En el siguiente apartado veremos el funcionamiento general de un DEM, continuaremos con la presentación de nuestra solución y finalizaremos con una serie de conclusiones y vías futuras de desarrollo.
2.- Funcionamiento del DEM
Aunque existen diferentes varios algoritmos de enrutamiento multicast como PIM(Protocol Independent Multicast), DVMRP (Distance Vector Multicast Routing Protocol),etc., en todos ellos hay que decidir los interfaces virtuales (VIFs) por los que debe de reenviarse cada paquete que llegue al router multicast.
Para mejorar la escalabilidad y el consumo de recursos, algunos de esos algoritmos (operando generalmente en dense mode) emplean prunning. El prunning consiste básicamente en evitar la retransmisión innecesaria de datagramas a localizaciones en las que no hay ningún receptor interesado en esos paquetes. Pero, ¿cómo sabe el router si hay receptores interesados?. Para esto se emplea el Internet Group Management Protocol (IGMP[4]). Este protocolo se emplea entre los equipos finales y su DEM más cercano y permite que éstos equipos finales informen al DEM de los grupos en los que están interesados. Además el mrouter deberá mantener este estado (grupos asociados a cada interfaz virtual).
2.1.- Soporte del SO al enrutamiento multicast
A nivel de SO lo que se pretende es que el tiempo de procesamiento de los datagramas sea lo más pequeño posible sobre todo teniendo en cuenta que estamos hablando de datos en muchos casos en tiempo real. Es por esto que el SO ofrece al DEM la posibilidad de enrutar automáticamente los datagramas sin necesidad de que el DEM vaya examinado datagrama a datagrama.
Gracias a este soporte del SO, el DEM simplemente tendrá que atender a los mensajes IGMP para averiguar cómo debe de hacerse la distribución de los datagramas en función de la dirección IP origen y del grupo al que van dirigidos. Una vez sabe esto, se lo indica al kernel mediante una serie de llamadas que ofrece el SO y de ahí en adelante todos los paquetes similares que lleguen los encaminará automáticamente el núcleo del SO. Del mismo modo el SO también ofrece llamadas para que el DEM le indique que debe de dejar de reenviar algún tipo determinado de datagramas.
El principal problema que se plantea es que no existe ningún control sobre los emisores y por lo tanto cualquier usuario que tenga accesible un router que entienda multicast puede emitir tráfico multicast ya que el kernel automáticamente reenviaría esos datagramas.
La única forma de poder controlar realmente a los emisores es a nivel de núcleo del sistema operativo ya que, como acabamos de ver, a nivel de DEM sólo se puede decidir si dejamos que un grupo multicast se distribuya a no. En ningún caso podemos a ese nivel discriminar datagramas en función del emisor.
Dado que necesitamos modificar el núcleo del sistema operativo, nuestro sistema se ha desarrollado sobre un sistema que ofece el código fuente del núcleo como es Linux[5].
Actualmente la gestión de los EM es un tema totalmente novedoso y por estudiar. De hecho, al día de hoy sólo existe una propuesta que se convirtió en internet-draft [8] que describe una serie de extensiones al protocolo IGMPv2 para soportar la autenticación de usuarios con sistemas de autenticación externos al DEM como por ejemplo RADIUS.
3.- Solución adoptada
A este problema se pueden presentar distintas soluciones cada una con sus ventajas e inconvenientes. Para llegar a la solución que vamos a presentar aquí se pasaron por diferentes soluciones intermedias. Pero independientemente de la solución planteada, existe un denominador común: la necesidad de controlar cuando un datagrama multicast debe reenviarse y cuando no. Como ya hemos visto este control debe de realizarse a nivel de SO.
3.1.- Modificaciones al kernel del SO
Las modificaciones que vamos a detallar a continuación se han realizado sobre un PC con Linux RedHat 5.2. Inicialmente se trabajó sobre el kernel 2.0.36 pero como descubrimos diferentes fallos en lo referente al enrutamiento multicast decidimos continuar con el kernel 2.2.2. Es importante destacar que las modificaciones realizadas en el kernel 2.0.36 no valen para el 2.2.2 ya que a partir del kernel 2.2.0 cambia el modo en que se intercambian los datos entre el espacio de datos del usuario y el espacio de datos del kernel.
Nuestra modificación al kernel consiste en la adicción de una serie de estructuras de datos que permitan almacenar los parámetros asociados a cada emisor multicast así como mantener un registro de los EM que están autorizados a emitir junto con los grupos a los que pueden enviar datagramas. Además añadimos una serie de funciones que permitan comprobar que realmente el tráfico generado por un EM se ajusta a los parámetros definidos para ese EM. Por último añadimos una serie nuevas llamadas al sistema que permiten la configuración dinámica.
Se definió una nueva estructura denominada msender_ctl. Esta estructura almacena la información necesaria para controlar el tráfico generado por un EM.
El siguiente paso fue definir una política de control que en nuestro caso consiste en descartar todo el tráfico multicast excepto el que provenga de un origen registrado en el kernel y cuyos parámetros no violen los establecidos en la estructura msender_ctl para ese emisor.
Con esta política conseguimos mantener controlados a los usuarios malintencionados ya que al no poder emitir no van a poder molestar a otras sesiones. Además, vamos a poder controlar que los datagramas enviados por un determinado usuario no usen TTLs superiores a los que tiene asignado ese usuario.
La implementación de está política se hizo con una rutina que comprobaba que cada paquete colocado en la cola de paquetes IP del kernel cumplía con la política definida anteriormente y en caso contrario se descartaba ese paquete eliminandolo de la cola.
La pregunta que surge ahora es, ¿cómo pasamos al kernel los parámetros asociados a cada emisor?. Para ello creamos tres nuevas llamadas al sistema: una para inicializar las estructuras de datos en el kernel, otra para añadir registrar a un nuevo EM en el kernel y otra para quitar el registro anterior de algún EM en el kernel. Estas nuevas llamadas nos permiten una gran flexibilidad ya que facilitan la gestión de usuarios de forma dinámica sin necesidad de reinicializar en ningún momento el enrutador multicast.
3.2.- Solución propuesta
La solución que buscamos debe de ser independiente del algoritmo de enrutamiento multicast empleado. Esta independencia se consigue gracias a las ventajas que aportan las llamadas al sistema que hemos creado:
- Nos permiten insertar y eliminar EM de un módo dinámico.
Se situan a nivel de kernel por debajo de cualquier DEM que se emplee.
Esta solución que proponemos se basa en la interacción de varios elementos:
- musersd. Es un demonio de gestión de usuarios que se encargará de interaccionar con el kernel y que hará de intermedario entre la aplicación de gestión y el kernel.
- mauthclient. Es la aplicación propiamente dicha que interactúa con el mauthserver.
- mauthserver. Se sitúa como elemento intermedio entre el mauthclient. Entre sus funiones destacan la de registrar los anuncios de sesiones que se produzcan implementando para ello los protocolos SAP (Sessión Announcement Protocol)[6] y SDP [7] (Sessión Description Protocol). Además aporta cierta tolerancia a fallos (TF) gracias a su situación estratégica.
El esquema general puede apreciarse en la figura 1 donde aparecen una serie de esquemas de comunicación entre los diferentes elementos de la arquitectura que se deben de definir.
3.3.- Comunicación entre el musersd y el mauthserver
Para la comunicación entre estas dos entidades se emplea un protoloco del tipo call/response que hemos denominado mcontrol. El musersd será el servidor que quedará permanentemente escuchando a los comandos que le llegan por determinado puerto UDP.El formato de los mensajes aparece en la siguiente figura.
El mauthserver enviará los comandos que le llegan del mauthclient y el musersd responderá con los correspondientes mensajes de ACK o ERROR. Además, para evitar comportamientos anómalos derivados del empleo de un protocolo no orientado a la conexión como es UDP se añadieron una serie de campos extras a los paquetes. Del mismo modo al existir la posibilidad de mensajes duplicados se implementa en el muserd un mecanismo que asegure un comportamiento similar al que ofrecería la semántica at most once de los Remote Procedure Call (RPC). En concreto una ventana deslizante.
El esquema general puede observarse en la siguiente figura.
3.4.- Comunicación entre el mauthserver y el mauthclient
En este caso hacen falta dos equemas de comunicación. En un sentido, el mauthserver comunicará al mauthclient la creación y eliminación de nuevas sesiones. En el otro sentido, el mauthclient comunica al mauthserver los comandos de añadir o eliminar EM que esté introduciendo el administrador. Para este segundo caso se sigue empleando el protocolo mcontrol.
En cuanto a la primera implementación, aprovechando que ambos elementos están implementados en lenguaje Java hemos aprovechado la posibilidad de serialización de objetos que ofrece este lenguaje para hacer el intercambio de objetos de la clase Comando donde un objeto de esta clase contendrá un atributo tipo que indica el tipo de comando (nueva sesión, eliminación de una anterior) así como un objeto de la clase Session que representa a la sesión sobre la que afecta el comando.
La Figura 4 muestra el applet de administración que hemos desarrollado.
4.- Conclusiones y vías futuras
MBone e IP multicast en general presenta actualmente una serie de carencias que hay que cubrir para que realmente pueda ser ofrecido por los ISPs. Uno de los problemas más importantes es la autenticación.
Hemos ofrecido un sistema de gestión y control de EM que permite de un modo totalmente sencillo e intuitivo que un administrador pueda gestionar mediante un applet los EM de su red.
Otro aspecto muy interesante de la solución ofrecida es el hecho de que es una solución totalmente transparente para el usuario final.
Aún así, aún pueden añadirse varias mejoras:
- Evitar que un equipo pueda suplantar a otro en la red. Para ello recurriremos al empleo de criptografía.
- Actualmente la autorización a un usuario se hace mediante la figura del administrador. Intentaremos integrar todo esto en un sistema similar al del RADIUS para liberar al administrador de estas tareas.
- En un siguiente paso, y apoyados en modificar IGMP, podríamos controlar también los receptores multicast para poder permitir conferencias del tipo pay-per-view.
Referencias
- Vinay Kumar "MBone: Interactive Multimedia on the Internet", New Riders, 1996. ISBN 1-6205-397-3.
- Steeve Deering. "IP Multicast Extensions for 4.3BSD UNIX and related systems", Junio 1989. Standford University.
- D. Waitzman, C. Partridge, S. Deering. "Distance Vector Multicast Routing Protocol", RFC 1075.
- W. Fenner. "Internet Group Management Protocol, Version 2". RFC 2236. Noviembre 1997.
- David A. Rusling. "The Linux Kernel". REVIEW, Version 0.8-2. Marzo 1998.
- Mark Handley. "SAP:Session Announcement Protocol", INTERNET-DRAFT. Noviembre 1996.
- Mark Handley, V. Jacobson, "SDP: Session Description Protocol". RFC 2327. Abril 1998.
- N. Ishikawa, N. Yamanouchi, O. Takahashi. "IGMP Extensions for Authentication of IP Multicast Senders and Receivers", INTERNET-DRAFT. Agosto 1998.
Antonio F. Gómez Skarmeta,
skarmeta [at] dif [dot] um.esÁngel L. Mateo Martínez,
amateo [at] dif [dot] um.esFacultad de Informática
Universidad de Murcia
Pedro M. Ruíz Martínez
pedro [dot] ruiz [at] rediris.es
Aplicaciones de trabajo cooperativo
RedIRIS