Você está na página 1de 11

Innovacente2: Aplicacin de las comunicaciones multimedia a la innovacin docente

Jos Antonio Prez Maestre (japerez@sadiel.es), David Miguel Corts Polo (dcorpol@unex.es) y Jos Lus Gonzlez-Snchez (jlgs@unex.es) Universidad de Extremadura. Escuela Politcnica. Departamento de Informtica. Avda. de la Universidad s/n. 10071 Cceres
Resumen- En la actualidad existen mltiples plataformas de elearning, basadas en su mayora en servicios web. Sin embargo, la distribucin de informacin multimedia iscrona (audio y video), ya sea en tiempo real o en diferido, no es un mtodo implantado en la docencia. Es por esto que las tecnologas MBone (Multicast BackBone) y 6Bone pueden aportar atractivos e innovadores mtodos, adems de buenas prcticas en el mbito de la tele-enseanza que son muy interesantes ya que puede ser de clara utilidad en el ambiente universitario. Con este proyecto se intenta dar ms realismo al uso de la tecnologa Multicast dentro de la Red de la Universidad de Extremadura, realizando pruebas de campo, que nos indiquen con claridad, que el multicast se puede usar con fiabilidad para las tareas de videoconferencia y audioconferencia y descubrir las limitaciones de uso, con las que todava cuenta esta Universidad, para el desarrollo completo de actividades Multicast.

De los cambios surgidos en ese periodo, el ms significativos fue la llegada de la banda ancha a los hogares particulares, que proporcionaba la posibilidad de pensar realmente en la utilizacin de Aula Virtual por parte de los miembros de la Comunidad Universitaria, al poder contar con banda ancha en sus domicilios. Dando ms posibilidades, tambin, al uso de la comunicacin multicast, que fue el tema principal en el que se bas el Proyecto InnovaCente valorando las posibilidades de uso en los distintos tipos de redes (ADSL, RDSI, RTB, etc.), de esta tecnologa multicast.

II. OBJETIVOS Despus de repasar los antecedentes de los que parte el proyecto, podemos realizar una descripcin ms precisa de este proyecto InnovaCente2. Es importante delimitar el contenido del proyecto para saber establecer el objetivo principal del mismo, objetivos secundarios y el resto de aspectos ms superfluos para llegar a fijar la frontera entre lo que es necesario en el Proyecto, y lo que es atractivo e interesante, pero apartado del mismo. El objetivo principal del Proyecto InnovaCente2 es implantar un sistema de comunicacin multicast que cubra la red de la Universidad de Extremadura, y probar sus efectos sobre el resto de comunicaciones realizadas sobre la misma red, as como probar el rendimiento y posibilidades reales del trfico multicast en la infraestructura actual de la UEx. Para conseguir este objetivo hay que: 1. Obtener, instalar y configurar las herramientas necesarias para desarrollar un sistema de comunicacin con direccionamiento multicast. Es necesario el estudio de: - las diferentes herramientas de comunicacin multicast desarrolladas por Universidades y organizaciones informticas sin nimo de lucro. - la comunicacin multicast, funcionamiento de los routers de direccionamiento, etc.

Palabras Claves Multicast, MBone, Innovacin docente, videoconferencia, trfico iscrono y multimedia

I. INTRODUCCIN 1. Antecedentes

n este proyecto trataremos un tema con una gran herencia dentro de la Escuela Politcnica de Cceres en la Universidad de Extremadura, el tema de la educacin a distancia o tele-educacin. El proyecto Aula Virtual Multimedia documentaba la instalacin de la infraestructura necesaria para poner en marcha Aula Virtual en la Escuela Politcnica de Cceres. Tambin describa las herramientas a utilizar y realizaba una propuesta de protocolo de flujos hbridos. El proyecto Innovacente pretenda complementar el proyecto Aula Virtual abordando temas no tratados relacionados con el consumo de ancho de banda, posibilidades de utilizacin, planificacin de sesiones; as como reorientar Aula Virtual adaptndolo a los cambios surgidos en el periodo de tiempo que separaba la realizacin de los dos proyectos.

- la construccin de tneles multicast/unicast para poder trabajar con los routers unicast. 2. Medir el trfico multicast generado por un conjunto de aplicaciones que permiten realizar actividades de trfico multicast. Es necesario el estudio de: - la arquitectura de la red de la Escuela Politcnica, la comunicacin entre las salas y el estudio de la red de la Universidad de Extremadura. - las diferentes herramientas de medicin de trfico existentes, instalacin y configuracin de las mismas. 3. Establecer los parmetros de Calidad de Servicio a tener en cuenta. Es necesario: - el estudio de la definicin de Calidad de Servicio para las diferentes redes de comunicacin y el establecimiento de los diferentes parmetros. - realizar pruebas de comunicacin con diferentes valores en los parmetros de calidad de servicio para establecer los adecuados, as como los mnimos exigibles. 4. Establecer el uso que es posible realizar de la comunicacin multicast en la Universidad de Extremadura sin que haya una prdida de Calidad de Servicio en las comunicaciones que circulan por la misma red. Es necesario: - el estudio de la posibilidad de planificar las sesiones de la comunicacin multicast, realizndolas en los momentos de menor utilizacin de la Red por el resto de usuarios. - establecer de una forma clara los parmetros de medicin de la Calidad de Servicio. - definir nuevos modos de funcionamiento de Aula Virtual. El presente proyecto ha establecido los siguientes objetivos secundarios: - Ampliar los conocimientos en protocolos de comunicacin unicast/multicast, en redes de computadores, en configuracin de herramientas de comunicacin y en Sistemas Operativos Unix/Linux. - Desarrollar de forma completa un Proyecto siguiendo todos los pasos del Ciclo de Vida Estructurado, afrontando problemas reales, limitaciones de hardware, de tiempo, etc.

