Universidad Carlos III

Transcripción

1 Universidad Carlos III ESCUELA POLITÉCNICA Ingeniería Técnica de Telecomunicación, Telemática Diseño y Desarrollo de una Aplicación Para el Estudio Comparativo de Topologías de Red Autor: José Miguel Vázquez Viejo Tutor: Isaac Seoane Pujol Co-Tutor: Isaías Martínez Yelmo

2 Este trabajo se encuentra bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 España. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Spain License.

3

4 IV

5 Resumen Este proyecto consiste en el diseño e implementación de una aplicación para, a partir de una topología de red descrita en un fichero XML, generar topologías básicas equivalentes, para su simulación y estudio. La aplicación, además, integra los módulos de simulación necesarios y ofrece al usuario un entorno para realizar un estudio comparativo de las gráficas obtenidas con los resultados de las simulaciones. En una primera parte se estudian las diferentes tecnologías de conmutación óptica y las funcionalidades del simulador NS-2 con los diferentes tipos de tráfico utilizado. En la segunda parte, se detalla el diseño y la implementación de una aplicación para facilitar el estudio comparativo de diferentes topologías de red. Para terminar, se estudian diferentes pruebas para comprobar el funcionamiento de la aplicación y se realiza una explicación de las gráficas con los resultados obtenidos. Palabras Clave Simulación, Redes ópticas

6 VI

7 Abstract This project consists on the design and implementation of an application to study and compare the performance of different network topologies. Based on a initial network topology describe in a XML file, the application creates the description of equivalent basic topologies for their simulation and study. The simulation modules required are also integrated into the chosen NS-2 simulator and managed from the developed application. It also provides the user with a graphical environment to compare the output data using a set of charts. First, optical switching technologies are briefly studied as also the NS-2 simulator and the modules required to generate different traffic pattern distributions. Next, the design and development of the application which allows to compare the network topologies are detailed. And finally, in order to guarantee the correct performance of the complete system, some validation tests have been made: the explanation of the results and the obtained charts are deeply described. Keywords Simulation, Optical networks

8

9 Agradecimientos En primer lugar me gustaría agradecer a mi familia por todos los valores que me han inculcado para ser mejor persona, por todo su apoyo y dedicación durante tantos años, incluso en los momentos tan difíciles que nos ha tocado vivir, confiando ciegamente en mí y por permitirme tomar las decisiones que yo consideraba más acertadas para mi futuro. También quiero agradecer a mi tutor Isaac todo el apoyo que me ha ofrecido, que no es poco; por no darme nunca por perdido y por ofrecerme la oportunidad de realizar este proyecto bajo su tutela y guía. También agradecer a Isaías su preocupación por el estado del proyecto a pesar de la distancia. A mis amigos de Pinto, Tote por esas batallas en el 41º milenio, Diana por esos días largos de estudio en tan inmejorable compañía y Bea por tantos buenos momentos que me hace pasar con sus locuras. Y aunque no lo lean, a mis amigos del barrio Adri, Javi, Keko y Víctor, porque trece años no se olvidan. Y cómo olvidar a mi otra familia, la integrada por toda esa gentucilla que me hace sentir tan bien y por tan diversos motivos. Adal, Aída, Carlitos, Deivid, Dieguete, Elenita, Gsus, Lisar, Rober, Samu y Virgi. Y por supuesto a los que considero como mis hermanos, Miguel y Pablete. Y por último, pero no por ello menos importante a Ruth, por todo su incondicional apoyo y confianza, por tantos y tan buenos momentos que hemos compartido y porque sin ella todo esto no tendría ningún sentido.

10

11 Índice general Glosario XXIII 1. Introducción Contexto Objetivos Contenido Estado del arte Redes ópticas OCS OPS OBS Resumen de planificación de WDM Simuladores de Red NS NS OMNeT OPNET XI

12 ÍNDICE GENERAL KivaNS CNET Resumen del estudio de los simuladores Teoría de colas M/M/ M/M/c G/G/c Teorema de Jackson Generadores de tráfico Herramientas Simulador NS Características Funcionamiento Java JDOM JFreeChart Commons-Math Entorno de desarrollo SNDlib Descripción de la aplicación Funcionalidad Simulador NS Integración XII

13 ÍNDICE GENERAL Generadores de tráfico utilizados Parser Parser de XML Generador de ficheros de ns Analizador de resultados GUI Interfaz de usuario Gráficas de resultados Ampliar funcionalidad Diagrama de clases simplificado Validación Pruebas a realizar Pruebas de carga Pruebas con carga baja en los enlaces Pruebas con carga media en los enlaces Pruebas con carga alta en los enlaces Pruebas de retardo Pruebas con tiempos de retardo bajo en los enlaces Pruebas con tiempos de retardo medio en los enlaces Pruebas con tiempos de retardo altos en los enlaces Estudio del estado de las colas de espera en los nodos Pruebas con demandas bajas Pruebas con picos de demanda Simulación de otros escenarios XIII

14 ÍNDICE GENERAL 6. Conclusiones y trabajo futuro Conclusiones Trabajo futuro A. Presupuestos 107 A.1. Tareas A.2. Costes A.2.1. Personal A.2.2. Material A.2.3. Costes indirectos A.3. Resumen A.3.1. Totales B. Manual de usuario 113 B.1. Descripción B.1.1. Pantalla Configuración B.1.2. Pantalla Opciones de Simulación B.1.3. Pantalla Esquema de la Red B.1.4. Pantalla Demandas de Tráfico B.1.5. Pantalla de Enlaces entre nodos B.1.6. Pantalla de Gráficas de resultados C. Manual de instalación 135 C.1. Instalación NS C.2. Instalación NAM XIV

15 ÍNDICE GENERAL D. Cambios en ficheros para la compilación de NS 139 E. Clases 145 E.1. Clases E.2. Diagrama de clases F. Ejemplos de ficheros 151 F.1. Fichero XML de SNDlib F.2. Fichero de trazas F.3. Fichero esqueleto F.4. Fichero para simular XV

16 ÍNDICE GENERAL XVI

17 Índice de Figuras 2.1. Esquema de WDM Esquema de nodo intermedio OPS Esquema de envío de tramas OBS Esquema de nodo intermedio OBS Protocolo JET Algoritmos de planificación OBS NAM OMNeT++ IDE Red OBS en OMNeT Dominios de OPNET Arquitectura de KivaNS Bloques del API de KivaNS Interfaz gráfico de KivaNS Interfaz gráfico de CNET Esquema de sistema M/M/ Función de densidad exponencial Función de distribución exponencial XVII

18 ÍNDICE DE FIGURAS 2.18.Esquema de sistema M/M/c Esquema de sistema G/G/c Esquema tráfico CBR Esquema tráfico Exponencial Curva de Koch Tráfico observado en una red Ethernet Esquema tráfico Autosimilar Gráfica de barras y series con JFreeChart Histograma con JFreeChart NetBeans Ejemplo de topología parseada Ejemplo de topología parseada en anillo Ejemplo de topología parseada en malla Ejemplo de topología parseada en estrella Diagrama parseo de XML Diagrama para generar fichero NS Diagrama de simulación Diagrama de análisis de trazas Diagrama de clases simplificado Red NFSNET, Europa y Polonia Prueba con baja carga para NFSNET Prueba con baja carga para Europa Prueba con baja carga para Polonia XVIII

19 ÍNDICE DE FIGURAS 5.5. Prueba con carga media para NFSNET Prueba con carga media para Europa Prueba con carga media para Polonia Prueba con carga alta para NFSNET Prueba con carga alta para Europa Prueba con carga alta para Polonia Prueba retardo bajo en enlaces para NFSNET Prueba retardo bajo en enlaces para Polonia Prueba retardo medio en enlaces para NFSNET Prueba retardo medio en enlaces para Polonia Prueba retardo alto en enlaces para NFSNET Prueba retardo alto en enlaces para Polonia Prueba sin carga Prueba con picos de carga Esquema de la M Colas en los nodos con apoyo de anillo interior. Congestión 50% Colas en los nodos sin apoyo de anillo interior. Congestión 50% Colas en los nodos con apoyo de anillo interior. Congestión 90% Colas en los nodos sin apoyo de anillo interior. Congestión 90% B.1. Pantalla de Configuración B.2. Simulación en curso B.3. Analizando y generando gráficas B.4. Topología en anillo recién abierta B.5. Topología en anillo XIX

20 ÍNDICE DE FIGURAS B.6. Topología en estructurada B.7. Pantalla Opciones Simulación B.8. Pantalla Esquema de la Red B.9. Pantalla Demandas de Tráfico B.10.Modificación de la primera demanda de tráfico B.11.Pantalla de Enlaces entre nodos B.12.Diálogo para añadir capacidad B.13.Gráficas de Tráfico B.14.Gráficas de Colas B.15.Gráficas de Retardo C.1. NAM E.1. Diagrama de clases XX

21 Índice de Tablas 2.1. Tabla comparación algoritmos de planificación Tabla comparación tecnologías conmutación óptica Tabla comparación simuladores de red A.1. Duración estimada de las tareas A.2. Salarios de especialistas A.3. Coste del personal A.4. Coste de licencias A.5. Costes indirectos A.6. Costes indirectos A.7. Presupuesto total XXI

22 ÍNDICE DE TABLAS XXII

23 Glosario A ACK (Acknowledgment) acuse de recibo, p. 11. AON (All Optical Networks) redes completamente ópticas, p. 7. ARP (Address Resolution Protocol) protocolo de resolución de direcciones, p. 22. C CBR (Constant Bit Rate) tasa de envío constante, p. 32. F FDL (Fiber Delay Lines) líneas ópticas de retardo; memoria óptica, p. 6. G Geometría Computacional se basa en aplicar algoritmos de geometría clásica en el ámbito de algoritmos de programación, p. 13. GUI (Graphical User Interface) interfaz gráfica de usuario, p. XIII. XXIII

24 GLOSARIO I ICMP (Internet Control Message Protocol) protocolo de mensajes de control de internet, p. 22. IP (Internet Protocol) protocolo de internet, p. 22. J JVM (Java Virtual Machine) máquina virtual de java, p. 61. N NACK (Negative Acknowledgment) acuse de recibo negativo, p. 11. NAM (Network Animator) animador de red, p. 17. O OBS (Optical Burst Switching) conmutación óptica de ráfagas, p. 9. OCS (Optical Circuit Switching) conmutación óptica de cirtuitos, p. 7. O/E/O conversión óptica-eléctrica-óptica, p. 7. OPS (Optical Packet Switching) conmutación óptica de paquetes, p. 8. T Tcl (Tool Comand Language) lenguaje de herramientas de comando, p. 16. TCP (Transmission Control Protocol) protocolo de control de transmisión, p. 37. XXIV

25 GLOSARIO W WDM (Wavelenght Division Multiplexing) onda, p. 5. multiplexación por división de longitudes de X XML (Extensible Markup Language) lenguaje de marcas extensible, p XXV

26 Capítulo 1 Introducción 1.1. Contexto Dado el gran aumento que han sufrido tanto las necesidades de ancho de banda en las redes, como la cantidad de usuarios conectados a las mismas, las velocidades experimentadas con los tradicionales bucles de abonado de par de cobre se quedan desfasadas en comparación con la cantidad de tráfico que deben gestionar. Con la aparición de las redes de fibra óptica, esas velocidades fueron aumentando en gran medida, llegando a alcanzar un orden de magnitud mayor que las redes eléctricas tradicionales. Aún así, la política de gestión de los recursos no permitía aprovechar todo el potencial que estas nuevas redes ofrecían. Por eso la investigación de nuevas políticas de gestión de los recursos consiguió aumentar de nuevo las velocidades. Pero surge el inconveniente de que los dispositivos de conmutación actuales sólo procesan señales eléctricas, teniendo que transformar la señal óptica a eléctrica para su procesado, lo que de nuevo limita los recursos que se ofrecen. Por esta razón, los diseños futuros para las redes ópticas están enfocados a que la red sea por completo óptica, sin necesidad de procesar la señal en un formato eléctrico. Por otro lado, desde la aparición de las redes informáticas se han querido estudiar las prestaciones, las características y el comportamiento que adoptaban ante diferentes estructuras de tráfico. Por estas razones surgieron los simuladores de red, para poder estudiar redes que de otro modo habría que estar recreando y construyendo físicamente, lo que puede ser una tarea muy costosa, tanto en tiempo como económicamente. 1

27 CAPÍTULO 1. INTRODUCCIÓN La idea inicial del proyecto era la simulación y estudio de anillos de OBS, pero durante la realización del proyecto se fue pensando en posibles ampliaciones. Se decidió no limitar la topología de red a anillos, si no a cualquier topología y realizar un estudio comparativo entre dicha red y otras topologías básicas, no sólo el anillo equivalente. También se tomó la decisión de poder modificar ciertos parámetros de la simulación, así como poder modificar ciertas características de las redes bajo estudio. Por último, se diseñó una vista con diferentes tipos de gráficas para poder analizar y comparar los resultados obtenidos de la realización de las diferentes simulaciones Objetivos El objetivo principal del proyecto consiste en el estudio comparativo de los resultados que se obtienen de la simulación de diferentes topologías de red, pero con unas prestaciones similares. Para conseguirlo, a partir de una topología de red dada, se generan topologías básicas (anillo, malla y estrella) equivalentes y se simulan. A continuación se procesan los resultados obtenidos para facilitar el estudio de la principal y tomar las decisiones pertinentes de diseño y planificación. Para facilitar esta tarea, se desarrolla un interfaz gráfico desde el que se pueden configurar y modificar parámetros de la simulación de forma sencilla e intuitiva, así como ofrecer al usuario una vista con los resultados obtenidos en forma de gráficas. Los objetivos específicos serían: Desarrollar un parser que, a partir de un fichero XML, con la descripción de la topología y sus demandas de tráfico habituales, genere las topologías básicas equivalentes. Diseño de un fichero esqueleto con los parámetros de configuración de las simulaciones a realizar, en el cual, se dejan sin configurar las opciones que se ofrecen al usuario para su modificación. Agregar los módulos para OBS al simulador e integrar dicho conjunto con la aplicación. Desarrollar un parser mediante el cual se procesen los ficheros de trazas obtenidos de las diferentes simulaciones. 2

28 1.3. CONTENIDO Diseñar una vista con diferentes gráficas de resumen de resultados, para facilitar el estudio comparativo de diferentes topologías de red Contenido En la primera parte de la memoria, compuesta por los Capítulos 2 y 3, se estudia el estado actual de las redes ópticas, así como los simuladores de red disonibles y los tráficos utilizados en la simulación. En el Capítulo 3 se detallan las herramientas utilizadas para la realización del proyecto. En la segunda parte, en el Capítulo 4 se detallan las decisiones de diseño tomadas para la realización del proyecto y la manera de implementarlas. Y en el Capítulo 5 se explican las pruebas realizadas para la validación del correcto funcionamiento de la aplicación. Para terminar, en el Capítulo 6 se enumeran las conclusiones obtenidas durante la realización de este proyecto y una serie de líneas de trabajos futuros para la ampliación de la funcionalidad. Además, se ofrecen Apéndices que contienen información útil pero no tenían cabida en la parte principal de esta memoria. En ellos, se puede encontrar el Presupuesto del proyecto, el Manual de la aplicación, el Manual de instalación, los ficheros que se deben modificar para la integración de OBS, las clases que intervienen en la aplicación, y ejemplos con los ficheros que maneja la aplicación. 3

29 CAPÍTULO 1. INTRODUCCIÓN 4

30 Capítulo 2 Estado del arte En este capítulo se hará un estudio de las tecnologías relacionadas con el proyecto: las diferentes tecnologías de conmutación para redes ópticas, los simuladores de red existentes, la teoría de colas y los diferentes generadores de tráfico utilizados Redes ópticas Con el aumento del tráfico en Internet y la cada vez mayor afluencia de usuarios en la red, las velocidades alcanzadas por los bucles de abonado de par de cobre se quedan cada vez más cortas, ya que son del orden de los 100Mbps. Con los enlaces ópticos, se consigue aumentar en gran medida la capacidad de los enlaces, llegando al orden de Gbps en caso de no haber interferencias; además de tener una atenuación muy baja, lo que conlleva una longitud de enlace mayor. Existen varias maneras de gestionar el enlace, pero la que ha resultado más eficaz y la que se usa en la actualidad para solventar el problema del incremento de tráfico y usuarios, ha sido la multiplexación óptica por longitud de onda o WDM [1]. WDM (Wavelenght Division Multiplexing) se sirve de diferentes longitudes de onda para realizar la transmisión de información a través de un medio óptico. La figura 2.1 representa el esquema de funcionamiento de WDM. El esquema de este tipo de redes se compone de enlaces y conmutadores. Los enlaces son fibras ópticas, donde los transmisores son láseres que generan las señales ópticas a partir de señales eléctricas transformadas, y los receptores realizan el proceso inverso; y los conmutadores son componentes de red encargados de dirigir el tráfico hacia 5

31 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.1: Esquema de WDM su destino, previa conversión al dominio eléctrico para el procesado de las cabeceras o paquetes de control. También existen líneas ópticas de retardo, o FDL(Fiber Delay Lines), que son latiguillos de fibra que introducen un retardo entre la entrada y la salida. Estos FDL se utilizan para solventar los problemas que aparecen cuando dos paquetes intentan usar la misma línea de salida a la vez. Como sólo uno de ellos puede ser enviado, se almacena el otro en un buffer, que en el caso de las redes ópticas se trata de los citados FDL. En una topología típica existen dos tipos de nodos. Los nodos externos de la red, encargados de inyectar el tráfico en la red, son conocidos como nodos edge. Y los nodos intermedios, encargados de la conmutación y encaminamiento de los paquetes se llaman nodos core. Como ya se ha dicho, se necesitan conversiones entre los dominios óptico y eléctrico en cada nodo, lo cual, impide aprovechar de manera eficiente el ancho de banda: la señal es convertida al dominio eléctrico, se procesa, y se vuelve a transformar a su forma óptica antes de pasar a la fibra de salida. Por tanto, la eficiencia de la comunicación está limitada por la capacidad de los dispositivos electrónicos del sistema, y aunque en los últimos 6

32 2.1. REDES ÓPTICAS años se ha conseguido un gran avance en cuanto a sus prestaciones, no es suficiente para alcanzar las velocidad de la tecnología óptica. Por estas razones, los diseños futuros de redes WDM se enfocan a la eliminación de las conversiones O/E/O, convirtiéndose en redes AON(All Optical Networks), lo que permitiría alcanzar tasas de transmisión del orden de Tbps. A continuación se explican las diferentes configuraciones en una red WDM para la gestión de las longitudes de onda λ s OCS En OCS [2](Optical Circuit Switching), se crea un circuito, o camino, entre los nodos de la red usando el encaminamiento por longitud de onda que ofrece la capa física, esto es, se reserva una longitud de onda λ para cada par de nodos, y una vez el camino está configurado, los datos permanecen en el dominio óptico hasta su destino, sin necesidad de realizar conversiones O/E/O intermedias. Pero el problema de OCS es que sólo es eficiente cuando existe un gran volumen de tráfico entre los nodos que establecen la conexión, ya que de otro modo, no se haría un uso eficiente de los recursos del enlace, porque la longitud de onda está reservada para ese enlace únicamente. Si la duración del tiempo de transmisión de datos es corta en relación con el tiempo del establecimiento de la conexión, estamos desaprovechando mucho ancho de banda. Otro inconveniente es que el número de longitudes de onda disponibles en cada fibra es limitado, lo que deriva en un problema de flexibilidad y escalabilidad. En una red grande, este limitado número de λ s hace imposible crear una malla de caminos ópticos entre todos los nodos. Además, para cada topología se debe resolver el problema del encaminamiento y alojamiento de las λ s por separado, no existiendo algoritmos que lo resuelvan en un tiempo aceptable. Si además tenemos en cuenta que son redes estáticas, conlleva una baja adaptabilidad a un tráfico cambiante. 7

33 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.2: Esquema de nodo intermedio OPS OPS Para solventar el problema de la limitación en cuanto al número de λ s surge OPS [2](Optical Packet Switching), que es otra posible configuración de WDM. Aprovecha de manera más eficiente el ancho de banda comparado con OCS, ya que en este caso, el tráfico de usuario se transporta junto con la información de control, lo que proporciona un uso más flexible y eficiente del ancho de banda disponible en la capa óptica. Los paquetes pueden transmitirse a través de cualquiera de las longitudes de onda disponibles en cada nodo, y al igual que en las redes eléctricas convencionales, los nodos intermedios se encargan del encaminamiento hacia su destino. El problema de esta tecnología es que los conmutadores, o nodos intermedios, deben procesar los paquetes en el dominio eléctrico, pero viajan de manera óptica, por lo que se necesita realizar una conversión O/E/O, la cual, como ya dijimos, genera un cierto retardo nada despreciable. La manera de encaminar un paquete es leyendo su cabecera, lo que conlleva la conversión entre dominio eléctrico y óptico de la misma. Los datos del paquete se retienen en memoria óptica hasta que se decide por dónde debe ser enviado, y llegado ese momento, se debe configurar la matriz de conmutación en ese nodo. Por lo tanto, el retardo total será la suma de la conversión optico-eléctrica de la cabecera, más el tiempo de configuracón de la matriz de conmutación, más el tiempo de reconstrucción del paquete en el dominio óptico. Podemos ver un esquema del funcionamiento de un nodo intermedio de OPS en la figura

