Repositorio Institucional de Documentos

Proyecto Final de Carrera Ingenier´ıa de Telecomunicaci´on An´alisis de tr´afico Ip multimedia en entornos empresariales: Automatizaci´on del proceso Autor: Elisa Santos Tena Director: Juli´an Fern´andez Navajas Septiembre de 2012 Departamento de Electr´onica y Comunicaciones Escuela de Ingenier´ıa y Arquitectura Universidad de Zaragoza El triunfo no esta en vencer siempre, sino en nunca desanimarse. Napole´on A todos los que no me dejaron desanimarme, especialmente a mis padres. iv An´alisis de tr´afico IP multimedia en entornos empresariales: Automatizaci´on del proceso Abstract El crecimiento en el uso de las aplicaciones multimedia en los ´ultimos a˜nos ya sean Web, video en tiempo real, conversaciones de voz, aplicaciones P2P y un largo etc´etera, ha hecho que aumente su tr´afico en la red. El incremento de ese tr´afico ha provocado la aparici´on de ciertos puntos cr´ıticos a lo largo del trayecto, siendo necesaria la identificaci´on y el an´alisis de los mismos. Este hecho, ha incitado a los expertos a buscar soluciones para controlar y gestionar este tr´afico, y por ello se est´an desarrollando continuamente herramientas que faciliten esta tarea. Este proyecto se basa en la implementaci´on de una herramienta automatizada enfocada al sector empresarial, para el estudio del comportamiento del tr´afico de aplicaciones sobre un entorno de red controlado. La necesidad viene dada porque es necesario conocer de antemano si la red ser´a capaz de soportar el lanzamiento de un servicio y para ello es muy ´util contar con una herrameinta que garantice repetibilidad en su an´alisis. Con el fin de desarrollar la herramienta, el primer paso fue seleccionar aquellas aplicaciones multimedia que se pueden definir como casos de uso com´un y que presentan modelos de tr´afico significativos en la red, como pueden ser voz, juegos online y videovigiliancia entre otros. Para facilitar esta seleci´on se acudi´o al entorno empresarial, de tal forma que se identificaron aplicaciones de uso frecuente. En segundo lugar se realiz´o la selecci´on de escenarios comunes en los entornos (WiFi y Ethernet) y que se han utilizado en el presente trabajo. Por ´ultimo se eligi´o la herramienta adecuada para proceder a la captura del tr´afico. Como resultado de todo el proceso llevado a cabo se obtuvo una herramienta automatizada para el an´alisis de tr´afico, la captura y generaci´on de flujos IP multimedia que permite obtener medidas de calidad en diferentes entornos controlado de laboratorio, as´ı como en entornos reales, de manera que sirva para la evaluaci´on de distintas tecnolog´ıas y aplicaciones, as´ı como la caracterizaci´on de entornos. v ´ Indice 1. Introducci´on 1 1.1. Motivaci´on.................................... 1 1.2. Objetivodelproyecto.............................. 2 1.3. Contexto..................................... 3 1.4. Estructura.................................... 3 2. Herramientas utilizadas 5 2.1. Herramientas para la captura de datos . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Tcpdump ................................ 5 2.1.2. Wireshark................................ 6 2.2. Herramientas para la generaci´on y gesti´on de tr´afico . . . . . . . . . . . . . 6 2.2.1. ETG/ETGAnalyzer........................... 6 2.2.2. TCyNETEM.............................. 7 2.3. Herramientas desarrolladas . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. Script de captura (captura.sh) . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Script para la generaci´on y captura del tr´afico (generacion.sh) ............................. 8 2.3.3. Script para la caracterizacion de entornos (entornos.sh) .............................. 10 2.4. Herramientas matem´aticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.1. Matlab.................................. 11 2.5. Aplicaciones multimedia y servicios . . . . . . . . . . . . . . . . . . . . . . 11 vii ´ INDICE ´ INDICE 2.5.1. Videovigilancia ............................. 12 2.5.2. VLC................................... 12 2.5.3. Sistema de Videoconferencia Vidyo . . . . . . . . . . . . . . . . . . 12 3. Metodolog´ıa de trabajo 15 3.1. Descripci´on ................................... 15 3.2. FASE 1: Estudio te´orico, selecci´on de aplicaciones y escenarios y planificaci´on 16 3.3. FASE 2: Desarrollo de los scripts ....................... 16 3.4. FASE 3: Montaje y configuraci´on de las aplicaciones y escenarios . . . . . . 17 3.5. FASE 4: Pruebas de an´alisis y obtenci´on de resultados . . . . . . . . . . . 17 3.5.1. Modelado de flujos IP . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.2. Medidasdecalidad........................... 18 3.5.3. Caracterizaci´on de entornos . . . . . . . . . . . . . . . . . . . . . . 20 3.6. FASE 5: Optimizaci´on y depurado . . . . . . . . . . . . . . . . . . . . . . . 20 4. Modelado de flujos IP 21 4.1. Modelado del sistema de videovigilancia . . . . . . . . . . . . . . . . . . . 21 4.1.1. Configuraci´on.............................. 22 4.1.2. Proceso de captura . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.3. Resultados................................ 23 4.2. ModeladoVLC ................................. 25 4.2.1. Configuraci´on.............................. 25 4.2.2. Proceso de captura . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.3. Resultados................................ 27 5. Medidas de calidad 29 5.1. Configuraci´on.................................. 30 5.2. Proceso de generaci´on y captura . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Resultados.................................... 32 viii ´ INDICE ´ INDICE 6. Caracterizaci´on de entornos 35 6.1. Configuraci´on.................................. 36 6.2. Proceso de generaci´on, captura y an´alisis . . . . . . . . . . . . . . . . . . . 37 6.3. Resultados.................................... 38 7. Conclusiones y L´ıneas futuras 43 7.1. Conclusiones................................... 43 7.2. L´ıneasfuturas.................................. 44 A. Acr´onimos y t´erminos 46 A.1.Acr´onimos.................................... 46 A.2.T´erminos .................................... 46 B. Desarrollo 47 C. Configuraci´on de las aplicaciones 49 C.1.AXIS2120.................................... 49 C.2.VLC ....................................... 51 D. Scripts 55 D.1. Script de captura de tr´afico (captura.sh) . . . . . . . . . . . . . . . . . . . 55 D.2. Script de generaci´on y captura (generacion.sh) . . . . . . . . . . . . . . . . 57 D.3. Script de caracterizaci´on (entornos.sh) . . . . . . . . . . . . . . . . . . . . 62 ix 2. Herramientas utilizadas En esta secci´on vamos a hablar de las herramientas y aplicaciones que hemos utilizado en el desarrollo del proyecto. El proceso de aprendizaje y utilizaci´on de las mismas ha sido continuo, y se ha debido poner especial cuidado en la decisi´on de las herramientas que se iban a utilizar ya que no todas trabajan con la misma exactitud ni obtienen los mismos resultados. Las lecturas recomendadas para la compresi´on de este cap´ıtulo [1] [2] [3] [4] [5] se encuentran recogidas en la bibliograf´ıa del proyecto. 2.1. Herramientas para la captura de datos Las herramientas de captura con las que hemos contado en el laboratorio donde se ha realizado el proyecto, son Tcpdump y Wireshark, para sistemas operativos de Linux y Windows. La diferencia principal entre ambas herramientas es que Tcpdump no permite el an´alisis de protocolos. En una primera fase del proyecto, utilizamos Wireshark para exportar las capturas en CSV (Comma Separated Value) para su posterior an´alisis matem´atico con MatLab descart´andose debido a que, aunque Tcpdump no posee un interfaz friendly para el usuario s´ı que permite proceder a la captura del tr´afico de forma desatendida. Una vez escogido Tcpdump el resto del proyecto se ha realizado para Linux y las herramientas y aplicaciones de la que hablemos a continuaci´on est´an orientadas a este entorno. 2.1.1. Tcpdump Tcpdump es un herramienta en l´ınea de comandos cuya utilidad principal es capturar el tr´afico que circula por la red. Permite al usuario filtrar la informaci´on capturada de manera que se obtiene una salida con la informaci´on deseada. 6 Herramientas utilizadas Adem´as, como trabaja en modo comando, permite capturar tr´afico de forma desatendida mediante la programaci´on de un script, lo que conlleva que nuestro proceso se realice de forma automatizada. En contraposici´on a otras herramientas de captura, Tcpdump carece de interfaz gr´afica, lo que lo hace un poco menos intuitivo a la hora de trabajar. Tcpdump funciona en la mayor´ıa de los sistemas operativos (la versi´on en Windows se llama WinDump) y hace uso de la biblioteca libpcap en el caso de los sistemas UNIX y Winpcap para Windows. 2.1.2. Wireshark Wireshark es un analizador de protocolos open-source dise˜nado por Gerald Combs y que actualmente est´a disponible para plataformas Windows y Linux. Su principal objetivo es el an´alisis y captura de tr´afico, adem´as de ser una excelente aplicaci´on did´actica para el estudio de las comunicaciones y para la resoluci´on de problemas de red. Una caracter´ıstica interesante de Wireshark es que implementa una amplia gama de filtros que facilitan la definici´on de criterios de b´usqueda para los m´as de 1100 protocolos soportados actualmente; y todo ello por medio de una interfaz sencilla e intuitiva para el usuario, cosa que no nos sucede con TcpDump. Otra caracter´ıstica de este analizador de protocolos es que permite exportar la informaci´on capturada a distintos y numerosos formatos de aplicaci´on. 2.2. Herramientas para la generaci´on y gesti´on de tr´afico Para la generaci´on del tr´afico de evaluaci´on que se utiliza en los procesos de medidas de calidad y caracterizaci´on de entornos, hemos contado con ETG, una herramienta desarrollada por el grupo de trabajo. Mientras que para la gesti´on del tr´afico se han utilizado dos herramientas disponibles para nuestro sistema Linux: TC y NETEM. 2.2.1. ETG/ETGAnalyzer Esta herramienta [1] ha sido desarrollada por el grupo de trabajo en el cu´al se enmarca el proyecto. Est´a orientada al estudio sistem´atico de comunicaciones de tr´afico multimedia en tiempo real E2E (End-to-end) buscando la automatizaci´on de tareas. Adem´as de 2.3 Herramientas desarrolladas 7 generar tr´afico, la herramienta permite realizar medidas de par´ametros objetivos y subjetivos de QoS (factor R, MOS) tanto en tr´afico en un solo sentido como en tr´afico de ida y vuelta en redes IP. La arquitectura propuesta en esta herramienta es emisor-receptor que nos permitir´a el estudio sistem´atico de redes de forma autom´atica, que es lo que estamos buscando en todo momento. Mediante el an´alisis del tr´afico recibido se obtendr´an par´ametros de retardo, p´erdidas y jitter, adem´as de estimar la calidad del sistema. Esta herramienta nos facilita la repetibilidad ya que cada flujo se puede repetir cada cierto tiempo, permite generar tr´afico equivalente al de diferentes servicios a partir de los modelos que dan informaci´on de los intervalos de transmisi´on de paquetes y el tama˜no de los mismos. La informaci´on necesaria para generar los flujos IP se consigue gracias a un fichero XML que se edita manualmente y que leer´a el emisor para llevar a cabo el env´ıo y la captura de tr´afico. Los flujos de informaci´on est´an formados por varios atributos, destacando: direcci´on IP del emisor y receptor remoto, n´umero de r´afagas a lanzar, n´umero de paquetes por r´afaga, tama˜no de los paquetes, as´ı c´omo tiempos de procesado (tiempo entre paquetes y tiempo entre r´afagas). M´as informaci´on en los anexos. 2.2.2. TC y NETEM TC Traffic Control [2] [3] es la herramienta de control de tr´afico de Linux que est´a contenida en el paquete iproute2 y que permite al usuario acceder a las funciones de red. TC nos permite limitar el ancho de banda determinado y puede ser utilizado tanto para configurar las disciplinas de cola, c´omo para configurar la clasificaci´on de los paquetes en la disciplina de cola. NETEM Network Emulator [4] es un emulador de red para Linux kernel 2.6.7 o versiones superiores que nos permite introducir de manera controlada en la red retrasos, p´erdidas, paquetes duplicados y paquetes da˜nados, siendo NETEM una extensi´on de TC. 2.3. Herramientas desarrolladas Recordando que el objetivo principal de este proyecto de fin de carrera, es que toda la metodolog´ıa propuesta se pueda realizar de manera automatizada. Para poder alcanzar este objetivo, las herramientas de captura, generaci´on y an´alisis se han integrado en un sistema software de manera que se obtiene un sistema final que nos permite automatizar el proceso en la medida de lo posible. Adem´as, debido a la elecci´on de trabajar con Linux, 8 Herramientas utilizadas estas herramientas han sido programadas para el citado sistema operativo. Los scripts desarrollado se encuentran en el apartado de anexos del proyecto. 2.3.1. Script de captura (captura.sh) El script desarrollado para este punto, nos permite capturar el tr´afico generado por la aplicaci´on multimedia o servicio a analizar, y almacenar los flujos de informaci´on para poder ser utilizados posteriormente. Este script se basa en la herramienta de captura Tcpdump, que nos permitir´a que dicho proceso de captura se haga de manera desatentida. Este software toma como par´ametros la duraci´on del proceso de captura, el n´umero de capturas a realizar, el tiempo que debe transcurrir entre cada captura, la direcci´on IP de la aplicaci´on que est´a generando el tr´afico y el puerto. Dispone de dos modos de uso: el primero de ellos trabaja de forma aislada y permite introducir los par´ametros mediante teclado. El segundo es llamado por otro script que se encargar´a de pasarle los par´ametros. En cualquiera de los dos casos nos permita realizar diversas capturas, a distintas horas sin tener que estar de manera f´ısica en el escenario. Una vez introducidos todos los par´ametros de configuraci´on de la captura, se procede a su ejecuci´on, almacenando el tr´afico capturado en dos archivos. El primero contiene toda la informaci´on capturada de la red, mientras que el segundo s´olo contiene el tr´afico referente a la aplicaci´on o servicio. Esto se consigue aplicando los filtros que Tcpdump nos ofrece, filtrando por direcci´on IP, puerto y por el protocolo utilizado (ICMP, TCP, UDP...). La informaci´on obtenida de cada paquete se almacena en un l´ınea independiente del fichero y se dispone por columnas con el siguiente orden: Tiempo de captura del paquete y el tama˜no del mismo. En el caso de ser utilizado por el usuario, una funcionalidad que se le ha a˜nadido al script es la de representar los flujos de informaci´on almacenados, que pueden resultar interesantes para tener una primera idea del comportamiento de los mismos. 2.3.2. Script para la generaci´on y captura del tr´afico (generacion.sh) El script que se ha desarrollado en este punto, nos va a permitir generar un tr´afico de evaluaci´on que ser´a introducido por el usuario. Dicho tr´afico servir´a tanto para evaluar diferentes aspectos de calidad de una red como caracterizar entornos. Para esta parte del proyecto se cuenta con la herramienta de generaci´on de tr´afico ETG desarrollada por el grupo, la cu´al gracias a un fichero configuraci´on en formato 2.3 Herramientas desarrolladas 9 XML permite generar flujos que tengan las mismas caracter´ısticas que aquellos generados por aplicaciones y servicios concretos y que se hayan modelado previamente. Por ello, el primer paso ha sido que el proceso de configuraci´on de dicho fichero de configuraci´on XML (test) se pueda realizar de diversas maneras. Se podr´a editar manualmente, o mediante una ayuda opcional de edici´on incluida en el script en el caso de no conocer los comandos de edici´on de textos. Si se opta por la ayuda, el programa pedir´a por teclado los diversos par´ametros que hacen falta para que la herramienta genere los flujos de tr´afico deseados y ser´a la propia herramienta la que cree el fichero de configuraci´on. Los par´ametros que se introducen por teclado son los siguientes: - Nombre del proyecto. - Nombre del test. - Fecha de Inicio, en formato DD/MM/YYYY HH:mm:ss. - Fecha de Fin, en formato DD/MM/YYYY HH:mm:ss. - Tama˜no de la cabecera. - Tiempo de espera antes iniciar. - Direcci´on Ip del emisor en formato XXX.XXX.XXX.XXX. - Interfaz del emisor (eth0,eth1...). - Puerto del emisor. - Direcci´on Ip del host remoto en formato XXX.XXX.XXX.XXX. - Interfaz remoto. - Puerto remoto. - Frecuencia (tiempo en segundos). - Numero de r´afagas a lanzar. - Tiempo entre r´afagas. - N´umero de paquetes por r´afaga. - Tiempo entre paquetes. - Tama˜no del paquete. - Tr´afico de ida o tr´afico de ida y vuelta. - N´umero de repeticiones. El siguiente paso del script es intercambiar las claves p´ublicas y privadas que permiten a nuestros equipos comunicarse entre s´ı de forma segura, mediante un script desarrollado por el grupo de trabajo (configure.sh). Despu´es de que las m´aquinas han compartido las claves se comienza el proceso de sincronizaci´on de las mismas. Una vez han compartido las claves y se han sincronizado entre s´ı los equipos, se comienza con el proceso de generaci´on de tr´afico gracias a la herramienta ETG, as´ı como el proceso de captura. La captura se hace para todos los interfaces del equipo que genera el tr´afico de evaluaci´on (any) generando un archivo que contiene toda la informaci´on capturada en dichos interfaces. 10 Herramientas utilizadas En nuestro caso, se captura tanto en el interfaz de entrada, como en el interfaz de salida del sistema, generando un fichero con toda la informaci´on. Gracias a que la herramienta de generaci´on de tr´afico asigna un n´umero de secuencia a cada paquete, podemos identificar en dicho archivo, los paquetes a la entrada y a la salida del sistema pudiendo de esta manera calcular retardos. Aplicando una serie de filtros y procesando el archivo que contiene toda la informaci´on, se obtienen dos archivos independientes, uno con los flujos a la entrada del sistema, y otro con los flujos a la salida, quedando preparados de esta manera por si quieren utilizarse en el proceso de caracterizaci´on de entornos, donde en este caso la informaci´on esta organizada por columnas y en el siguiente orden: n´umero de secuencia, tama˜no del paquete y tiempo de emisi´on o recepci´on. 2.3.3. Script para la caracterizacion de entornos (entornos.sh) El software desarrollado en este punto, permite caracterizar distintos entornos de red gracias al uso de una serie de algoritmos que analizan el comportamiento del tr´afico. Para este punto contaremos con la herramienta de generaci´on de tr´afico ETG, que generar´a un tr´afico de evaluaci´on el cu´al nos permitir´a caracterizar el entorno, que es usada por nuestro script de generaci´on y captura de tr´afico (generacion.sh) y que genera dos archivos de informaci´on. El script desarrollado trabaja con los dos archivos mencionados, uno con la informaci´on del tr´afico a la entrada del sistema bajo an´alisis y el otro con la informaci´on del tr´afico capturado a la salida del sistema. Ambos ficheros contar´an con la informaci´on de n´umero de secuencia, tama˜no del paquete y tiempo de emisi´on o recepci´on dispuestos por columnas. Con estos tres campos de informaci´on es suficiente para poder obtener distintos par´ametros caracter´ısticos de nuestro sistema, como pueden ser: n´umero de paquetes perdidos y en consecuencia la tasa de p´erdida, velocidad del enlace a la entrada y a la salida, retardos, tama˜nos de buffer presentes en la conexi´on a estudiar, as´ı como otros. El procesado de los archivos por el software desarrollado es el siguiente: una vez consolidados los archivos para que ambos presenten la informaci´on dispuesta en el mismo orden, estos se comparan entre s´ı generando un tercero que contar´a con la informaci´on total necesaria para la caracterizaci´on. En nuestro caso, el archivo total cuenta con 4 columnas de informaci´on de la siguiente manera: n´umero de secuencia del paquete, tama˜no, tiempo de emisi´on y tiempo de recepci´on. Con el archivo anterior, ya s´olo queda decidir qu´e caracter´ısticas del sistema se quiere estudiar. Se ha a˜nadido al script el caso particular de c´alculo del tama˜no del buffer con tres 2.4 Herramientas matem´aticas 11 opciones diferentes, debido a que era una caracter´ıstica que se quer´ıa estudiar en el grupo. Para ello se cuenta con los tres m´etodos de an´alisis que se exponen a continuaci´on: M´etodo 1: Algoritmo que cuenta el n´umero de paquetes que hay en el buffer en el momento de la entrada de un nuevo paquete, bas´andose en los tiempos de entrada-salida. M´etodo 2: Algoritmo que estima el n´umero de paquetes teniendo en cuenta el retardo de un paquete en el buffer, obtenido con base al tama˜no del paquete y a la velocidad de salida. M´etodo 3: Algoritmo que estima las velocidades de llenado y vaciado del buffer con base en las relaciones temporales de los paquetes recibidos con respecto a la estimaci´on del tiempo en el que fueron enviados. Para este algoritmo s´olo se necesita el fichero de salida. 2.4. Herramientas matem´aticas En ciertos momentos de nuestro proyecto, se ha necesitado un entorno matem´atico en el que realizar c´alculos con las capturas y los an´alisis de los flujos de informaci´on. Se ha optado por utilizar MatLab ya que es un herramienta ampliamente conocida y que proporciona gran potencia matem´atica. 2.4.1. Matlab MATLAB es un software matem´atico que ofrece un entorno integrado con un lenguaje de programaci´on propio. Est´a disponible para las plataformas Unix, Windows y Apple Mac OS X. Entre sus prestaciones b´asicas se hallan: la manipulaci´on de matrices, la representaci´on de datos y funciones, la implementaci´on de algoritmos, la creaci´on de interfaces de usuario (GUI) y la comunicaci´on con programas en otros lenguajes y con otros dispositivos hardware. Es un software muy usado en universidades y centros de investigaci´on y desarrollo, aunque es un producto propietario de MathWorks y por lo tanto sujeto a licencia. En el presente trabajo se ha utilizado principalmente para analizar las tramas de informaci´on obtenidas en las capturas del tr´afico en la red, ya que en muchos casos la complejidad de ciertas operaciones matem´aticas hizo necesario contar con una herramienta de este tipo. 2.5. Aplicaciones multimedia y servicios Adem´as de escoger las herramientas a utilizar en el desarrollo del proyecto, es necesario estudiar y seleccionar aquellas aplicaciones y servicios multimedia que despiertan mayor inter´es, tanto para nosotros como para el entorno empresarial. 12 Herramientas utilizadas 2.5.1. Videovigilancia La AXIS 2120 es una c´amara fija de red, tambi´en conocida como c´amara IP, para aplicaciones de videovigilancia y monitorizaci´on en forma remota. Proporciona m´ultiples secuencias fijas JPEG y motion-JPEG de forma simult´anea, sea a frecuencia de imagen m´axima o con calidades que pueden configurarse para que se adapten a las necesidades del servicio y a las restricciones del ancho de banda. Permite obtener hasta 25/30 im´agenes/seg (PAL/NTSC) a una resoluci´on de 352×288, hasta 5 niveles distintos de compresi´on y 7 anchos de banda (desde 0,1 hasta 2 MBit/s) o eliminar la restricci´on del ancho de banda (unlimited). El proceso de configuraci´on de la c´amara es muy sencillo. B´asicamente se debe configurar la direcci´on IP desde la cu´al se esta enviando los flujos de informaci´on, as´ı como los par´ametros mencionados: tipo de imagen (single omotion), compresi´on utilizada en la transmisi´on y ancho de banda utilizado. El grupo dispone de una c´amara accesible para la investigaci´on, por lo que tambi´en se ha podido utilizar siempre que ha sido necesario probar las herramientas. 2.5.2. VLC VLC media player es un reproductor multimedia y framework multimedia libre y de c´odigo abierto desarrollado por el proyecto VideoLAN. Es un programa multiplataforma con versiones disponibles para muchos sistemas operativos como Microsoft Windows, GNU/Linux, Mac OS X, BeOS...etc. Es un reproductor de audio y v´ıdeo capaz de reproducir muchos c´odecs y formatos, adem´as de capacidad de streaming (uno de los principales usos que vamos a estudiar en este trabajo). Es software libre, distribuido bajo la licencia GPL. Desde un primer momento se tuvo la limitaci´on de que el presente proyecto se pudiera probar asiduamente en instalaciones empresariales, por lo que el manejo y estudio de esta aplicaci´on, nos supon´ıa una alternativa a no poder acudir a la empresa siempre que se necesite probar la herramienta. Fundamentalmente hemos utilizado VLC para realizar streamings de audio y v´ıdeo. 2.5.3. Sistema de Videoconferencia Vidyo Vidyo es un software de videoconferencia para empresas que utiliza la aquitectura adaptativa de v´ıdeo en capas, ofreciendo una menor latencia y una alta calidad en la 2.5 Aplicaciones multimedia y servicios 13 definici´on. La arquitectura de Vidyo optimiza din´amicamente la calidad del v´ıdeo seg´un la red y las capacidades de los dispositivos terminales individuales para ofrecer experiencias con calidad de telepresencia a todos los participantes. Vidyo utiliza tecnolog´ıa de enrutamiento inteligente sensible a los medios con la flexibilidad y la solidez del est´andar de compresi´on de v´ıdeo H.264 SVC (Scalable Video Coding) para ofrecer colaboraciones y comunicaciones de v´ıdeo, de altas prestaciones, en Internet, 3G/4G, WiFi y WiMAX. Esta innovadora soluci´on ha desencadenado una revoluci´on en el sector, haciendo que las videoconferencias con calidad de alta definici´on sean accesibles para todos, sobre cualquier red y en cualquier terminal. Otra de las ventajas de Vidyo es que ofrece soporte de videoconferencia en sistemas de salas, equipos de sobremesa y dispositivos m´oviles y para distintos sistemas operativos. El sistema de videoconferencia Vidyo est´a formado b´asicamente por: VidyoRouter, VidyoDesktop y VidyoGateway donde el primero, es el elemento central del sistema VidyoConferencing, el segundo es la aplicaci´on que se descarga en el dispositivo y el tercero es un sistema que permite adaptar nuestro nuevo sistema con otros sistemas de videoconferencia heredados. Debido a que se trata de un sistema profesional, el uso est´a limitado a la disponibilidad que nos ofrece la empresa ORBE. S.L. 20 Metodolog´ıa de trabajo 3.5.3. Caracterizaci´on de entornos Para esta ´utima prueba del proyecto, se utiliza el mismo escenario montado para las medidas de calidad, aunque en este caso despu´es de la captura se procede a la caracterizaci´on de entornos de red basada en el an´alisis del tr´afico y trabajaremos con los scripts desarrollados de generaci´on y caracterizaci´on de entornos (generacion.sh y entornos.sh) que se encuentran ubicados en el quipo A. El orden de actuaci´on para el an´alisis de este escenario es el siguiente: en primer lugar se genera un tr´afico de evaluaci´on con la herramienta de generaci´on de tr´afico que tenemos en nuestro sistema, desde el equipo A (local) hacia el equipo B (remoto), tal y como se ha indicado anteriormente (igual que en el apartado de calidad) obteniendo los dos archivos de informaci´on, que ser´an la entrada del script de caracterizaci´on de entornos, el cu´al tratara los flujos de informaci´on para obtener distintas caracter´ısticas del entorno. Se ha a˜nadido la funcionalidad de capturar un tercer archivo en el equipo B cuando ´este se encuentre en otra localizaci´on y por lo tanto no se pueda conectar directamente, aunque en este proyecto no se vayan a realizar pruebas con el mismo. El tr´afico de evaluaci´on para realizar la caracterizaci´on es de tipo uniforme, y es generado de manera que saturemos la entrada al sistema. Una vez obtenidos los ficheros ya s´olo queda tratarlos para obtener las caracter´ıticas del sistema bajo an´alisis mediante los m´etodos descritos en el cap´ıtulo 2. 3.6. FASE 5: Optimizaci´on y depurado Despues de haber completado las fases previamente comentadas, se ha realizado un proceso de optimizaci´on de los script y depurado del sistema para hacerlo mucho m´as manejable y f´acil para el usuario. Se han desarrollado una serie de manuales que pueden ser le´ıdos en el propio terminal de Linux, donde se explica el funcionamiento de los scripts y se dan las pautas iniciales para su correcto funcionamiento, as´ı como unos anexos de configuraci´on de las aplicaciones que facilitan el proceso al usuario. Se han modificado algunos algoritmos que hac´ıan que el proceso se ralentizar´a para archivos de informaci´on de gran tama˜no. 4. Modelado de flujos IP Como se ha indicado anteriormente, para las empresas proveedoras es muy ´util poder conocer de antemano el comportamiento que un nuevo servicio puede provocar en la red de acceso estudiando el impacto que tendr´ıa sobre un escenario real. Por ese motivo, una de las funcionalidades que se ha desarrollado en el presente proyecto, permite capturar y analizar los flujos de distintas aplicaciones multimedia sobre entornos reales. Con esta primera funcionalidad, se han llevado a cabo una serie de pruebas que ratifiquen su perfecto funcionamiento a la hora de ser usado por la empresa proveedora, obteniendo a modo de ejemplo unos resultados para las aplicaciones analizadas. Para esta secci´on de modelado de flujos IP de las tres funcionalidades desarrolladas se ha utilizado solamente la opci´on 1 (captura de tr´afico). Se han hecho pruebas sobre dos de las aplicaciones mencionadas en el cap´ıtulo 2: sistema de televigilancia y sistema de streaming, ya que debido a la disponibilidad del sistema de videoconferencia sobre este no se han podido realizar las pruebas. A continuaci´on se explica detalladamente el proceso de configuraci´on de los escenarios de cada una de ellas y los resultados obtenidos. Las lecturas recomendadas para la compresi´on de este cap´ıtulo [6] [7] [9] se encuentran recogidas en la bibliograf´ıa del proyecto. 4.1. Modelado del sistema de videovigilancia Para esta parte del proyecto contamos con una c´amara fija de red AXIS 2120 que proporciona m´ultiples secuencias JPEG (fijas y motion) pudiendo obtener hasta 25/30 im´agenes/seg (PAL/NTSC) a una resoluci´on de 352 ×288, sobre una red con anchos de banda de 10 Mbps. El primer es el montaje del escenario que se corresponde con el montaje mencionado en el cap´ıtulo 3 y la configuraci´on de las aplicaciones. El escenario espec´ıfico utilizado para determinar el tr´afico de la c´amara es el mostrado en la Fig. 4.1. 22 Modelado de flujos IP Figura 4.1: Escenario utilizado para el sistema de videovigilancia En este apartado s´olo vamos a trabajar con la opci´on 1 del sistema desarrollado que utiliza el script de captura (captura.sh). El sistema va a estar ubicado en el equipo de captura, y est´a conectado al Hub de 10Mbps en donde podremos capturar todo el tr´afico generado por la c´amara. 4.1.1. Configuraci´on El proceso de configuraci´on de la c´amara es muy sencillo. El primero paso es acceder a ella de forma remota desde el equipo de trabajo mediante un navegador web tradicional. A continuaci´on configuramos la direcci´on IP desde la cu´al la c´amara est´a enviando los flujos de informaci´on. Tambi´en debemos configurar los distintos par´ametros que proporciona el fabricante, ya que el comportamiento del flujo de datos difiere en funci´on de la configuraci´on elegida. Los m´as significativos para nosotros para modelar el tr´afico son: tipo de imagen (single omotion), compresi´on utilizada en la transmisi´on (ver tabla 4.1), tama˜no de la imagen en pixeles (352 ×288 ´o 704 ×576) y ancho de banda utilizado por la c´amara (2Mbps,1Mbps,0.5Mbps...). FORMATOS DE COMPRESI´ ON AXIS Opciones Factor de compresi´on 352 ×288 704 ×576 Lowest 75K300K Low 13K50K Medium 8K32K High 4K16K Very high 3K12K Tabla 4.1: Formatos de compresi´on de la c´amara AXIS 2120 En los anexos podemos encontrar con m´as detalle los distintos par´ametros de 4.1 Modelado del sistema de videovigilancia 23 configuraci´on de la c´amara. Una vez configurada la c´amara y el escenario, comenzamos con el proceso de captura. 4.1.2. Proceso de captura El orden de actuaci´on es el siguiente: procedemos a generar tr´afico desde la c´amara IP y a continuaci´on lanzamos desde el equipo de captura nuestro sistema software, eligiendo la opci´on 1 (captura del tr´afico) el cu´al nos pide una serie de par´ametros para configurar la captura. El sistema captura toda la informaci´on existente en la red en la que estamos trabajando. A continuaci´on aplica un filtro por direcci´on IP de la fuente, puerto, tipo de tr´afico a capturar y almacena los flujos de informaci´on obtenidos en un archivo en formato de texto. Adem´as, tambi´en almacena la captura realizada por Tcpdump para su posterior consulta si fuese necesario y genera una gr´afica del tr´afico capturado. Ya tenemos la informaci´on necesaria para poder trabajar en un entorno matem´atico que nos ayude a conocer el comportamiento del tr´afico de la aplicaci´on en nuestro entorno de red. 4.1.3. Resultados Una de las primeras conclusiones a la que hemos llegado es que de los par´ametros de configuraci´on mencionados, el m´as importante a la hora de caracterizar los flujos de informaci´on es el tipo de compresi´on utilizada, afectando tanto a la calidad con la que el usuario percibe las im´agenes como al comportamiento de los paquetes en la red. Se han hecho pruebas para distintos anchos de banda (2Mbps, 1Mbps y 0,5Mbps), distintos factores de compresi´on y distintos tama˜nos de imagen (352 ×288 ´o 704 ×576). Se ha concluido que el ancho de banda configurado en la c´amara no es determinante en el n´umero de paquetes enviados en cada r´afaga, permaneciendo constante para los tres anchos de banda con los que se han hecho las pruebas pero si es determinante en el tiempo entre r´afagas. El nivel de compresi´on utilizado define el n´umero de paquetes enviado en cada r´afaga, es decir el tama˜no de la imagen en cada instante. El tama˜no de los paquetes ser´a siempre de 1500 bytes, excepto el ´ultimo paquete que ser´a de tama˜no variable dependiendo del tipo de compresi´on elegida y de la resoluci´on de la imagen. Podemos ver en la tabla 4.2 el n´umero de paquetes/r´afaga y el tiempo entre r´afagas que se obtienen en funci´on de la resoluci´on, del factor de compresi´on y del ancho de banda escogidos: 24 Modelado de flujos IP Paquetes/r´afaga - Tiempo r´afagas(ms) Resoluci´on Nivel de compresi´on 2Mbps 1Mbps 0.5Mbps 352 ×288 75K16 - 280 16 - 280 16- 600 13K(7-9) - 40 (7-9) - 80 (7- 9) - 160 8K5 - 40 5 - 80 5 - 160 4K3 - 40 3 - 40 3 - 80 3K3 - 40 3 - 40 3 - 80 704 ×576 300 38 -240 38 - 480 38 - 900 50K25 - 160 25 - 280 25 - 400 32K15 - 160 15 - 160 15 - 400 16K9 - 160 9 - 160 9 - 200 12K9 - 160 9 - 160 9 - 200 Tabla 4.2: Resultados obtenidos ambos tama˜nos de imagen Los flujos de informaci´on de la c´amara se realizan siempre por r´afagas, compuestas a su vez por el n´umero de paquetes que proporcione el tipo de compresi´on utilizada. Las tramas van seguidas dentro de la r´afaga y el tiempo entre r´afagas ser´a tambi´en variable dependiendo de la configuraci´on elegida. En la Fig. 4.2 podemos ver una representaci´on del tr´afico capturado, para un ancho de banda de 2Mbps, para una resoluci´on de imagen peque˜na y utilizando un factor de compresi´on medio (8K). Se pueden diferenciar el n´umero de paquetes enviados en cada r´afaga, asi como el tiempo entre r´afagas, que con la configuraci´on ya descrita podemos observar que es de 40 ms y se puede concluir que el tr´afico presenta un comportamiento uniforme. Figura 4.2: Detalle de una c´aptura de tr´afico de la AXIS 2120 4.2 Modelado VLC 25 Pero al contrario que el n´umero de paquetes/r´afaga que permanecia constante independientemente del ancho de banda utilizado, no lo hace para el tiempo entre r´afagas siendo distinto dependiendo del ancho de banda. Cabe destacar que para esta aplicaci´on se han hecho bastantes pruebas y se han obtenido m´as resultados que para las otras debido a la simplicidad de la aplicaci´on como a la simplicidad de los modelos que genera. 4.2. Modelado VLC En este apartado contamos con VLC media player que es un reproductor multimedia y framework, capaz de reproducir muchos c´odecs y formatos, adem´as de capacidad de streaming. Se va a realizar la prueba de captura de tr´afico con nuestro sistema desarrollado para una aplicaci´on de streaming entre dos equipos de nuestro laboratorio que est´an interconectados entre s´ı mediante un hub de 100Mbps. Siguiendo el esquema general del cap´ıtulo 3 la topolog´ıa necesaria para esta prueba es la mostrada en la figura 4.3. Figura 4.3: Escenario utilizado para el servicio de streaming. El programa VLC debe estar instalado en ambos equipos, tanto en el servidor como en el cliente. En nuestro equipo de captura tendremos ubicado el sistema desarrollado y utilizaremos la opci´on de captura de tr´afico (opci´on 2). 4.2.1. Configuraci´on Tanto el servidor como el cliente se configuran de manera diversa y por tanto hay que tener cuidado a la hora de la configuraci´on del servicio VLC en ambos equipos. En el servidor, debemos tener el archivo de audio o v´ıdeo con el que vamos a hacer el streaming, y en las opciones que nos proporciona la herramienta debemos elegir emisi´on. Una vez elegido, la aplicaci´on nos pide el protocolo que queremos utilizar para hacer el 26 Modelado de flujos IP PAR´ AMETROS CONFIGURACI´ ON STREAMING PROTOCOLOS C´ ODECS RTP MPEG-1,2,4 UDP DIVX 1,2,3 Archivo H.264, H.263 HTTP Theora MMS MP4, WAV y MOV IceCast AAC, Vorbis y MP3 Tabla 4.3: Protocolos y c´odecs que ofrece VLC streaming y si queremos que haya trascodificaci´on o no (se utiliza alguno de los c´odecs que posee la herramienta). Los protocolos y c´odecs se pueden consultar en la tabla que aparece a continuaci´on (4.3). Ahora s´olo queda introducir la direcci´on del equipo con el que vamos a hacer streaming y el puerto solicitado por el protocolo. Debemos configurar la aplicaci´on VLC en el equipo que act´ua como cliente. En este equipo deberemos elegir la opci´on de volcado de red y despu´es introducir el protocolo elegido para la emisi´on. En este caso no se debe poner direcci´on IP debido a que es el cliente el que esta recibiendo la informaci´on. Una vez configuradas las dos m´aquinas, ya s´olo queda comenzar con el streaming comenzando con el volcado de red en el cliente y a continuaci´on la emisi´on en el servidor. En los anexos podemos encontrar con m´as detalle el proceso de configuraci´on de la aplicaci´on vlc para el realizado del streaming. 4.2.2. Proceso de captura El proceso es similar al utilizado en la captura del sistema de videovigilancia. Lo primero es comenzar a recibir el streaming en el equipo que act´ua como cliente con la opci´on de volcado de red. A continuaci´on, desde el servidor comenzamos el proceso de emisi´on del archivo de v´ıdeo o audio elegido. Una vez se esta realizando el streaming podemos proceder a capturar los flujos de tr´afico desde nuestro equipo de captura. Igual que en el caso anterior nuestra herramienta captura los flujos de tr´afico que a continuaci´on son filtrados, por direcci´on IP del emisor, puerto y tipo de tr´afico capturado para obtener nuestro archivo de texto listo para ser tratado con un entorno matem´atico. 4.2 Modelado VLC 27 4.2.3. Resultados Se han realizado varias capturas, modificando tanto el protocolo utilizado en la transmisi´on como el tipo de codificaci´on, y la primera conclusi´on a la que se ha llegado, es que el tr´afico no presenta un comportamiento uniforme, siendo bastante complejo el modelo de tr´afico que utiliza. Para un streaming con un protocolo UDP y sin codificaci´on, el tiempo entre tramas obtenido no es constante llegando a variar desde 0,20ms entre algunas tramas hasta 2ms entre otras de ellas. Como podemos observar, para el streaming no es f´acil obtener a primera vista un modelo de tr´afico. En el streaming de v´ıdeo realizado en este caso, el ´unico par´ametro que permanece constante es el tama˜no del paquete que para un protocolo UDP y sin codificaci´on presenta un tama˜no de 1370bytes. Esto se debe a que transmitimos informaci´on con TS (Transport Stream), protocolo que divide la informaci´on en streams de 188 bytes fijos y los paquetes IP pueden contener m´ultiplos de estos, por lo tanto el mayor tama˜no posible ser´ıa 1370 bytes. 5. Medidas de calidad La calidad con la que un sistema soporta un nuevo servicio as´ı como la calidad con la que un sistema soporta una o varias comunicaciones simult´aneas sin que se presente deterioro en la informaci´on son dos medidas que van a ser de inter´es tanto para una empresa proveedora como para el usuario del servicio. Es por ello que surge la necesidad de desarrollar una herramienta que permita evaluar dichos aspectos de calidad sobre un entorno real. Para esta secci´on de medidas de calidad, se utiliza solamente de las tres funcionalidades desarrolladas la opci´on 2 (generaci´on y captura de tr´afico). En este caso se analiza la calidad de nuestro sistema software enviando sobre ´el un tr´afico de evaluaci´on que seguir´a el modelo introducido por el usuario. Este modelo, puede ser uno de los calculados previamente o alguno conocido por el usuario. Se van a realizar dos medidas de calidad: la primera de las pruebas realizadas consiste en medir la calidad de un sistema mientras que la segunda obtiene el n´umero de comunicaciones para las cu´ales el sistema no presenta deterioro en la informaci´on. Para la realizaci´on de estas dos medidas se va a utilizar la topolog´ıa siguiente: Figura 5.1: Montaje pruebas medida de calidad Vamos a estudiar dos dispositivos con los que contamos en el laboratorio: un Switch 36 Caracterizaci´on de entornos El Hub de salida del sistema es un Hub de 10Mbps para el caso del Switch Ethernet ya que al presentar una velocidad en el enlace de salida m´as baja se consigue saturar el buffer del propio switch , mientras que para los puntos de acceso contaremos con un Hub tanto a la entrada como a la salida del sistema, siendo tanto el Hub de entrada como el de salida de 100Mbps con lo que la comunicaci´on de los puntos de accesso est´a solamente limitada por el ancho de banda del enlace inal´ambrico y para saturar el punto de acceso simplemente se deber´a poner un ancho de banda menor a 100Mbps. Con este montaje obtendremos retardos, tasa de p´erdida del sistema y el tama˜no del buffer de los dos sistemas expuestos obteniendo los l´ımites de llenado y vaciado del mismo. El primer paso a realizar es el montaje del escenario y la comprobaci´on de las distintas conexiones que lo constituyen. A continuaci´on se detalla el proceso de configuraci´on de los dispositivos y aplicaciones. Las lecturas recomendadas para la compresi´on de este cap´ıtulo [10] [11] se encuentran recogidas en la bibliograf´ıa del proyecto. 6.1. Configuraci´on Una vez que tenemos el montaje de nuestro escenario real y se ha comprobado el correcto funcionamiento de las conexiones, vamos a proceder a la configuraci´on de los distintos dispositivos y aplicaciones con las que contamos en la topolog´ıa propuesta. El Switch Ethernet debe configurarse de manera que no se realice control del flujo en el mismo. Debemos desactivar esa opci´on puesto que lo que nosotros queremos es que el buffer del dispositivo se sature y eso no lo conseguiremos con el control de flujo activo. Se deben configurar los dos puntos de acceso (AP) de manera que se puedan transmitir datos entre ambos. Para ello, adem´as de configurar sus direcciones IP se debe crear entre ellos una red inal´ambrica que los conecte (de la cu´al variaremos el ancho de la conexi´on). Respecto a los otros dispositivos, el equipo A va a ser el encargado de generar el tr´afico de evaluaci´on y capturar los flujos de informaci´on para su posterior an´alisis. Este tr´afico de evaluaci´on va a ser uniforme y constante, para que sea mucho m´as f´acil de analizar a la hora de caracterizar el entorno. Adem´as, gracias a la herramienta de generaci´on de tr´afico ETG los flujos de informaci´on generados llevan asociado un n´umero de secuencia que nos va a servir para identificar los paquetes a la entrada y a la salida del sistema, lo que nos facilita el an´alisis. Tanto la herramienta para la generaci´on de flujos desarrollado por el grupo (ETG) como el software desarrollado para este proyecto se encuentran ubicados en el equipo A, donde se almacenan tambi´en los resultados obtenidos tanto de la captura de tr´afico como los de su posterior an´alisis. Cabe destacar que para las pruebas realizadas, hemos contado con los dos equipos en 6.2 Proceso de generaci´on, captura y an´alisis 37 el laboratorio, pero se est´an realizando otras medidas dentro del grupo, donde el equipo B puede no encontrarse en la misma ubicaci´on, siendo entonces imposible realizar la conexi´on directa del interfaz eth1 como captura. 6.2. Proceso de generaci´on, captura y an´alisis El proceso de trabajo de esta ´ultima prueba del proyecto para ambos sistemas a caracterizar va a ser el siguiente: 1. Generaci´on de tr´afico uniforme con la opci´on 2 de la herramienta. 2. Captura del tr´afico con la opci´on 2 de la herramienta. 3. An´alisis del tr´afico del sistema a caracterizar con la opci´on 3 de la herramienta. Descripci´on del proceso: Una vez tenemos el montaje y hemos configurado los dispositivos, lanzamos nuestra herramienta eligiendo la opci´on 3: Caracterizaci´on de entornos. Esta herramienta a su vez lanza la opci´on 2 de generaci´on y captura del tr´afico. El proceso a seguir para la generaci´on y captura es el mismo que el utilizado para medidas de calidad. Una vez se ha acabado con la captura del tr´afico de evaluaci´on generado y se han creado los dos archivos con lo que trabajaremos se comienza con el an´alisis del tr´afico para obtener las distintas caracter´ısticas del sistema. Los archivos creados en el paso anterior poseen informaci´on de n´umero de secuencia, tiempo de emisi´on o recepci´on y tama˜no del paquete. Con estos tres campos de informaci´on es suficiente para poder obtener distintos par´ametros caracter´ısticos de nuestro sistema, como pueden ser: n´umero de paquetes p´erdidos y en consecuencia la tasa de p´erdida, tama˜no del buffer del sistema, velocidad del enlace a la entrada y la salida, retardos, as´ı como otros. El siguiente paso a realizar por el script de caracterizaci´on es la consolidaci´on de los datos en un solo archivo. Esto se ha hecho, debido a que a la hora de trabajar con dos archivos independientes, se aumentaba mucho el tiempo de procesado de los mismos y la capacidad del sistema, por tanto se decidi´o consolidar los dos archivos en uno solo que cuenta con la siguiente informaci´on: N´umero de secuencia Tama˜no paquete Tiempo de emisi´on Tiempo de recepci´on Gracias a que tenemos los tiempos de emisi´on y recepci´on de los paquetes, el c´alculo del retardo que introduce el sistema es un paso muy f´acil. El programa calcula la resta de 38 Caracterizaci´on de entornos ambos tiempos para cada par de paquetes con el mismo n´umero de secuencia y finalmente calcula la media de todos los paquetes para obtener un retardo medio. El archivo consolidado ya no cuenta con los paquetes que se han perdido en el sistema bajo an´alisis, sino que en este archivo s´olo tenemos informaci´on de aquellos paquete que han salido del sistema. Por lo tanto la manera de calcular la tasa de p´erdida es la siguiente: el script va comprobando el n´umero de secuencia (primera columna) del archivo consolidado hasta que se produce un salto de m´as de un n´umero de secuencia. Ah´ı es donde tenemos los paquetes perdidos, por lo que s´olo falta hacer una operaci´on matem´atica. Para la obtenci´on del tama˜no del buffer se han desarrollado 3 m´etodos en el grupo (de los cu´ales se utilizan dos en el presente proyecto): M´etodo 1: Algoritmo que cuenta el n´umero de paquetes que hay en el buffer en el momento de la entrada de un nuevo paquete, bas´andose en los tiempos de entradasalida. M´etodo 2: Algoritmo que estima el n´umero de paquetes teniendo en cuenta el retardo de un paquete en el buffer, obtenido con base al tama˜no del paquete y a la velocidad de salida. M´etodo 3: Algoritmo que estima las velocidades de llenado y vaciado del buffer con base en las relaciones temporales de los paquetes recibidos con respecto a la estimaci´on del tiempo en el que fueron enviados. Para este algoritmo s´olo se necesita el fichero de salida. En este proyecto y para estas pruebas se han utilizado los dos primeros, ya que el tercero se usa cuando uno de dos equipos se encuentra en otra ubicaci´on (remoto). Una vez se ha calculado el tama˜no del buffer la propia herramienta genera una gr´afica en la que podemos apreciar el mecanismo de llenado y vaciado debuffer caracterizado. 6.3. Resultados Se han hecho pruebas para tres tr´aficos de evaluaci´on de tama˜nos de paquete distintos: 1500, 800 y 200 bytes para el caso del Switch Ethernet y tama˜nos: 1300, 800 y 300 bytes para el caso de los puntos de acceso. Adem´as, el ancho de banda utilizado en el enlace inal´ambrico para las pruebas en el segundo sistema bajo an´alisis corresponde a BW=11Mbps consiguiendo as´ı saturar el dispositivo. Se ha conluido que ambos sistemas poseen un buffer que presentan una gr´afica de llenado y vaciado en forma de diente de sierra, por lo tanto ambos presentan un l´ımite 6.3 Resultados 39 Sistema bajo an´alisis L´ımite superior L´ımite inferior Switch Ethernet 116 86 Access Point 56 30 Tabla 6.1: L´ımites de llenado y vaciado de los buffer estudiados superior de llenado y un l´ımite inferior de vaciado, descart´ando paquetes cuando el buffer lleno. Estos l´ımites pueden consultarse en la siguiente tabla: A continuaci´on podemos ver el mecanismo de llenado y vaciado del Switch Ethernet en donde se aprecian los l´ımites superior e inferior de llenado y vaciado del buffer. Esta gr´afica es la generada por nuestra herramienta, y debido a la cantidad de paquetes capturados, no se puede ver con tanto detalle c´omo esper´abamos. Adem´as, se han generado varias r´afagas y se ha capturado y graficado el tiempo entre dos de ellas. Podemos ver que la velocidad de llenado del buffer en este caso es mayor que la velocidad de vaciado: Figura 6.2: Ocupaci´on del buffer para tr´afico uniforme 1500bytes vs Tiempo (ms) Queremos representar el archivo anterior (graphic prueba 1500.txt) con un poco m´as de detalle. Gracias a que nuestra herramienta genera una versi´on del archivo en .CSV (Comma Separated Value) se puede tratar con un entorno matem´atico y obtener una imagen como la que presentamos a continuaci´on: 40 Caracterizaci´on de entornos Figura 6.3: Detalle ocupaci´on del buffer para tr´afico uniforme 1500bytes vs Tiempo (ms) El mecanismo de llenado as´ı como los l´ımites superior e inferior es exactamente igual para los tres tama˜nos de paquetes en ambos sistemas, por lo que se concluye que el buffer de ambos dispositivos esta definido a nivel de paquetes y no de bytes. El tama˜no del paquete no influye en los l´ımites de llenado y vaciado del buffer al estar ´este definido por n´umero de paquetes y no por bytes pero s´ı que influyen en la velocidad con la que se llena o se vac´ıa dicho buffer. En la gr´afica siguiente, podemos comprobar como para dos tr´aficos con tama˜nos distintos de paquete (1500 vs 800) el Switch Ethernet posee un buffer con l´ımites superior e inferior de 116 y 86 para ambos, pero podemos obrservar que el tiempo que tarda en llenarse y vaciarse no es el mismo, llen´andose el buffer mucho antes para el tama˜no de paquete de 800 bytes. Figura 6.4: Velocidad de llenado y vaciado del buffer del Switch Ethernet 6.3 Resultados 41 Para el punto de acceso el ancho de banda de la transmisi´on va a jugar un papel importante, no en los l´ımites superior e inferior del buffer, puesto que al igual que para el Switch permanecen constantes para cualquier ancho de banda y tama˜no de paquete, pero si lo har´a en la velocidad de llenado y vaciado del mismo y para un mismo tama˜no de paquete. 7. Conclusiones y L´ıneas futuras 7.1. Conclusiones La metodolog´ıa de trabajo propuesta, nos ha permitido realizar una serie de pruebas sobre diversos flujos de tr´afico. Con todo ello hemos obtenido resultados de comportamiento del tr´afico en la red, aspectos de calidad de entornos reales y la identificaci´on de par´ametros caracter´ısticos de dichos entornos. Adem´as se ha buscado desarrollar una herramienta de trabajo que facilite al usuario la captura y an´alisis de distintos flujos de informaci´on automatizando, en la medida de lo posible, los procesos necesarios. Los objetivos presentados al comienzo del proyecto se fueron modificando durante su desarrollo para adecuarlos al trabajo que se estaba realizando y a los resultados que se estaban obteniendo. De esta manera, se ha conseguido una herramienta que permite capturar el tr´afico de una aplicaci´on o servicio en la red de forma automatizada y desatendida para el usuario. A modo de ejemplo, c´omo resultado de las pruebas hemos obtenido el modelo que presentan los flujos de tr´afico para varias aplicaciones multimedia, y extrayendo conclusiones sobre los mismos, como son la mayor sencillez de los modelos para tr´afico de videovigilancia frente a la complejidad presentada para el sistema de streaming. Se ha automatizado tambi´en el proceso de generaci´on de flujos de tr´afico previamente conocidos, utiliz´andolos para realizar pruebas de calidad tanto de aplicaciones como de sistemas. As´ı se ha comprobado la calidad que presenta una aplicaci´on al atravesar un sistema y el n´umero de aplicaciones que presenta dicho sistema antes de provocar deterioro en la informaci´on. Por ´ultimo y gracias a estas pruebas previas, se ha desarrollado una herramieta que permite al usuario caracterizar entornos reales, bas´andose en el an´alisis del tr´afico que atraviesa el sistema y que previamente ha sido capturado y generado. Con estas pruebas se han obtenido caracter´ısticas como retardos, p´erdidas y tama˜nos de buffer, posibilitando en todo momento la automatizaci´on del proceso. 44 Conclusiones y L´ıneas futuras Como en los casos anteriores, a modo de ejemplo se concluy´o que el mecanismo de llenado y vaciado tanto del punto de acceso WIFI, c´omo del switch ethernet utilizado es de tipo diente de sierra con unos l´ımites superiores e inferiores constantes en ambos casos y con una velocidad de llenado mucho mayor que la velocidad de vaciado del buffer. 7.2. L´ıneas futuras Como se ha dicho en el apartado de conclusiones la finalizaci´on del proyecto ha permitido el desarrollo de una herramienta de an´alisis para flujos de tr´afico. En el futuro, podr´ıan ser llevadas a cabo diversas mejoras y ampliaci´on de las funcionalidades de dicha herramienta. Algunas mejoras se nombran a continuaci´on: 1. Se podr´ıa a˜nadir la funcionalidad a la herramienta que permitiera la obtenci´on de forma automatizada de los modelos que siguen los flujos de informaci´on analizados; ya que esta tarea se sal´ıa de los objetivos del proyecto. 2. Se podr´ıa mejorar la funcionalidad de generaci´on y captura de tr´afico de manera que no fuera necesario disponer de una conexi´on f´ısica en el equipo de salida del sistema a caracterizar pudiendo encontrarse en otra ubicaci´on. Actualmente se esta trabajando en el grupo en esta mejora. 3. Se podr´ıan realizar medidas de calidad de los dispositivos analizados utilizando un tercer equipo que nos permita introducir p´erdidas en el sistema. 4. Podr´ıan a˜nadirse otros par´ametros a capturar en el script de caracterizaci´on de entornos, ya que ahora mismo s´olo se dispone de retardos, tasa de p´erdida y tama˜no del buffer. Adem´as, las pruebas realizadas se han hecho para escenarios comunes y para equipos y aplicaciones de las que dispon´ıamos en el laboratorio. Ser´ıa interesante probar la herramienta en otros escenarios y para otras aplicaciones multimedia, as´ı como caracterizar los buffers de otros equipos y fabricantes que debido a la limitaci´on de tiempo no se ha podido realizar. Decir por ´ultimo que la herramienta desarrollada va a ser utilizada por el grupo para realizar capturas y medidas de calidad en el sistema de videoconferencia de una manera m´as exhaustiva y espec´ıfica pues se estan realizando otros estudios sobre dicho sistema Vydio. Bibliograf´ıa [1] L.A. Casadesus Pazos, J.Fernandez Navajas, J. Ruiz Mas, J.M. Salda˜na Medina, J.I. Aznar Baranda, y E. Viruete Navarro, Herramienta para automatizaci´on de medidas de tiempo real extremo a extremo, Actas del XXVI Simposium Nacional de la Union cientifica Internacional de Radio (URSI 2011), Legan´es (Espa˜na). ISBN 9788493393458. Septiembre 2011. [2] W. Almesberger, Linux Network Traffic Control - Implementation Overview. [3] STANIC, Milan P. tctraffic control - Linux QoS control tool. [4] A. Keller, Manual tc Packet Filtering and netem ETH Zurich, July 20, 2006. [5] C. Villamizar and C. Song , High performance tcp in ansnet, SIGCOMM Comput Commun. Rev., vol. 24, pp.45-60, October 1994. [Online] Avaible: http://doi.acm.org/10.1145/205511.205520 [6] A. Golaup, H. Aghvami A multimedia traffic modeling framework for simulation-based performance evaluation studies Computer Networks, vol. 50, no. 12, pp. 2071-2087, 2006, network Modelling and Simulation. [7] http://www.videolan.org/. [8] IEEE Standard for Information Tecchnology. Wireless lan medium access control (mac) and physical layer (phy) specifications. Technical report, IEEE Computer Society, 2007. [9] Telecomunication Standardization Sector of ITU. G.729 coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (cs-acelp). Technical report, International Telecomunication Union, 2007. [10] G. Appenzeller, I. Keslassy, N. McKeown emphSizing Router Buffers, SIGCOMM 2004. [Online] yuba.stanford.edu/ nickm/papers/sigcomm2004.ps [11] A Vishwanath, V Sivaraman, and G N Rouskas. Considerations for sizing buffers in optical packet switched networks. IEEE INFOCOM 2009 The 28th Conference on Computer Communications, pages 1323−1331, 2009. 52 Configuraci´on de las aplicaciones Figura C.4: Configuraci´on de la emisi´on del streaming. Paso 1 Ahora la aplicaci´on pedir´a la ruta donde se encuentra el archivo con el que vamos a realizar el streaming. Una vez le hemos indicado el archivo le damos a emitir. Los pasos que vienen a continuaci´on forman parte del proceso de configuraci´on de la aplicaci´on. Vamos a introducir el tipo de protocolo elegido para la transmisi´on as´ı como la codificaci´on elegida tal y como se ve en la siguiente imagen: Figura C.5: Configuraci´on de la emisi´on del streaming. Paso 2 C.2 VLC 53 La opci´on Display locally nos permite reproducir el archivo en local, pudiendo comprobar que se esta emitiendo el archivo deseado y de manera correcta. Vamos a elegir el tipo de protocolo a utilizar de la lista de protocolos posibles. Una vez elegido debemos darle al boton a˜nadir pues nos pedir´a informaci´on distinta para cada protocolo para poder realizar el streaming. Figura C.6: Configuraci´on de la emisi´on streaming. Paso 3 Para el ejemplo de la imagen se ha elegido un protocolo de transmisi´on RTP. Debemos introducir la direcci´on de la m´aquina que va a actuar como cliente y el puerto de la misma (en nuestro caso hemos utilizado un puerto situado entre el 5000 y 8000). Adem´as debemos elegir la codificaci´on utilizada de entre las existentes. En nuestro caso, no hemos activado la codificac´on porque queremos obtener los flujos de informaci´on del streaming sin ninguna codificaci´on de los mismos. Cuando hemos configurado los par´ametros del streaming le damos a emisi´on. Por ´ultimo, aparece una ventana donde aparecen los par´ametros configurados en modo comando. Antes de finalizar y darle a emitir el archivo seleccionado debemos configurar y lanzar la recepci´on en el equipo que act´ua como cliente. Equipo Cliente: Este paso es m´as rapido y sencillo pues s´olo debemos lanzar la recepci´on del streaming en nuestro equipo. Para ello, una vez lanzada la aplicaci´on VLC en el equipo, iremos de nuevo al menu principal y elegiremos la opci´on Medio→Abrir Volcado de Red...:N 54 Configuraci´on de las aplicaciones Figura C.7: Configuraci´on de la recepci´on del streaming. Paso 1 Ahora nos aparece una ventana en la que tenemos que introducir los mismos par´ametros utilizados para configurar la emisi´on. Por lo tanto elegiremos como protocolo usado RTP, pero en este caso no debemos introducir direcci´on ni puerto pues es este equipo el que esta recibiendo. A continuaci´on le damos al bot´on Abrir, y ya tenemos el equipo cliente preparado para recibir el streaming, por lo tanto ya s´olo debemos volver al equipo servidor y darle al bot´on emisi´on. D. Scripts D.1. Script de captura de tr´afico (captura.sh) echo “PROCESO DE CAPTURA DE DATOS ” echo “Cuanto tiempo quiere que duren las capturas (en minutos)?” read TIEMPO let A=$TIEMPO let B=60 let C=$A*$B echo “Cuantas capturas quiere realizar?” read CAPTURAS echo “Cuanto tiempo quiere que pase entre cada captura (0 en caso de continuas)?” read ESPERA echo “Escriba la direccion de la fuente” read DIRECCION echo “La direccion es del tipo X.X.X.X: y/n?” read RESPUESTA echo “Escriba el puerto de la direcci´on fuente: ” read PUERTO echo “Que interfaz quiere capturar (eth0,eth1,...)?” read INTERFAZ case $RESPUESTA in Y|y) echo ‘PUEDE CONTINUAR CON EL PROCESO” ;; n|N) echo “NO ELIGIO NINGUNA OPCION VALIDA” exit ;; esac echo “Elija el protocolo usado: TCP, ICMP, IP, RTP, UDP” read PROTOCOLO case $PROTOCOLO in 56 Scripts icmp|ICMP) ;; ip|IP) ;; tcp|TCP) ;; rtp|RTP) ;; udp|UDP) ;; ?) echo ”SE HA EQUIVOCADO” exit ;; esac k=0 while [ $k -lt $CAPTURAS ]; do tcpdump -i $INTERFAZ -w programawk $k& sleep $C rm ./fichproc ps aux |grep ”tcpdump”|cut -b 10-14 >./fichproc fich=“./fichproc” read PROC<$fich kill -15 $PROC cp programawk $k ./captures k=$(($k+1)) sleep $ESPERA done rm programawk* cd ./captures echo “Procesado de las capturas” for x in ‘ls‘ do tcpdump -i $INTERFAZ src $DIRECCION and src port $PUERTO and ip proto $PROTOCOLO -r $x>$x.txt awk ’{print $1,$12,$14}’$x.txt >final1.txt tr -d : <final1.txt>final2.txt tr -d , <final2.txt>final3.txt tr -d . <final3.txt>$x.txt rm $x done rm final* clear echo ”GENERACION GRAFICAS JPEG ” echo “set terminal png”>graphic.gnuplot D.2 Script de generaci´on y captura (generacion.sh) 57 echo “set autoscale # scale axes automatically”>> graphic.gnuplot echo “unset log # remove any log-scaling”>> graphic.gnuplot echo “unset label # remove any previous labels”>> graphic.gnuplot echo “set xtic auto # set xtics automatically”>> graphic.gnuplot echo “set ytic auto # set ytics automatically”>> graphic.gnuplot echo “set output ‘salida.png’ ”>> graphic.gnuplot echo “set key bottom right nobox”>> graphic.gnuplot echo “set title ‘Modelado de trafico IP’ ”>> graphic.gnuplot echo “set xlabel ‘Time (microseconds)’ ”>> graphic.gnuplot echo “set ylabel ‘Tama˜no (packets)’ ”>> graphic.gnuplot echo “plot ‘pincho1.txt’ ”w impulses >> graphic.gnuplot gnuplot <graphic.gnuplot D.2. Script de generaci´on y captura (generacion.sh) # Compartici´on de claves # Este proceso solo debe realizarse una vez asi que preguntara al usuario si es la #primera vez y compartira las claves, sino NO read -p “Es la primera vez que va a generar trafico de evaluacion (si/no)?” RESPUESTA CONFIGURE case $RESPUESTA CONFIGURE in si|S|s|S) read -p “Remote username:” USERNAME read -p “Remote ip:” REMOTEIP ./configure $USERNAME $REMOTEIP ;; no|NO|n|N) ;; esac mkdir capturas generacion # Configuracion del XML echo “A continuacion debe introducir los datos de generacion de los flujos” read -p “Nombre del proyecto: ”NOMBRE read -p “Nombre del test: ”NOMBRE TEST read -p “Fecha de Inicio, en formato DD/MM/YYYY HH:MM:SS: ”FECHA INICIO read -p “Fecha de Fin, en formato DD/MM/YYYY HH:MM:SS: ”FECHA FIN read -p “Tama˜no de la cabecera (en bytes): ” CABECERA read -p “Tiempo de espera antes iniciar (en segundos): ” ESPERA read -p “Local Host, en formato XXX.XXX.XXX.XXX: ”HOST read -p “Local Interface (eth0,eth1...): ” INTERFAZ read -p “Local Port: ”PORT LOCAL read -p “Remote Host: ” REMOTO read -p “Remote Interface” INTERFAZ REMOTO read -p “Remote Port: ”PORT REMOTO 58 Scripts read -p “Frecuencia (tiempo en segundos): ”FRECUENCIA read -p “Numero de Rafagas: ”NUM RAFAGAS read -p “Tiempo entre rafagas (en segundos): ”TIME RAFAGAS read -p “Numero de paquetes por rafaga: ”PAQUETES read -p “Tiempo entre paquetes (en segundos): ”TIME PAQUETES read -p “Tama˜no del paquete: ”TAMANO PAQUETE read -p “Trafico de ida (pulse 0) o trafico de ida y vuelta (pulse 1): ”TIPO read -p “Numero de repeticiones: ” REPETICIONES echo “Ahora debe introducir los datos de la captura” read -p “Numero de capturas: ” CAPTURAS read -p “Cuanto tiempo quiere capturar (en segundos): ”TIEMPO CAPTURA read -p “Donde quiere capturar el trfico: 0 destino, 1 origen, 2 ambos:”DONDE read -p “Cuanto tiempo de guarda quiere aplicar a la captura?”TIEMPO GUARDA # Proceso de generaci´on del archivo XML con el que generaremos el tr´afico de evaluaci´on echo “<test>”>test.xml echo “<description>”>> test.xml echo “<id>$NOMBRE</id>< −− id −− >”>> test.xml echo “<text>$NOMBRE TEST</text><!− − Test desciption −− >”>> test.xml echo “<beginningDate>$FECHA INICIO</beginningDate> <!− − “DD/MM/YYYY HH:mm:ss”−− >”>> test.xml echo “<endDate>$FECHA FIN</endDate>¡−− “DD/MM/YYYY HH:mm:ss”−− >”>> test.xml echo “<headerSize>$CABECERA</headerSize>< −− Tama˜no del header del paquete de los paquetes, para calcular ancho de banda −− >”>> test.xml echo “</description>”>> test.xml echo “<stream>”>> test.xml echo “<beginWait>$ESPERA</beginWait><!− − time in seconds. iniciar este tiempo despues de la hora de inicio −− >”>> test.xml echo “<localHost>$HOST</localHost>”>> test.xml echo “<localInterface>$INTERFAZ</localInterface>”>> test.xml echo “<localPort>$PORT LOCAL </localPort>”>> test.xml echo “<remoteHost>$REMOTO</remoteHost>”>> test.xml echo “<remoteInterface>$INTERFAZ</remoteInterface>”>> test.xml echo “<remotePort>$PORT REMOTO</remotePort>”>> test.xml echo “<frequency>$FRECUENCIA</frequency><!− − time in seconds. 0 just once and stop −− >”>> test.xml echo “<numberOfBursts>$NUM RAFAGAS</numberOfBursts>”>> test.xml echo “<timeBetweenBursts>$TIME RAFAGAS</timeBetweenBursts><!− − time in microseconds −− >”>> test.xml echo “<numberOfPackets>$PAQUETES</numberOfPackets>”>> test.xml echo “<timeBetweenPackets>$TIME PAQUETES</timeBetweenPackets><!− − time in microseconds −− >”>> test.xml D.2 Script de generaci´on y captura (generacion.sh) 59 echo “<packetsSize>$TAMANO PAQUETE</packetsSize><!− − Tama˜no del payload del paquete −− >”>> test.xml echo “<rtt>$TIPO</rtt><!− − Indica si el trafico va a ser capturado en el emisor. 1 si (rtt). 0 no (one way).−− >”>> test.xml echo “<file></file><!− − nombre del fichero de tama˜nos y tiempos, dejarlo vacio si no es necesario −− >”>> test.xml echo “<burstFile></burstFile¿”>> test.xml echo “<numberOfRepetitions>$REPETICIONES¡/numberOfRepetitions¿¡!– repeat this communication. 0 just one thread –¿”>> test.xml echo “<codec></codec><!− − codec en caso de audio. Admite G729a y G711, dejar en blanco si no es audio −− >”>> test.xml echo “<dejitterBufferDelay></dejitterBufferDelay><!− − en caso de audio −− >”>> test.xml echo “</stream>”>> test.xml echo “<capture>”>> test.xml echo “<localHost>$LOCAL HOST</localHost>”>> test.xml echo “<remoteHost>$REMOTE HOST</remoteHost>”>> test.xml echo “<frequency>$FRECUENCIA< /frequency><!− − time in seconds. 0 just once and stop −− >”>> test.xml echo “<timeBetweenBursts>$TIME RAFAGAS</timeBetweenBursts><!− − time in seconds −− >”>> test.xml echo “<numberOfCaptures>$CAPTURAS< /numberOfCaptures><!− − number of captures −− >”>> test.xml echo “<time>$TIEMPO CAPTURA</time><!− − time to capture in seconds –¿))¿test.xml echo “<file></file><!− − tiempo a capturar, frecuencia −− >”>> test.xml echo “<capture>$DONDE</capture><!− − Indica donde el trafico va a ser capturado. O destino, 1 origen, 2 ambos extremos−− >”>> test.xml echo “</capture>”>> test.xml echo “</test¿”>> test.xml # Lanzamos el ETG, que generara tr´afico y me hara una captura del origen ./etg test.xml tcpdump -i eth0 cp D* ./capturas generacion # Ahora se ha generado un archivo donde tendremos toda la informaci´on empieza por D # y lo copiamos en la carpeta de resultados cd ./capturas generacion for x in ‘ls‘ do tcpdump -r $x -nn -tt -x dst $REMOTO and dst port $PORT REMOTO >pincho1.txt # NUMERO DE SECUENCIA EN HEXADECIMAL # # Aqui lo que vamos a obtener es el numero de secuencia en hexadecimal de la trama obtenida de la captura para el trafico de entrada al buffer awk ’ BEGIN { FS=“ ” cont=1 60 Scripts } { if (cont==1) { printf $1 “\t” printf $9 “\t” } if (cont==3) { printf $9 } if (cont==4) { printf $2 printf $3 “\n” } cont++ if (cont==7) { cont=1 } } ’ pincho1.txt >entrada.txt # swap and erasing ( size ) and erasing . # Obtenemos un fichero del trafico a la entrada del buffer que tendra en columnas: # Columna 1 Columna 2 Columna 3 # Numero de secuencia (hexadecimal) Tiempo origen Tama˜no awk ’{printf $3 “\t”$1 “\t”$2 “\n”}’ entrada.txt >temp.txt tr -d . <temp.txt>temp2.txt sed -i “s/)//g”temp2.txt sed -i “s/(//g”temp2.txt cp temp2.txt entrada1.txt rm temp.txt rm temp2.txt # NUMERO DE SECUENCIA EN DECIMAL # # Obtenemos un fichero del trafico a la entrada del buffer que tendra en columnas: # Columna 1 Columna 2 Columna 3 # Numero de secuencia (decimal) Tiempo origen Tama˜no awk ’ BEGIN { FS=“ ” pos=1 } { while (pos<13) { if (substr($pos,1) == “3”) { pos=pos+1 printf $pos D.2 Script de generaci´on y captura (generacion.sh) 61 pos=pos+1 } if (substr($pos,1) == “2”) { pos=13 } } printf “\t” printf $2 “\t”$3 “\n” pos=1 } ’ entrada1.txt >entradaNStemp.txt # CREO ARCHIVO FINAL ENTRADA # awk ’ BEGIN{ } { getline a <“entradaNStemp.txt” printf $2 “\t”$3 “\t”a“\n” } ’ entrada1.txt >entrada2.txt # Ahora tengo el archivo con informaci´on de entrada y salida en uno lo tengo que desglosar en dos # archivo de entrada awk ’ BEGIN { igual=0 } while ($1=igual) printf $1 “\t”$2 “\t”$3 “\n” igual++ } }’ entrada2.txt >entradaNS.txt # archivo de salida awk ’ BEGIN{ igual=0 } while ($1=igual){ igual++ } if ($1==igual){ printf $1 “\t”$2 “\t”$3 “\n” } }’ entrada2.txt >salidaNS.txt }’ entrada2.txt ¿salidaNS.txt