1. Laboratorio de Telemtica El Laboratorio de Telemtica (Figura 1) est formado por un nmero aproximado de 10 puestos, siendo actualmente uno de ellos servidores, Patanegra. De ellos 4 suelen ser porttiles (como el usado en este proyecto). En este laboratorio todos los puestos tienen una asignacin de direcciones IP dinmicas, mediante DHCP. A pesar de esta asignacin dinmica, en realidad todos los puestos tienen siempre la misma direccin IP, pues el servidor siempre que haya direcciones IP libres para utilizar tiene una tabla de referencias entre la direccin fsica de cada tarjeta y la direccin IP que le corresponde. As el puesto del porttil de InnovaCente2 tiene la direccin IP 158.49.122.154, y el puesto de josecasa tiene la direccin IP 158.49.125.108. La mscara de red de los puestos de la Sala es 255.255.240.0. Los equipos de Telemtica en la actualidad no forman ninguna subred, de manera que utilizan direcciones IP sin un control especfico, y tienen acceso a los mensajes de broadcast emitidos por toda la red de la Escuela Politcnica. Esto se debe a que los equipos estn conectados formando una VLAN o LAN Virtual. Este hecho impide una buena gestin y control del trfico, pues dificulta mucho el anlisis del mismo. La red actual es de 10 megabits por segundo desde cada puesto a cada conmutador. La topologa de este laboratorio es en estrella.

III.

DESARROLLO

Para el desarrollo de este proyecto primero tenemos que conocer in situ de la infraestructura de la universidad, es por esto que se ha optado por desarrollar un pequeo anlisis de la topologa, de dentro hacia fuera; es decir, se describe la red del Laboratorio de Telemtica, las redes de las diferentes Salas, las conexiones entre ellas, la conexin de todas ellas en la Escuela Politcnica, la topologa del Campus, la Red de la Universidad de Extremadura y la salida de esta red hacia la conexin a Internet.

Figura 1: Esquema del laboratorio

2. Sala GIS La sala GIS (figura 2) est formada por un nmero aproximado de 25 puestos. En la Sala Lupe todos los puestos tienen una asignacin de direcciones IP dinmicas, mediante DHCP. Los equipos de la Sala GIS en la actualidad no forman ninguna subred, de manera que utilizan direcciones IP sin un control especfico, y tienen acceso a los mensajes de broadcast emitidos por toda la red de la Escuela Politcnica. Esto se debe a que los equipos estn conectados formando una VLAN o LAN Virtual. Este hecho impide una buena gestin y control del trfico, pues dificulta mucho el anlisis del mismo. La red actual es de 10 megabits por segundo desde cada puesto a cada conmutador, mientras que los conmutadores estn conectados entre s y a la red del edificio a 100 megabits por segundo. 3. Sala Sun La sala SUN (figura 3) est formada por un nmero aproximado de 19 puestos. En esta todos los puestos tienen una asignacin de direcciones IP dinmicas, mediante DHCP. La red actual es de 10 megabits por segundo desde cada puesto a cada conmutador, mientras que los conmutadores estn conectados entre s y a la red del edificio a 100 megabits por segundo. 4. Sala Norba La sala Norba (figura 4) est formada por treinta puestos conectados mediante una red Ethernet a 100 Mbps, cuya electrnica est compuesta por conmutadores no gestionables. Adems, posee un router con dos interfaces Ethernet, uno conectado a la subred de la sala, cuya IP es 158.49.98.62, con mscara de red 255.255.255.192; y otro conectado a la red Ethernet del edificio, cuya direccin IP es 158.49.114.208 y su mscara de red es 255.255.240.0. Los puestos de esta sala tienen IPs pblicas, con nmeros comprendidos entre el 158.49.98.1 para el puesto 1 y el 158.49.98.30 para el puesto 30. La mscara de red correspondiente a estos puestos es 255.255.240.0, y la direccin de broadcast de la subred es 158.49.98.63.

5. Sala Novell La sala Novell (figura 5) est formada por treinta puestos conectados mediante una red Ethernet a 100 Mbits cuya electrnica est compuesta por conmutadores no gestionables. La red de la sala Novell tienen direccin IP 158.49.98.64, formando una subred que agrupa a los treinta puestos, que tienen tambin IPs pblicas, con nmeros comprendidos entre el 158.49.98.71 para el puesto 1 y el 158.49.98.100 para el puesto 30. La mscara de red de los puestos es 255.255.255.192. Al igual que la sala Norba posee un router con dos salidas Ethernet, una hacia la subred de la sala, con direccin IP 158.49.98.64 y mscara de red 255.255.255.192, y otra hacia la red del edificio, con direccin IP 158.49.114.21, y mscara de red 255.255.255.192.

Figura 2: Esquema de la sala GIS