34 2.1. REDES ÓPTICAS Figura 2.3: Esquema de envío de tramas OBS [5] Aunque la conmutación de paquetes ofrece un mejor uso del ancho de banda disponible que OCS, al tener un retardo tan grande, estamos limitando ese ancho de banda y se termina por realizar un mal uso del mismo OBS Se debe buscar un término medio entre OCS y OPS ya que ninguna aprovecha al máximo el ancho de banda disponible en los enlaces, por eso surge OBS [2] [3] [4](Optical Burst Switching), como otra configuración de WDM, que se parece a las dos anteriores. Esto se debe a que el intercambio de información se realiza mediante ráfagas, no con paquetes. Si el tamaño de las ráfagas es muy grande, el esquema se parece a OCS, ya que se estaría bloqueando una longitud de onda durante mucho tiempo. En el otro extremo, si se trata de ráfagas pequeñas, se asemeja a OPS. Además de tener canales exclusivos para la transmisión de los datos, se dispone de canales de control, por donde viajan las cabeceras, o paquetes de control. 9

35 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.4: Esquema de nodo intermedio OBS [5] Creación de ráfagas Cada ráfaga que se envía es ensamblada en el nodo origen, en ella se almacenan en un buffer todos los paquetes con el mismo destino y se asigna una cabecera. De esta manera, se pueden tratar las ráfagas como si fuesen paquetes. Los buffer tienen una capacidad máxima, lo que determina el tamaño máximo de la ráfaga. Antes de enviar la ráfaga se envía un paquete de control, que contiene la información necesaria para el encaminamiento de dicha ráfaga a través de la red. Tras enviar ese paquete por un canal dedicado, el nodo envía la ráfaga de datos. Hay que señalar que el envío del paquete de control y el de la ráfaga de datos se realizan por canales completamente diferentes. Se puede ver un pequeño esquema de este proceso en la figura 2.3. Encaminamiento de ráfagas Los nodos intermedios procesan el paquete de control de manera eléctrica, mediante la conversión pertinente, y planifican los puertos de salida y los instantes de ocupación 10

36 2.1. REDES ÓPTICAS a través de una multiplexación estadística de los canales ópticos, lo que permite que dichos canales puedan ser compartidos por ráfagas de flujos diferentes, lo que mejora la utilización. Se puede ver el esquema del funcionamiento de un nodo intermedio, que dispone de dos canales de datos y uno de control, en la figura 2.4. Mecanismos de reserva de recursos Antes de enviar una ráfaga, los nodos deben reservar los recursos necesarios para que lleguen a su destino sin retardos. La decisión de cómo reservar dichos recursos se toma mediante ciertos mecanismos [3], algunos de los cuales, se explican a continuación: Tell-and-Wait: cuando una fuente desea enviar una ráfaga, primero intenta reservar el ancho de banda/longitud de onda desde la fuente hasta el destino enviando un mensaje de petición. Cada nodo intermedio reserva esa salida específica. Si el ancho de banda es reservado con éxito se envía un ACK para informar a la fuente de que debe enviar la ráfaga inmediatamente. En caso negativo se enviará un NACK, indicando a la fuente que deberá liberar el recurso reservado y esperar un tiempo para volver a intentarlo. Tell-and-Go: cuando una fuente desea transmitir una ráfaga, lo hace sin ningún tipo de reserva previa de recursos. Se envían al mismo tiempo tanto la ráfaga de datos como la cabecera, por lo que, en los nodos intermedios, los datos se deben retrasar antes de que la unidad de control reserve el canal para la salida de los mismos. En caso de fallar la reserva en cualquiera de los nodos intermedios, se envía un NACK a la fuente y pasado un tiempo se inicia la retransmisión de la ráfaga. Just In Time(JIT): está considerado una variante de Tell-and-Wait, ya que cada petición de transmisión se envía a un planificador central. El planificador informa a cada nodo del intervalo de tiempo exacto en el que llegará la ráfaga antes de que se transmita. El término Just-in-Time (justo a tiempo), se refiere a que en el momento en que una ráfaga llega a un nodo intermedio, la matriz de conmutación ya está configurada. Debido a que es un protocolo centralizado, que no es escalable ni robusto, se proponen otras soluciones. Just Enough Time(JET): este es el mecanismo que presenta un mejor uso del ancho de banda. El tiempo que permanecen reservados los recursos en un nodo, 11

37 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.5: Protocolo JET es el tiempo que tarda en configurarse el nodo, más el tiempo que tarda en llegar y transmitirse la ráfaga, más el tiempo que tarda en desconfigurarse. En la figura 2.5 se puede ver que primero se envía la cabecera para después mandar la ráfaga sin procesamientos intermedios, por lo que no sufre retardo alguno. También minimiza el tiempo necesario antes de enviar los datos, ya que sólo notifica que va a llegar una ráfaga y no espera a que se configuren los conmutadores de longitud de onda. En realidad, JET no reserva recursos desde que el paquete de control llega a un nodo hasta que pasa la ráfaga. En su lugar, reserva los recursos de una forma óptima desde que llega la ráfaga hasta que es conmutada. De esta manera, el tiempo que el recurso permanece reservado para la transmisión es óptimo. Algoritmos de planificación En los conmutadores electrónicos convencionales, la contención de los paquetes se resuelve mediante buffers. Pero en redes OBS el almacenamiento es muy limitado o casi 12

38 2.1. REDES ÓPTICAS nulo, por lo que se debe planificar de una manera diferente. Cuando se recibe una ráfaga en un nodo intermedio, su envío se puede planificar sobre múltiples longitudes de onda. Para realizar este cometido se recurre al planificador de ráfagas, que elegirá una longitud de onda adecuada para la ráfaga recibida, siguiendo un algoritmo en concreto. Se define el horizonte de planificación como el último momento en el cual la longitud de onda está planificada para ser usada. Algunos algoritmos de planificación [3] son los siguientes: LAUC(Latest Available Unscheduled Channel)/Horizon: para cada longitud de onda se mantiene un sólo horizonte de planificación. Sólo se eligen los canales cuyos horizontes preceden al tiempo de llegada de la nueva ráfaga, y de entre todos ellos, se elige el que tiene el horizonte menor. El horizonte se actualiza después de hacer la reserva para la siguiente ráfaga. La idea básica de este algoritmo es reducir al mínimo los huecos en el ancho de banda creados al hacer una reserva. LAUC-VF(Void Filling): la simplicidad en operación e implementación es la principal ventaja de los algoritmos basados en Horizon, pero se malgastan huecos entre dos reservas existentes. Por lo tanto, los algoritmos capaces de rellenar los vacíos (con nuevas reservas en los huecos existentes) son más adecuados. Se han definido algunas variantes de este algoritmo: Min-SV(Starting Void): funciona igual que LAUC-VF pero se alcanza un punto óptimo más rápido, usando técnicas de Geometría Computacional. Min-EV(Ending Void): intenta minimizar el nuevo hueco entre el final de una nueva reserva y una ya existente. Best Fit: intenta minimizar la longitud total del principio y del final de los vacíos generados después de la reserva. En la figura 2.6 se puede ver un esquema de los algoritmos descritos y en la tabla 2.1 se muestra una comparación entre los mismos, siguiendo la siguiente notación: W : Número de longitudes de onda en cada puerto de salida. 13

39 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.6: Algoritmos de planificación OBS Algoritmo Complejidad temporal Información de estado Uso del ancho de banda LAUC O(W) Horizon i Bajo LAUC-VF O(WlogM) S i, j, E i, j Alta Min-SV/EV O(logM) S i, j, E i, j Alta Best Fit O(log 2 M) S i, j, E i, j Alta Tabla 2.1: Tabla comparación algoritmos de planificación M: Máximo número de ráfagas (o reservas) en todos los canales. Horizon: Horizonte del canal i. S i, j y E i, j : Tiempo inicial (S) y final (E) de la reserva j del canal i. 14

40 2.1. REDES ÓPTICAS Uso BW Latencia Tolerancia fallos Granularidad Dificultad impl. OCS Bajo Alta Baja Baja Bajo OPS Alto Baja Alta Alta Alto OBS Moderado Baja Media Moderada Moderado Tabla 2.2: Tabla comparación tecnologías conmutación óptica Viendo la tabla, el algoritmo Min-SV/EV es el mejor entre los de Void Filling. De hecho, se puede reducir al mínimo el nuevo vacío generado, buscando primeramente un vacío apropiado usando Min-EV, y después si no se encuentra un vacío apropiado, buscar el horizonte usando Min-SV Resumen de planificación de WDM Tras analizar las diferentes tecnologías de conmutación óptica se puede hacer un resumen de las mismas, expuesto en la tabla 2.2: Además, la tecnología OBS ofrece la siguiente serie de ventajas respecto a OCS y OPS: usa caminos ópticos entre nodos, igual que OCS, pero sólo se asigna una λ a cada ráfaga, en vez de a todo el enlace. por cada ráfaga se toma la decisión de encaminamiento, como en OPS, pero sin almacenar los datos en memoria óptica. la conversión O/E/O se realiza sólo a los paquetes de control, que se reciben antes que los datos. los paquetes que van hacia un mismo nodo se tratan como uno solo, lo que disminuye la congestión, la complejidad y el tiempo de procesamiento. 15

41 CAPÍTULO 2. ESTADO DEL ARTE 2.2. Simuladores de Red Desde la aparición de las redes de ordenadores se han intentado estudiar sus características, sus prestaciones y su comportamiento ante tipos y estructuras diferentes de tráfico. Los simuladores de red ofrecen dicha posibilidad de una manera sencilla y rápida sin necesidad de tener que construir y recrear la red bajo estudio. En esta sección se analizan los principales simuladores de red existentes NS Inicialmente conocido como LNBL Network Simulator [6], es una herramienta de simulación desarrollada por el Network Research Group 1 en el Lawrence Berkeley National Laboratory 2. NS es un motor de simulación de eventos de red, extensible y fácil de configurar y programar. Para la configuración de la topología a simular se utiliza el lenguaje Tcl(Tool Comand Language), y los pasos que sigue la simulación al ser ejecutada son: 1. Se define la topología. 2. Las fuentes de tráfico se configuran. 3. Se recolectan las estadísticas. 4. Se invoca la simulación. Su desarrollo, gracias a la universidad UC Berkeley 3 desembocó en la segunda versión [7], la cual, utiliza una nueva arquitectura, que utiliza Object Tcl, una extensión de Tcl, para la descripción de la topología a simular. Casi toda la funcionalidad de la primera versión de NS se encuentra integrada en la segunda versión, por lo que mantiene plena compatibilidad con versiones anteriores de todas las funciones, excepto con el manejador de flujo, por lo que scripts desarrollados para la primera versión funcionarán de manera automática para la segunda

42 2.2. SIMULADORES DE RED Figura 2.7: NAM Actualmente, el desarrollo se encuentra en la versión 2.34 desde el 17 de Junio de 2009, algún tiempo después de que la versión 3 de NS se empezase a desarrollar. Esto da una idea de lo importante que ha sido este simulador a lo largo del tiempo. Existe un visor de los eventos simulados, el NAM(Network Animator), que muestra de manera gráfica dichos eventos, el cual se encuentra actualmente en la versión En la figura 2.7 se ve un ejemplo de una simulación de red. Para el caso de la simulación de una red óptica de OBS, existe el módulo obs-0.9a, desarrollado por la universidad de Maryland 4. Además, en [8], podemos encontrar dicho módulo, modificado por Isaías Martínez Yelmo de la UC3M, ya incorporado en NS-2, en

43 CAPÍTULO 2. ESTADO DEL ARTE su versión NS-3 Se llega a la tercera versión del Network Simulator [9], esta vez bajo licencia GNU GPLv2, y queda libre para su investigación, desarrollo y uso. Sigue siendo un simulador de eventos de red, aunque ya no existe compatibilidad con versiones anteriores, debido a que el lenguaje de configuración ya no es OTcl, sino Python. Esta versión intenta solucionar algunos problemas que tenía la segunda versión como la interoperabilidad y acoplamiento entre modelos; y la falta de gestión de memoria. Debido a que su concepción está orientada a la educación, los ficheros de trazas son configurables por el usuario, al contrario que NS-2. También trata de acercarse lo más posible a la realidad, haciendo que los nodos sean como ordenadores a los que se les puede añadir módulos/tarjetas de red. Actualmente se encuentra en la versión 3.11, desde el 25 de Mayo de 2011, y ya está en desarrollo la siguiente, debido a que la política de actualizaciones es lanzar una nueva versión cada 4 meses. Al igual que con la segunda versión, está disponible el visor NAM para ver los resultados de una simulación de manera gráfica. En cuanto al estudio que interesa, es decir las redes ópticas de OBS, desafortunadamente no se ha encontrado ningún módulo en desarrollo para esta versión del simulador OMNeT++ OMNeT++ [10], es un marco modular orientado a objetos para simular eventos discretos de red. Posee una arquitectura genérica, por lo que se puede usar, y se usa, para problemas del tipo: modelado de comunicaciones por cable e inalámbricas modelado de protocolos modelado de redes de colas 18

44 2.2. SIMULADORES DE RED Figura 2.8: OMNeT++ IDE modelado de multiprocesadores y otras distribuciones de hardware validación de arquitecturas de hardware evaluación de los aspectos del rendimiento de sistemas de software complejos en general, modelado y simulación de cualquier sistema en el que la aproximación a eventos discretos sea aceptable, y sea conveniente asignar a las entidades la comunicación mediante el intercambio de mensajes OMNet++ en sí mismo no es un simulador de algo concreto, sino que proporciona la infraestructura y herramientas para la escritura de simulaciones. Uno de los ingredientes fundamentales de esta infraestructura es una arquitectura de componentes para los modelos de simulación. Los modelos se crean a partir de componentes reutilizables, llamados módulos y aquellos que estén bien escritos, se podrán reutilizar mejor, por lo que podrán combinarse de varias formas. Los módulos, escritos en C++, se pueden conectar entre sí a través de puertas, y se combinan para formar módulos complejos. Se comunican mediante el paso de mensajes, que pueden llevar estructuras de datos arbitrarios. Se pueden pasar mensajes a través de 19

45 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.9: Red OBS en OMNeT++ las rutas predefinidas, o directamente a su destino, como puede ser en las simulaciones inalámbricas. El usuario describe la estructura del modelo a simular en lenguaje NED, que permite declarar módulos simples, y conectarlos y ensamblarlos en módulos complejos. Existe una herramienta gráfica para ayudar a la configuración de las simulaciones, OMNeT++ IDE. Es una herramienta basada en la plataforma Eclipse y la extiende con nuevos editores y vistas. También añade funcionalidad para crear y configurar los modelos, realizar ejecuciones por lotes y analizar los resultados de la simulación; mientras, Eclipse ofrece la edición de C++, integración y otras características a través de plug-ins de código abierto. En la figura 2.8 se puede ver una captura de dicho interfaz. En cuanto al estudio de OBS, existe un módulo, desarrollado por el GRSST 5, que implementa dicha tecnología, permite el estudio de los nodos core y los edge, y enlaza la red OBS con otras redes soportadas por OMNeT++. Un ejemplo de una red OBS simulada con OMNeT++ es la mostrada en la figura

46 2.2. SIMULADORES DE RED Figura 2.10: Dominios de OPNET OPNET OPNET [11] es una herramienta de simulación de alto nivel basada en eventos que opera a nivel de paquete. Originalmente se ideó para la simulación de redes fijas, aunque actualmente existen gran cantidad de posibilidades para las simulaciones de redes inalámbricas. Se puede usar como una herramienta de investigación o como una herramienta de análisis y desarrollo de redes. Consiste en una interfaz de alto nivel, generada con C y C++, con una inmensa li- 21

47 CAPÍTULO 2. ESTADO DEL ARTE brería de funciones específicas de OPNET. Posee una estructura jerárquica, por lo que el modelado se divide en tres dominios principales: Dominio de red: Incluye todas las redes y subredes, topologías de red, coordenadas geográficas o movilidad. Dominio de nodo: Los nodos de una red, tales como routers, estaciones de trabajo o dispositivos móviles. Dominio de procesado: El comportamiento dentro de los nodos de la red. Para cada uno de esos dominios, posee un interfaz gráfico para poder editar el comportamiento de la red a simular. En la figura 2.10, se muestra un esquema de los tres dominios y su relación con los demás. El principal problema de este simulador es que se requiere comprar la licencia para su uso, por lo que, existiendo otras posibilidades gratuitas, es poco recomendable KivaNS KivaNS [12] es una aplicación gratuita y de código abierto basada en Java para generar esquemas de redes y simular el encaminamiento de paquetes a través de dichas redes. Al contrario que la mayoría de simuladores, que están pensados para evaluar parámetros de carga y rendimiento, KivaNS está orientado a simular el comportamiento del protocolo IP, y más específicamente el tratamiento de los datagramas y su encaminamiento. Para ello, se apoya en protocolos como ARP e ICMP, y emula el funcionamiento básico de tecnologías de enlace como Ethernet. Se compone de dos partes implementadas en Java. La primera es un API que ofrece un motor de simulación de redes a otras aplicaciones, y la segunda es una interfaz gráfica que hace uso del API de simulación. En la figura 2.11 se puede ver un esquema de la arquitectura de KivaNS. La figura 2.12 ilustra el esquema de bloques del API, compuesto por un gestor de eventos discretos, objetos representativos de las redes, objetos representando a los equipos de la red, y una pila de comunicaciones. De esta forma, se posee un API modular y extensible, al que se le pueden incorporar nuevos tipos de redes y equipos. 22

48 2.2. SIMULADORES DE RED Figura 2.11: Arquitectura de KivaNS Figura 2.12: Bloques del API de KivaNS La interfaz de usuario (figura 2.13) permite especificar las topologías de redes de datos mediante un editor gráfico, configurar mediante diálogos el direccionamiento y encaminamiento de los equipos de la red, y acceder a las características del API de simulación sin necesidad de programar. Dado que es un simulador orientado al estudio del protocolo TCP/IP, no existen módulos que implementen OBS. Pero al ser un simulador modular, se pueden implementar los módulos que se deseen para su simulación. 23

49 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.13: Interfaz gráfico de KivaNS CNET CNET [13] es un simulador de red que permite la experimentación con diferentes capas de enlace, capas de red y protocolos de enrutamiento y transporte en redes formadas por la combinación de WAN s LAN s o WLAN s. Acorde con el modelo de referencia OSI, CNET provee las capas Física y de Aplicación. Con Tcl/Tk, CNET provee una representación gráfica de la red que se va a ejecutar, a través de un terminal ASCII, y permite modificar algunos atributos de la misma mientras se está simulando. Se pueden seleccionar los nodos que intervienen para acceder a una pequeña ventana con las estadísticas de dicho nodo. Los atributos de los nodos son modificados mediante sencillos checkboxes, y si es un atributo común a todos los nodos, se modificará en todos en ellos. Se muestra un ejemplo de dicho interfaz gráfico con los atributos y estadísticas de los nodos en la figura

50 2.2. SIMULADORES DE RED Figura 2.14: Interfaz gráfico de CNET Resumen del estudio de los simuladores En la tabla 2.3 se detalla una comparación de diferentes propiedades entre los simuladores analizados. En cuanto al simulador de red para complementar la aplicación, se ha elegido NS-2. Es un simulador muy extendido por todo el mundo, con gran cantidad de módulos disponibles, y además, el que necesitamos para simular redes OBS está ya integrado con la versión 2.28 de ns en [8]. En las prácticas realizadas durante la titulación en los laboratorios de Ingeniería Telemática 6 de la Universidad Carlos III de Madrid(UC3M) 7 se utiliza precisamente esa versión del simulador, por lo que su uso es familiar. Además, como esta aplicación pretende ser una ayuda a la hora de simular, analizar y comparar las prestaciones de diferentes topologías, es posible, que en años venideros, sirva de ayuda al alumnado para el estudio

