A.F. Gómez Skarmeta, A.L. Mateo y P. M. Ruíz
1.- Introducción
Cuando a principios de los 90 se empezó a trabajar y diseñar con el MBone[1] (subred dentro de Internet con capacidad para trabajar con tráfico IP Multicast) se pensaba que se iba a convertir en la tecnología de red idónea para el desarrollo eficiente de servicios de audio/vídeo conferencia multipunto sobre Internet. Sin embargo, con el paso de los años se ha convertido en un servicio que todavía no ha alcanzado la madurez y popularidad necesaria para cubrir las expectativas que se tenían.
La idea fundamental que hace que el IP Multicast sea tan atractivo para desarrollar servicios de videoconferencia multipunto se basa en la utilización de direcciones IP multicast (o de grupo), en vez de las direcciones IP unicast tradicionales (que se corresponden con un único equipo de la red). Gracias a esto se tienen las siguientes ventajas:
- Optimización del ancho de banda utilizado al circular por cada enlace entre el origen y el destino(s) de datos un único paquete.
- La complejidad de la distribución a todos los destinos recae en los equipos de red y no en los equipos finales. Esto simplifica el trabajo de los mismos y los libera de carga.
Sin embargo, también presenta otras carencias, que han sido las que han limitado el crecimiento de este servicio.
Durante el resto de este artículo, vamos a hacer un repaso a los problemas que se encuentran en estos momentos y cuáles son las líneas de trabajo, tanto a nivel de red como de aplicaciones, para intentar solucionarlos.
2.- Nivel de red
El nivel de red multicast es quizás, el sector donde más trabajo se ha realizado. En estos momentos, nos encontramos ante una red formada básicamente por túneles de tipo flood and prune, lo que origina una gran fuente de problemas: los problemas de pruning. Actualmente, se está realizando la migración de estos túneles (en su mayoría DVMRP [2]) a túneles PIM/DM [3] (también de tipo flood and prune), con la intención de pasar después a enrutamiento PIM/SM [4], más eficiente, ya que se basa en la construcción de un árbol de distribución a partir de un router central.
Sin embargo, el hecho de que PIM/SM esté basado en la utilización de un router central, le hace presentar problemas de escalabilidad, impidiendo por tanto su utilización para la evolución hacia una red con IP multicast nativo. Con este último objetivo, surge la arquitectura de protocolos MASC/BGMP[5], que se basa en la misma filosofía que BGP, pero llevada a tráfico multicast.
MASC/BGMP se basa en dividir toda la red multicast en Autonomous Systems (AS). Entre los distintos AS’s que formen la red se realizará enrutamiento BGMP. Además, dentro de cada AS habrá un MAAS (Multicast Address Allocation Server), que será el encargado de obtener y repartir las direcciones multicast mediante MASC.
Otro aspecto que presenta bastantes carencias en el nivel de red multicast actual, está relacionado con el control de acceso. Actualmente no hay definido ningún mecanismo para poder controlar quién accede (para transmitir o recibir) a un determinado grupo multicast, lo que limita enormemente las posibilidades de expansión del IP multicast, sobre todo desde una perspectiva económica. Frente a este problema, solo ha surgido una propuesta basada en la extensión del protocolo IGMP[6] para permitir la autenticación de los emisores y de los receptores. Por nuestra parte, en la Universidad de Murcia nos encontramos trabajando en este problema [7] y esperamos tener dentro de poco el diseño de una solución más flexible y acorde a las propuestas de los grupos de trabajo de Internet.
3.- Nivel de aplicación
El nivel de aplicación dentro de la videoconferencia multicast es, quizás, el campo que más deficiencias presenta, pues gran parte del trabajo que se ha realizado en este campo ha estado orientado sobre todo a poder demostrar las posibilidades del IP multicast, estando la mayor parte de las aplicaciones en un estado poco evolucionado.
Las principales líneas de trabajo que nos podemos encontrar aquí son:
- Coordinación entre aplicaciones: Actualmente nos podemos encontrar con que cada aplicación realiza una única función dentro de la videoconferencia. Así, tenemos una aplicación para transmisión/recepción de vídeo, otra para audio,... Además, estas aplicaciones se encuentran totalmente descoordinadas entre sí y hacen difícil el seguimiento de una videoconferencia.
- Integración con H.323 y H.320: El IP multicast no es la única solución existente para la realización de una conferencia, sino que también se puede utilizar otros protocolos, de entre los que hay que destacar H.323 y H.320. Por lo tanto, es necesario un trabajo para conseguir la integración de los distintos abanicos de posibilidades que se le ofrecen al usuario final.
- Integración con WWW: Actualmente existe ya alguna aproximación para la resolución de este problema. Así, nos encontramos con el conjunto de aplicación mStar y sobre todo con el proyecto MASH [8], que mediante modificaciones a las aplicaciones desarrolladas en el LBL y un plugin han desarrollado un sistema para introducir toda la videoconferencia en una ventana del navegador.
- Control y administración de la conferencia : El control de una conferencia implica las tareas:
- Control del acceso de los usuarios a la conferencia.
- Gestión de flujo: determinar quién puede o no realizar una tarea en cada momento.
- Gestión de red: gestión de QoS,...
- Gestión de la metaconferencia: cómo se anuncia, cómo se inicia...
- Actualmente, ya hay definida alguna propuesta, como es el protocolo CCCP (Conference Control Channel Protocol[9]). La idea que propone es similar al Conference Bus que se utiliza entre vic y vat, pero con una estructura más generalizada. Consiste en utilizar un grupo multicast para la comunicación entre los distintos componentes de la videoconferencia. Además, aparece la figura de un agente central que es el encargado de coordinarlo todo (por ejemplo, la transmisión de vídeo no realizaría directamente por la aplicación que proporciona el vídeo, sino que ésta tendría que pedir "permiso" previamente a la transmisión).
- Calidad de Servicio: El trabajo en este área se centra fundamentalmente en la integración de RSVP en las aplicaciones y servicios multicast.
- Para finalizar y a modo de resumen, hemos realizado un repaso por los distintos aspectos que definen el "estado del arte" dentro del IP multicast y las aplicaciones MBone definiendo las características más comunes así como las líneas de trabajo actuales más importantes.
Bibliografía
- Vinay Kumar. "Mbone: Interactive Multimedia on the Internet". New Ridersk, 1996. ISBN 1-56205-397-3
- D. Waitzman, C. Partridge, S. Deering. "Distance Vector Multicast Routing Protocol". RFC 1075
- V. Jacobson, D. Farinacci, L. Wei, S. Deering, A. Helmy. "Protocol Independent Multicast Dense Mode, Protocol Specification". Internet-Draft.
- D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. "Protocol Independent Multicast-Sparse Mode (PIM-SM). Protocol Specification". RFC 2362
- S. Kumar, P. Padoslavov, D. Thaler, C. Alaettimoglu, D. Estrin, M. Handley. "The MASC/BGMP Architecture for Inter-domain Multicast Routing"
- W. Fenner. "Internet Group Management Protocol. Version 2". RFC 2236
- Antonio F. Gómez Skarmeta, Ángel L. Mateo Martínez, Pedro M. Ruíz Martínez. "Control de acceso en entornos multicast: un enfoque a la autenticación de emisores". JITEL’99
- The MASH Project Home Page. http://www-mash.cs.berkeley.edu/mash/index.html
- J. Crowcroft, M. Handley, I. Wakeman. "Internetworking Multimedia". UCL Press. http://www.cs.ucl.ac.uk/staff/J.Crowcroft/mmbook/book/book.html
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