Figura 4: Esquema de la sala Norba

Figura 3: Esquema de la sala Sun

De igual forma se encuentra la arquitectura del resto de pabellones de la Escuela Politcnica. Todos estos routers se unen en otro que es el que gestiona todas las comunicaciones de entrada y salida de la Escuela Politcnica con la sede de Infraestructuras en la Facultad de Derecho. 7. Campus de Cceres La Escuela Politcnica est unida al campus de Cceres con una conexin a 155 Megabits, mediante Fibra ptica configurada como ATM. Las conexiones del campus de Cceres tienen una topologa de estrella, de tal forma que cada una de las facultades tiene una conexin individual mediante Fibra ptica hasta la sede del Servicio de Infraestructuras situado en la Facultad de Derecho.
Figura 5: Esquema de la sala Novell

6. Escuela Politcnica La red existente en el pabelln de Informtica es una Ethernet de 100 Mbits. La red tiene una topologa de estrella, encontrndose el centro de la misma en la pequea habitacin situada en la parte derecha de la entrada al pabelln desde cafetera en la planta baja; mientras que en la parte izquierda se encuentra el ascensor. Aqu se localiza un router Cabletron Smart Switch 6.000. Este router est formado por varios mdulos, conectados entre s por cables de fibra ptica, y a donde llegan las conexiones de los diferentes despachos, salas y aulas. Por fibra ptica llega la conexin desde el router ATM Alcntara.

Figura 7: Topologa del pabelln de informtica

Figura 6: Pabelln de informtica

Figura 8: Topologa del campus universitario de Cceres

8. Universidad de Extremadura Desde aqu toda la informacin pasa por un Cabletron Smart Switch 10.000, que se encarga de enviarla hacia la sede del Servicio de Infraestructuras de la Universidad de Extremadura de Badajoz, que cuenta con otro modelo similar. La conexin que actualmente existe entre Cceres y Badajoz es una conexin dedicada proporcionada por Telefnica de 150 Megabits por segundo, compartida para Investigacin + Desarrollo y Gestin, los dos departamentos independientes que existen. El servidor Tajo acta como servidor DNS, servidor de correo electrnico y servidor de noticias. La conexin de los cuatro campus que forman la Universidad de Extremadura no tiene topologa de estrella. Aunque no se conoce exactamente la conexin de estos campus, pues est contratada a Telefnica que es la que se encarga de proporcionar el servicio y de mantener las centrales de conmutacin, seguramente el campus de Plasencia se une a la Red de la Universidad por el campus de Cceres, mientras que el campus de Mrida se une a la Red de la Universidad por el campus de Badajoz. La conexin entre la red troncal, Plasencia y Mrida es una lnea dedicada de 2 Megabits por segundo. Una vez que hemos estudiado el entorno en el que nos movemos vamos a ver los programas usados para el anlisis. Primero hay que decir que el software usado para la transmisin multicast de contenidos es VLC, separndonos un poco de las clsicas aplicaciones de MBone, en este proyecto vamos a hacer uso de una herramienta perteneciente al proyecto VideoLAN, VLC. Una aplicacin que utilizaremos para reproducir vdeo y audio, emitir y recibir tambin, a travs de l, vdeo y audio en videoconferencia y audioconferencia como trfico multicast, reproducir de forma remota vdeos grabados anteriormente, etc. Ser nuestra principal herramienta de trabajo para realizar multicast. Para el anlisis vamos a usar la herramienta ourmon, que es una herramienta desarrollada para el filtrado y captura de paquetes en modo promiscuo en primer lugar, y el anlisis y la obtencin de grficas con estos anlisis en segundo lugar. Esta aplicacin tiene una arquitectura que est formada por dos partes bien diferenciadas: una primera escrita en C que se encarga de la captura de los paquetes que respondan a determinados filtros configurados, y la modificacin de un fichero contador de los mismos; y una segunda escrita en PERL y que utiliza la herramienta RRDtool para la creacin de las grficas con los resultados obtenidos.

todo el mundo, dentro de GNU bajo licencia GPL (General Public License). VideoLAN est diseado para transmitir vdeo MPEG en redes con gran capacidad de ancho de banda. La solucin VideoLAN incluye: VLS (Servidor VideoLAN), el cual puede transmitir archivos MPEG-1, MPEG-2 y MPEG-4, DVDs, canales digitales de satlite, canales digitales de televisin terrestre y vdeo en vivo sobre la red en unicast o multicast. VLC (inicialmente Cliente VideoLAN), el cual puede ser usado como servidor para transmitir archivos MPEG-1, MPEG-2 y MPEG-4, DVDs y vdeo en vivo sobre la red en unicast o multicast; o usado como cliente para recibir, decodificar y visualizar flujos MPEG sobre varios sistemas operativos. A continuacin se muestra una ilustracin de la solucin VideoLAN completa: VLC trabaja sobre muchas plataformas: Linux, Windows, Mac OS X, BeOS, *BSD, Solaris, Familiar Linux, Yopy/Linupy y QNX. Puede leer: -Archivos MPEG-1, MPEG-2 y MPEG-4 / DivX desde un disco duro, un CD-ROM,... -DVDs y VCDs, desde una tarjeta receptora de satlite (DVB-S), -Flujos MPEG-1, MPEG-2 and MPEG-4 desde la red enviados por la salida de VLS o VLCs. VLC tambin puede ser usado como servidor para transmitir: -Archivos MPEG-1, MPEG-2 y MPEG-4 / DivX, DVDs, Desde una tarjeta codificadora MPEG, a un destino como: Una direccin IP normal, esto es lo que se llama unicast, un grupo dinmico de mquinas a las que el cliente puede conectarse o desconectarse (por ejemplo a una direccin IP multicast), esto es lo que se llama multicast, en IPv4 o IPv6.