51 CAPÍTULO 2. ESTADO DEL ARTE Interfaz gráfico Módulo OBS Bajo nivel Eventos NS-2 NS-3 OMNeT++ OPNET KivaNS CNET Tabla 2.3: Tabla comparación simuladores de red de redes que utilicen tecnología OBS Teoría de colas La teoría de colas [14] es el estudio matemático de las líneas de espera, o colas, dentro de una red de comunicaciones. Su objetivo principal es el análisis de varios procesos, tales como la llegada de los datos al final de la cola o el tiempo de espera en la cola. Generalmente es considerada una rama de investigación operativa porque sus resultados a menudo son aplicables en una amplia variedad de situaciones como negocios, comercio, industria, ingenierías, transporte y telecomunicaciones. Los elementos más importantes de un sistema de colas son: las llegadas de los usuarios al sistema, la cola de espera, el servicio que ofertan los servidores y la salida de los usuarios del sistema. En general, un sistema de colas consiste en uno o varios servidores que prestan un servicio a uno o varios usuarios que acceden al sistema. El proceso de llegadas lo regula una fuente generadora de usuarios y, en general, estas llegadas serán de forma aleatoria. Si, cuando un usuario llega al sistema, el servidor está libre, se le da servicio. Si el tiempo de servicio es mayor que el intervalo entre llegadas, el siguiente usuario, cuando accede al sistema, encuentra que el servidor está ocupado, por lo que debe quedar en espera, formando la cola. Existen varios tipos de configuración para una red de colas, y sus características vie- 26

52 2.3. TEORÍA DE COLAS Figura 2.15: Esquema de sistema M/M/1 nen dadas por el tipo de distribución que siguen los procesos de llegadas, la distribución de la tasa de servicio, el número de servidores, el tamaño de la cola, la política de gestión de cola y otras. Para identificar cada una de ellas se sigue una notación específica, conocida como notación Kendall. A continuación se pasa a explicar la configuración básica, con un servidor y procesos de llegadas de Poisson; y las configuraciones que se han utilizado para el desarrollo de este proyecto M/M/1 En el caso de un sistema de este tipo se establece que: la tasa de llegadas (λ) es un procesos de Poisson, que la tasa de servicio (µ) sigue una distribución exponencial y que en el sistema se dispone de un servidor. Además, otras características de este sistema es que la cola es infinita, que su política es FIFO (First In First Out) y que el número de usuarios que entran al sistema es inifinito. A partir de las tasas mencionadas anteriormente se puede definir el factor de utilización ρ como: ρ = λ µ En el caso de que ρ sea menor que 1 se llega al estado estacionario del sistema, esto es, que la cola, en caso de ser infinita, no está saturada; y en caso de no serlo, no se pierden usuarios que llegan al sistema cuando la cola está llena, y por lo tanto, se da servicio a todos ellos. Se muestra un esquema de este tipo de sistemas en la figura

53 CAPÍTULO 2. ESTADO DEL ARTE Fórmula de Little Explicado de forma muy breve, el teorema de Little dice que si un sistema es estacionario, el número de usuarios en el sistema L es igual a la tasa media de llegadas λ por el tiempo medio de estancia en cola W : L = λw El número medio de usuarios en el sistema L viene dado por: L = ρ 1 ρ con una varianza: σ 2 = ρ (1 ρ) 2 El tiempo medio de espera en el sistema T es: T = 1 µ λ es: Aplicando las fórmulas anteriores se obtiene que el tiempo total de espera en cola W W = L λ = ρ λ(1 ρ) = ρ µ λ Distribución exponencial Se ha hablado de que la tasa de servicio siguen una distribución exponencial. Para ilustrar la distribución exponencial se puede ver la figura 2.16, que muestra su función de densidad. Y posee una función de distribución como la mostrada en la figura

54 2.3. TEORÍA DE COLAS Figura 2.16: Función de densidad exponencial Figura 2.17: Función de distribución exponencial 29

55 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.18: Esquema de sistema M/M/c M/M/c En este otro modelo, la tasaa de llegadas se rige por un proceso de Poisson, la tasa de servicio sigue una distribución exponencial, pero, en este caso, en el sistema se dispone de c servidores. Al igual que el M/M/1, la cola de espera es infinita y tiene política FIFO. Para este modelo, cabe destacar que todos los servidores comparten la misma cola, por lo que si hay un usuario en cola y un servidor queda libre, pasará a ese servidor. El factor de utilización es diferente, y se define como: ρ = λ cµ Y de nuevo, para que el sistema alcance la estacionariedad ρ debe ser menor que 1. Se puede ver un esquema de este tipo de sistema en la figura Para el caso concreto de este proyecto, se ha utilizado para el cálculo de las tasas de llegadas para el tráfico exponencial G/G/c En este último modelo que se verá, las tasas de llegadas y de servicio siguen una distribución generalista, que puede ser cualquier función de distribución que no sea ni de 30

56 2.3. TEORÍA DE COLAS Figura 2.19: Esquema de sistema G/G/c Poisson ni determinista. Como las funciones son desconocidas, el factor de utilización no se calcula de manera trivial, si no que dependerá de la función en cuestión. El esquema general para este tipo de sistemas se puede ver en la figura Como en el sistema se puede introducir cualquier distribución generalista, en el caso de este proyecto se ha utilizado el tráfico Autosimilar, explicado en el siguiente apartado Teorema de Jackson Para terminar con esta sección, se explicará brevemente el Teorema de Jackson [15]. Partiendo de las premisas de que un sistema está compuesto por m servidores, con una tasa de servicio exponencial; los usuarios llegan al sistema con una tasa que sigue una distribución de Poisson; y una vez servido, un usuario se dirige hacia otro de los servidores con una probabilidad fija, o abandona el sistema. El Teorema de Jackson afirma que, en una red como la descrita, cada servidor es un sistema de colas independiente, con una entrada de Poisson. Así pues, cada servidor se puede estudiar de manera independiente como un M/M/1 ó un M/M/c de tal manera que, los resultados pueden combinarse mediante métodos estadíticos y los retardos medios pueden sumarse para obtener el retardo total del sistema. Esto es especialmente útil para el estudio de redes de colas, cuyo escenario cumple con las premisas para aplicar el Teorema de Jackson. 31

57 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.20: Esquema tráfico CBR 2.4. Generadores de tráfico Existen muchas maneras teóricas de representar el tráfico que cursa una red. Como hablar de todas ellas abarcaría gran parte del capítulo tan sólo se van a explicar los tres utilizados en este proyecto, que son: CBR, Exponencial y Autosimilar. CBR (Constant Bit Rate) El tráfico CBR se caracteriza por el envío constante de tráfico a una misma tasa. Por lo que origen y destino deben tener una sincronización temporal. CBR se adapta para cualquier tipo de datos para los que los sistemas finales requieren un tiempo de respuesta predecible y una cantidad fija de ancho de banda continuamente disponible para el tiempo de la conexión. Los servicios más comunes son los de videoconferencia, telefonía o cualquier tipo de servicio bajo demanda, tales como audio y voz interactivos. En la figura 2.20 se muestra un esquema tipo del tráfico CBR, donde el tamaño de los paquetes es constante y el tiempo entre llegadas es constante, por lo que la tasa también lo es. 32

58 2.4. GENERADORES DE TRÁFICO Figura 2.21: Esquema tráfico Exponencial Exponencial En el caso del generador de tráfico exponencial para NS, se trata de un tráfico On/Off, esto es, durante los periodos de encendido, los paquetes se generan con una tasa constante y durante los períodos de apagado no se genera tráfico. Los tiempos de on y off se generan mediante una distribución exponencial, explicada en el apartado anterior. En la figura 2.21 se puede ver un esquema de tráfico Exponencial, donde el tamaño de los paquetes es constante y la media del tiempo entre llegadas es 1 λ. Tráfico Autosimilar La autosimilaridad o autosimilitud, es la propiedad de un objeto en el que el todo es exacta o aproximadamente igual a una parte de sí mismo. Un ejemplo de autosimilitud es la curva de Koch, ilustrada en la figura En el caso de las redes y el intercambio de paquetes se suele dar en el tráfico de Internet. Si se observa el tráfico a lo largo de un periodo de tiempo, tendrá una determinada forma; si atendemos al tráfico en un periodo de tiempo más pequeño, tendrá aproximadamente la misma forma. Un buen ejemplo es la gráfica A diferencia de otros tipos de tráfico, éste no viene implementado con NS. En cambio, hay que descargarlo y compilarlo desde el módulo para OBS desarrollado por la Universi- 33

59 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.22: Curva de Koch Figura 2.23: Tráfico observado en una red Ethernet [16] dad de Maryland. Para poder entender los parámetros a configurar debemos saber cómo se genera éste tipo de tráfico. El tiempo de llegada de los paquetes es autosimilar con un exponente de Hurst H [17] y una tasa media específica. Los tiempos entre paquetes siguen una distribución Gamma [18] (están correlados con H). El tamaño de los paquetes es un proceso autosimilar, con exponente Hurst (no necesariamente el mismo que para el tiempo de llegadas). Además, el tamaño sigue una distribución binomial negativa [19]. 34

60 2.4. GENERADORES DE TRÁFICO Figura 2.24: Esquema tráfico Autosimilar En la figura 2.24 se muestra un esquema del tráfico Autosimilar, donde el tamaño de los paquetes no es constante, si no que sigue una distribución binomial negativa y el tiempo entre llegadas sigue una distribución Gamma, como se ha visto antes. 35

61 CAPÍTULO 2. ESTADO DEL ARTE 36

62 Capítulo 3 Herramientas Este capítulo describe de manera breve las herramientas utilizadas durante el proyecto: el simulador NS-2, las API s necesarias del lenguaje de programación JAVA y la librería de topologías de red SNDlib Simulador NS-2 Como ya se dijo en el Capítulo 2.2.1, NS es un simulador de eventos discretos enfocado a la creación e investigación de redes. Proporciona un gran apoyo para la simulación del protocolo TCP, enrutamiento y protocolos multicast a través de redes cableadas e inalámbricas(locales y satélite) Características NS está basado en dos lenguajes: un simulador orientado a objetos, escrito en C++ y un intérprete OTcl(una extensión orientada a objetos de Tcl), usado para ejecutar scripts de comandos del usuario. Posee una abundante librería de objetos de red y protocolos y hay dos jerárquicas. La jerarquía compilada de C++ y la interpretada de OTcl, las cuales tienen una correspondencia uno-uno entre ellas, es decir, por cada objeto de la jerarquía compilada de C++ existe un objeto de la jerarquía interpretada de Tcl. Cuando en Tcl se configura algún objeto para la simulación, se acude a la jerarquía de C++ para utilizar ese objeto compilado. Esto se debe a que la simulación de redes abarca tareas de diferente ámbito, y debe cumplir dos 37

63 CAPÍTULO 3. HERRAMIENTAS requisitos principales: Se requiere la simulación detallada de los protocolos de comunicación, con un lenguaje de programación capaz de manejar datos de manera eficiente y con buenas prestaciones de velocidad. Se debe permitir una fácil reconfiguración de los escenarios a simular. La jerarquía compilada de C++ permite conseguir eficiencia en la simulación y rapidez en los tiempos de ejecución. Esto es especialmente útil para el funcionamiento de los protocolos, ya que reduce el tiempo de procesamiento de los paquetes y eventos, lo que satisface el primer requisito. En el script OTcl del usuario, se define una topología de red, los protocolos y aplicaciones que se quiere simular (siempre que se hayan definido en la jerarquía compilada) y el formato de salida que se desea obtener del simulador, lo que consigue satisfacer el segundo requisito para simulación de redes. NS provee un mecanismo de enlace entre los dos lenguajes (usando tclcl), mediante el cual OTcl hace uso de los objetos compilados por C++ creando una asociación del objeto OTcl por cada objeto C++. Al ser un simulador de eventos, el avance del tiempo depende de la programación de dichos eventos que son gestionados por un planificador. Un evento es un objeto de la jerarquía de C++ con un ID único, un tiempo programado y un puntero a otro objeto que lo maneja. El programador guarda una estructura de datos ordenada con los eventos a ejecutar y los va liberando uno a uno, invocando al manejador del evento correspondiente Funcionamiento A continuación se explicará el funcionamiento interno de NS. Para ello se comentará la creación de los diferentes componentes que posee una red, la formación de los paquetes para el intercambio de información y la forma que NS gestiona los eventos ocurridos en la red. 38

64 3.1. SIMULADOR NS-2 Componentes de red La ruta que seguirán los datos se construye mediante la interconexión de componentes de red, indicando en cada objeto cuál es el objeto siguiente. De esta manera cuando un usuario quiere crear un nuevo componente, puede escribir el código en OTcl ó C++, o bien interconectar pequeños componentes, por ejemplo, se puede conseguir crear un enlace mediante la interconexión de una serie de paquetes y un retardo. Este mecanismo otorga un gran potencial a NS, ya que se pueden construir objetos complejos a partir de objetos simples. Los objetos importantes dentro de la ruta de datos son: Conectores: elementos con una sola salida, se colocan en serie para formar objetos más complejos. Algunos ejemplos son las colas o los retardos. Clasificadores: poseen varias salidas, por lo que los datos de entrada pueden optar por cualquiera de ellas, o por varias, en base a un criterio concreto. Unos ejemplos son los clasificadores de direcciones, de puertos... Agentes: representan puntos finales en la red, donde los paquetes se crean o se destruyen. Son utilizados para implementar protocolos, como TCP ó UDP. Aplicaciones: son los objetos que generan la información, y van montados sobre los agentes. La creación de un nodo se realiza mediante la interconexión de clasificadores, luego se le añaden agentes y sobre ellos, las aplicaciones. La topología se forma creando varios nodos e interconectándolos entre sí a través de enlaces. Paquetes de datos Para el intercambio de información en NS, se utilizan los llamados paquetes, que están compuestos por una pila de cabeceras y una zona de datos. Cuando se crea un protocolo nuevo, se registra su cabecera, y cuando se crea un objeto simulador se inicializa el formato de cabecera de todos los tipos registrados, indicando, para cada uno de ellos, en qué posición del paquete se encuentra el acceso a sus datos. Cada vez que se crea un paquete, se crea a la vez una cabacera con todos los tipos registrados, y cada objeto de 39

65 CAPÍTULO 3. HERRAMIENTAS la red puede acceder a la cabecera deseada utilizando la posición de acceso correspondiente. Normalmente, un paquete sólo se compone de las cabeceras, sin datos, ya que el transporte de datos reales no es de mucho interés en simulaciones que no sean de tiempo real. Aún así, algunas aplicaciones y agentes soportan el intercambio de información real. Programador de eventos El intercambio de información se consigue pasando mensajes de datos de unos objetos a otros a través de los caminos establecidos. Esto no consume tiempo simulado, a menos que los componentes retarden los paquetes. En esos casos los instantes de envío y recepción los controla un programador de eventos central. Como ya se apuntó, los eventos tienen un tiempo programado y un puntero a su manejador. El programador mantiene un tiempo de simulación y una cola con los eventos simulados y según avanza ese tiempo, va ejecutando los eventos mediante una llamada a sus manejadores Java Java es un lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems. El lenguaje en sí es muy parecido a C y C++, pero el modelo de objetos es más simple y no posee herramientas de bajo nivel, que suelen inducir a muchos errores, como es la manipulación de punteros y memoria. Se van a describir las librerías java utilizadas en la aplicación: JDOM Provee una potente API para acceder, manipular y extraer datos de un fichero XML a partir de código Java. Interactúa bien con los estándares existentes como SAX y DOM, pero no es una capa de abstracción o mejora de dichos API s. Por el contrario, proporciona un robusto y ligero medio de lectura y escritura de datos XML. 40

66 3.2. JAVA JFreeChart JFreeChart es una librería libre que permite que sea fácil para los desarrolladores mostrar gráficas en sus aplicaciones. El proyecto fue creado en el año 2000 por David Gilbert. Actualmente lo utilizan unos desarroladores en el mundo y sigue siendo gestionado por Gilbert. Tiene un amplio conjunto de funciones, incluyendo: Una consistente y bien documentada API, implementando un gran número de tipos de gráficas Un diseño flexible y fácil de extender Ofrece soporte para diferentes tipos de formato de salida, inluyendo componentes Swing, archivos de imagen (PNG y JPEG) y gráficos vectoriales (PDF, EPS y SVG) Es software libre y se distribuye bajo los términos de GNU LGPL 1, que permite su uso en aplicaciones propietarias. Hay que añadir que la librería JFreeChart utiliza otra más a su vez, aunque el usuario no sea consciente de ello. Se trata de la librería JCommon, una librería de clases de utilidad para entornos gráficos. Entre sus usos está el centrado automático de ventanas en pantalla, por ejemplo. Algunos ejemplos de gráficas que se pueden realizar son las figuras 3.1 y Commons-Math Java provee una extensión matemática implementada sólo para los algoritmos matemáticos más básicos. Con esta librería se consigue la implementación de muchos otros de más complejidad, tales como: Representación de números básicos complejos mediante operaciones algebraicas Método de Newton para aproximar raíces Coeficientes binomiales

67 CAPÍTULO 3. HERRAMIENTAS Figura 3.1: Gráfica de barras y series con JFreeChart Figura 3.2: Histograma con JFreeChart Crecimiento y decrecimiento exponencial Interpolación polinómica Representación de matrices básicas con operaciones algebraicas Además, implementa algoritmos básicos de estadística: 42 Estadísticas de una variable simple

68 3.3. SNDLIB Distribuciones de frecuencia Generación de números aleatorios siguiendo distribuciones Gauissiana, Exponencial y Poisson Regresión y correlación de dos variables Entorno de desarrollo Para el desarrollo de la aplicación se ha elegido NetBeans 2 como entorno de trabajo. Es un entorno de desarrollo de código abierto y libre, en el que los desarrolladores pueden programar en diferentes lenguajes, tales como C/C++, PHP, Groovy o Java. Para el desarrollo del proyecto, su generador de interfaces gráficos de Java Swing ha sido de gran ayuda a la hora de crear la aplicación, ya que basta con seleccionar el componente que se quiere introducir en la interfaz y colocarlo en la posición deseada para que automáticamente se cree. Además, con un sencillo menú desplegable, se puede acceder a las propiedades de dicho elemento y modificarlas según las necesidades. También genera el paquete jar para su posterior ejecución de una manera sencilla para el usuario. Basta con acceder al menú Ejecutar y seleccionar la opción Generar Main Project. En la figura 3.3 se muestra una captura de pantalla del entorno de trabajo utilizado SNDlib Para poder simular redes se necesita tener un fichero describiendo la topología de dicha red. En [20] hay disponible una librería de diferentes redes reales, con datos ficticios, cuya descripción se encuentra en formato XML, lo que facilita la creación de los ficheros de simulación en gran medida, ahorrando al usuario el trabajo de tener que generar él mismo dicho fichero elemento a elemento. Dicha librería tiene varios propósitos:

69 CAPÍTULO 3. HERRAMIENTAS Figura 3.3: NetBeans hacer diseños de pruebas de red reales para facilitar el trabajo de la comunidad de investigación servir como punto de referencia estándar para probar, evaluar y comparar los modelos de diseño de redes y algoritmos ser una fuente de información y recursos relacionados con el diseño de la red fija, y proporcionar una plataforma de contacto para los investigadores y los profesionales que trabajan en este campo 44

70 Capítulo 4 Descripción de la aplicación En este capítulo se realizará un análisis de las decisiones tomadas para la creación de la aplicación, así como de las funciones que debe cumplir Funcionalidad En resumen, la funcionalidad principal que debe cumplir la aplicación es: Se dispone de un fichero XML [20] en el que se define una topología de red, tanto sus nodos, como sus enlaces y demandas entre nodos. A partir de ese fichero, leer los nodos, los enlaces y las demandas para poder transformar dicha topología a un fichero de simulación de NS. Tomando como referencia un fichero esqueleto, generar el fichero de NS y simularlo. Una vez terminada la simulación, leer los ficheros de resultados generados por el simulador y construir gráficas representativas de dichos resultados para su estudio. Además se pueden añadir funciones que no son primordiales, pero complementan la aplicación y la hacen más útil de cara al usuario: Posibilitar la modificación de cualquier aspecto del escenario, ya sean los enlaces o las demandas de tráfico. Cambiar el tipo de tráfico que se va a intercambiar entre nodos. 45

71 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Ofrecer la posibilidad al usuario de cambiar los parámetros de la simulación. Ofrecer una vista en la aplicación del esquema de la red. Creación y exportación de gráficas para el posterior estudio de la simulación realizada. Generación y simulación de diferentes topologías con las mismas prestaciones que el escenario inicial Simulador NS-2 En este apartado se explicará la configuración y ejecución del simulador NS-2 con el módulo para OBS y algunos ejemplos de cómo configurar los parámetros de los tipos de tráfico utilizados Integración Como se dijo en el Capítulo 2, se utilizará como simulador NS-2 en su versión 2.28, con el módulo para OBS integrado. Ambos componentes se encuentran en [8] para descargar y descomprimir en el entorno de trabajo. Una vez descomprimidos los ficheros, se debe compilar el entorno para poder ejecutarlo en el sistema. Pero antes se deben realizar modificaciones en los ficheros del módulo de OBS para que su integración sea correcta [21] [22], y se detallan en el Apéndice D. Todo ello se realiza siguiendo una serie de pasos, descritos en el Manual de instalación en el Apéndice C Generadores de tráfico utilizados En el Capítulo 2 se estudiaron de manera teórica los diferentes tipos de tráfico utilizados, así que ahora tan solo se explicará la forma de configurarlos y algún ejemplo de ello. 46

72 4.2. SIMULADOR NS-2 Módulo CBR Los parámetros configurables en NS para este tipo de tráfico son: rate : la tasa de tráfico enviada, medida en bits/s interval : el tiempo entre paquetes, medido en segundos packetsize : el tamaño constante de los paquetes, medido en bits random : es un flag que indica si se debe introducir ruido aleatorio en las salidas, por defecto está desactivado maxpkts : el número máximo de paquetes enviados, por defecto 2 28 Las variables rate y interval son mútuamente exclusivas. En una simulación con este tipo de tráfico se debe especificar una u otra, pero no ambas. En la aplicación se utilizan rate, packetsize y random. Un ejemplo para configurar tráfico CBR es: Se desea mandar tráfico de un nodo A a un nodo B durante un segundo En concreto, se desea que en total se transmitan 100Mb Teniendo las premisas anteriores, es fácil averiguar los parámetros que se deben configurar. Como rate se mide en bits/s, tan sólo se debe establecer el parámetro rate a 100mb, sin importar el tamaño de los paquetes, ya que el propio generador de tráfico calcula cuántos paquetes se deben mandar para poder alcanzar la tasa establecida. Otro ejemplo para este tráfico es: Se desea enviar tráfico entre dos nodos, C y D, durante dos segundos En concreto se desean enviar paquetes de 2000 bits cada uno Ahora se debe tener en cuenta que no se dice la cantidad de tráfico que se desea mandar, tan solo el número de paquetes y el tamaño de los mismos. Tras hacer un cálculo sencillo, se ve que en total se deben enviar 20Mb en toda la simulación, por lo tanto, si el rate se mide en Mb/s, se debe dividir el tráfico total entre los segundos de simulación, quedando una configuración de rate =10mb y packetsize =

73 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Módulo Exponential Los parámetros que se pueden configurar en NS son: packetsize : el tamaño constante de los paquetes generados, medido en bits busrt time : el tiempo medio en el que el generador está encendido, medido en segundos idle time : el tiempo medio en el que el generador está apagado, medido en segundos rate : la tasa de tráfico enviada durante los tiempos de encendido, medido en bits/s La consecuencia más inmediata deducida, es que al ser un tráfico on/off, tal y como se explicó en el Capítulo 2, la tasa media de tráfico dependerá de la duración de las ráfagas, quedando una relación de la siguiente manera: tasa media = rate burst time burst time+idle time Para poder obtener una relación entre tasa media y rate sin conocer los valores de burst time y idle time, se ha diseñado un experimento. Se fija el valor rate a 100Mb/s, y con las estadísticas que ofrece la simulación al terminar, se calcula el número de bits enviados en un segundo, obteniendo que la tasa media es de 70,92Mb/s. Por lo tanto, se puede obtener la relación fácilmente con un sencillo cálculo: tasa media = rate 1, Hay que apuntar que esta relación sólo es válida para los valores de burst time y idle time configurados por defecto para este tipo de tráfico, en cuanto el usuario modifique alguno de estos valores la relación ya no será correcta. Como curiosidad, se puede configurar el tráfico Exponential On/Off como un proceso de Poisson. Se puede conseguir estableciendo la variable burst time a 0s y la variable rate a un valor muy alto. Se garantiza que si el tiempo de ráfaga es 0s, al menos se enviará un paquete. 48

74 4.2. SIMULADOR NS-2 En el caso del proyecto, los parámetros configurados han sido rate y packetsize. Utilizando los mismos ejemplos que para el caso del tráfico CBR, en esta ocasión los parámetros a configurar son: Para el caso entre los nodos A y B, se debe configurar tan solo el rate ya que directamente se ofrece el dato. Pero en esta ocasión debemos tener en cuenta la relación entre la tasa media y el rate, por lo tanto, se debe configurar de la siguiente manera rate =141mb. En el caso entre los nodos C y D, sucede exactamente igual que para CBR, se indica la cantidad de paquetes a enviar y el tamaño de los mismos, por lo que se debe calcular la tasa. En este caso, y teniendo en cuenta la relación mencionada antes, se deberá configurar el tráfico como rate =14.1mb y packetsize =2000. Módulo SelfSimilar Tras la explicación del tráfico en el Capítulo 2, se verán los parámetros que se pueden configurar: rate: la tasa media de llegada de paquetes, medida en paquetes/s Ht: exponente Hurst para el proceso de llegadas std dev inter batch time: desviación estándar del tiempo entre paquetes, dependiendo de la tasa establecida deberá tener un determinado orden de magnitud batchsize: el tamaño medio de los paquetes, medido en bytes Hb: exponente Hurst para el tamaño de los paquetes sb: parámetro de varianza de la distribución binomial negativa (número de distribuciones geométricas convolucionadas) En el proyecto se han configurado todos los parámetros, pero sólo son modificables rate, std dev inter batch time y batchsize, los demás están configurados en el fichero esqueleto, pero sin ser modificables por la aplicación. Se ha tomado esta decisión arbitrariamente, apoyándonos en la premisa de que el resto de parámetros podrían ser de 49

75 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN una complejidad mayor para un usuario inexperto. En cualquier caso, se pueden modificar mediante la edición del citado fichero esqueleto. Siguiendo los ejemplos de configuración anteriores, para el tráfico SelfSimilar se hará de la siguiente forma: Para el tráfico de 100Mbps entre los nodos A y B, se debe tener en cuenta que, en este caso, la tasa no se mide en bits/s, si no en paquetes/s. Por lo tanto se debe hacer un cálculo previo. Necesitamos conocer el tamaño de los paquetes, que lo estableceremos a 2000bits. Haciendo un cálculo sencillo, se obtiene que se deben mandar paquetes/s. También se deben configurar el resto de parámetros, como el std dev inter batch time y los parámetros de las distribuciones. Hay que tener en cuenta que el tamaño de los paquetes se mide en bytes. Los parámetros que se deben configurar para realizar la simulación son: rate=50000, batchsize=250, std dev inter batch time=1e-5, Ht=0,5, Hb=-0,5, sb=0. Para el tráfico entre C y D no se necesitan cálculos previos, ya que nos indican la cantidad de paquetes que se desean enviar en dos segundos, por lo tanto en un segundo, se deberán enviar la mitad para conseguir el tráfico deseado. Como std dev inter batch time depende de la magnitud de rate, también se modifica, pero el resto de parámetros sigue igual: rate=5000, batchsize=250, std dev inter batch time=1e-4, Ht=0,5, Hb=-0,5,sb= Parser Se ha diseñado e implementado un parser de ficheros XML para la lectura de ficheros que contienen la topología de la red a simular, así como para leer los ficheros de trazas generados por el simulador. Además, se implementa un generador de ficheros con la topología leída en formato NS listo para simular Parser de XML Para poder traducir la topología XML a ficheros NS, primero se necesita leer esa topología, por lo que es necesario implementar un parser que realice ese trabajo. En el caso 50

76 4.3. PARSER de Java, está disponible la librería JDOM, que facilita la lectura de ficheros XML, después, sólo se debe decidir lo que se hace con los datos leídos. Para guardar los datos de una forma sencilla e intuitiva, la aplicación dispone de clases Java con atributos correspondientes a los datos leídos del fichero. Así por cada nodo que haya en el fichero, se tendrá un objeto Node con los atributos leídos, en este caso, la Id y las coordenadas. Hay que señalar, que, como se explicó en el Capítulo 2.1, la red se compone de nodos edge y nodos core, en este caso, se ha decidido que por cada nodo leído del fichero XML se generen un edge y un core asociados. Al igual que con los nodos del fichero, para los enlaces se tendrán objetos Link con los siguientes atributos: los nodos extremos, la capacidad del enlace, el coste inicial de esa capacidad y una lista con posibles módulos de ampliación de capacidad y su coste asociado; y para las demandas, objetos Demand, que tendrán como atributos la cantidad de demanda y el origen y destino de la misma. Cuando se termine de leer el fichero XML, la aplicación dispondrá de tres Vectores con los nodos, los enlaces y las demandas almacenados. Un ejemplo de un fichero XML con una topología de 14 nodos, demandas entre cada uno de ellos y enlaces correpondientes a la red NFSNET, encontrado en [20], se encuentra disponible en el Apéndice F.1. El proceso de lectura de los enlaces es algo particular, ya que se van a estudiar y comparar cuatro topologías de las mismas prestaciones, las cuales se van a simular: la original leída, un anillo, una malla y una estrella. Tanto los nodos como las demandas de tráfico no se ven afectadas por la topología a simular, pero los enlaces evidentemente sí. Al consistir en un estudio comparativo entre la topología leída y otras topologías básicas de las mismas características que la primera, habrá ocasiones en el que la creación de las otras topologías no se realice de manera directa o trivial. Para ello se ha tomado como decisión de diseño adaptar los enlaces originales a las nuevas topologías para poder conservar las prestaciones de la red en la medida de lo posible. A continuación se explica la toma de decisiones que se han llevado a cabo para poder crear las topologías básicas a partir de la topología original leída. Como ayuda visual, se dispone de un ejemplo de red leída en la figura 4.1, a partir de la cual, se generarán las topologías con las mismas prestaciones. 51

77 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Figura 4.1: Ejemplo de topología parseada Anillo Un anillo es una distribución de red en la cual un nodo está conectado a otros dos mediante sendos enlaces. La interconexión se realiza de tal manera que el primero se conecta con el último y el segundo; el segundo con el primero y el tercero; y así sucesivamente. Los enlaces pueden ser unidirecionales o bidireccionales, por lo que los anillos pueden ser direccionales o adireccionales. En este caso, se trata de enlaces bidireccionales, por lo tanto la red es adireccional, es decir, se puede enviar tráfico en un sentido o en el contrario. Dadas las caraterísticas de la red original y del anillo, se ha tomado la decisión de que la capacidad del nuevo enlace entre dos nodos se calcule de la siguiente manera: Se suman las capacidades de cada nodo extremo del nuevo enlace. Se elige la menor de las sumas realizadas en el paso anterior. nuevo enlace i, j = min( links i ; links j ) En el ejemplo, la capacidad del nuevo enlace entre los nodos 1 y 2, se tendrá: 52 min(3gbps;3gbps + 3Gbps + 5Gbps) = 3Gbps