Figura 9: Solucin VideoLAN

IV. VIDEOLAN, VLC 1. Proyecto VideoLAN VideoLAN es una solucin de software completa para transmisin de vdeo, desarrollada por estudiantes de cole Centrale Paris (http://www.ecp.fr) y desarrolladores de

2.

VLS

VLS puede transmitir: -Un fichero MPEG-1, MPEG-2 o MPEG-4 almacenado en un disco duro, un CD,..., -Un DVD insertado en un lector de DVD, o copiado en un disco duro, -Transmisiones digitales satelitales (DVB-S) o terrestres (DVB-T) Una tarjeta codificadora MPEG; a un destino como: Una mquina (p.e. a una direccin IP), esto es lo que se llama unicast, un grupo dinmico de mquinas a las que el cliente puede conectarse o desconectarse (p.e. a una direccin IP multicast), esto es lo que se llama multicast, en IPv4 o en IPv6. Un Pentium a 100 MHz con 32 MB de memoria debera ser suficiente para enviar un flujo a la red. Cuando se transmiten muchos vdeos almacenados en un disco duro, la limitacin no es el procesador sino el disco duro y la conexin de red. 3. Mini-SAP-Server

los valores de las ltimas dos horas, el ltimo da, la ltima semana, el ltimo mes y el ltimo ao. El script de perl recoge los datos del fichero fuente mon.lite, que tiene el siguiente formato: El script de perl busca cadenas de caracteres idnticas a pkts, fixed_ipproto..., capturando los valores que indica separados por el identificador :, y comprobando los ndices a los que corresponde. De esta manera, en los paquetes (pkts) se comprueban los paquetes recibidos por cada uno de los interfaces y los paquetes eliminados, en los protocolos IP (fixed_ipproto) se comprueban los paquetes del protocolo tcp, udp, icmp y xtra. Y as de manera sucesiva (ver figura 10) Con el objetivo de impedir posibles errores en la toma de los datos por lentitud de la mquina en la realizacin de los clculos necesarios, se realiza una copia del fichero mon.lite en otro directorio, para que el ejecutable que cuenta los paquetes pueda modificarlo; y el script toma los datos, realiza la diferencia con los datos del fichero anterior, que se almacenan en otro fichero; y almacena estos valores actualizando las bases de datos.

Se puede aadir informacin de servicio a un canal basado en el estndar SAP/SDP para la solucin VideoLAN. El miniservidor-SAP enva anuncios acerca de los programas multicast en la red en IPv4 o IPv6, y VLC recibe estos anuncios y automticamente aade los anuncios de programas a su lista de reproduccin.

VI. ESTUDIO PRCTICO. RESULTADOS Esta aplicacin ha sido creada para servir de base terica y prctica para el estudio de las aplicaciones MBone y as poder comprobar que la herramienta funciona segn lo esperado y acorde con los estndares. Para entender correctamente estas pruebas hay que tener en cuenta el espacio en el que nos estamos moviendo, es decir, en un entorno no orientado a aplicaciones multicast, compartido con muchos otros usuarios, en el que este tipo de trfico est cortado por los problemas que puede generar y en el que en la mayora de los casos no se pueden crear unos escenarios de pruebas contundentes ya que al problema de los filtros con este tipo de trfico hay que aadir que las mquinas con las que se cuenta, no son todo lo potentes que se necesitan para poder visualizar vdeo y audio en tiempo real con demasiada fluidez.

V. OURMON El programa Ourmon se encuentra ya en una fase estable de desarrollo y es de cdigo libre. Creada por Jim Binkley y Sun Nan pertenecientes a la Portland State University, pretende posibilitar el estudio de la red con equipos PC, consiguiendo analizadores del estado de LAN's y WAN's. Ourmon utiliza las libreras pacp para capturar los paquetes de la tarjeta ethernet en modo promiscuo (pueden capturarse paquetes de un mximo de dos dispositivos a la vez). Este programa realiza los siguientes anlisis: - Tipos de paquetes capturados. - Protocolo de transporte utilizado por los paquetes IP, que puede ser TCP, UDP, paquetes ICMP y otros paquetes que entran en la categora de xtra. - Circulacin de paquetes en determinados puertos de TCP. - Circulacin de paquetes entre dos direcciones IP determinadas. - Direccionamiento de los paquetes ip: unicast, multicast, broadcast. - Tamao de los paquetes, clasificndolos en pequeos, medianos y grandes. Estos datos se representan utilizando el software RRDtool, trayendo el Ourmon el fichero perl necesario para la creacin de grficas con los datos del ltimo da, la ltima semana, el ltimo mes y el ltimo ao; y que se ha modificado para tener

Figura 10: Formato del fichero de entrada mon.lite del script del ourmon

1.

Prueba 1 Trafico local

El primer caso que se plantea en este estudio prctico es el anlisis de una transmisin en la sala Novell. Al usar esta sala, se tuvo acceso a un mayor nmero de ordenadores que actuaron como receptores. La prueba consisti en la emisin de vdeo, capturado por webcam, en tiempo real, en la que existan veinticuatro receptores. Los receptores no se unieron a la sesin al mismo tiempo, sino que lo hicieron uno a uno con un tiempo de espera estipulado. El emisor se ejecut bajo Linux Debian, pero los veinticuatro ordenadores receptores de la sesin trabajaron bajo Sistema Operativo Windows XP. La transmisin se realiz a travs de una sesin multicast con direccin IP 231.231.231.231 y puerto 1234. La prueba se desarroll entre las 17:30 y las 20:10, con una duracin total de 2 horas y 40 minutos. Se instal en los receptores la versin de VLC para Windows, descargada de la pgina web de VideoLAN. Este fue el desarrollo de la prueba:
17:30-> Se pone en marcha el 1 receptor. 17:35-> Se pone en marcha el 2 receptor. 17:45-> Se pone en marcha el 3 receptor. 17:50-> Se pone en marcha el 4 receptor. 17:55-> Se pone en marcha el 5 receptor. 18:01-> Se pone en marcha el 6 receptor. 18:10-> Se ponen en marcha el 7 y 8 receptores. 18:13-> Se pone en marcha el 9 receptor (este ordenador, igual que alguno otro, se ejecuta lentamente. Parece a causa de poca memoria libre por estar muy cargado de programas instalados y de su configuracin). 18:25-> Se ponen en marcha el 10, 11 y 12 receptores. 18:35-> Se ponen en marcha el 13, 14 y 15 receptores. 18:48-> Se ponen en marcha el 16, 17 y 18 receptores. 19:04-> Se ponen en marcha el 19 y 20 receptores. 19:12-> Se ponen en marcha el 21, 22, 23 y 24 receptores. **************** 24 equipos clientes y porttil servidor de VLC multicast en ip 231.231.231.231 19:35-> cierro 6 equipos clientes y quedan 18 como receptores 19:46-> cierro 12 equipos clientes y quedan 6 como receptores 19:57-> cierro 5 equipos clientes y queda solo 1 como receptores 20:08-> cierro el ltimo cliente y ya nadie queda como receptor. 20:10->dejo de transmitir con el porttil Figura 11: Comparativa de protocolos

Figura 12: Comparativa Multicast, Unicast

Primero vamos a analizar la grfica de los protocolos de esta manera tenemos que tener en cuenta que la prueba se realiz en la Sala Novell, donde existe una subred que permanece aislada, pero no exenta, del trfico que confluye en el resto de la red. Es por ello por lo que la grfica no recoge ningn tipo de trfico TCP, sino que las comunicaciones que se registran son nicamente las generadas por la sesin multicast, en UDP. Si ahora estudiamos las transmisiones multicast podemos ver Lo ms caracterstico es la inmediata subida del valor del consumo de ancho de banda a su media habitual, alrededor de 700 Kbits/s, nada ms iniciar la sesin con un receptor, quedndose constante hasta la unin sucesiva de ms receptores. Despus, con la suma de receptores no se incrementa exponencialmente el consumo de ancho de banda, sino que se mantiene oscilando entorno a la media. No obstante, el perfil abandona su homogeneidad para presentar picos, mximos y mnimos, causados presumiblemente por el aumento de las tareas que la red adquiere con cada unin o abandono de la sesin. Como conclusin podemos aportar que el trfico multicast de la transmisin no aumenta a causa del elevado nmero de receptores, mantenindose en unos ratios similares durante toda la prueba, que no superan los 870Kbits/s, y rondando siempre la media de los 600 kbits/s. Estos ratios para una transmisin de vdeo a veinticuatro receptores, aunque sea con el formato MPEG-4, hacen ver el buen funcionamiento del protocolo multicast. Aunque, en esta ocasin, las grficas muestran un flujo con ms sierras y no tan llano, parece afectarlas la constante

Las grficas resultantes de esta transmisin son las siguientes:

actividad de los anuncios SAP y comandos de unin a la sesin multicast realizada. 2. Prueba 2 Varios equipos emisores y receptores de trafico

En esta prueba vamos a ver como reacciona la red ante varias emisiones a la vez. Esta prueba, realizada en el Laboratorio de Telemtica, consisti en la creacin de tres sesiones multicast dentro de la misma sala. Se usan tres equipos, y cada uno de ellos emite una sesin multicast, a la vez que hacen de receptor de las otras dos sesiones. Dos de los equipos se ejecutaron bajo Sistema Operativo Linux Debian, y el tercero se ejecuto bajo Linex. La transmisin se realiz a travs de tres sesiones multicast, con las siguientes direcciones IP: 231.231.231.231, 232.232.232.232 y 233.233.233.233. Este fue el desarrollo de la prueba:
12:32-->empieza a emitir porttil la sesin 1 12:33-->empieza a recibir josecasa la sesin 1 12:34-->empieza a recibir agila la sesin 1 12:41-->empieza a emitir josecasa la sesin 2 12:42-->empieza a recibir porttil la sesin 2 12:44-->empieza a recibir agila la sesin 2 12:48-->empieza a emitir agila la sesin 3 12:49-->empieza a recibir porttil la sesin 3 12:51-->empieza a recibir josecasa la sesin 3 NOTA***todo ok, nica observacin es que josecasa a pequeos momentos no es capaz de procesar las 2 pelculas que le toca recibir a la perfeccin y a veces parecen fotogramas sueltos pero recibe ok 13:05-->apagamos todos

Figura 13: Comparativa de protocolos

Figura 14: Comparativa Multicast, Unicast

En estas pruebas se observa mejor el aumento del trfico ocasionado por cada una de las sesiones. A pesar de que esta prueba se realiz en el Laboratorio de Telemtica, si comparamos por protocolos usados, no aparece ms que pequeos trficos de TCP, y no se observa que en ese momento hubiese gran cantidad de trfico ajeno a la prueba. Por lo tanto, la nica lnea protagonista es la del consumo de ancho de banda en UDP generada por nosotros, que llega a alcanzar los 3 Mbits/s, a causa de las tres sesiones activas. Si nos fijamos en la figura 14, lo ms importante a rescatar es el incremento en el consumo de ancho de banda acaecido en cada una de las creaciones de las tres sesiones multicast abiertas, y que terminan conviviendo en el tiempo. Por eso se denotan los tres niveles en aumento desde el principio de la prueba. Por otro lado, tambin aumenta en nmero de receptores, pero esto, como ya se ha observado en las pruebas anteriores, no afecta al ancho de banda. De tal manera que a modo de conclusin Los tres escalones que se forman en la grfica, nos hacen ver cmo, segn se abre una sesin, el trfico multicast suma el ratio de transmisin de esa comunicacin. Esto nos permite comprobar que la apertura incontrolada de diferentes sesiones multicast, con coste alto de ancho de banda (por ejemplo, esta transmisin de vdeo), provocara cuellos de botella en la red. Pero mientras la red tenga suficiente ancho de banda, las comunicaciones no se interrumpen para nada unas a otras, pudiendo disfrutar de esas sesiones multicast con calidad perfecta.

Los tres equipos usados fueron: El porttil con direccin IP 158.49.122.154, emitiendo por la direccin multicast IP 231.231.231.231 un vdeo grabado en formato DIVX. El ordenador josecasa con direccin IP 158.49.125.108 emitiendo por la direccin multicast IP 232.232.232.232 una videoconferencia captada con la webcam en tiempo real. El ordenador Agila con direccin IP 158.49.122.107 emitiendo por la direccin multicast IP 233.233.233.233 un vdeo grabado en formato DIVX. Las grficas en las que se presentan los resultados fueron obtenidas con la herramienta Ourmon. Los resultados de esta prueba son los que se presentan a continuacin:

La prueba nos demuestra la posibilidad de tener ms de una sesin abierta en una mquina, con el nico lmite que pongan los recursos hardware del sistema. 3. Prueba 3 Trfico en diferentes edificios del campus

Como se puede ver en las dos grficas la sesin multicast UDP registrada, tiene las misma caractersticas de buen funcionamiento, ya explicadas anteriormente. Y se observa tambin que cuando a tenido que circular trfico TCP, ajeno al generado por nosotros, lo realiza sin inconvenientes. En esta prueba se denota que existe la posibilidad de utilizar sistemas de comunicacin multicast entre estos dos centros del campus. Dejando ver que las videoconferencias y las audioconferencias se pueden realizar con xito a travs de trfico multicast. La infraestructura de la red es suficiente para abordar estas tareas multicast con xito. Y sigue demostrndose que sesiones individuales no afectan al resto del trfico que coexiste en la red. 4. Prueba 4 QoS en el trfico entre diferentes edificios del campus

La realizacin de esta prueba consisti en la creacin de una sesin multicast, donde se emite vdeo, en tiempo real, capturado por una webcam. La prueba se realiz entre un emisor localizado en el Laboratorio de Telemtica de la Escuela Politcnica, y un receptor colocado en la sala de libre acceso de la Facultad de Filosofa y Letras. Estas dos facultades pertenecientes al campus universitario de Cceres. En esta prueba, tanto el emisor como el receptor se ejecutaron bajo Sistema Operativo Linux Debian. La comunicacin se mantuvo 30 minutos, entre las 11:32 y las 12:02 del da 13 de Julio de 2005 La transmisin se realiz a travs de una sesin multicast abierta en la direccin IP 231.231.231.231 y puerto 1234. Las grficas en las que se presentan los resultados fueron obtenidas con la herramienta Ourmon, en la mquina receptora. Los resultados de esta prueba son los que se presentan a continuacin:

En este apartado, se van a comentar las mediciones hechas para intentar analizar la Calidad de Servicio. Para ello, las pruebas se realizan en los enlaces usados para las comunicaciones, llevadas a cabo en las pruebas del sistema multicast. Estas se efectan ejecutando los scripts, creados en este proyecto, para el estudio de la Calidad de Servicio. La prueba consisti en un emisor que ejecut, en dos ocasiones, los scripts de anlisis, pasando por parmetro la direccin IP de un receptor: La primera, mientras se emite una sesin multicast de videoconferencia del emisor al receptor. La segunda, sin sesin multicast, entre emisor y receptor. En este caso el emisor se encontraba en la sala de libre acceso de la Facultad de Filosofa y Letras, y el receptor se encontraba en el Laboratorio de Telemtica de la Escuela Politcnica. El emisor fue el porttil, con la direccin IP 158.49.122.154, y con el Sistema Operativo Linux Debian.

Figura 15: Comparativa de protocolos

El receptor fue el ordenador josecasa, con la direccin IP 158.49.125.108, y con el Sistema Operativo Linux Debian. Las grficas en las que se presentan los resultados fueron obtenidas con los scripts de anlisis. Estas grficas representan un minuto de tiempo, en el que se recogen los datos expuestos. Los resultados de esta prueba son los que se presentan a continuacin. Con sesin multicast:

Figura 16: Comparativa Multicast, Unicast

sistema, debido a la falta de depuracin de los enrutadores multicast, y a la falta del hardware requerido para su adecuado funcionamiento. De este modo, ocurran casos en los que por un puesto existan hasta 10 tneles software multicast, lo que provocaba un enorme cuello de botella y amplios retardos. Viendo estos inconvenientes, se tom la decisin de modificar las caractersticas ms problemticas. Esto no supone que el MBone fuera un fracaso, pues la mayora de sus sistemas y protocolos eran excelentes, como el protocolo H.261 usado por netmeeting. Solamente se observ, que el diseo desarrollado para arreglar las dificultades tcnicas que existan, funcionaba adecuadamente pero con limitaciones que se estaban rebasando. En este periodo, el MBone est en una fase de espera, mientras los usuarios y servidores van adaptando sus sistemas hardware. Se ha desestimado la posibilidad de enrutadores multicast software, a causa de la amplia construccin de tneles, que estimulaban la inundacin del sistema con paquetes, la presencia de retardos grandiosos y numerosos cuellos de botella. Se ha optado como modelo la existencia de enrutadores multicast hardware, suplantando los enrutadores unicast por enrutadores multicast. La eleccin del cambio se asienta, adems, en la renovacin que es indispensable hacer para usar el nuevo protocolo IP v.6, ms adecuado al uso que se est haciendo del conjunto de protocolos TCP/IP que el protocolo IP v.4 usado. Asimismo, el algoritmo de enrutamiento multicast tambin se ha modificado, pasando del DVMRP, algoritmo tipo dense, al PIM-SM, algoritmo tipo sparse, El cual impide la obligacin de efectuar peridicamente inundaciones de paquetes para reconfigurar e ir adecuando el rbol de usuarios multicast; y se adapta mucho mejor a sistemas con muchas subredes o ramas del rbol, y pocos usuarios en cada rama; configuraciones ms usuales en las comunicaciones multicast. Actualmente, la Universidad de Extremadura se encuentra a mitad de camino para adaptarse al cambio, con enrutadores hardware con direccionamiento multicast y PIM-SM. Por el contrario RedIris, que se encarga de proporcionar Internet a la Universidad de Extremadura y de comunicarla con el resto de las Universidades, ya est adaptada al cambio. Pero los principales, los Proveedores de Servicios de Internet (ISP), que trabajan con la red pblica de comunicaciones, y que proporcionan comunicacin a cada particular, an estn atrasados del todo. Todava permanecen los enrutadores que solamente abordan direccionamiento unicast. La convivencia entre estos dos sistemas es imposible de llevar a cabo, puesto que un sistema de enrutamiento multicast no funciona existiendo otro sistema de enrutamiento que encamina los paquetes de otra manera. Esto hace que no funcione el enrutador mrouted, de modo que construye el tnel pero no encamina los paquetes por l, pues estos paquetes con direccionamiento multicast son procesados por el router de la Universidad; y el mrouted, al hallar un sistema que procesa los paquetes, no utiliza el tnel. Este inconveniente provoca que no sea posible establecer

Figura 17: QoS con una sesin multicast abierta

Sin sesin multicast

Figura 18: QoS sin sesiones multicast abiertas

Como concusin podemos aadirla observacin de que las sesiones multicast creadas no provocan aumentos en lo retados, mantenindose prcticamente los mismos valores medios, tanto en la ejecucin con multicast como en la ejecucin sin multicast. Durante las sesiones multicast se producen unos picos en los retardos, ms frecuentes que en la medidas tomadas sin las sesiones. Estos picos pueden venir provocados por la gran carga de trfico UDP a causa de las sesiones multicast. Pero en general son valores realmente bajos, que llevan a la conclusin de que la infraestructura de la red, que da soporte a esta comunicaciones, aborda sin problemas, y sin causar retardos ni cuellos de botella, las sesiones multicast que se deseen realizar a travs de ella. Los valores de la desviacin media de los retardos, recogidos en las grficas, nos hace observar que el jitter debe ser bastante bajo, cosa que beneficia a las comunicaciones multimedia. VII. CONCLUSIONES La tcnica de direccionamiento multicast constituye un sistema de comunicacin conveniente para retransmisiones de uno a muchos. Las posibilidades ofrecidas por este sistema generaron una enrgica expansin de la tecnologa MBone, nacida en 1.996, en el periodo de 1.998 y 1.999. En principio, MBone era una tecnologa que estaba en un periodo de prueba, y se pretenda analizar las consecuencias de esta en las redes existentes. As, los resultados positivos, y las perspectivas, llevaron a cabo una expansin que no estuvo acompaada de un ordenamiento adecuado. Esto caus numerosos errores en el

comunicacin multicast con ninguna herramienta todava entre la Escuela Politcnica y un usuario particular en su casa. Por el contrario, queda probado que el sistema de comunicacin multicast es factible en el campus de Cceres, donde su uso no da problema alguno. Adems, sin la necesidad de crear tneles. La infraestructura es la adecuada para disfrutar de videoconferencias y audioconferencias en sesiones Multicast. As, se puede dar paso ya a su utilizacin en casos reales, pero sin salir del mbito Universitario. El objetivo de Aula Virtual de que los usuarios puedan recibir el servicio de la comunicacin multicast desde sus casas, no es posible en la actualidad. Sin embargo es un paso muy corto el que falta por dar, y ya no esta en nuestra manos, sino en la de los Proveedores de Servicios de Internet, que necesitan encontrar un modo de facturar el trfico multicast, antes de poder comercializarlo, algo que todava no saben cmo hacer. VIII. LNEAS DE INVESTIGACIN FUTURAS En estos momentos no es posible realizar comunicaciones multicast entre los particulares y los centros universitarios, que es parte del objetivo de Aula Virtual. Pero la modificacin de los sistemas hardware de enroutamiento nos da a entender que no a mucho tardar, estas comunicaciones podrn tener lugar. Para ello, ser necesario redefinir este proyecto y adaptarlo a los resultados de estos nuevos logros tecnolgicos. Por otro lado, la Red de la Universidad de Extremadura, todava no est capacitada para abordar el uso del nuevo protocolo IPv6. No obstante este protocolo se va a imponer (o ya esta empezando a hacerlo), por lo que la universidad se deber de adaptarse de manera obligatoria en un breve espacio de tiempo. Esto proporcionar sistemas de control de QoS, que permitirn la realizacin de estudios exhaustivos sobre la calidad del servicio ofrecido por la red. Adems, hemos comentado la posibilidad de usar ya esta tecnologa, en actividades de mbito interno universitario. Y esto abre la puerta a mltiples tareas, en las que se desarrollen mtodos de aprovechamiento por parte de la Universidad de Extremadura. Para la elaboracin de estos nuevos proyectos proponemos, no solo la participacin de los becarios y alumnos de proyecto fin de carrera, sino inclusive la de los profesores y el personal administrativo. Tambin, existe un amplio mundo de posibilidades en el mbito de las comunicaciones inalmbricas, donde todo el trabajo de los sistemas multicast est por hacer. Adems, la Escuela Politcnica dispone actualmente de una red inalmbrica, por lo que las bases en las infraestructuras ya estn proporcionadas. Incluso las redes inalmbricas, en muchas ciudades, ya empiezan a ser realidad, y el acceso de los usuarios particulares a las sesiones multicast pronto estarn tan cerca como lo estn por cable. Igualmente, es necesario transportar los sistemas de comunicacin multicast con software libre a otras arquitecturas de computadores.

IX. BIBLIOGRAFA [1] G. Snchez Gutirrez, E. Mancha Gonzlez. Innovacente: Implantacin de Trfico Multicast en la Innovacin Docente. Proyecto de Fin de Carrera. Curso 2.002/03. Ingeniera Informtica. Escuela Politcnica de Cceres. Universidad de Extremadura. [2] M. Banikazemi, IP Multicasting: Concepts, Algorithms, and Protocols.http://www.cis.ohio-state.edu/~jain/cis78897/ip_multicast/index.htm. Julio de 2.000. [3] Manual de RRDTool. http://people.ee.ethz.ch/~oetiker/webtools/rrdtool. [4] J. Binkley, S. Nan, "OURMON: technical explanation". http://ourmon.cat.pdx.edu/ourmon/info.html. Febrero 2.002. [5] Alexis de Lattre, Anil Daoud, Benjamin Pracht, Clment Stenac, VLC Play Howto.pdf, www.videolan.org, , 2.004. [6] D. Waitzman, C. Partridge, S. Deering, Distance Vector Multicast Routing Protocol. Internet Request for Comment. RFC 1.075. Noviembre de 1.988. [7] D. Estrin, D. Farinacci, A. Helmy, D. Thales, S. Deering, M. Handley, V. Jacobson, C. Lin, P. Sharma, L. Wei, Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification. Internet Request for Comment. RFC 2.362. Junio de 1.998. [8] D. Thales, Interoperability Rules for Multicast Routing Protocols. Internet Request for Comment. RFC 2.715. Octubre de 1.999. [9] J. Moy, Multicast Extensions to OSPF. Internet Request for Comment. RFC 1.584. Marzo de 1.994. [10] QoS en Aplicaciones Cliente-Servidor. Grupo de Comunicaciones en Banda Ancha y Sistemas Distribuidos. Departamento de Electrnica, Informtica y Automtica. Universidad de Girona. http://eia.udg.es/~marzo/catcampus/qos.pdf. Marzo de 1.998. [11] Mecanismos de control de congestin y QoS. Departamento de Lenguajes y Sistemas e Ingeniera del Software. Universidad Politcnica de Madrid. http://pegaso.ls.fi.upm.es/disenyo_planif/QOS-DEF-2002.pdf. Febrero de 2.002.

Você também pode gostar