78 4.3. PARSER Figura 4.2: Ejemplo de topología parseada en anillo quedando la nueva topología como se muestra en la figura 4.2. De esta manera, se agrega toda la capacidad de salida del nodo, pero limitando el enlace al valor más restrictivo. Malla Una malla es una distribución de red en la que todos los nodos están conectados entre sí unos con otros, esto es, cada nodo está conectado directamente a los demás. Para generar una malla con las mismas prestaciones que la topología original, se ha decidido que la capacidad de los nuevos enlaces se calcule de la siguiente forma: Se suman las capacidades de cada nodo extremo del nuevo enlace. Se divide dicha suma entre el número de enlaces que tenía ese nodo en la topología original para obtener el valor medio de la capacidad. Se escoge el menor de los valores medios calculados para cada par de nodos. nuevo enlace i, j = min( links i #links i ; links j #links j ) Así, la capacidad del nuevo enlace entre los nodos 1 y 2, será: 53

79 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Figura 4.3: Ejemplo de topología parseada en malla min( 3Gps 1enlace ; 3Gbps+3Gbps+5Gbps 3enlaces ) = 3Gbps y la malla quedará como la figura 4.3. Lo que se pretende, es seguir manteniendo la capacidad de cada nodo, pero como ahora tienen muchos más enlaces que originalmente, se divide toda la capacidad total inicial entre los enlaces actuales, de esta manera, en media, sigue siendo la misma. Estrella Una distribución en estrella se caracteriza por que todos los nodos están conectados a uno solo, que hace de concentrador, por el cual debe pasar todo el tráfico que se inyecte en la red antes de encaminarse a su destino. Para conseguir generar una topología en estrella de prestaciones similares a la topología leída, se ha tomado como decisión que cada nodo se conecte al central con una capacidad calculada así: Se suman todas las capacidades del nodo en cuestión. El resultado será la nueva capacidad de enlace 54

80 4.3. PARSER Figura 4.4: Ejemplo de topología parseada en estrella nuevo enlace i,central = links i Es importante señalar que se tomó la decisión de insertar un nuevo nodo para que haga las funciones de concentrador. Esto se debe a que si se hubiese elegido uno al azar de los disponibles, el riesgo de seleccionar uno poco apto para realizar dicha tarea es muy alto. De esta manera, el nodo central posee una capacidad de enlace infinita, tan solo se ve limitado por los demás nodos, de forma que seguimos manteniendo las mismas prestaciones en la red. Por lo tanto, en la nueva topología, entre el nodo 2 y el central habrá una capacidad de: 3Gbps + 3Gbps + 5Gbps = 11Gbps quedando la nueva configuración de red como se aprecia en la figura 4.4. Para ayudar a la comprensión de los pasos que sigue la aplicación para realizar el parseo de un fichero XML, en la figura 4.5 se puede ver un diagrama de flujo con los mismos. Todas estas acciones las realiza la clase Parser.java, como se explica en el Apéndice E. 55

81 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Figura 4.5: Diagrama parseo de XML 56

82 4.3. PARSER Generador de ficheros de ns Como ya se dijo, para poder simular topologías en NS se necesita escribir esa topología, con todos los nodos, los enlaces y el tráfico, en un fichero Tcl. Se ha decidido que en la aplicación se puedan configurar ciertos parámetros de la simulación, tales como el retardo de los enlaces, el número de canales de OBS y el tamaño de los paquetes, pero hay muchos otros que no son configurables desde la misma. Aún así, esos parámetros no se dejan sin configurar, están preconfigurados, pero sin ser modificables desde la aplicación gráfica, en el fichero que posee el esqueleto con las declaraciones de los parámetros de las simulaciones a realizar. El fichero esqueleto no posee la declaración de los nodos, los enlaces, ni del tráfico de nuestra simulación, tan sólo es un fichero base, del que se cogerán los parámetros no modificables por el entorno gráfico y se rellenará con la topología leída del fichero XML, creando el fichero final de la topología, que será el que se vaya a simular. Para poder realizar esta tarea, se han tomado varias decisiones de diseño que se enumeran a continuación: Se han insertado marcas en el fichero esqueleto, a partir de las cuales se introduce la configuración modificable por la aplicación, como pueden ser los nodos, los enlaces, las demandas, los canales de OBS o el tamaño de los paquetes. Las marcas deben ser lo suficientemente intuitivas para que un desarrollador, que desee modificar la funcionalidad de la aplicación, sea capaz de hacerlo sin apenas esfuerzo, ya sea eliminando marcas para que esos parámetros no sean configurables o añadiendo marcas para poder modificar parámetros que actualmente no lo son. El fichero debe ser lo más genérico posible, ya que se van a simular diferentes topologías para su posterior comparación, por lo tanto no se puede utilizar un fichero específico para cada una de ellas, debe ser una estructura común. La ejecución de la simulación puede ser desde cualquier lugar, por lo tanto, se deben establecer rutas completas tanto a los ficheros con el módulo de OBS como a la carpeta donde el usuario quiere almacenar los ficheros de trazas. 57

83 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Por poner algunos ejemplos de marcas, a partir de la marca ##NODOS## la aplicación introduce la declaración de los nodos y a partir de la marca ##ENLACES## la aplicación introduce la declaración de los enlaces, tanto los edge-core como core-core. En el Manual de Usuario, en el Apéndice B, se enumeran todas las marcas que se han insertado en el fichero esqueleto para que los parámetros que indican, sean modificables mediante la aplicación gráfica. Y en el Apéndice F podemos ver un ejemplo del fichero esqueleto para la simulación y el fichero final que se va a simular, una vez que la aplicación ha insertado todos los parámetros. Para ayudar a comprender cómo la aplicación genera el fichero a partir del esqueleto, y simula todas las topologías generadas, se pueden ver los diagramas de flujo en las figuras 4.6 y 4.7. La clase encargada de realizar estas funciones es NS.java, cuya funcionalidad se detalla en el Apéndice E Analizador de resultados Para generar las gráficas con los resultados, se necesitan analizar dichos resultados. Para ello, se dispone de unos ficheros de trazas para cada una de las simulaciones llevadas a cabo. Dichos ficheros son generados por el simulador NS, y la aplicación los lee, analiza las trazas y genera las gráficas con los resultados obtenidos. Un ejemplo de este fichero se encuentra en el Apéndice F.2. Cada una de las líneas corresponde a la traza de un paquete, por lo que debemos leer línea a línea este fichero y almacenar los datos necesarios. Las líneas tienen el formato siguiente: IPKT A continuación se procede a desglosar la línea de ejemplo, explicando la utilidad de cada uno de los campos disponibles. + indica el evento que ha ocurrido. Puede que se encole un paquete para enviarlo (+), que se envíe (-), que se reciba (r) o que se descarte (d) indica el instante de tiempo, en segundos, en el que ocurre el evento. 58

84 4.3. PARSER Figura 4.6: Diagrama para generar fichero NS 2 indica el nodo que envía el paquete a nivel físico. 17 es el nodo destino a nivel físico. IPKT indica el tipo de paquete. 64 indica el tamaño, en bits, del paquete. 1 es el flow id 59

85 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Figura 4.7: Diagrama de simulación indican los flags del paquete, en caso de tener alguno activo el primer número es el nodo que envía el paquete a nivel de red, el último es el puerto del nodo origen el primer número es el nodo destino del paquete a nivel de red, el último es el puerto del nodo destino. 0 es el número de secuencia 73 es el id del paquete, único en toda la simulación. 60 El inconveniente de analizar este tipo de ficheros es que puede haber ocasiones en el

86 4.4. GUI que la cantidad de trazas sea muy grande, por ejemplo, algunas pruebas han generado ocho millones de trazas, y almacenarlas todas en un Vector se antoja una tarea casi imposible debido al escaso espacio de memoria del que dispone la JVM, aunque siempre se puede ampliar a la hora de ejecutar cualquier aplicación. En su lugar, lo que se ha hecho, es ir sacando datos a la vez que se va leyendo el fichero. Para poder sacar dichos datos, la aplicación se apoya en objetos Trace, que disponen de atributos útiles para analizar las trazas, y que se corresponde con cada uno de los campos de las líneas del fichero de trazas explicadas más arriba. Una vez se tienen los datos almacenados, se pasa a la creación de gráficas. En la figura 4.8 se puede ver el diagrama de flujo para el análsis y la posterior representación de los resultados en forma de gráficas, para entender mejor su funcionamiento. Como se detalla en el Apéndice E, la clase encargada de leer los ficheros de trazas y generar las gráficas es PanelGraficas.java GUI Se trata de un interfaz gráfico que proporciona ayuda a la hora de simular redes con diferentes topologías. A través de dicho interfaz se configuran los parámetros de la simulación, tales como el tipo de tráfico entre los nodos, la cantidad de tráfico, la capacidad de los enlaces, el factor de ocupación ρ de los enlaces y el tiempo de simulación, además del número de simulaciones que se desean realizar para obtener datos estadísticos aceptables. Además, la aplicación analiza los resultados obtenidos en cada una de esas simulaciones y genera gráficas para mostrar dichos resultados, de esta manera, se puede analizar las redes más sencillamente. Para saber cómo funciona la aplicación, en el Apéndice B se dispone del Manual de usuario de la aplicación, donde se explican las pantallas de las que disponemos para configurar las simulaciones a realizar. 61

87 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Figura 4.8: Diagrama de análisis de trazas 62

88 4.4. GUI Interfaz de usuario Como ya se apuntó en el Capítulo 3.2.4, el interfaz de usuario se ha generado utilizando NetBeans, ya que proporciona las herramientas necesarias para generar GUI s de una manera rápida y sencilla. Se tomó como decisión de diseño dividir la interfaz en varias pestañas para separar las diferentes funcionalidades de la aplicación: Configuración: en esta pantalla se utilizan varios JTextField para solicitar al usuario los ficheros necesarios para la simulación, tales como el fichero a parsear, el fichero esqueleto de NS, la carpeta de trabajo y la carpeta donde se encuentra instalado NS con el módulo de OBS. Además se ofrece la posibilidad de ejecutar NAM, aunque el usuario será el encargado de decidir qué simulación quiere ver en el animador. Opciones de Simulación: en la segunda pestaña disponible, el usuario podrá seleccionar el tipo de tráfico que desea utilizar, ya sea CBR, Exponencial o Autosimilar, así como varias opciones de la simulación, tales como el retardo de los enlaces o los canales disponibles para los nodos OBS. También se decisdió ofrecer la posibilidad de establecer los enlaces o las demandas con el mismo valor, o cambiar la probabilidad de bloqueo en los enlaces para que la tasa de los tráficos fuese diferente con cada ρ. Esquema de Red: se mostrará al usuario un esquema dibujado de la red. Al tener cuatro topologías, la original, en anillo, en malla y en estrella; la mostrada será la que se seleccione en la pestaña de los enlaces. La posición de los nodos la podemos obtener del fichero XML, por lo que estaremos mostrando la distribución real de la red. Demandas: en esta pestaña se muestra una tabla con las demandas de tráfico entre los nodos. Además se ofrece la posibilidad de modificar una demanda, simplemente seleccionándola y utilizando el JTextField disponible en esta misma pestaña. Enlaces: aquí se puede ver una tabla con los enlaces de las topologías. Para seleccionar cuál se desea visualizar, está disponible un JComboBox con las topologías generadas, y basta con seleccionar la elegida para que la tabla cambie automáticamente. También existe la posibilidad de modificar los enlaces, ya sea uno seleccionado, todos, o tan sólo los que estén a 0Mb/s. Esta última funcionalidad se ha 63

89 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN añadido porque algunas topologías encontradas en SNDlib tienen todos los enlaces a 0 y sería bastante tedioso ir agregando capacidad uno a uno. Como nota, decir que los enlaces que estén a 0 no se pasarán al fichero NS ya que no distingue si el enlace tiene o no capacidad, e intenta mandar datos a través de un enlace con capacidad 0. También advertir que la aplicación, antes de pasar la topología a NS, comprueba si algún nodo se ha quedado aislado, es decir si todos sus enlaces tienen capacidad 0. Gráficas: en la última pestaña es donde se muestran las gráficas para el estudio de la simulación. Señalar que las gráficas se generan de manera estadística, es decir, cuantas más simulaciones se realicen, se obtendrán más datos, y los valores medios mostrados serán más precisos. Los datos leídos del fichero de trazas se van almacenando en archivos localizados en la carpeta datos dentro del entorno de trabajo seleccionado, de esta manera, si al visualizar las gráficas se observa que la desviación típica es muy grande, se pueden consultar estos ficheros para ver qué simulación es la que ha ocasionado este desvío. También se ofrece la posibilidad de exportar las gráficas a un fichero de texto para su posterior estudio en otras plataformas. Para una información más detallada de las diferentes pantallas de la aplicación se dispone del Manual de usuario en el Apéndice B Gráficas de resultados Para analizar los datos de una forma más sencilla, se decidió ofrecer al usuario un conjunto de gráficas para consultar, las cuales, ilustran algunos datos importantes de la simulación. La clase encargada de crear y mostrar las gráficas es PanelGraficas.java y en ella se hace uso del paquete JFreeChart, descrito en el Capítulo Gracias a dicho paquete podemos crear gráficas de varios tipos, tales como barras, histogramas, lineales y otras. El usuario tiene disponibles tres conjuntos de gráficas: Gráficas de tráfico: en las que se da la posibilidad de analizar la cantidad de tráfico que procesan los nodos, ya sea por paquetes o por tráfico total, además de saber cuánto tráfico inserta cada nodo en el sistema. Para la generación de estas gráficas se ha decidido seguir los siguientes pasos: 64

90 4.4. GUI A medida que se lee el fichero de trazas, se almacena el tamaño del paquete leído o se aumenta el número de paquetes leídos Si es una recepción o un encolamiento para envío se mira el nodo que lo está procesando y el dato leído en el punto anterior se almacena para ese nodo en los paquetes procesados Si es un descarte se mira el nodo que lo está descartando y el dato leído en el primer punto se almacena para ese nodo en los paquetes descartados Una vez se ha leído todo el fichero, se generan porcentajes de los paquetes cursados y descartados por cada nodo El objetivo de estas gráficas es ofrecer una vista sencilla e intuitiva de la cantidad de tráfico que debe procesar cada nodo. De esta manera, se puede modificar la capacidad de los nodos en función del porcentaje de tráfico que deban procesar, a mayor tráfico, mayor capacidad. Gráficas del estado de las colas en los nodos: en este grupo se muestran dos gráficas sencillas, la primera muestra el tiempo medio que espera un paquete en la cola de los nodos. Para este cálculo, NS impone una limitación, ya que en el fichero de trazas, la precisión del tiempo no va más allá de los µs. La manera de generar la gráfica es: Se van leyendo las líneas del fichero de trazas Cada vez que se recibe un paquete, se almacena el instante de tiempo en una variable para cada nodo Cuando ese mismo paquete se encola para su envío se mira el instante de tiempo y se le resta el anterior El dato anterior se almacena para su posterior representación La segunda gráfica muestra una serie por cada nodo del sistema, esta serie muestra la cantidad de paquetes en la cola de un nodo en cada 10ms de la simulación. Para poder realizar esta gráfica se siguen los siguientes pasos: Se va leyendo el fichero de trazas Cuando se recibe un paquete o se descarta, se mira el instante de tiempo y se divide entre 0,01 para obtener el slot de 10ms en el que ocurre 65

91 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Se aumenta el número de paquetes en cola del nodo en cuestión en el slot de 10ms correspondiente El motivo de este conjunto de gráficas es ofrecer al usuario una vista del estado de las colas en cada nodo. Con la primera gráfica podemos ver el tiempo que tarda un paquete entre que entra en cola y es enviado. Con la segunda, se consigue, de una manera rápida y visual, saber la cantidad de tráfico que le llega a un nodo cada 10ms, lo que da una idea de lo congestionado que se encuentra. Gráficas de retardo: en este último conjunto, se muestran los tiempos medios de retardo entre cada par de nodos, es decir, el tiempo que tarda un paquete desde que se envía hasta que es recibido por el nodo destino. También se ofrece una matriz con la cantidad de nodos intermedios que un paquete debe atravesar para llegar a un nodo destino, ya que cuantos más nodos deba atravesar un paquete, mayor será el tiempo empleado en llegar. Para poder generar estas gráficas se debe: Mientras se lee el fichero de trazas, para cada nodo externo se almacenan los instantes de tiempo en los que se envía tráfico Si se recibe un paquete y no es el destino, se aumenta en uno el número de nodos intermedios entre el origen y el destino Si se recibe un paquete y es el destino, se mira el instante de tiempo y se le resta el instante de envío Con este último conjunto de gráficas se pretende controlar a simple vista, posibles retardos en la recepción de los paquetes, lo que podría venir dado por una alta congestión en uno de los nodos intermedios. También hay que señalar que por cada topología simulada se muestran estos tres conjuntos de gráficas, pudiendo elegir en cada momento a través de un menú desplegable las gráficas que se quieren mostrar y de qué topología en concreto. En el Manual de usuario, en el Apéndice B, se puede encontrar una descripción más detallada sobre la función de cada una de las gráficas. Al usuario se le ofrece la posibilidad de exportar las gráficas a un fichero de texto para su posterior procesamiento en otras plataformas capaces de representar gráficas, como 66

92 4.4. GUI pueden ser MATLAB 1 o gnuplot 2, cada gráfica tiene un modelo de fichero de salida, ya que no todas las gráficas son iguales. Por ejemplo, las gráficas de barras generan un fichero donde la primera columna es el nombre del nodo, la segunda es el valor medio calculado y la tercera es la desviación típica. En el Manual de usuario, en el Apéndice B, se detalla el formato de todos los ficheros para que su procesado sea más cómodo y así facilitar su representación. Por supuesto, este formato no sigue ningún estándar, se ha tomado la decisión de exportar las gráficas de esa manera ya que era la más lógica Ampliar funcionalidad Durante la realización del proyecto surgieron otras posibles ampliaciones para la aplicación, algunas de ellas son: añadir más tipos de tráfico o tener la posibilidad de seleccionar entre más tipos de nodos, como ethernet o wifi; e incluso diferentes tipos de red, ya que la aplicación no está ligada a la tecnología. Pero debido a que la funcionalidad principal era la simulación de redes ópticas con OBS, se dejaron para posibles líneas futuras de desarrollo, como se verá en el Capítulo 6. Aún así, se ha considerado que las descritas aquí poseen cierta relevancia e interés, y por esta razón se detalla su posible implementación. Añadir nuevo tipo de tráfico Para añadir un nuevo tipo de tráfico hay que seguir una sencilla serie de pasos: 1. Modificar la pestaña de Opciones de Simulación para que se pueda seleccionar el nuevo tráfico, además de poder elegir un valor para el tamaño de los paquetes. 2. Modificar el fichero esqueleto de la topología en NS para poder introducir ese nuevo tipo de tráfico, basta con seguir la estructura de los procedimientos ya generados para los otros tráficos. 3. Cuando se vaya a escribir la topología final de NS, escribir en el código de la aplicación un nuevo caso, para este nuevo tráfico, siguiendo la estructura de los que ya están

93 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN Añadir nuevo tipo de nodo Añadir un tipo nuevo de nodo no es tan sencillo como añadir tráfico, ya que los nodos tienen ciertas características, sobretodo si son nodos wifi, como puede ser la antena, la potencia de la antena..., pero en esencia se siguen los mismos pasos. 1. Ofrecer la posibilidad al usuario de elegir un tipo de nodo u otro, preferiblemente en la pestaña de las Opciones de Simulación, ya que ahí es donde se configuran todos los parámetros. 2. Modificar el fichero esqueleto para añadir todos los parámetros de los nodos que no vamos a ofrecer al usuario para modificar. 3. Los parámetros modificables debemos mostrarlos en una pestaña. 4. A la hora de escribir los nodos en el fichero final NS, escribir una declaración u otra, dependiendo de la elección del usuario. 5. Los enlaces no son los mismos que para OBS, por lo tanto a la hora de escribirlos en el fichero NS para simular deberemos poner enlaces correspondientes a la elección del usuario Diagrama de clases simplificado En la figura 4.9 se muestra un diagrama de clases simplificado, en el que se ilustra la relación entre las clases, y en el que, a primera vista, se puede ver como la clase central de la aplicación es Interfaz.java. Para ver una descripción de la funcionalidad de cada una de las clases y un diagrama más detallado, consultar el Apéndice E. 68

94 4.4. GUI Figura 4.9: Diagrama de clases simplificado 69

95 CAPÍTULO 4. DESCRIPCIÓN DE LA APLICACIÓN 70

96 Capítulo 5 Validación En este capítulo se validará el funcionamiento de la aplicación y se analizarán las pruebas realizadas para ello Pruebas a realizar Para comprobar el correcto funcionamiento de la aplicación se han elegido una serie de pruebas: Prueba 1: Arrancar la aplicación sin fichero.lastconf para que no cargue ninguna configuración por defecto. Prueba 2: Una vez realizada una simulación, cerrar la aplicación y volver a abrirla para comprobar que se cargan los ficheros de la última simulación realizada. Prueba 3: Tras la lectura y posterior parseo del fichero XML, comprobar que la red mostrada en el Panel de Red se corresponde con la leída. Prueba 4: Comprobar que las demandas y los enlaces se corresponden con los leídos en el fichero XML. Prueba 5: Sabiendo que existe algún nodo aislado, es decir, sin ningún enlace con capcidad diferente de 0Mbps, intentar generar el fichero para la simulación y comprobar que la ventana de aviso se muestra. Prueba 6: Simulación de envío del tráfico leído del fichero XML con una capacidad de 1Gbps para cada uno de los enlaces con diferentes niveles de carga. 71

97 CAPÍTULO 5. VALIDACIÓN Figura 5.1: Red NFSNET (arriba), proyecto Nobel para Europa (abajo izquierda) y Polonia (abajo derecha) [20] Prueba 7: Simulación de una red cambiando los retardos entre los enlaces. Prueba 8: Simulación de una red para comprobar el estado de las colas de espera en los nodos. Prueba 9: Simulación de un escenario diferente en el que se puede aplicar teoría de colas. Prueba 10: Una vez realizada una simulación y mostradas sus gráficas, exportarlas a un fichero de texto. Las pruebas de robustez de la aplicación se han pasado con éxito, pero las que aportan una mejor visión de la funcionalidad de la aplicación son las de simulación y obtención 72

98 5.2. PRUEBAS DE CARGA de gráficas de resultados. Por ello, se va a explicar de manera más detallada los resultados obtenidos en las diferentes pruebas de simulación. Para más información de cómo configurar los parámetros de la simulación, consultar el Apéndice B Pruebas de carga Estas pruebas se han decidido realizar en tres topologías diferentes, dos de ellas con características similares y otra con el doble de dimensión que las anteriores (figura 5.1). Esto es debido a que, como premisa, redes de características similares, deberían tener resultados similares, y para que la validación sea correcta, deberían mostrar resultados acordes. Para realizar las simulaciones se ha elegido el tráfico Exponential ya que es el modelo de tráfico teórico más conocido y estudiado Pruebas con carga baja en los enlaces Los parámetros configurados en la simulación para esta batería de pruebas han sido: La capacidad de los enlaces es de 1Gbps. La carga de los enlaces es de N 1 1, lo que en este caso es aproximadamente un 7%. 4 canales de datos y 1 de control. Retardo de enlace de 1ms. Tamaño de paquete de 2000bits. La primera red, que consiste en 14 nodos, 21 enlaces y 91 demandas de tráfico, distribuidas como se puede observar en [23], correspondiente a la NFSNET, ha obtenido los resultados mostrados en la figura 5.2. Para comprender e interpretar las gráficas de resultados se va a explicar su representación. Las gráficas representan los porcentajes de paquetes cursados o descartados en cada nodo en función del total cursado por la red, y cada una de ella se corresponde con 73

99 CAPÍTULO 5. VALIDACIÓN Figura 5.2: Prueba con baja carga para NFSNET [23]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella una de las topologías generadas a partir de la NFSNET. El orden de izquierda a derecha y de arriba a abajo es: la topología original de la red NFSNET, el anillo, la malla y la estrella, todas ellas equivalentes. En el eje de ordenadas se representa el nombre de los nodos y en el de abscisas el porcentaje de paquetes respecto del total cursado por la red. A cada nodo le corresponden dos barras, una azul y una roja. Las barras azules indican el porcentaje de paquetes procesados por el nodo, mientras que la roja señala el porcentaje de paquetes descartados. Para entender mejor la representación de dichas gráficas se va a exponer un ejemplo. En el anillo generado (esquina superior derecha), el nodo de Palo-Alto (primer nodo), procesa de manera correcta el 3% del tráfico total que circula por la red; y descarta un porcentaje menor a 1% del total de dicho tráfico. Por otro lado, el nodo de Urbana-Champaign (sexto nodo), procesa correctamente en torno al 10% del total cursado por la red y descarta del orden de un 4%. Una vez explicada una posible representación de los resultados, se puede realizar una interpretación de los mismos, aunque hay que recordar que el objetivo no es elegir la mejor distribución de la red, si no aportar las herramientas de ayuda necesarias para 74

100 5.2. PRUEBAS DE CARGA Figura 5.3: Prueba con baja carga para Europa [24]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella que el usuario tome esa decisión. En el escenario simulado anteriormente se observa que la red no presenta apenas congestión en ninguna de sus variantes, como era de esperar antes de realizar la simulación, dado que la carga de entrada es baja. Para el segundo escenario, conformado por 28 nodos, 41 enlaces y 378 demandas de tráfico, descrito en [24], correspondiente a la red de Europa para el proyecto Nobel 1, se han obtenido los resultados representados en la figura 5.3. En comparación con la simulación anterior, se puede ver fácilmente que al ser una red más grande, el tráfico es mayor, por lo que los nodos deben procesar muchos más paquetes, formando colas de espera mayores y descartando un porcentaje mayor de los mismos. Para la tercera topología, integrada por 12 nodos, 18 enlaces y 66 demandas de tráfico, ubicada en [25], correspondiente a la red de Polonia, se han obtenido los resultados mostrados en la figura

101 CAPÍTULO 5. VALIDACIÓN Figura 5.4: Prueba con baja carga para Polonia [25]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella Al tener las mismas dimensiones que la primera red, es de esperar que los resultados obtenidos sean similares. Y comparando las figuras 5.2 y 5.4 se puede comprobar que la premisa es cierta y que para redes similares se obtienen resultados similares. Lo que nos permite validar la aplicación Pruebas con carga media en los enlaces Los parámetros configurados para estas pruebas han sido: La capacidad de los enlaces es de 1Gbps. La carga de los enlaces es de un 50%. 4 canales de datos y 1 de control. Retardo de enlace de 1ms. Tamaño de paquete de 2000bits. 76

102 5.2. PRUEBAS DE CARGA Figura 5.5: Prueba con carga media para NFSNET [23]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella Para estas pruebas se han utilizado las mismas tres topologías que en la prueba anterior, usando los mismos parámetros de configuración a excepción de la carga en los enlaces. Para la red NFSNET, con 14 nodos, 21 enlaces y 91 demandas de tráfico [23], se han obtenido los resultados mostrados en la figura 5.5. En ella se puede observar cómo el porcentaje de tráfico descartado aumenta respecto a la prueba anterior, algo lógico si tenemos en cuenta que los nodos están al 50% de su capacidad. Para el caso de la red de Europa, la conformada por 28 nodos, 41 enlaces y 378 demandas [24], se obtienen los resultados de la figura 5.6. Como era de esperar, el porcentaje de tráfico descartado por los nodos aumenta considerablemente comparado con la prueba anterior, pero es algo previsible teniendo en cuenta que la carga es del 50%. Y para la última de las redes probadas, la formada por 12 nodos, 18 enlaces y 66 demandas [25], y muy similar en características y prestaciones de la primera red, se vuelve a tener unos resultados parecidos a los obtenidos por dicha red, como se puede ver en la figura

103 CAPÍTULO 5. VALIDACIÓN Figura 5.6: Prueba con media carga para Europa [24]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella Figura 5.7: Prueba con carga media para Polonia [25]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella 78

104 5.2. PRUEBAS DE CARGA Pruebas con carga alta en los enlaces Los parámetros configurados en esta ocasión son: La capacidad de los enlaces es de 1Gbps. La carga de los enlaces es de un 95%. 4 canales de datos y 1 de control. Retardo de enlace de 1ms. Tamaño de paquete de 2000bits. De nuevo se han vuelto a utilizar las mismas topologías que en las pruebas anteriores, manteniendo de nuevo las mismos parámetros para la simulación, pero cambiando la carga de los nodos a una mucho mayor, lo que nos lleva a pensar de antemano que la cantidad de paquetes descartados en estas simulaciones aumentará de manera considerable, en un concreto hasta un 95%. Para la red NFSNET, la que compuesta de 14 nodos, 21 enlaces y 91 demandas de tráfico [23] se obtienen los resultados mostrados en la figura 5.8, y como se ha señalado antes, la cantidad de paquetes descartados aumenta desmesuradamente hasta casi llegar a descartar la totalidad de los paquetes que circulan por la red. Para la red de mayores dimensiones, la correspondiente a Europa, con 28 nodos, 41 enlaces y 378 demandas [24], se tienen los resultados mostrados en la figura 5.9. Si analizamos brevemente dicha figura, se observa a primera vista como ahora los resultados ya se parecen más a los de la red de estudio, pero esto es debido a que la primera red está saturada casi al completo, al igual que esta, por lo que los resultados serán muy parecidos. Para la tercera red, la de Polonia, con 12 nodos, 18 enlaces y 66 demandas [25], los resultados obtenidos son los mostrados en la figura De nuevo, podemos observar, si comparamos los resultados con los de la primera red, que ambas son muy parecidas, lo que confirma la suposición inicial de que redes de una magnitud similar tienen resultados similares. 79

105 CAPÍTULO 5. VALIDACIÓN Figura 5.8: Prueba con carga alta para NFSNET [23]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella Figura 5.9: Prueba con carga alta para Europa [24]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella 80

106 5.3. PRUEBAS DE RETARDO Figura 5.10: Prueba con carga alta para Polonia [25]. El orden de las topologías, de izquierda a derecha y de arriba a abajo es: original, anillo, malla, estrella 5.3. Pruebas de retardo Lo que se pretende conseguir con estas pruebas es comprobar que, en una red simulada, si se introduce un retardo de enlace mayor al que inicialmente tenía, las gráficas de retardo mostrarán un aumento significativo del retardo entre dos nodos extremos. Para realizar estas pruebas se ha decidido utilizar la red NFSNET [23] y para comprobar que la aplicación funciona correctamente utilizaremos la red de Polonia [25] para contrastar los resultados entre dos redes similares. Para estas pruebas, de nuevo se elige el tráfico Exponential, por las razones antes citadas Pruebas con tiempos de retardo bajo en los enlaces Los parámetros configurados para la simulación son los descritos a continuación: La capacidad de los enlaces es de 1Gbps. 81

107 CAPÍTULO 5. VALIDACIÓN La carga de los enlaces es de un 50%. 4 canales de datos y 1 de control. Tamaño de paquete de 2000bits. Las primeras pruebas se harán con un retardo de enlace de 1ms. Cabe destacar que este retardo será el mismo para los enlaces edge-core y para los core-core. En la figura 5.11 se muestra el resultado de la simulación antes descrita. Para una mejor comprensión de las gráficas se van a describir brevemente. Cada fila corresponde a una topología, de arriba a abajo son: la topología original, el anillo, la malla y la estrella, todas ellas equivalentes. Por cada fila hay dos gráficas, la media del retardo entre dos nodos extremos, medida en ms, y los nodos intermedios entre nodos extremos. Cada gráfica se compone de una matriz de colores y una escala de grises a su derecha. Los ejes de la matriz se corresponden con los nodos, es decir, que la posición 2:3, es el retardo o los nodos intermedios (según la gráfica que se esté estudiando) que hay entre el nodo 2 y el 3, por lo tanto, si se quiere conocer el valor obtenido, se debe mirar el color de la posición deseada y comprobarlo con la escala adjunta. Una vez explicado el formato de las gráficas y su manera de interpretación, vamos a poner un ejemplo. Si quisiéramos saber el retardo que existe entre los nodos 4 y 5 en la topología original, se debe mirar la matriz y consultar el color en la escala adjunta, en este caso, tendríamos un valor aproximado de 4,5ms. La gráfica de los nodos se muestra para comprobar que los picos en el retardo corresponden a un gran número de nodos intermedios. Por ejemplo, en la topología en anillo se detecta que entre los nodos 3 y 10 hay un retardo de aproximadamente 9ms, algo bastante grande para ser un retardo de enlace de 1ms, pero si se comprueba la gráfica de nodos intermedios, se ve que los paquetes que van desde el nodo 3 al 10 deben pasar por 7 nodos intermedios, lo que aumenta en gran medida el retardo. La peculiar configuración de las gráficas, en forma de matriz triangular, se debe a que las demandas de tráfico sólo están configuradas en un sentido en el fichero XML. La aplicación no se encarga de duplicar esas demandas, tan sólo se limita a simular lo que haya en dicho fichero. Si observamos las gráficas detenidamente, es fácil saber de antemano la forma que tendrán. Los nodos en el anillo están unidos con el anterior y el siguiente, por lo que es 82

108 5.3. PRUEBAS DE RETARDO Figura 5.11: Prueba retardo bajo en enlaces para NFSNET [23]. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 83

109 CAPÍTULO 5. VALIDACIÓN Figura 5.12: Prueba retardo bajo en enlaces para Polonia [25]. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 84

110 5.3. PRUEBAS DE RETARDO fácil pensar que el retardo será pequeño en nodos cercanos y grande en nodos alejados, y como se muestra en las gráficas de resultados, se obtiene esa figura tan peculiar. Para el caso de la malla, era sencillo pensar que el retardo sería igual para todos los nodos, a menos que hubiese congestión, ya que en una malla, todos los nodos se interconectan entre sí. Y para el caso de la estrella, tenemos la misma filosofía que para la malla, solo que esta vez en vez de ser enlace directo, se pasa por un nodo concentrador. Los resultados de la topología de Polonia para contrastar se muestran en la figura Como en este caso estamos atendiendo al retardo entre nodos, que la red tenga las mismas características es algo que carece de importancia, ya que lo que verdaderamente importa en este tipo de análisis es la diposición de los enlaces, y como se puede apreciar, entre las dos redes no hay demasiado parecido. Lo que sí se puede comparar es el retardo máximo, que está en torno a los 6,5ms. Si se comparase con una red de mayor magnitud, el retardo en dicha red superaría con creces al de estas dos más pequeñas, aunque como se ha señalado, depende de la disposición de los enlaces y de su retardo o longitud Pruebas con tiempos de retardo medio en los enlaces Los parámetros de estas simulaciones son los siguientes: La capacidad de los enlaces es de 1Gbps. La carga de los enlaces es de un 50%. 4 canales de datos y 1 de control. Tamaño de paquete de 2000bits. Para este segundo bloque de pruebas de retardo, se va a aumentar el retardo de los enlaces a 10ms. Como se puede comprobar en las figuras 5.13 y 5.14, el retardo entre los nodos ha aumentado un orden de magnitud, como era de esperar al aumentar el retardo de los enlaces del mismo modo. Se puede apreciar, cómo el retardo en este caso mantiene las mismas proporciones que en las primeras pruebas, es decir, se tienen los mismos retardos entre nodos, pero un orden de magnitud mayor, por lo que de cara a la tercera batería de pruebas de retardo, cabe esperar un resultado similar. 85

111 CAPÍTULO 5. VALIDACIÓN Figura 5.13: Prueba retardo medio en enlaces para NFSNET [23]. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 86

112 5.3. PRUEBAS DE RETARDO Figura 5.14: Prueba retardo medio en enlaces para Polonia [25]. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 87

113 CAPÍTULO 5. VALIDACIÓN Figura 5.15: Prueba retardo alto en enlaces para NFSNET [23]. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 88

114 5.3. PRUEBAS DE RETARDO Figura 5.16: Prueba retardo alto en enlaces para Polonia [25]. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 89

115 CAPÍTULO 5. VALIDACIÓN Pruebas con tiempos de retardo altos en los enlaces Los parámetros con los que se ha configurado la simulación son: La capacidad de los enlaces es de 1Gbps. La carga de los enlaces es de un 50%. 4 canales de datos y 1 de control. Tamaño de paquete de 2000bits. Para este tercer y último bloque de pruebas de retardo, se va a fijar el retardo de los enlaces a 100ms, que para redes de fibra óptica es mucho, pero el objetivo de la prueba era validar la aplicación para diferentes magnitudes del retardo entre dos nodos extremos. Como se comprueba en las figuras 5.15 y 5.16, el retardo sigue el mismo patrón que las pruebas anteriores, pero en un orden de magnitud mucho mayor. Como ya se había apuntado, este resultado era el esperado según el estudio de las anteriores pruebas Estudio del estado de las colas de espera en los nodos Lo que se pretende conseguir con estas pruebas es comprobar que al introducir picos de carga en un escenario, los nodos involucrados deben procesar muchos más paquetes, y por lo tanto, las colas de dichos nodos crecerán visiblemente. Para la realización de estas pruebas se toma como red de estudio la de Almenia, descrita en [26]. El tamaño de los enlaces se ha fijado a 50Mb/s, teniendo en cuenta que las demandas de tráfico no son muy grandes, y 4 canales de datos de OBS y 1 de control. El tráfico enviado a sido Exponential, con un tamaño de paquete de 2000bits Pruebas con demandas bajas Como ya se dijo, se van a estudiar las colas de los nodos, por lo que las gráficas interesantes serán las de número de paquetes en cola cada 10ms. Para esta prueba se han obtenido las gráficas mostradas en la figura

116 5.4. ESTUDIO DEL ESTADO DE LAS COLAS DE ESPERA EN LOS NODOS Figura 5.17: Prueba sin carga. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 91

117 CAPÍTULO 5. VALIDACIÓN Este tipo de gráficas representan la cantidad de paquetes que tiene un nodo en cola cada 10ms. Para su mejor comprensión, se va a explicar brevemente su estructura. En el eje de ordenadas tenemos los instantes de tiempo y en el de abscisas el número de paquetes en la cola de un nodo. Como se puede apreciar, para cada nodo existe una serie de puntos por cada instante de tiempo, cada uno pintado de un color y con una leyenda para identificarlos. La figura en concreto está compuesta por los resultados de las diferentes topologías, que de arriba a abajo son: la original, el anillo, la malla y la estrella. Así por ejemplo, en el nodo de Frankfurt de la topología original, se tienen más o menos 2 paquetes en cola habitualmente, pero en los instantes de tiempo 13,0s y 16,0s se llegan a tener seis paquetes en cola, lo que induce a pensar que hay cierta congestión en esos instantes de tiempo Pruebas con picos de demanda Para poder realizar un estudio comparativo, se ha simulado la misma red, con los mismos parámetros, pero introduciendo picos de tráfico en tres demandas. De esta forma, se puede pensar a priori, que las colas en los nodos van a aumentar de una manera significativa. Los resultados de estas pruebas se muestran en la figura Como se había previsto, las colas en los nodos por los cuales se encaminan los picos, crecen lo suficiente como para ser visibles y nada despreciables en su estudio. Tras analizar la gráfica, se podría tomar la decisión de aumentar la capacidad de los enlaces involucrados en ese aumento de paquetes en cola, para evitar la saturación de las mismas en caso de que haya otros picos de demanda inesperados Simulación de otros escenarios Como se ha explicado en el Capítulo 2.2.1, la aplicación está basada en un simulador de eventos, que permite simular redes de colas. En general, estableciendo los parámetros correctos, podemos simular otros tipos de estas redes. Para ilustrarlo, se va a simular un modelo para redes de vehículos, que sigue los mismos principios: análogamente, los paquetes serían coches, la capacidad del enlace sería la velocidad de incorporación a la vía, los nodos serían las entradas o salidas y la velocidad de propagación sería la velocidad de la vía. 92

118 5.5. SIMULACIÓN DE OTROS ESCENARIOS Figura 5.18: Prueba picos de carga. El orden de las topologías,de arriba a abajo es: original, anillo, malla, estrella 93

119 CAPÍTULO 5. VALIDACIÓN Figura 5.19: Esquema de la M-40 Concretamente se ha elegido un esquema de la M-40, mostrado en la figura Se han utilizado dos topologías para este escenario, la propia M-40, formando un anillo exterior entre las salidas a las otras carreteras, y la M-30, formando un anillo más pequeño sólo entre ciertas salidas para aligerar el tráfico existente en la primera simulación. Para la de la topología en anillo, sólo se utilizarán los enlaces de la M-40. Una vez establecida la topología de la red y procesada por la aplicación, se deben introducir los parámetros de la simulación. Para ello, se harán las siguientes suposiciones: El tamaño de los coches: en este caso los coches equivalen a los paquetes, por lo que se debe introducir el tamaño de la unidad mínima en metros. Para este escenario, se ha elegido como tamaño de unidad de computación 6. La cantidad de coches: podemos relacionarla con las demandas entre nodos. La demanda entre, por ejemplo, el nodo A1 y el A4 equivaldría a la cantidad de coches que entrando a la red por el nodo A1, desean salir de ella en el nodo A4. Cabe destacar que las demandas se miden en un orden de magnitud de 10 6, y que las unidades de computación ocupan un tamaño de 6 unidades de medida, por lo que si, por ejemplo, se desea simular que del A1 al A4 van 50 unidades de computación, se debe poner una demanda de 300, y como la aplicación pide un orden de magnitud de 10 6 el dato correcto debe ser 0,

120 5.5. SIMULACIÓN DE OTROS ESCENARIOS El número de carriles: como se vió en el Capítulo 2.3, se puede modelar este tipo de redes como un sistema M/M/c. Para el ejemplo que nos ocupa el número de carriles equivale al número de canales de datos disponibles para la transmisión de datos, de esta manera, se han estimado el número de canales en 3, por lo que se tienen que configurar 3 canales de datos y 1 de control, luego el sistema será un M/M/3, con entrada tráfico Exponential. La velocidad de incorporación: equivale a la capacidad del enlace. Para el caso planteado, se tienen 3 canales, y se asume que la velocidad de incorporación a la vía es de unos 50km/h o 13m/s, por lo tanto la capacidad de los nodos de entrada se debe establecer a 39m/s. Haciendo unos cálculos previos a la simulación se puede obtener la tasa de servicio del sistema, cúantos coches se incorporan a la carretera. tiempo servicio = 6m/coche 13m/s = 0,46s/unidades O lo que es lo mismo, se envían (tasa servicio µ) 2,16unidades/s. La congestión de las incorporaciones: al tratarse de un sistema M/M/c, se puede representar este dato como el factor de ocupación de los nodos ρ, tal y como se explicó en el Capítulo 2.3, con lo que se puede indicar si es una hora con mucho tráfico o con tráfico menos congestionado. Se puede calcular la tasa de llegadas de los paquetes, o lo que es lo mismo cada cuánto tiempo llegan paquetes al sistema, utilizando la fórmula descrita en el Capítulo 2.3 para un sistema M/M/c, como: λ = ρ cµ Si se sustituyen los datos en la fórmula anterior se obtiene la tasa de llegadas para un determinado ρ. El tiempo de viaje: este último parámetro tiene relación con el retardo de los enlaces, el cual hay que configurar en el campo correspondiente de la pestaña de Opciones de Simulación de la aplicación. Se ha decidido que entre los nodos hay una distancia de 10km y que los paquetes (coches) viajan una velocidad media de 100km/h, por lo que haciendo unos pequeños cálculos, se obtiene que los tardan 360s desde un nodo al siguiente. De nuevo se debe tener cuidado al introducir este dato en la aplicación, ya que se deben introducir ms, por lo tanto si queremos establecer el retardo a 360s se debe poner en la casilla correspondiente al retardo de los enlaces. 95

121 CAPÍTULO 5. VALIDACIÓN Figura 5.20: Colas en los nodos con apoyo de anillo interior. Congestión 50%. Figura 5.21: Colas en los nodos sin apoyo de anillo interior. Congestión 50%. Una vez que se han establecido los parámetros para la simulación se procede a obtener los resultados gráficos. Se han realizado dos simulaciones para comprobar el funcionamiento. Una con un factor de ocupación del 50% y otra del 90%, obteniéndose los resultados que se muestran en las siguientes figuras. En la figura 5.20 se muestran las colas con el respaldo de la red interna mientras que en la figura 5.21 se muestran los resultados para la red externa únicamente. Ambas figuras se han obtenido mediante una simulación de 7 nodos, interconectados como se muestra en la figura 5.19, y con los parámetros que se han explicado anteriormente, además de un factor de ocupación del 50%. Se puede apreciar cómo sin el apoyo del anillo interno la red está algo más cargada, pero dada la poca carga, apenas es relevante. Pero para la simulación realizada con los mismos parámetros descritos antes, pero con 96

122 5.5. SIMULACIÓN DE OTROS ESCENARIOS Figura 5.22: Colas en los nodos con apoyo de anillo interior. Congestión 90%. Figura 5.23: Colas en los nodos sin apoyo de anillo interior. Congestión 90%. un factor de ocupación del 90%, mostrado en las figuras 5.22 y 5.23, se puede apreciar como la red sin el anillo interior está algo más cargada. 97

123 CAPÍTULO 5. VALIDACIÓN 98

124 Capítulo 6 Conclusiones y trabajo futuro En la primera parte del capítulo se revisará el trabajo que se ha realizado y en la segunda se expondrán posibles mejoras para ampliar la aplicación Conclusiones El proyecto consistía en facilitar el estudio comparativo de los resultados obtenidos al realizar simulaciones de diferentes topologías de red. Para ello, se diseñó y desarrolló una aplicación con la que, a partir de una topología de red, descrita en formato XML, se generasen las diferentes topologías básicas equivalentes y se pudiesen configurar de una manera fácil e intuitiva los diferentes parámetros de simulación. Una vez realizada la simulación, con un simulador bien conocido como es NS-2, se construirían los diferentes informes gráficos para facilitar el estudio comparativo de las diferentes topologías de red. Los objetivos a priori se han cumplido, pero en el camino recorrido aparecieron problemas, sobretodo con la compilación del módulo de OBS supuestamente integrado en NS-2, lo que más tarde se comprobó que no era así, por lo que se tuvo que buscar posibles soluciones. Para ello, se intentó compilar el módulo original OWns, del cual procede la versión del actual módulo de OBS, pero no fue una solución correcta. Al final, se consiguió encontrar las modificaciones pertinentes que había que hacer a los ficheros del módulo [21] [22] para su posterior compilación e integración. Dichos cambios están descritos en el Apéndice D y los pasos para poder compilar todo el simulador se encuentran en el Apéndice C. 99

125 CAPÍTULO 6. CONCLUSIONES Y TRABAJO FUTURO Además, se pueden sacar las siguientes conclusiones del trabajo realizado: Se ha desarrollado un proyecto de código abierto, por lo cual, cualquier persona puede modificar o ampliar funcionalidades de la aplicación de forma modular y escalable. Para poder ejecutar la aplicación sólo se necesita un equipo con Linux y la instalación del simulador NS-2 con el módulo para OBS, lo cual es bastante sencillo si se siguen las instrucciones descritas en el Manual de instalación en el Apéndice C. La aplicación permite la simulación de cuatro topologías, a saber, una original, una anillo, una malla y una estrella, todas ellas equivalentes. Posteriormente, facilita el estudio comparativo de las mismas, a través de los resultados obtenidos de la simulación, mediante gráficas que ilustran sus prestaciones: bloqueos, retardos, dimensión de colas y tráfico procesado. Uno de los enfoques para la aplicación, es que sirviese de ayuda para la docencia, por lo que posibilita a usuarios no familiarizados con NS-2 la realización de simulaciones de redes que de otra manera deberían realizar en línea de comandos. Pero sin duda, la conclusión más importante, es que la piedra angular del proyecto reside en el fichero esqueleto, donde se encuentran los parámetros que va a utilizar la simulación y no se pueden modificar desde la aplicación gráfica. Además, servirá para generar las topologías en NS para su simulación, a partir de las cuales, se obtendrán los ficheros de trazas para poder mostrar de manera gráfica los resultados obtenidos y, como se dijo, facilitar el estudio comparativo de las topologías de red Trabajo futuro Gracias a que es una aplicación de código abierto, es posible la ampliación de funcionalidades, así como la modificación de las existentes hasta ahora. Algunas de ellas, ya se han descrito en el Capítulo 4 y ahora detallaremos las que consideramos de una realización más factible. 100 Como se dijo en el Capítulo 4, se podrían ampliar los tipos de nodos que se pueden simular, como por ejemplo nodos ethernet o wifi; o añadir más tipos de tráfico

126 6.2. TRABAJO FUTURO para enviar entre nodos. Esto daría mucha más flexibilidad a la aplicación, ya que el número de posibilidades de simulación crecería desmesuradamente. Para realizarlo, bastaría con modificar el fichero esqueleto, añadiendo los parámetros de los nodos o del tráfico, y mostrándolos en el interfaz para su posible modificación. Una buena línea de futuro sería añadir más parámetros para configurar desde el entorno gráfico, ofreciendo la posibilidad a un usuario avanzado, que sea capaz de modificar el esqueleto, de no tener que molestarse en cambiar los parámetros en el propio fichero, si no que sería la propia aplicación la encargada de hacerlo. Para realizarlo, tan sólo habría que introducir más marcas en el fichero y posteriormente, mostrar los campos correspondientes en la aplicación, para permitir la modificación. Dado que los nodos no se encuentran siempre a la misma distancia, hay enlaces que poseen un retardo mayor que otros. Partiendo de esa base, se podría modificar la aplicación para establecer un retardo de enlace en función de la distancia entre los nodos. Para ello, habría que calcular la distancia entre los extremos y a la hora de introducir el enlace en el fichero de simulación, calcular el retardo que tendría y ponerlo en la declaración. Las redes permiten un estudio muy amplio de sus prestaciones, y los resultados mostrados por la aplicación pueden no ser suficientes, por lo que en una línea de trabajo futuro, se podrían añadir más gráficas para un estudio más completo de los eventos en la red. Bastaría con saber el tipo de estudio que se desea realizar, a partir de los resultados que ofrece NS, y crear gráficas acordes. Como no todo el mundo utiliza sistemas Linux, se podría ampliar su uso a otros sistemas operativos. Tan sólo habría que modificar las rutas de acceso a los ficheros en función del sistema anfitrión, ya que como la aplicación es Java, que es multiplataforma, la ejecución de la aplicación no tendría problemas. Como se ha visto durante el estudio del proyecto, existen muchos simuladores de red aparte de NS, por lo que se podría ofrecer la posibilidad de elegir qué simulador se desea utilizar, como por ejemplo OMNeT++ o NS-3 ampliando la compatibilidad del Generador de ficheros de simulación. Para esta línea habría que tener varios ficheros esqueleto, uno por cada simulador disponible en la aplicación, ya que al estar escritos en lenguajes diferentes, la compatibilidad entre ellos es nula. 101

127 CAPÍTULO 6. CONCLUSIONES Y TRABAJO FUTURO Otra posible ampliación es la generación de topologías sin necesidad de parsear ningún fichero, tan sólo introduciendo en la aplicación el número de nodos de la topología y los enlaces entre ellos, se generaría la red deseada por el usuario. Para realizar este trabajo se podría enfocar de varias maneras: se podría pedir al usuario el número de nodos y los enlaces entre ellos, u ofrecer la posibilidad de arrastrar nodos a una pantalla y unirlos mediante flechas. 102

128 Bibliografía [1] M. Maier, Optical switching networks. Cambridge Univ Pr, ISBN [2] C. Qiao and M. Yoo, Optical burst switching (OBS)-a new paradigm for an optical internet, Journal of high speed networks, vol. 8, no. 1, p. 69, ISSN [3] Y. Chen, C. Qiao, and X. Yu, Optical burst switching: A new area in optical networking research, Network, IEEE, vol. 18, no. 3, pp , ISSN [4] T. Battestilli and H. Perros, An introduction to optical burst switching, Communications Magazine, IEEE, vol. 41, no. 8, pp. S10 S15, ISSN [5] D. Larrabeiti and P. Pacyna, Introduction to optical burst switching (obs). [6] S. McCanne, S. Floyd, and K. Fall, LBNL Network Simulator, ns version 1. http: //ee.lbl.gov/ns/, [En línea; acceso el 25-Mayo-2011]. [7] U. of California-Berkeley, The Network Simulator - ns-2. nsnam/ns/, [En línea; acceso el 18-Mayo-2011]. [8] I. Martínez-Yelmo, OBS-WLAN Simulator based on OWNs and NS e-archivo.uc3m.es/handle/10016/7952, [En línea; acceso el 31-Mayo-2011]. [9] U. of California-Berkeley, The ns-3 network simulator [En línea; acceso el 18-Mayo-2011]. [10] U. of California-Berkeley, OMNeT++ Network Simulation Framework. omnetpp.org/, [En línea; acceso el 27-Mayo-2011]. 103

129 BIBLIOGRAFÍA [11] I. O. Technologies, Network Modeling Network Simulation. com/solutions/network_rd/modeler.html, [En línea; acceso el 27-Mayo- 2011]. [12] T. L. Faubel, A. F. Zaragoza, J. M. Díaz, O. Ferrer, and F. A. Candelas, KivaNS [En línea; acceso el 18-Mayo-2011]. [13] T. University of Western Australia, The cnet network simulator. uwa.edu.au/cnet/, [En línea; acceso el 18-Mayo-2011]. [14] D. Bertsekas, R. Gallager, P. Humblet, and M. I. of Technology. Center for Advanced Engineering Study, Data networks. Prentice-hall New York, ISBN [15] W. Stallings, Data and computer communications. Pearson/Prentice Hall, ISBN [16] M. ALZATE and A. Monroy, Introducción al tráfico autosimilar en redes de comunicaciones, Revista de Ingeniería Universidad Distrital, ISSN X. [17] P. P. de Pesteny, The Hurst Exponent and Technical Analysis. optimaltrader.net/hurst_exponent.htm, [En línea; acceso el 5-Julio-2011]. [18] U. de Barcelona, La distribución Gamma. GrupsInnovacio/Statmedia/demo/Temas/Capitulo4/B0C4m1t7.htm, [En línea; acceso el 5-Julio-2011]. [19] U. de Valencia, DISTRIBUCION BINOMIAL NEGATIVA. ceaces/base/modelos%20de%20probabilidad/binegativa.htm, [En línea; acceso el 5-Julio-2011]. [20] Zuse-Institute Berlin, SNDlib [En línea; acceso el 31-Mayo-2011]. [21] J. Study, Ubuntu 8.04 Study Notes (4)-NS2 installation. jerry_916/blog/item/e0e d51d009065b.html, [En línea; acceso el 13-Junio-2011]. [22] F. M. Heart, NS2 learning (1)-ns2.29 installation. blog/item/ffcfa4fac9ba2c15a9d31153.html, [En línea; acceso el 13-Junio- 2011]. 104

130 BIBLIOGRAFÍA [23] SNDlib, nobel-us. objectname=nobel-us&format=xml&objecttype=network, [En línea; acceso el 5-Julio-2011]. [24] SNDlib, nobel-eu. objectname=nobel-eu&format=xml&objecttype=network, [En línea; acceso el 5-Julio-2011]. [25] SNDlib, polska. polska&format=xml&objecttype=network, [En línea; acceso el 5-Julio-2011]. [26] SNDlib, nobel-germany. objectname=nobel-germany&format=xml&objecttype=network, [En línea; acceso el 5-Julio-2011]. 105

131

132 Apéndice A Presupuestos En este capítulo se analizará el desarrollo de este proyecto en términos económicos. A.1. Tareas En este apartado se muestra una estimación de la duración de las distintas tareas que se han llevado a cabo para la realización del proyecto. Las tareas no se han realizado de manera continua, ya que se ha intercalado el desarrollo del proyecto con estudios y becas. En la tabla A.1 se resumen la tareas llevadas a cabo y la duración en horas estimadas para su realización. A.2. Costes Como se ha visto, la duración del proyecto ha sido de novecientas noventa horas, que asumiendo ocho horas de trabajo al día equivalen a unos 124 días laborables, con lo que podemos asumir que si el proyecto lo realizara una persona a tiempo completo se habría podido terminar aproximadamente en unos 6 meses. A.2.1. Personal Para la realización del proyecto se ha necesitado cubrir las tareas que realizarían los especialistas que se detallan en la tabla A.2, junto con el precio de la mano de obra por 107

133 APÉNDICE A. PRESUPUESTOS Descripción Investigación, documentación y análisis Despliegue y configuración del entorno de trabajo Diseño de la aplicación Integración del módulo de OBS en NS-2 Desarrollo del parser Desarrollo de la aplicación Desarrollo de las gráficas con los resultados Integración del sistema completo Realización de pruebas Redacción de la memoria Número de horas estimado 60 horas 10 horas 30 horas 300 horas 50 horas 200 horas 100 horas 40 horas 50 horas 150 horas Tabla A.1: Duración estimada de las tareas hora. El jefe de proyecto será la tutor del mismo. Cargo Coste (por hora) Analista 35,00C Diseñador 40,00C Gestión de calidad y pruebas 35,00C Jefe de proyecto 45,00C Programador 25,00C Tabla A.2: Salarios de especialistas Si se aplican estos costes al número de horas dedicado por cada especialista en función de las fases de diseño y las tareas encomendadas, el resultado se puede ver en la tabla A.3. El coste del personal asciende a C. A.2.2. Material En este apartado se detalla el coste de los materiales empleados durante la realización del proyecto. Estos costes se pueden dividir en equipo y licencias. 108

134 A.2. COSTES Actividad Jefe de proyecto Analista Diseñador Pruebas Programador Totales Investigación, documentación y análisis Despliegue y configuración del entorno de trabajo Diseño de la aplicación Integración del módulo de OBS Desarrollo del parser Desarrollo de la aplicación Desarrollo de las gráficas Integración Pruebas Redacción de la memoria Horas totales Costes 900C C C 2.800C C C Tabla A.3: Coste del personal 109

135 APÉNDICE A. PRESUPUESTOS Equipo El equipo utilizado consta de un ordenador personal con monitor de 20, procesador de dos núcleos y 4GB de memoria RAM. Valorado en 750C todo el conjunto. Licencias En la tabla A.4 se analiza el coste de las licencias que se han necesitado en la elaboración del proyecto. Concepto Licencias Coste/licencia Coste Ubuntu Linux 1 0,00C 0,00C Java 1 0,00C 0,00C Netbeans IDE 1 0,00C 0,00C Latex 1 0,00C 0,00C Total 0,00C Tabla A.4: Coste de licencias Es coste total en licencias es de 0,00C. A.2.3. Costes indirectos En la tabla A.5 se resumen el resto de costes, derivados del uso de instalaciones durante los seis meses que duró el proyecto. Concepto Coste Alquiler del local 1.800,00C Luz y agua 420,00C Servicio de limpieza 360,00C Teléfono fijo y conexión a internet 120,00C Total 2.700,00 C Tabla A.5: Costes indirectos 110

136 A.3. RESUMEN Los gastos ascienden a C en este apartado. A.3. Resumen Teniendo en cuenta todos los costes relatados anteriormente, el coste total necesario para realizar el proyecto asciende a ,00C, tal y como se muestra en la tabla A.6. Concepto Cantidad Mano de obra ,00C Equipo 750,00C Licencias 0,00C Costes indirectos 2.700,00C Total ,00 C Tabla A.6: Costes indirectos Esta cantidad no tiene en cuenta ni el análisis del riesgo ni los impuestos. 111

137 APÉNDICE A. PRESUPUESTOS A.3.1. Totales Finalmente, en la tabla A.7 se desglosa el balance final del coste del proyecto. Concepto Coste total Riesgo (20%) Beneficio (20%) Total sin I.V.A. I.V.A. (18%) Total Cantidad ,00C 6.460,00C 6.460,00C ,00C 8.139,60C ,60C Tabla A.7: Presupuesto total Teniendo en cuenta los costes desglosados en los apartados anteriores, el presupuesto total de este proyecto asciende a la cantidad de CINCUENTA Y TRES MIL TRESCIEN- TOS CINCUENTA Y NUEVE CON SESENTA euros. 112

138 Apéndice B Manual de usuario La aplicación pretende servir de ayuda a la hora de simular, comparar y estudiar los resultados de diferentes topologías mediante la simulación en NS-2. Con ella, se puede tomar como referencia una topología SNDlib [20], y utilizando un simple fichero con el esqueleto de la configuración de NS, simular tantas veces como se necesite para poder sacar resultados estadísticos. Además, la propia aplicación ofrece al usuario la posibilidad de analizar topologías en anillo, malla o estrella de prestaciones similares, utilizando los mismos parámetros para cada una de ellas, y una vez terminada la simulación consultar gráficas para ver el rendimiento de cada una de las mismas. B.1. Descripción La aplicación se divide en varias pestañas: Configuración: configuración de rutas y ficheros. Opciones de simulación: opciones ha introducir en la simulación. Esuqema de la Red: esquema dibujado de la red. Demandas de tráfico: tabla con las demandas de tráfico. Enlaces entre nodos: tabla con los enlaces entre nodos. Gráficas de resultados: gráficas para poder analizar los resultados. 113

139 APÉNDICE B. MANUAL DE USUARIO Figura B.1: Pantalla de Configuración B.1.1. Pantalla Configuración En esta pantalla, figura B.1, se configurará las rutas de los ficheros a utilizar y el número de simulaciones a realizar. Para saber el número de simulaciones a realizar hay que tener en cuenta el funcionamiento interno de la aplicación. Se van a simular 4 topologías diferentes, todas con el mismo tráfico, para poder compararlas eficientemente. Por cada simulación que queramos hacer para sacar unos buenos datos estadísticos, se van a realizar 4 simulaciones, una por cada topología, es decir, si queremos hacer 4 simulaciones, en realidad, estaremos haciendo 16, 4 simulaciones por 4 topologías en cada simulación. Archivo de topología SNDlib: este fichero debe seguir una estructura en formato XML determinada. En [20], se pueden encontrar varios ejemplos de redes reales tales como la red de Atlanta, Francia, Alemania, Europa o EEUU y en el Apéndice F, se puede ver más en detalle cómo es la estructura del fichero. Si se introduce un fichero que no sigue este tipo de formato, no se realizará bien el parseo del mismo, por lo que no se obtendrán los resultados requeridos. La aplicación no se encarga de comprobar que el formato del fichero es correcto. 114

140 B.1. DESCRIPCIÓN Archivo esqueleto de NS: en este fichero se configura toda la simulación del NS a excepción de ciertos parámetros. Para poder realizar la configuración que quiere el usuario, debe haber ciertos flags dentro del fichero que actuarán como marcadores para que la aplicación sea capaz de generar el correcto fichero con la topología, una vez se ha detectado el flag, la línea siguiente en el fichero final corresponderá a la configuración del parámetro correspondiente. Estos flags son, por orden de aparición en el fichero: ##EDGE COUNT##: el número de nodos edge de la red. Su número será igual al número de nodos parseados del fichero SNDlib. ##CORE COUNT##: el número de nodos core de la red. Igual que los nodos edge, serán el mismo número que los nodos parseados, debido a que se ha decidido que cada nodo parseado sea una pareja edge-core dentro de la red OBS. ##DELAY##: el delay (retardo) de los enlaces. Este valor será el mismo tanto entre un edge y su core, como entre cores. ##TOTAL CHANNELS##: el número total de canales por cada nodo, contando con los canales de datos y con los canales de control. ##CONTROL CHANNELS##: el número de canales para el intercambio de mensajes de control en cada nodo. ##DATA CHANNELS##: el número de canales para el intercambio de datos en cada nodo. ##TOPOLOGIA JERARQUICA##: la configuración para hacer efectivo el direccionamiento jerárquico. ##NODOS##: la declaración de los nodos. Primero se declaran los edge y después los core. ##ENLACES##: la declaración de los enlaces. Primero se declaran los enlaces entre edge-core y después entre los core, siguiendo con la configuración de los enlaces requerida por el usuario, ya sea la misma que está parseada u otra diferente de las ofertadas. ##UDP SIZE##: tamaño del paquete de UDP. ##BATCHSIZE##: en caso de que estemos utilizando tráfico SelfSimilar, éste será el tamaño de los paquetes. 115

141 APÉNDICE B. MANUAL DE USUARIO ##CBR SIZE##: cuando se utilice el tráfico CBR, el tamaño de los paquetes será el que se configure a continuación de este flag. ##EXPO SIZE##: cuando se seleccione el tráfico Exponential, este flag será el predecesor del tamaño de los paquetes. ##DEMANDAS##: la declaración del tráfico a simular. ##TIEMPO SIMULACION##: el tiempo que se va a simular. Carpeta de trabajo: en esta carpeta, elegida por el usuario, es donde se guardarán todos los ficheros de la simulación (topologías, trazas y ficheros de NAM), los datos analizados para realizar las gráficas y las gráficas exportadas a fichero de texto para su posterior generación en otras plataformas si se desea. Instalación de NS: esta carpeta es donde se encuentra la instalación de NS, se pueden tener varias versiones del simulador instaladas, la versión que se utilizará es la seleccionada en este campo. Aún así, se recomienda tener como instalación predeterminada la utilizada por la aplicación. Número de simulaciones: es el número de simulaciones que se van a realizar. Como ya se ha comentado, el total de simulaciones será el número introducido por el usuario por 4 topologías en cada una de esas simulaciones. Tiempo de simulación actual: este campo no es editable por el usuario, en su lugar, se muestra el tiempo que va a simular el NS. Para calcularlo, símplemente se añade un segundo al tiempo de finalización de la ráfaga de tráfico más tardía, de ésta manera, nos aseguramos que todas los paquetes han llegado a su destino, suponiendo que no se hayan tirado. Cada vez que se empieza una nueva tanda de simulaciones el tiempo es diferente, lo que tiene su lógica, ya que las topologías de una misma simulación tienen los mismos tiempos de ráfagas de tráfico. Hay que señalar, que los campos para introducir los ficheros y carpetas requeridos para la simulación, siendo la primera vez que se ejecuta la aplicación, aparecerán en blanco, pero una vez se realice una simulación, las siguientes veces aparecerán los datos de la última simulación. Esto es gracias a que cuando se pulsa el botón Simulación, se crea un fichero oculto, llamado.lastconf, que se almacena en la misma ruta donde se encuentra la aplicación. Se procede a explicar los botones disponibles en esta pantalla: 116

142 B.1. DESCRIPCIÓN Botones de Examinar y Guardar: evidentemente, estos botones abrirán un navegador de archivos para poder localizar y seleccionar los ficheros y carpetas que se requieren para la simulación, explicados más arriba. Parsear fichero SNDlib: con este botón se parsea el fichero XML con la declaración de los nodos, los enlaces y las demandas de tráfico. Como ya se dijo, éste fichero debe tener una estructura determinada para poder realizar bien el parseo. Hasta que que se ha parseado el fichero, la aplicación no deja hacer nada más, ya que antes de parsear no se tiene ningún dato de la red a simular. Una vez se tiene todo el esquema de la red almacenado, se habilitan el resto de pestañas y el botón para generar los ficheros para simular en el NS. Generar topología NS: pulsando este botón se generan todos los ficheros para simular en NS. El lugar donde se crearán será la carpeta elegida como Carpeta de trabajo. Los ficheros tendrán un formato como topologyx-y.tcl, donde X es el número de la simulación (empezando en 0) e Y es el número de la topología (0 para la original, 1 para el anillo, 2 para la malla y 3 para la estrella). Hay que hacer una advertencia llegado este punto, se deben configurar todas las opciones que se quieran aplicar a la simulación antes de generar los ficheros de NS, una vez generados, si se cambia algún parámetro, se debe volver a generar los ficheros (pulsar el botón) para que los cambios se apliquen. Es posible editar los ficheros una vez creados, pero corre a cuenta del usuario, y lo más seguro es que los datos de las gráficas a analizar no sean los deseados si las opciones en las simulaciones no son las mismas. Aún así, no se puede cambiar el nombre del fichero ya que la aplicación al ejecutar NS, llama a esos ficheros, con ese nombre. Cualquier otro nombre hará que la ejecución no sea correcta. Arrancar simulación: al pulsar este botón se arranca la simulación entera, es decir, se simulará de manera continuada todos los ficheros, de todas las topologías, de todas las tandas de simulación requeridas por el usuario. Hasta que no se termine de simular todos esos ficheros, no se empezará a analizar los ficheros de trazas. Mientras está simulando, podremos ver una ventana similar a la figura B.2. Una vez terminadas todas las simulaciones, la aplicación comenzará automáticamente a analizar los diferentes ficheros de trazas generados por NS. Mientras está analizando, se podrá observar una ventana similar a la figura B.3. La primera barra de progreso hace referencia a todos los ficheros que se van a 117

143 APÉNDICE B. MANUAL DE USUARIO Figura B.2: Simulación en curso Figura B.3: Analizando y generando gráficas analizar, es decir, que si hemos decidido hacer 4 simulaciones, el 100% de los ficheros a analizar será 16, 4 simulaciones por 4 topologías. La segunda barra de progreso se refiere a cada fichero por separado, contando el número de trazas que se han analizado respecto del total en el fichero que estamos analizando en ese momento. Mientras se están analizando los ficheros de trazas, se crea una carpeta en la Carpeta de trabajo llamada datos donde se almacenan los datos analizados de cada gráfica para cada una de las simulaciones y cada una de las topologías. Hay que apuntar que los datos de las gráficas se crean usando la media de los resultados de todas las simulaciones, por ejemplo, se hacen 4 simulaciones, y en la gráfica del Porcentaje de tráfico inyectado en la red tenemos que para el nodo 1, se han obtenido los resultados 20%, 15%, 30%, 17%; el dato mostrado en la tabla será 20,5%, y se tendrá una desviación típica representada al mismo tiempo. De esta manera, si se observa en una desviación típica muy grande, se puede consultar los datos sacados para ver qué simulación es la que ha provocado esos puntos atípicos que han hecho que la media se desvíe tanto. Hasta que el análisis no termine, no se habilitará la pestaña de las gráficas, al igual que el resto de botones para realizar más simulaciones. Una vez las gráficas se hayan mostrado, la aplicación cambiará automáticamente de pestaña. 118

144 B.1. DESCRIPCIÓN Figura B.4: Topología en anillo recién abierta Además, como ya se señaló, cuando se pulsa este botón, se genera el fichero.lastconf, que servirá para rellenar los campos donde se introducen los ficheros y carpetas la próxima vez que se ejecute la aplicación. Ejecutar NAM: una vez terminado todo el proceso de simulación y análisis de trazas, se habilitará este botón para ejecutar el NAM y poder visualizar la simulación que se ha realizado. La manera de cargarlo es abriendo el fichero.nam y darle al PLAY. Podemos reestructurar el dibujo de la red presionando el botón RE-LAYOUT. Por ejemplo, para la simulación 0 de la topología en anillo, se abrirá el fichero topology0-1.nam para obtener una ventana como la figura B.4. Pulsando el botón RE-LAYOUT, las veces necesarias, se puede reestructurar como se muestra en las figuras B.5 y B.6, para una mejor visualización. B.1.2. Pantalla Opciones de Simulación En esta pantalla, figura B.7, se pueden configurar algunos de los parámetros de las simulaciones. Hay disponibles varios cuadros para rellenar y configurar. Algunos son bastante intui- 119

145 APÉNDICE B. MANUAL DE USUARIO Figura B.5: Topología en anillo Figura B.6: Topología en anillo estructurada 120

146 B.1. DESCRIPCIÓN Figura B.7: Pantalla Opciones Simulación tivos, pero otros no lo son tanto. Se procede a explicarlos un poco más detalladamente. Tipo de tráfico: define el tipo de tráfico que se va a utilizar, dándo a elegir entre SelfSimilar, CBR o Exponential. Según el tipo de tráfico elegido, la declaración de dicho tráfico en el fichero TCL será de una manera o de otra. Opciones Generales: se pueden configurar varios parámetros de la simulación que no se ven influidos por el tipo de tráfico que hayamos elegido. Básicamente son parámetros de configuración de los nodos y enlaces. Por defecto ya tienen unos valores, así el usuario no tiene que preocuparse de rellenarlos, y en caso que se desee, basta con modificar éstos datos. Hay que tener en cuenta que los datos serán iguales para todos los nodos y enlaces. Retardo enlaces: es el retardo de los enlaces. Por defecto está configurado a 1ms. Canales datos: son los canales de datos de los que disponen los nodos. 121

147 APÉNDICE B. MANUAL DE USUARIO Canales control: son los canales de control que disponen los nodos. Habitualmente, el número de canales de control es menor que el de datos. Tamaño UDP: éste es el único parámetro de tráfico que es común a los tres tipos. Esto se debe a que todos los tráficos posibles de la simulación funcionan sobre el protocolo UDP debido a su sencillez. Opciones SelfSimilar: en este campo se configura el tamaño de los paquetes del tráfico SelfSimilar. Sólo se toma en cuenta cuando se selecciona el tráfico SelfSimilar. Opciones CBR: se configura el tamaño de los paquetes del tráfico CBR, siempre y cuando se haya seleccionado el tráfico CBR. Opciones Exponential: cuando se selecciona el tráfico Exponential, se utiliza para configurar el tamaño de los paquetes de dicho tráfico. Tiempo de Simulación: esta opción se utiliza para hacer simulaciones más cortas y rápidas. Se puede elegir truncar el tiempo de simulación a un tiempo elegido o se puede dejar que simule en su totalidad. Si se elige un tiempo menor del calculado, el tráfico que debería enviarse a partir de ese tiempo no será simulado. Enlaces: se puede decir a la aplicación que ponga todos los enlaces iguales,o que deje los que haya recolectado del fichero. Como los enlaces originales son válidos sólo para la topología original, se ha decidido calcular los enlaces equivalentes para el resto de topologías. Anillo: para el anillo, se ha sumado todas las capacidades de los nodos implicados en el nuevo enlace y se ha cogido la menor de dichas sumas para intentar emular las limitaciones de los nodos. Se puede realizar de ésta manera ya que los enlaces son Dúplex, en caso contrario, habría que calcular por separado los enlaces como origen y como destino para cada nodo y después escoger el menor. Malla: para la malla se ha realizado el mismo proceso, pero en este caso, no se ha utilizado la suma de las capacidades de cada par de nodos del nuevo enlace, si no que se ha escogido la menor media de esas capacidades. Es decir que primero se han sumado todas las capacidades del nodo y se han dividido por el número de enlaces que tiene el nodo en la topología original. 122

148 B.1. DESCRIPCIÓN Estrella: para la estrella, primero de todo se ha añadido un nodo central, a modo de concentrador de tráfico. Se decidió hacerlo de ésta manera para evitar que se eligiese un nodo al azar y seleccionar uno malo para realizar éstas funciones. Los enlaces de ésta topología son la suma de los enlaces de la topología original. De esta forma, intentamos plasmar en la nueva topología toda la capacidad del que disponían los nodos en la topología original. Demandas: en este cuadro se puede seleccionar entre utilizar las demandas cogidas del fichero SNDlib o poner la misma cantidad de demanda de tráfico para todas Si se quiere modificar una sóla, debemos ir a la pestaña correspondiente de las demandas. Prob. Bloqueo: se configurar la probabilidad de bloqueo en los enlaces entre un edge y su core. Inicialmente se selecciona N 1 1 para evitar bloqueo, pero se puede ajustar al porcentaje deseado. B.1.3. Pantalla Esquema de la Red En esta pantalla se muestra un dibujo esquemático de la red, donde se dibujan los nodos y los enlaces parseados. Con esta pantalla se pretende ofrecer una ayuda visual del esquema de la red, pudiendo ver a simple vista como se distribuyen geográficamente los nodos y los enlaces que hay entre ellos. Por ejemplo, una vez cogida la red de Atlanta, la pantalla del Esquema de la Red mostrará la figura B.8. B.1.4. Pantalla Demandas de Tráfico En esta pantalla, figura B.9, se muestra una tabla con todas las demandas de tráfico entre los nodos. El formato de la tabla es el siguiente: ID: es un identificador único para cada demanda. Source: es el ID del nodo que manda el tráfico. 123

149 APÉNDICE B. MANUAL DE USUARIO Figura B.8: Pantalla Esquema de la Red Figura B.9: Pantalla Demandas de Tráfico 124

150 B.1. DESCRIPCIÓN Figura B.10: Modificación de la primera demanda de tráfico Target: es el ID del nodo que recibe el tráfico. Value(Mb): es la cantidad de tráfico, en media, medido en Mb, que se mandará desde el origen al destino durante la simulación. Al mismo tiempo, se ofrece al usuario la posibilidad de modificar cada una de estas demandas de tráfico. Para modificar una, tan solo hay que seleccionarla, introducir en el campo de texto el nuevo valor de la demanda, medido en Mb, y pulsar el botón Modificar. Por defecto, aunque no se vé reflejado, está seleccionada la primera demanda de la lista, así que si nada más abrir la pestaña se modifica una demanda sin haber seleccionado nada, se modificará la primera. En la figura B.10 se ha modificado la primera demanda para que ahora sea de 1000Mb. B.1.5. Pantalla de Enlaces entre nodos En esta pantalla, mostrada en la figura B.11, se muestra una tabla con los enlaces entre los nodos. 125

151 APÉNDICE B. MANUAL DE USUARIO Figura B.11: Pantalla de Enlaces entre nodos La tabla tiene el formato siguiente: ID: es un identificador del enclace, único para cada uno. Source: un extemo del enlace. Target: el otro estremo del enlace. Capacity(Mb/s): la capacidad del enlace medida en Mb/s En este caso, los enlaces son Dúplex, por lo que en realidad no hay un nodo origen y otro destino para el enlace, los dos extremos actúan como origen y destino al mismo tiempo, depende de la demanda de tráfico. Gracias al desplegable, se puede seleccionar cada una de las topologías para ver sus enlaces. Además, se ofrece al usuario la posibilidad de modificar los enlaces. Pulsando cada una de las opciones, se podrá añadir capacidad a un enlace seleccionado, a todos los enlaces o a los que estén con capacidad 0Mb/s. 126

152 B.1. DESCRIPCIÓN Figura B.12: Diálogo para añadir capacidad Seleccionado: marcando esta opción y pulsando el botón Añadir capacidad, se mostrará un diálogo como el de la figura B.12. En él se muestran los datos del enlace seleccionado y más abajo se le puede añadir capacidad. El propio formato SNDlib da la opción de añadirle módulos de capacidad al enlace, por lo que se reaprovecha esa capacidad. Para ello, se muestra un desplegable con los módulos que se pueden añadir, tan sólo se debe seleccionar qué tipo queremos añadir, seleccionar cuántos módulos se quieren añadir y pulsar el botón Añadir. Enseguida se modificarán los datos del enlace en ese mismo diálogo. También se le puede quitar módulos a la capacidad total, tan sólo es necesario decirle que el número de módulos a añadir es negativo, esto es, poniendo un número negativo en el contador. Ya sólo resta pulsar Aceptar para volver a la ventana con los enlaces, y el modificado aparecerá reflejado en la tabla. Todos: si se selecciona esta opción y se pulsa Añadir capacidad, se añadirá un módulo, del valor más bajo que nos ofrezca SNDlib, a cada uno de los enlaces. Actuales a 0: si se marca esta opción y se pulsa Añadir capacidad, se añadirá un módulo, del valor más bajo ofrecido por SNDlib, a cada enlace que actualmente tenga una capacidad de 0Mb/s. Como bien se muestra en la pestaña, los enlaces con capacidad 0Mb/s no se introducen en el fichero TCL, esto se debe a que NS no calcula rutas en función de la capacidad del enlace, tan sólo en función del número de saltos. De esta manera, si en el fichero TCL se introduce un enlace con capacidad 0Mb/s, NS intentará mandar tráfico por ese enlace, y no por ningún otro. 127

153 APÉNDICE B. MANUAL DE USUARIO Hay que señalar que añadir capacidad a un enlace original, no hace que se modifiquen los enlaces del resto de topologías, como se explicaba en la descripción de la pantalla de Opciones de la Simulación. B.1.6. Pantalla de Gráficas de resultados En esta pantalla se muestran los resultados, obtenidos al realizar la simulación, en forma de gráficas. En dicha pantalla, hay disponible dos desplegables, en los cuales se puede seleccionar, tanto la topología de la que se quiere ver las gráficas, como un grupo de gráficas para analizar lo ocurrido durante la simulación. Para un mejor estudio de dichas gráficas, se ofrece la posibilidad de ampliar las mismas. Para ello, basta con situar el cursor dentro de una de ellas, hacer click izquierdo en el ratón y arrastrar el cursor para seleccionar la zona a ampliar. Miestra se arrastra el cursor, se sombreará dicha zona. También se pueden guardar las gráficas a un fichero.png gracias a la librería utilizada. Tan solo es necesario pulsar el botón derecho del ratón sobre la gráfica para ver diferentes opciones. Las gráficas están divididas en tres grupos: Gráficas de tráfico: muestra una pantalla como de la de la figura B.13. En ella, se encuentran cuatro gráficas analizando el porcentaje de tráfico cursado por los nodos. Porcentaje de paquetes cursados por nodo: muestra el porcentaje de paquetes que tiene que cursar cada nodo. Se muestran dos barras para cada conjunto edge-core, una que muestra el porcentaje de los paquetes procesados respecto del total que circula por la red, y la otra el porcentaje de paquetes tirados respecto del total que circula por la red. Hay que tener en cuenta que el total de paquetes que circulan por la red es la suma de todos los paquetes que se reciben en algún nodo, incluso si ya se ha contabilizado en otro nodo diferente. Porcentaje de tráfico cursado por nodo respecto al enviado: se muestra el porcentaje de tráfico cursado por cada nodo respecto del total enviado. El tráfico total enviado es la suma de tráfico que envían los edge, tan sólo se contabiliza una vez, en el momento en que se inyecta en la red. 128

154 B.1. DESCRIPCIÓN Figura B.13: Gráficas de Tráfico Porcentaje de tráfico cursado por cada nodo: muestra el porcentaje de tráfico cursado por cada nodo respecto del total. Al igual que con la primera gráfica, el tráfico total es la suma de todos los paquetes que circulan por la red, contabilizándolos cada vez que son procesados por un nodo. Porcentaje de tráfico enviado por cada nodo: ésta última gráfica muestra el porcentaje de tráfico que inyecta cada nodo en la red, respecto al total inyectado. Como ya dijimos en la segunda gráfica, el tráfico total se calcula sumando el tráfico una sóla vez, cuando se inyecta en la red. Como se puede ver en éstas gráficas, la desviación típica que tienen las medias puede llegar a ser muy grande, esto es debido a que la cantidad de tráfico que circula por la red varía con cada simulación, ya que las demandas de tráfico son aleatorias y un nodo no siempre envía tráfico la misma cantidad de tiempo. Por eso se incluye la opción de realizar varias simulaciones, ya que cuantas más simulaciones, la media de tráfico enviado será más parecida a la que se tiene en la tabla de las demandas de tráfico. Como se explicó, los datos de cada simulación por separado se almacenan en la carpeta datos, ubicada dentro de la carpeta de 129

155 APÉNDICE B. MANUAL DE USUARIO Figura B.14: Gráficas de Colas trabajo. Gráficas de Colas: muestra una pantalla como la figura B.14. En se pueden analizar las colas de tráfico de los nodos. Tiempo medio de espera en cola: se representa el tiempo medio de espera en cola de un paquete. En este ejemplo, los paquetes, en media, esperan 0.5µs, con una desviación típica de ±0.5µs, lo que nos da a entender que los valores pueden estar entre 1µs y 0µs, este error se debe a que la precisión del fichero de trazas de NS no va más allá de un 1µs. Número de paquetes en cola cada 10ms: muestra un número de series, correspondientes a cada uno de los nodos, en el que se representa la cantidad de paquetes en cola de los nodos, por cada 10ms. Gráficas de Retardo: en esta pantalla, figura B.15, se muestran las estadísticas del retardo extremo a extremo. En ella se puede analizar el retardo extremo a extremo entre los nodos. Éstas gráficas son algo diferentes, ya que no son gráficas de barras o de series. En cambio, 130

156 B.1. DESCRIPCIÓN Figura B.15: Gráficas de Retardo son gráficas con códigos de colores, más concretamente, con escala de grises. Para poder analizarla, se debe mirar las ordenadas y las abscisas de la gráfica y el color que corresponda a ese punto, consultarlo en la tabla adjunta para saber su valor. La primera consecuencia de esta tabla es que no podemos encontrar un valor concreto, si no que estaremos estimando el valor observando la tabla. Retardo medio entre nodos[ms](media): muestra la media del retardo entre nodos medido en ms. La escala de ésta tabla varía según la media máxima calculada. Retardo medio entre nodos[µs](desviación): muestra la desviación típica de la media calculada. Se mide en µs debido a que su precisión es muy alta y al medirla en ms se obtenían todos los valores negro, es decir muy próximos a 0. Al igual que la gráfica anterior, la escala de ésta gráfica varía según la desviación típica máxima calculada. Retardo medio entre nodos (nodos intermedios): muestra la cantidad de nodos intermedios que tiene que recorrer un paquete hasta llegar a su destino. Ésta tabla es útil, ya que si encontramos una media muy alta, se puede 131

157 APÉNDICE B. MANUAL DE USUARIO mirar y si el número de nodos intermedios es alto, tendría lógica que el retardo entre extremos sea alto. La escala de ésta gráfica es diferente de las anteriores, ya que el máximo de ésta es el número de nodos. En el peor de los casos, un paquete tiene que pasar por todos los nodos para llegar a su destino. Además de mostrar las gráficas, también se dispone del botón Exportar datos de las gráficas, que como su nombre indica, realiza la función de exportar los datos de las gráficas a ficheros de texto, almacenados en la carpeta graficas, dentro de nuestra carpeta de tranajo. De ésta manera se pueden exportar a otras plataformas capaces de representar gráficas, siempre y cuando se procesen los ficheros. El nombre de los ficheros será el de las iniciales de la gráfica, seguido por un número de 0 a 3 que indica la topología. Por ejemplo, el fichero PPPpN-0, son los datos de la gráfica de Porcentaje de Paquetes Procesados por Nodo(PPPpN) de la topolog ia original(0). El formato de los ficheros varía según la gráfica exportada. Común a todos: todos los ficheros comienza con el nombre de la gráfica, la topología que representan y la fecha en la que se han exportado los datos. La fecha está en formato AAAAMMDD HHMMSS. Gráfica porcentaje paquetes procesados Gráfica de Porcenataje de Paquetes Procesados por Nodo(PPPpN): tiene el siguiente formato. N Cada línea son los datos de un nodo. La primera columna es el nombre del nodo, la segunda, la media de los paquetes procesados, la tercera, la desviación típica de los paquetes procesados, la cuarta, la media de los paquetes tirados y la quinta, la desviación de los paquetes tirados. Gráfica de Porcentaje de Tráfico Ponderado por Nodo(PTPpN): sigue el formato siguiente. N Al igual que la gráfica anterior, cada línea representa los datos de un nodo. La primera columna es el nombre del nodo, la segunda, es la media del tráfico ponderado y la tercera, la desviación típica. Gráfica de Porcentaje de Tráfico por Nodo(PTpN): tiene el siguiente formato. 132

158 B.1. DESCRIPCIÓN N El formato es igual que la anterior, ya que ambas dos son gráficas de barras. La primera columna es el nombre del nodo, la segunda, es la media del tráfico y la tercera, la desviación típica. Gráfica de Porcentaje de Tráfico Enviado por Nodo(PTEpN): N Igual que todas las gráficas de barras, cada línea representa los datos de un nodo. La primera columna es el nombre del nodo, la segunda, la media del tráfico enviado y la tercera, la desviación típica. Gráfica de Tiempo de Espera en Cola(TEC): N De nuevo, al tratarse de una gráfica de barras, tiene el mismo formato que las anteriores. Gráfica de Número de Paquetes en Cola cada 10ms(NPCms): Cada línea de este fichero representa un slot de tiempo, en nuestro caso, 10ms. La primera columna es el slot de tiempo a representar, y las sucesivas son los valores para cada nodo. Las columnas pares representa la media de paquetes en cola en ese instante de tiempo para cada nodo, y las columnas impares, exceptuando la primera, son las deviaciones típicas de las medias. Podemos decir que a partir de la primera, cada par de columnas representa la información de un nodo. Gráfica de Medias de Retardo entre Nodos(MRN): este fichero representa una tabla. Un ejemplo de una fila es En este caso, la primera columna representa el número del nodo, no su nombre, y las columnas sucesivas son el retardo medio entre ese nodo y los demás. Hay que recordar que los datos se miden en ms. Gráfica de Desviación de Retardo entre Nodos(DRN): al igual que el anterior, este fichero representa una tabla

159 APÉNDICE B. MANUAL DE USUARIO El formato es igual que el anterior, pero en este caso se tienen las desviaciones típicas, medidas en µs. Gráfica de Nodos Intermedios de Retardo entre Nodos(NIRN): al ser el mismo tipo de gráfica que las anteriores, este fichero representa la tabla De nuevo, el formato es igual que los anteriores, la primera columna es el número de nodo, y las sucesivas son los nodos intermedios entre éste y los demás. 134

160 Apéndice C Manual de instalación Para poder ejecutar la aplicación correctamente, se debe instalar el simulador NS, más concretamente la versión 2.28 y añadir el módulo de OBS modificado para poder realizar las simulaciones correctamente. Existe una versión del simulador con el módulo ya instalado, listo para compilar en nuestro propio sistema [8], previa modificación de los ficheros a compilar. Además, se recomienda tener instalado NAM (Network Animator) en su versión 1.15 ya que es una ayuda visual a la simulación. C.1. Instalación NS El sistema en el que se han instalado todos los requisitos para poder usar la aplicación es una distribución Linux Ubuntu Para poder instalar correctamente el simulador NS en el sistema, se deben seguir una serie de pasos: 1. Instalar las librerías de tcl y tk: tcl, tcl-dev, tk, tk-dev. Para ello, basta con ejecutar: sudo apt-get install tcl tcl-dev tk tk-dev 2. Instalar gcc y g++. Se recomienda utilizar la versión 4.4 de ambas librerías, ya que es la versión probada. sudo apt-get install gcc g++ 3. Se deben añadir dos repositorios nuevos para instalar otcl y tclcl. Dichos repositorios son: deb aherms/debian sid ns2 135

161 APÉNDICE C. MANUAL DE INSTALACIÓN deb-src aherms/debian sid ns2 4. Instalar los paquetes mitotocl, mitotcl-dev, tclcl, tclcl-dev. sudo apt-get install mitotcl mitotcl-dev tclcl tclcl-dev 5. Debido a que el configure del paquete de NS busca el tcl en un lugar equivocado, se puede solucionar de dos maneras: a) Cuando se ejecute.configure, decirle al script dónde se encuentra la instalación de tcl con la opción --with-tcl=path. b) Hacer un enlace simbólico para que el script lo encuentre directamente: ln -s /usr/share/tcltk/tcl8.4 /usr/lib/tcl Al igual que con la instalación de tcl, pasa lo mismo con la instalación de tk, por lo que las maneras de solventar el problema son las mismas, tan sólo se deben usar las rutas de tk o la opción de tk: a) Opción --with-tk=path a la hora de ejecutar el.configure b) Enlace simbólico a la ruta de instalación de tk: ln -s /usr/share/tcltk/tk8.4 /usr/lib/tk Para que la compilación del módulo sea correcta, se deben efectuar ciertos cambios en los ficheros de NS [21] [22], detallados en el Apéndice D. 8. Ejecutar el configure para que genere el fichero Makefile para el sistema:./configure En caso de que no encuentea la instalación de otcl o tclcl, se pueden poner opciones similares a las anteriores para configurar la ruta de éstos paquetes. 9. Ejecutar el make para compilar NS:./make 10. Instalar los binarios para que sean ejecutables desde cualquier path:./sudo make install Este paso se debe hacer con permisos de root, ya que se escribe en el directorio /usr/bin, del cual es propietario el usuario root y nadie tiene permisos de escritura excepto él. 136

162 C.2. INSTALACIÓN NAM Figura C.1: NAM C.2. Instalación NAM Para instalar NAM, es tan sencillo como ejecutar el siguiente comando: sudo apt-get install nam Debido a que se encuentra en los repositorios de ubuntu, no se debería tener ningún problema para instalarlo en el sistema. No es necesario ningún tipo de configuración previa y para comprobar que funciona correctamente, basta con ejecutar nam en un terminal, lo que debería arrancar el programa y mostrar una ventana igual que la figura C