Aplicación para comparar topologías de red - e

Universidad Carlos III E SCUELA P OLIT ÉCNICA Ingenierı́a Técnica de Telecomunicación, Telemática Diseño y Desarrollo de una Aplicación Para el Estudio Comparativo de Topologı́as de Red Autor: José Miguel Vázquez Viejo Tutor: Isaac Seoane Pujol Co-Tutor: Isaı́as Martı́nez Yelmo Este trabajo se encuentra bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 España. This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Spain License. http://creativecommons.org/licenses/by-nc-nd/3.0/deed.es IV Resumen Este proyecto consiste en el diseño e implementación de una aplicación para, a partir de una topologı́a de red descrita en un fichero XML, generar topologı́as básicas equivalentes, para su simulación y estudio. La aplicación, además, integra los módulos de simulación necesarios y ofrece al usuario un entorno para realizar un estudio comparativo de las gráficas obtenidas con los resultados de las simulaciones. En una primera parte se estudian las diferentes tecnologı́as de conmutación óptica y las funcionalidades del simulador NS-2 con los diferentes tipos de tráfico utilizado. En la segunda parte, se detalla el diseño y la implementación de una aplicación para facilitar el estudio comparativo de diferentes topologı́as de red. Para terminar, se estudian diferentes pruebas para comprobar el funcionamiento de la aplicación y se realiza una explicación de las gráficas con los resultados obtenidos. Palabras Clave Simulación, Redes ópticas VI 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 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 dedicación durante tantos añ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 más acertadas para mi futuro. Tambié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. También agradecer a Isaı́as su preocupació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 compañı́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 años no se olvidan. Y có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 ú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 ningún sentido. Índice general Glosario XXIII 1. Introducción 1 1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Contenido 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Estado del arte 5 2.1. Redes ópticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. OCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. OPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. OBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 . . . . . . . . . . . . . . . . . 15 2.2. Simuladores de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.4. Resumen de planificación de WDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.3. OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.4. OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1. NS 2.2.2. NS-3 XI Í NDICE GENERAL 2.2.5. KivaNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.6. CNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.7. Resumen del estudio de los simuladores . . . . . . . . . . . . . . . 25 2.3. Teorı́a de colas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.1. M/M/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.2. M/M/c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.3.3. G/G/c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.3.4. Teorema de Jackson . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4. Generadores de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3. Herramientas 37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.1.1. Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.1.2. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1. Simulador NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.1. JDOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.2. JFreeChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2.3. Commons-Math . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2.4. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3. SNDlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2. Java 4. Descripción de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.1. Integración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.1. Funcionalidad 4.2. Simulador NS-2 XII 45 Í NDICE GENERAL 4.2.2. Generadores de tráfico utilizados . . . . . . . . . . . . . . . . . . . 46 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3.1. Parser de XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3.2. Generador de ficheros de ns . . . . . . . . . . . . . . . . . . . . . 57 4.3.3. Analizador de resultados . . . . . . . . . . . . . . . . . . . . . . . 58 4.4. GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.1. Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4.2. Gráficas de resultados . . . . . . . . . . . . . . . . . . . . . . . . 64 4.4.3. Ampliar funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4.4. Diagrama de clases simplificado . . . . . . . . . . . . . . . . . . . 68 4.3. Parser 5. Validación 71 5.1. Pruebas a realizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.2. Pruebas de carga 73 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 . . . . . . . . . . . . . . 76 5.2.3. Pruebas con carga alta en los enlaces . . . . . . . . . . . . . . . . 79 5.3. Pruebas de retardo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.2.1. Pruebas con carga baja en los enlaces 5.2.2. Pruebas con carga media en los enlaces . . . . . . . . 81 . . . . . . . 85 5.3.3. Pruebas con tiempos de retardo altos en los enlaces . . . . . . . . 90 5.4. Estudio del estado de las colas de espera en los nodos . . . . . . . . . . . 90 5.4.1. Pruebas con demandas bajas . . . . . . . . . . . . . . . . . . . . 90 5.4.2. Pruebas con picos de demanda . . . . . . . . . . . . . . . . . . . 92 5.5. Simulación de otros escenarios . . . . . . . . . . . . . . . . . . . . . . . 92 5.3.1. Pruebas con tiempos de retardo bajo en los enlaces 5.3.2. Pruebas con tiempos de retardo medio en los enlaces XIII Í NDICE GENERAL 6. Conclusiones y trabajo futuro 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 99 6.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 A. Presupuestos 107 A.1. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.2. Costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.2.1. Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.2.2. Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A.2.3. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.3.1. Totales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 B. Manual de usuario 113 B.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 B.1.1. Pantalla Configuración . . . . . . . . . . . . . . . . . . . . . . . . 114 B.1.2. Pantalla Opciones de Simulación . . . . . . . . . . . . . . . . . . . 119 B.1.3. Pantalla Esquema de la Red . . . . . . . . . . . . . . . . . . . . . 123 B.1.4. Pantalla Demandas de Tráfico . . . . . . . . . . . . . . . . . . . . 123 B.1.5. Pantalla de Enlaces entre nodos . . . . . . . . . . . . . . . . . . . 125 B.1.6. Pantalla de Gráficas de resultados . . . . . . . . . . . . . . . . . . 128 C. Manual de instalación 135 C.1. Instalación NS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 C.2. Instalación NAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 XIV Í NDICE GENERAL D. Cambios en ficheros para la compilación de NS 139 E. Clases 145 E.1. Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 E.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 F. Ejemplos de ficheros 151 F.1. Fichero XML de SNDlib . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 F.2. Fichero de trazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 F.3. Fichero esqueleto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 F.4. Fichero para simular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 XV Í NDICE GENERAL XVI Índice de Figuras 2.1. Esquema de WDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Esquema de nodo intermedio OPS . . . . . . . . . . . . . . . . . . . . . 8 2.3. Esquema de envı́o de tramas OBS . . . . . . . . . . . . . . . . . . . . . 9 2.4. Esquema de nodo intermedio OBS . . . . . . . . . . . . . . . . . . . . . 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.6. Algoritmos de planificación OBS . . . . . . . . . . . . . . . . . . . . . . . 14 2.7. NAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.8. OMNeT++ IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.9. Red OBS en OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.10.Dominios de OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.11.Arquitectura de KivaNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.12.Bloques del API de KivaNS . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.13.Interfaz gráfico de KivaNS . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.14.Interfaz gráfico de CNET . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.15.Esquema de sistema M/M/1 . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.16.Función de densidad exponencial . . . . . . . . . . . . . . . . . . . . . . 29 2.17.Función de distribución exponencial . . . . . . . . . . . . . . . . . . . . . 29 2.5. Protocolo JET XVII Í NDICE DE F IGURAS 2.18.Esquema de sistema M/M/c . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.19.Esquema de sistema G/G/c . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.20.Esquema tráfico CBR 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.22.Curva de Koch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.23.Tráfico observado en una red Ethernet . . . . . . . . . . . . . . . . . . . . 34 2.24.Esquema tráfico Autosimilar . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1. Gráfica de barras y series con JFreeChart . . . . . . . . . . . . . . . . . . 42 3.2. Histograma con JFreeChart . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3. NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.1. Ejemplo de topologı́a parseada . . . . . . . . . . . . . . . . . . . . . . . 52 4.2. Ejemplo de topologı́a parseada en anillo . . . . . . . . . . . . . . . . . . . 53 4.3. Ejemplo de topologı́a parseada en malla . . . . . . . . . . . . . . . . . . 54 . . . . . . . . . . . . . . . . . 55 4.5. Diagrama parseo de XML . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.6. Diagrama para generar fichero NS . . . . . . . . . . . . . . . . . . . . . . 59 4.7. Diagrama de simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.8. Diagrama de análisis de trazas . . . . . . . . . . . . . . . . . . . . . . . . 62 4.9. Diagrama de clases simplificado . . . . . . . . . . . . . . . . . . . . . . . 69 5.1. Red NFSNET, Europa y Polonia . . . . . . . . . . . . . . . . . . . . . . . 72 5.2. Prueba con baja carga para NFSNET . . . . . . . . . . . . . . . . . . . . 74 5.3. Prueba con baja carga para Europa . . . . . . . . . . . . . . . . . . . . . 75 5.4. Prueba con baja carga para Polonia . . . . . . . . . . . . . . . . . . . . . 76 2.21.Esquema tráfico Exponencial 4.4. Ejemplo de topologı́a parseada en estrella XVIII Í NDICE DE F IGURAS 5.5. Prueba con carga media para NFSNET . . . . . . . . . . . . . . . . . . . 77 5.6. Prueba con carga media para Europa . . . . . . . . . . . . . . . . . . . . 78 5.7. Prueba con carga media para Polonia . . . . . . . . . . . . . . . . . . . . 78 5.8. Prueba con carga alta para NFSNET . . . . . . . . . . . . . . . . . . . . 80 5.9. Prueba con carga alta para Europa . . . . . . . . . . . . . . . . . . . . . 80 5.10.Prueba con carga alta para Polonia . . . . . . . . . . . . . . . . . . . . . 81 5.11.Prueba retardo bajo en enlaces para NFSNET . . . . . . . . . . . . . . . 83 5.12.Prueba retardo bajo en enlaces para Polonia . . . . . . . . . . . . . . . . 84 5.13.Prueba retardo medio en enlaces para NFSNET . . . . . . . . . . . . . . 86 5.14.Prueba retardo medio en enlaces para Polonia . . . . . . . . . . . . . . . 87 5.15.Prueba retardo alto en enlaces para NFSNET . . . . . . . . . . . . . . . . 88 5.16.Prueba retardo alto en enlaces para Polonia . . . . . . . . . . . . . . . . . 89 5.17.Prueba sin carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.18.Prueba con picos de carga . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.19.Esquema de la M-40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.20.Colas en los nodos con apoyo de anillo interior. Congestión 50 %. . . . . . 96 5.21.Colas en los nodos sin apoyo de anillo interior. Congestión 50 %. . . . . . . 96 5.22.Colas en los nodos con apoyo de anillo interior. Congestión 90 %. . . . . . 97 5.23.Colas en los nodos sin apoyo de anillo interior. Congestión 90 %. . . . . . . 97 B.1. Pantalla de Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . 114 B.2. Simulación en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.3. Analizando y generando gráficas . . . . . . . . . . . . . . . . . . . . . . 118 B.4. Topologı́a en anillo recién abierta . . . . . . . . . . . . . . . . . . . . . . 119 B.5. Topologı́a en anillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 XIX Í NDICE DE F IGURAS B.6. Topologı́a en estructurada . . . . . . . . . . . . . . . . . . . . . . . . . . 120 B.7. Pantalla Opciones Simulación . . . . . . . . . . . . . . . . . . . . . . . . 121 B.8. Pantalla Esquema de la Red . . . . . . . . . . . . . . . . . . . . . . . . . 124 B.9. Pantalla Demandas de Tráfico . . . . . . . . . . . . . . . . . . . . . . . . 124 B.10.Modificación de la primera demanda de tráfico . . . . . . . . . . . . . . . 125 B.11.Pantalla de Enlaces entre nodos . . . . . . . . . . . . . . . . . . . . . . . 126 B.12.Diálogo para añadir capacidad . . . . . . . . . . . . . . . . . . . . . . . . 127 B.13.Gráficas de Tráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 B.14.Gráficas de Colas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 B.15.Gráficas de Retardo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 C.1. NAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 E.1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 XX Índice de Tablas . . . . . . . . . . . . . . . 14 2.2. Tabla comparación tecnologı́as conmutación óptica . . . . . . . . . . . . . 15 2.3. Tabla comparación simuladores de red 26 2.1. Tabla comparación algoritmos de planificación . . . . . . . . . . . . . . . . . . . A.1. Duración estimada de las tareas . . . . . . . . . . . . . . . . . . . . . . . 108 A.2. Salarios de especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A.3. Coste del personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.4. Coste de licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.5. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.6. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.7. Presupuesto total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 XXI Í NDICE DE TABLAS XXII Glosario A ACK (Acknowledgment) acuse de recibo, p. 11. AON (All Optical Networks) redes completamente ópticas, p. 7. ARP (Address Resolution Protocol) protocolo de resolución de direcciones, p. 22. C CBR (Constant Bit Rate) tasa de envı́o constante, p. 32. F FDL (Fiber Delay Lines) lı́neas ópticas de retardo; memoria óptica, p. 6. G Geometrı́a Computacional se basa en aplicar algoritmos de geometrı́a clásica en el ámbito de algoritmos de programación, p. 13. GUI (Graphical User Interface) interfaz gráfica de usuario, p. XIII. XXIII G LOSARIO 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) má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) conmutación óptica de ráfagas, p. 9. OCS (Optical Circuit Switching) conmutación óptica de cirtuitos, p. 7. O/E/O conversión óptica-eléctrica-óptica, p. 7. OPS (Optical Packet Switching) conmutación ó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 transmisión, p. 37. XXIV G LOSARIO W WDM (Wavelenght Division Multiplexing) multiplexación por división de longitudes de onda, p. 5. X XML (Extensible Markup Language) lenguaje de marcas extensible, p. 151. XXV Capı́tulo 1 Introducció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 comparación con la cantidad de tráfico que deben gestionar. Con la aparición de las redes de fibra óptica, esas velocidades fueron aumentando en gran medida, llegando a alcanzar un orden de magnitud mayor que las redes eléctricas tradicionales. Aún ası́, la polı́tica de gestión de los recursos no permitı́a aprovechar todo el potencial que estas nuevas redes ofrecı́an. Por eso la investigación de nuevas polı́ticas de gestión de los recursos consiguió aumentar de nuevo las velocidades. Pero surge el inconveniente de que los dispositivos de conmutación actuales sólo procesan señales eléctricas, teniendo que transformar la señal óptica a eléctrica para su procesado, lo que de nuevo limita los recursos que se ofrecen. Por esta razón, los diseños futuros para las redes ópticas están enfocados a que la red sea por completo óptica, sin necesidad de procesar la señal en un formato eléctrico. Por otro lado, desde la aparición de las redes informáticas se han querido estudiar las prestaciones, las caracterı́sticas y el comportamiento que adoptaban ante diferentes estructuras de trá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 económicamente. 1 C AP ÍTULO 1. I NTRODUCCI ÓN La idea inicial del proyecto era la simulación y estudio de anillos de OBS, pero durante la realización del proyecto se fue pensando en posibles ampliaciones. Se decidió 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 básicas, no sólo el anillo equivalente. También se tomó la decisión de poder modificar ciertos parámetros de la simulación, ası́ como poder modificar ciertas caracterı́sticas de las redes bajo estudio. Por último, se diseñó una vista con diferentes tipos de gráficas para poder analizar y comparar los resultados obtenidos de la realización de las diferentes simulaciones. 1.2. Objetivos El objetivo principal del proyecto consiste en el estudio comparativo de los resultados que se obtienen de la simulació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 básicas (anillo, malla y estrella) equivalentes y se simulan. A continuación se procesan los resultados obtenidos para facilitar el estudio de la principal y tomar las decisiones pertinentes de diseño y planificación. Para facilitar esta tarea, se desarrolla un interfaz gráfico desde el que se pueden configurar y modificar parámetros de la simulación de forma sencilla e intuitiva, ası́ como ofrecer al usuario una vista con los resultados obtenidos en forma de gráficas. Los objetivos especı́ficos serı́an: Desarrollar un parser que, a partir de un fichero XML, con la descripción de la topologı́a y sus demandas de tráfico habituales, genere las topologı́as básicas equivalentes. Diseño de un fichero esqueleto con los parámetros de configuración de las simulaciones a realizar, en el cual, se dejan sin configurar las opciones que se ofrecen al usuario para su modificación. Agregar los módulos para OBS al simulador e integrar dicho conjunto con la aplicación. Desarrollar un parser mediante el cual se procesen los ficheros de trazas obtenidos de las diferentes simulaciones. 2 1.3. C ONTENIDO Diseñar una vista con diferentes gráficas de resumen de resultados, para facilitar el estudio comparativo de diferentes topologı́as de red. 1.3. Contenido En la primera parte de la memoria, compuesta por los Capı́tulos 2 y 3, se estudia el estado actual de las redes ópticas, ası́ como los simuladores de red disonibles y los tráficos utilizados en la simulación. En el Capı́tulo 3 se detallan las herramientas utilizadas para la realización del proyecto. En la segunda parte, en el Capı́tulo 4 se detallan las decisiones de diseño tomadas para la realización del proyecto y la manera de implementarlas. Y en el Capı́tulo 5 se explican las pruebas realizadas para la validación del correcto funcionamiento de la aplicación. Para terminar, en el Capı́tulo 6 se enumeran las conclusiones obtenidas durante la realización de este proyecto y una serie de lı́neas de trabajos futuros para la ampliación de la funcionalidad. Además, se ofrecen Apéndices que contienen información ú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 aplicación, el Manual de instalación, los ficheros que se deben modificar para la integración de OBS, las clases que intervienen en la aplicación, y ejemplos con los ficheros que maneja la aplicación. 3 C AP ÍTULO 1. I NTRODUCCI ÓN 4 Capı́tulo 2 Estado del arte En este capı́tulo se hará un estudio de las tecnologı́as relacionadas con el proyecto: las diferentes tecnologı́as de conmutación para redes ópticas, los simuladores de red existentes, la teorı́a de colas y los diferentes generadores de tráfico utilizados. 2.1. Redes ópticas Con el aumento del trá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 más cortas, ya que son del orden de los 100Mbps. Con los enlaces ópticos, se consigue aumentar en gran medida la capacidad de los enlaces, llegando al orden de Gbps en caso de no haber interferencias; además de tener una atenuación muy baja, lo que conlleva una longitud de enlace mayor. Existen varias maneras de gestionar el enlace, pero la que ha resultado más eficaz y la que se usa en la actualidad para solventar el problema del incremento de tráfico y usuarios, ha sido la multiplexación óptica por longitud de onda o WDM [1]. WDM (Wavelenght Division Multiplexing) se sirve de diferentes longitudes de onda para realizar la transmisión de información a través de un medio ó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 ópticas, donde los transmisores son láseres que generan las señales ópticas a partir de señales eléctricas transformadas, y los receptores realizan el proceso inverso; y los conmutadores son componentes de red encargados de dirigir el tráfico hacia 5 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.1: Esquema de WDM su destino, previa conversión al dominio eléctrico para el procesado de las cabeceras o paquetes de control. También existen lı́neas ó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 sólo uno de ellos puede ser enviado, se almacena el otro en un buffer, que en el caso de las redes ó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 tráfico en la red, son conocidos como nodos edge. Y los nodos intermedios, encargados de la conmutación y encaminamiento de los paquetes se llaman nodos core. Como ya se ha dicho, se necesitan conversiones entre los dominios óptico y eléctrico en cada nodo, lo cual, impide aprovechar de manera eficiente el ancho de banda: la señal es convertida al dominio eléctrico, se procesa, y se vuelve a transformar a su forma óptica antes de pasar a la fibra de salida. Por tanto, la eficiencia de la comunicación está limitada por la capacidad de los dispositivos electrónicos del sistema, y aunque en los últimos 6 2.1. R EDES ÓPTICAS años se ha conseguido un gran avance en cuanto a sus prestaciones, no es suficiente para alcanzar las velocidad de la tecnologı́a óptica. Por estas razones, los diseños futuros de redes WDM se enfocan a la eliminación de las conversiones O/E/O, convirtiéndose en redes AON(All Optical Networks), lo que permitirı́a alcanzar tasas de transmisión del orden de Tbps. A continuación se explican las diferentes configuraciones en una red WDM para la gestión de las longitudes de onda λ’s. 2.1.1. 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 está configurado, los datos permanecen en el dominio óptico hasta su destino, sin necesidad de realizar conversiones O/E/O intermedias. Pero el problema de OCS es que sólo es eficiente cuando existe un gran volumen de tráfico entre los nodos que establecen la conexión, ya que de otro modo, no se harı́a un uso eficiente de los recursos del enlace, porque la longitud de onda está reservada para ese enlace únicamente. Si la duración del tiempo de transmisión de datos es corta en relación con el tiempo del establecimiento de la conexión, estamos desaprovechando mucho ancho de banda. Otro inconveniente es que el nú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 número de λ’s hace imposible crear una malla de caminos ópticos entre todos los nodos. Ademá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 además tenemos en cuenta que son redes estáticas, conlleva una baja adaptabilidad a un tráfico cambiante. 7 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.2: Esquema de nodo intermedio OPS 2.1.2. OPS Para solventar el problema de la limitación en cuanto al número de λ’s surge OPS [2](Optical Packet Switching), que es otra posible configuración de WDM. Aprovecha de manera más eficiente el ancho de banda comparado con OCS, ya que en este caso, el tráfico de usuario se transporta junto con la información de control, lo que proporciona un uso más flexible y eficiente del ancho de banda disponible en la capa óptica. Los paquetes pueden transmitirse a través de cualquiera de las longitudes de onda disponibles en cada nodo, y al igual que en las redes elé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 eléctrico, pero viajan de manera óptica, por lo que se necesita realizar una conversió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 conversión entre dominio eléctrico y óptico de la misma. Los datos del paquete se retienen en memoria óptica hasta que se decide por dónde debe ser enviado, y llegado ese momento, se debe configurar la matriz de conmutación en ese nodo. Por lo tanto, el retardo total será la suma de la conversión optico-eléctrica de la cabecera, más el tiempo de configuracón de la matriz de conmutación, más el tiempo de reconstrucción del paquete en el dominio óptico. Podemos ver un esquema del funcionamiento de un nodo intermedio de OPS en la figura 2.2. 8 2.1. R EDES ÓPTICAS Figura 2.3: Esquema de envı́o de tramas OBS [5] Aunque la conmutació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. 2.1.3. OBS Se debe buscar un término medio entre OCS y OPS ya que ninguna aprovecha al máximo el ancho de banda disponible en los enlaces, por eso surge OBS [2] [3] [4](Optical Burst Switching), como otra configuración de WDM, que se parece a las dos anteriores. Esto se debe a que el intercambio de información se realiza mediante ráfagas, no con paquetes. Si el tamaño de las rá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 ráfagas pequeñas, se asemeja a OPS. Además de tener canales exclusivos para la transmisión de los datos, se dispone de canales de control, por donde viajan las cabeceras, o paquetes de control. 9 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.4: Esquema de nodo intermedio OBS [5] Creación de ráfagas Cada rá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 ráfagas como si fuesen paquetes. Los buffer tienen una capacidad máxima, lo que determina el tamaño máximo de la ráfaga. Antes de enviar la ráfaga se envı́a un paquete de control, que contiene la información necesaria para el encaminamiento de dicha ráfaga a través de la red. Tras enviar ese paquete por un canal dedicado, el nodo envı́a la ráfaga de datos. Hay que señalar que el envı́o del paquete de control y el de la ráfaga de datos se realizan por canales completamente diferentes. Se puede ver un pequeño esquema de este proceso en la figura 2.3. Encaminamiento de ráfagas Los nodos intermedios procesan el paquete de control de manera eléctrica, mediante la conversión pertinente, y planifican los puertos de salida y los instantes de ocupación 10 2.1. R EDES ÓPTICAS a través de una multiplexación estadı́stica de los canales ópticos, lo que permite que dichos canales puedan ser compartidos por ráfagas de flujos diferentes, lo que mejora la utilizació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 ráfaga, los nodos deben reservar los recursos necesarios para que lleguen a su destino sin retardos. La decisión de cómo reservar dichos recursos se toma mediante ciertos mecanismos [3], algunos de los cuales, se explican a continuación: Tell-and-Wait: cuando una fuente desea enviar una ráfaga, primero intenta reservar el ancho de banda/longitud de onda desde la fuente hasta el destino enviando un mensaje de petición. Cada nodo intermedio reserva esa salida especı́fica. Si el ancho de banda es reservado con éxito se envı́a un ACK para informar a la fuente de que debe enviar la ráfaga inmediatamente. En caso negativo se enviará un NACK, indicando a la fuente que deberá liberar el recurso reservado y esperar un tiempo para volver a intentarlo. Tell-and-Go: cuando una fuente desea transmitir una ráfaga, lo hace sin ningún tipo de reserva previa de recursos. Se envı́an al mismo tiempo tanto la rá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 retransmisión de la ráfaga. Just In Time(JIT): está considerado una variante de Tell-and-Wait, ya que cada petición de transmisión se envı́a a un planificador central. El planificador informa a cada nodo del intervalo de tiempo exacto en el que llegará la ráfaga antes de que se transmita. El término Just-in-Time (justo a tiempo), se refiere a que en el momento en que una ráfaga llega a un nodo intermedio, la matriz de conmutación ya está 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 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.5: Protocolo JET es el tiempo que tarda en configurarse el nodo, más el tiempo que tarda en llegar y transmitirse la ráfaga, más el tiempo que tarda en desconfigurarse. En la figura 2.5 se puede ver que primero se envı́a la cabecera para después mandar la ráfaga sin procesamientos intermedios, por lo que no sufre retardo alguno. También minimiza el tiempo necesario antes de enviar los datos, ya que sólo notifica que va a llegar una rá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 ráfaga. En su lugar, reserva los recursos de una forma óptima desde que llega la ráfaga hasta que es conmutada. De esta manera, el tiempo que el recurso permanece reservado para la transmisión es óptimo. Algoritmos de planificación En los conmutadores electrónicos convencionales, la contención de los paquetes se resuelve mediante buffers. Pero en redes OBS el almacenamiento es muy limitado o casi 12 2.1. R EDES ÓPTICAS nulo, por lo que se debe planificar de una manera diferente. Cuando se recibe una ráfaga en un nodo intermedio, su envı́o se puede planificar sobre múltiples longitudes de onda. Para realizar este cometido se recurre al planificador de ráfagas, que elegirá una longitud de onda adecuada para la ráfaga recibida, siguiendo un algoritmo en concreto. Se define el horizonte de planificación como el último momento en el cual la longitud de onda está planificada para ser usada. Algunos algoritmos de planificación [3] son los siguientes: LAUC(Latest Available Unscheduled Channel)/Horizon: para cada longitud de onda se mantiene un sólo horizonte de planificación. Sólo se eligen los canales cuyos horizontes preceden al tiempo de llegada de la nueva ráfaga, y de entre todos ellos, se elige el que tiene el horizonte menor. El horizonte se actualiza después de hacer la reserva para la siguiente ráfaga. La idea bá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 operación e implementació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 más adecuados. Se han definido algunas variantes de este algoritmo: • Min-SV(Starting Void): funciona igual que LAUC-VF pero se alcanza un punto óptimo más rápido, usando té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 despué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 comparación entre los mismos, siguiendo la siguiente notación: W : Número de longitudes de onda en cada puerto de salida. 13 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.6: Algoritmos de planificación OBS Algoritmo LAUC LAUC-VF Min-SV/EV Best Fit Complejidad temporal O(W) O(WlogM) O(logM) O(log2 M) Información de estado Horizoni Si, j , Ei, j Si, j , Ei, j Si, j , Ei, j Uso del ancho de banda Bajo Alta Alta Alta Tabla 2.1: Tabla comparación algoritmos de planificación M: Máximo número de ráfagas (o reservas) en todos los canales. Horizon: Horizonte del canal i. Si, j y Ei, j : Tiempo inicial (S) y final (E) de la reserva j del canal i. 14 2.1. R EDES ÓPTICAS OCS OPS OBS Uso BW Bajo Alto Moderado Latencia Alta Baja Baja Tolerancia fallos Baja Alta Media Granularidad Baja Alta Moderada Dificultad impl. Bajo Alto Moderado Tabla 2.2: Tabla comparación tecnologı́as conmutación ó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 después si no se encuentra un vacı́o apropiado, buscar el horizonte usando Min-SV. 2.1.4. Resumen de planificación de WDM Tras analizar las diferentes tecnologı́as de conmutación óptica se puede hacer un resumen de las mismas, expuesto en la tabla 2.2: Además, la tecnologı́a OBS ofrece la siguiente serie de ventajas respecto a OCS y OPS: usa caminos ópticos entre nodos, igual que OCS, pero sólo se asigna una λ a cada ráfaga, en vez de a todo el enlace. por cada ráfaga se toma la decisión de encaminamiento, como en OPS, pero sin almacenar los datos en memoria óptica. la conversión O/E/O se realiza só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 congestión, la complejidad y el tiempo de procesamiento. 15 C AP ÍTULO 2. E STADO DEL ARTE 2.2. Simuladores de Red Desde la aparición de las redes de ordenadores se han intentado estudiar sus caracterı́sticas, sus prestaciones y su comportamiento ante tipos y estructuras diferentes de tráfico. Los simuladores de red ofrecen dicha posibilidad de una manera sencilla y rápida sin necesidad de tener que construir y recrear la red bajo estudio. En esta sección se analizan los principales simuladores de red existentes. 2.2.1. NS Inicialmente conocido como LNBL Network Simulator [6], es una herramienta de simulación desarrollada por el Network Research Group 1 en el Lawrence Berkeley National Laboratory 2 . NS es un motor de simulación de eventos de red, extensible y fácil de configurar y programar. Para la configuración de la topologı́a a simular se utiliza el lenguaje Tcl(Tool Comand Language), y los pasos que sigue la simulación al ser ejecutada son: 1. Se define la topologı́a. 2. Las fuentes de tráfico se configuran. 3. Se recolectan las estadı́sticas. 4. Se invoca la simulación. Su desarrollo, gracias a la universidad UC Berkeley 3 desembocó en la segunda versión [7], la cual, utiliza una nueva arquitectura, que utiliza Object Tcl, una extensión de Tcl, para la descripción de la topologı́a a simular. Casi toda la funcionalidad de la primera versión de NS se encuentra integrada en la segunda versió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 versión funcionarán de manera automática para la segunda. 1 http://www-nrg.ee.lbl.gov/ 2 http://www.lbl.gov/ 3 http://www.berkeley.edu/ 16 2.2. S IMULADORES DE R ED Figura 2.7: NAM Actualmente, el desarrollo se encuentra en la versión 2.34 desde el 17 de Junio de 2009, algún tiempo después de que la versió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 gráfica dichos eventos, el cual se encuentra actualmente en la versión 1.15. En la figura 2.7 se ve un ejemplo de una simulación de red. Para el caso de la simulación de una red óptica de OBS, existe el módulo obs-0.9a, desarrollado por la universidad de Maryland 4 . Además, en [8], podemos encontrar dicho módulo, modificado por Isaı́as Martı́nez Yelmo de la UC3M, ya incorporado en NS-2, en 4 http://www.umd.edu/ 17 C AP ÍTULO 2. E STADO DEL ARTE su versión 2.28. 2.2.2. NS-3 Se llega a la tercera versión del Network Simulator [9], esta vez bajo licencia GNU GPLv2, y queda libre para su investigació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 configuración ya no es OTcl, sino Python. Esta versión intenta solucionar algunos problemas que tenı́a la segunda versión como la interoperabilidad y acoplamiento entre modelos; y la falta de gestión de memoria. Debido a que su concepción está orientada a la educación, los ficheros de trazas son configurables por el usuario, al contrario que NS-2. También trata de acercarse lo más posible a la realidad, haciendo que los nodos sean como ordenadores a los que se les puede añadir módulos/tarjetas de red. Actualmente se encuentra en la versión 3.11, desde el 25 de Mayo de 2011, y ya está en desarrollo la siguiente, debido a que la polı́tica de actualizaciones es lanzar una nueva versión cada 4 meses. Al igual que con la segunda versión, está disponible el visor NAM para ver los resultados de una simulación de manera gráfica. En cuanto al estudio que interesa, es decir las redes ópticas de OBS, desafortunadamente no se ha encontrado ningún módulo en desarrollo para esta versión del simulador. 2.2.3. OMNeT++ OMNeT++ [10], es un marco modular orientado a objetos para simular eventos discretos de red. Posee una arquitectura genérica, por lo que se puede usar, y se usa, para problemas del tipo: modelado de comunicaciones por cable e inalámbricas modelado de protocolos modelado de redes de colas 18 2.2. S IMULADORES DE R ED Figura 2.8: OMNeT++ IDE modelado de multiprocesadores y otras distribuciones de hardware validación de arquitecturas de hardware evaluación de los aspectos del rendimiento de sistemas de software complejos en general, modelado y simulación de cualquier sistema en el que la aproximación a eventos discretos sea aceptable, y sea conveniente asignar a las entidades la comunicació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 simulación. Los modelos se crean a partir de componentes reutilizables, llamados módulos y aquellos que estén bien escritos, se podrán reutilizar mejor, por lo que podrán combinarse de varias formas. Los módulos, escritos en C++, se pueden conectar entre sı́ a través de puertas, y se combinan para formar módulos complejos. Se comunican mediante el paso de mensajes, que pueden llevar estructuras de datos arbitrarios. Se pueden pasar mensajes a través de 19 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.9: Red OBS en OMNeT++ las rutas predefinidas, o directamente a su destino, como puede ser en las simulaciones inalámbricas. El usuario describe la estructura del modelo a simular en lenguaje NED, que permite declarar módulos simples, y conectarlos y ensamblarlos en módulos complejos. Existe una herramienta gráfica para ayudar a la configuración de las simulaciones, OMNeT++ IDE. Es una herramienta basada en la plataforma Eclipse y la extiende con nuevos editores y vistas. También añade funcionalidad para crear y configurar los modelos, realizar ejecuciones por lotes y analizar los resultados de la simulación; mientras, Eclipse ofrece la edición de C++, integración y otras caracterı́sticas a través de plug-ins de código abierto. En la figura 2.8 se puede ver una captura de dicho interfaz. En cuanto al estudio de OBS, existe un mó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 2.9. 5 https://www.tlm.unavarra.es/investigacion/ 20 2.2. S IMULADORES DE R ED Figura 2.10: Dominios de OPNET 2.2.4. OPNET OPNET [11] es una herramienta de simulación de alto nivel basada en eventos que opera a nivel de paquete. Originalmente se ideó para la simulación de redes fijas, aunque actualmente existen gran cantidad de posibilidades para las simulaciones de redes inalámbricas. Se puede usar como una herramienta de investigación o como una herramienta de análisis y desarrollo de redes. Consiste en una interfaz de alto nivel, generada con C y C++, con una inmensa li- 21 C AP ÍTULO 2. E STADO DEL ARTE brerı́a de funciones especı́ficas de OPNET. Posee una estructura jerá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 geográficas o movilidad. Dominio de nodo: Los nodos de una red, tales como routers, estaciones de trabajo o dispositivos móviles. Dominio de procesado: El comportamiento dentro de los nodos de la red. Para cada uno de esos dominios, posee un interfaz grá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 relación con los demá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. 2.2.5. KivaNS KivaNS [12] es una aplicación gratuita y de código abierto basada en Java para generar esquemas de redes y simular el encaminamiento de paquetes a través de dichas redes. Al contrario que la mayorı́a de simuladores, que están pensados para evaluar parámetros de carga y rendimiento, KivaNS está orientado a simular el comportamiento del protocolo IP, y má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 bá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 simulación de redes a otras aplicaciones, y la segunda es una interfaz gráfica que hace uso del API de simulació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 2.2. S IMULADORES DE R ED 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 gráfico, configurar mediante diálogos el direccionamiento y encaminamiento de los equipos de la red, y acceder a las caracterı́sticas del API de simulación sin necesidad de programar. Dado que es un simulador orientado al estudio del protocolo TCP/IP, no existen módulos que implementen OBS. Pero al ser un simulador modular, se pueden implementar los módulos que se deseen para su simulación. 23 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.13: Interfaz gráfico de KivaNS 2.2.6. CNET CNET [13] es un simulador de red que permite la experimentación con diferentes capas de enlace, capas de red y protocolos de enrutamiento y transporte en redes formadas por la combinación de WAN’s LAN’s o WLAN’s. Acorde con el modelo de referencia OSI, CNET provee las capas Fı́sica y de Aplicación. Con Tcl/Tk, CNET provee una representación gráfica de la red que se va a ejecutar, a través de un terminal ASCII, y permite modificar algunos atributos de la misma mientras se está simulando. Se pueden seleccionar los nodos que intervienen para acceder a una pequeña ventana con las estadı́sticas de dicho nodo. Los atributos de los nodos son modificados mediante sencillos checkboxes, y si es un atributo común a todos los nodos, se modificará en todos en ellos. Se muestra un ejemplo de dicho interfaz gráfico con los atributos y estadı́sticas de los nodos en la figura 2.14. 24 2.2. S IMULADORES DE R ED Figura 2.14: Interfaz gráfico de CNET 2.2.7. Resumen del estudio de los simuladores En la tabla 2.3 se detalla una comparación de diferentes propiedades entre los simuladores analizados. En cuanto al simulador de red para complementar la aplicación, se ha elegido NS-2. Es un simulador muy extendido por todo el mundo, con gran cantidad de módulos disponibles, y además, el que necesitamos para simular redes OBS está ya integrado con la versión 2.28 de ns en [8]. En las prácticas realizadas durante la titulación en los laboratorios de Ingenierı́a Telemática 6 de la Universidad Carlos III de Madrid(UC3M) 7 se utiliza precisamente esa versión del simulador, por lo que su uso es familiar. Además, como esta aplicación pretende ser una ayuda a la hora de simular, analizar y comparar las prestaciones de diferentes topologı́as, es posible, que en años venideros, sirva de ayuda al alumnado para el estudio 6 http://www.it.uc3m.es/ 7 http://www.uc3m.es 25 C AP ÍTULO 2. E STADO DEL ARTE Interfaz gráfico Módulo OBS X X X X X X NS-2 NS-3 OMNeT++ OPNET KivaNS CNET Bajo nivel X X X Eventos X X X X Tabla 2.3: Tabla comparación simuladores de red de redes que utilicen tecnologı́a OBS. 2.3. Teorı́a de colas La teorı́a de colas [14] es el estudio matemático de las lı́neas de espera, o colas, dentro de una red de comunicaciones. Su objetivo principal es el aná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 investigació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 má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 serán de forma aleatoria. Si, cuando un usuario llega al sistema, el servidor está 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 está ocupado, por lo que debe quedar en espera, formando la cola. Existen varios tipos de configuración para una red de colas, y sus caracterı́sticas vie- 26 2.3. T EOR ÍA DE COLAS Figura 2.15: Esquema de sistema M/M/1 nen dadas por el tipo de distribución que siguen los procesos de llegadas, la distribución de la tasa de servicio, el número de servidores, el tamaño de la cola, la polı́tica de gestión de cola y otras. Para identificar cada una de ellas se sigue una notación especı́fica, conocida como notación Kendall. A continuación se pasa a explicar la configuración básica, con un servidor y procesos de llegadas de Poisson; y las configuraciones que se han utilizado para el desarrollo de este proyecto. 2.3.1. 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 distribución exponencial y que en el sistema se dispone de un servidor. Ademá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 número de usuarios que entran al sistema es inifinito. A partir de las tasas mencionadas anteriormente se puede definir el factor de utilizació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 está saturada; y en caso de no serlo, no se pierden usuarios que llegan al sistema cuando la cola está llena, y por lo tanto, se da servicio a todos ellos. Se muestra un esquema de este tipo de sistemas en la figura 2.15. 27 C AP ÍTULO 2. E STADO DEL ARTE Fórmula de Little Explicado de forma muy breve, el teorema de Little dice que si un sistema es estacionario, el nú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 nú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 µ−λ Aplicando las fórmulas anteriores se obtiene que el tiempo total de espera en cola W es: W= L λ = ρ λ(1−ρ) = ρ µ−λ Distribución exponencial Se ha hablado de que la tasa de servicio siguen una distribución exponencial. Para ilustrar la distribución exponencial se puede ver la figura 2.16, que muestra su función de densidad. Y posee una función de distribución como la mostrada en la figura 2.17 28 2.3. T EOR ÍA DE COLAS Figura 2.16: Función de densidad exponencial Figura 2.17: Función de distribución exponencial 29 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.18: Esquema de sistema M/M/c 2.3.2. M/M/c En este otro modelo, la tasaa de llegadas se rige por un proceso de Poisson, la tasa de servicio sigue una distribució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, pasará a ese servidor. El factor de utilizació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 2.18. Para el caso concreto de este proyecto, se ha utilizado para el cálculo de las tasas de llegadas para el tráfico exponencial. 2.3.3. G/G/c En este último modelo que se verá, las tasas de llegadas y de servicio siguen una distribución generalista, que puede ser cualquier función de distribución que no sea ni de 30 2.3. T EOR ÍA DE COLAS Figura 2.19: Esquema de sistema G/G/c Poisson ni determinista. Como las funciones son desconocidas, el factor de utilización no se calcula de manera trivial, si no que dependerá de la función en cuestión. El esquema general para este tipo de sistemas se puede ver en la figura 2.19. Como en el sistema se puede introducir cualquier distribución generalista, en el caso de este proyecto se ha utilizado el tráfico Autosimilar, explicado en el siguiente apartado. 2.3.4. Teorema de Jackson Para terminar con esta sección, se explicará brevemente el Teorema de Jackson [15]. Partiendo de las premisas de que un sistema está compuesto por m servidores, con una tasa de servicio exponencial; los usuarios llegan al sistema con una tasa que sigue una distribució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 ó un M/M/c de tal manera que, los resultados pueden combinarse mediante métodos estadı́ticos y los retardos medios pueden sumarse para obtener el retardo total del sistema. Esto es especialmente útil para el estudio de redes de colas, cuyo escenario cumple con las premisas para aplicar el Teorema de Jackson. 31 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.20: Esquema tráfico CBR 2.4. Generadores de tráfico Existen muchas maneras teóricas de representar el tráfico que cursa una red. Como hablar de todas ellas abarcarı́a gran parte del capı́tulo tan sólo se van a explicar los tres utilizados en este proyecto, que son: CBR, Exponencial y Autosimilar. CBR (Constant Bit Rate) El tráfico CBR se caracteriza por el envı́o constante de tráfico a una misma tasa. Por lo que origen y destino deben tener una sincronizació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 conexión. Los servicios má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 tráfico CBR, donde el tamaño de los paquetes es constante y el tiempo entre llegadas es constante, por lo que la tasa también lo es. 32 2.4. G ENERADORES DE TR ÁFICO Figura 2.21: Esquema tráfico Exponencial Exponencial En el caso del generador de tráfico exponencial para NS, se trata de un trá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 tráfico. Los tiempos de “on” y “off” se generan mediante una distribución exponencial, explicada en el apartado anterior. En la figura 2.21 se puede ver un esquema de tráfico Exponencial, donde el tamaño de los paquetes es constante y la media del tiempo entre llegadas es λ1 . Trá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 2.22. En el caso de las redes y el intercambio de paquetes se suele dar en el tráfico de Internet. Si se observa el tráfico a lo largo de un periodo de tiempo, tendrá una determinada forma; si atendemos al tráfico en un periodo de tiempo más pequeño, tendrá aproximadamente la misma forma. Un buen ejemplo es la gráfica 2.23. A diferencia de otros tipos de tráfico, éste no viene implementado con NS. En cambio, hay que descargarlo y compilarlo desde el módulo para OBS desarrollado por la Universi- 33 C AP ÍTULO 2. E STADO DEL ARTE Figura 2.22: Curva de Koch Figura 2.23: Tráfico observado en una red Ethernet [16] dad de Maryland. Para poder entender los parámetros a configurar debemos saber cómo se genera éste tipo de trá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 distribución Gamma [18] (están correlados con H). El tamaño de los paquetes es un proceso autosimilar, con exponente Hurst (no necesariamente el mismo que para el tiempo de llegadas). Además, el tamaño sigue una distribución binomial negativa [19]. 34 2.4. G ENERADORES DE TR ÁFICO Figura 2.24: Esquema tráfico Autosimilar En la figura 2.24 se muestra un esquema del tráfico Autosimilar, donde el tamaño de los paquetes no es constante, si no que sigue una distribución binomial negativa y el tiempo entre llegadas sigue una distribución Gamma, como se ha visto antes. 35 C AP ÍTULO 2. E STADO DEL ARTE 36 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 programación JAVA y la librerı́a de topologı́as de red SNDlib. 3.1. Simulador NS-2 Como ya se dijo en el Capı́tulo 2.2.1, NS es un simulador de eventos discretos enfocado a la creación e investigación de redes. Proporciona un gran apoyo para la simulación del protocolo TCP, enrutamiento y protocolos multicast a través de redes cableadas e inalámbricas(locales y satélite). 3.1.1. Caracterı́sticas NS está basado en dos lenguajes: un simulador orientado a objetos, escrito en C++ y un intérprete OTcl(una extensió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 jerá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 algún objeto para la simulación, se acude a la jerarquı́a de C++ para utilizar ese objeto compilado. Esto se debe a que la simulación de redes abarca tareas de diferente ámbito, y debe cumplir dos 37 C AP ÍTULO 3. H ERRAMIENTAS requisitos principales: Se requiere la simulación detallada de los protocolos de comunicación, con un lenguaje de programación capaz de manejar datos de manera eficiente y con buenas prestaciones de velocidad. Se debe permitir una fácil reconfiguración de los escenarios a simular. La jerarquı́a compilada de C++ permite conseguir eficiencia en la simulación y rapidez en los tiempos de ejecución. Esto es especialmente ú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 simulació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 asociación del objeto OTcl por cada objeto C++. Al ser un simulador de eventos, el avance del tiempo depende de la programación de dichos eventos que son gestionados por un planificador. Un evento es un objeto de la jerarquı́a de C++ con un ID ú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. 3.1.2. Funcionamiento A continuación se explicará el funcionamiento interno de NS. Para ello se comentará la creación de los diferentes componentes que posee una red, la formación de los paquetes para el intercambio de información y la forma que NS gestiona los eventos ocurridos en la red. 38 3.1. S IMULADOR NS-2 Componentes de red La ruta que seguirán los datos se construye mediante la interconexión de componentes de red, indicando en cada objeto cuál es el objeto siguiente. De esta manera cuando un usuario quiere crear un nuevo componente, puede escribir el código en OTcl ó C++, o bien interconectar pequeños componentes, por ejemplo, se puede conseguir crear un enlace mediante la interconexió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 má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 ó UDP. Aplicaciones: son los objetos que generan la información, y van montados sobre los agentes. La creación de un nodo se realiza mediante la interconexión de clasificadores, luego se le añaden agentes y sobre ellos, las aplicaciones. La topologı́a se forma creando varios nodos e interconectándolos entre sı́ a través de enlaces. Paquetes de datos Para el intercambio de información en NS, se utilizan los llamados paquetes, que está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 qué posició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 C AP ÍTULO 3. H ERRAMIENTAS la red puede acceder a la cabecera deseada utilizando la posición de acceso correspondiente. Normalmente, un paquete sólo se compone de las cabeceras, sin datos, ya que el transporte de datos reales no es de mucho interés en simulaciones que no sean de tiempo real. Aún ası́, algunas aplicaciones y agentes soportan el intercambio de información real. Programador de eventos El intercambio de información se consigue pasando mensajes de datos de unos objetos a otros a travé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 recepción los controla un programador de eventos central. Como ya se apuntó, los eventos tienen un tiempo programado y un puntero a su manejador. El programador mantiene un tiempo de simulación y una cola con los eventos simulados y según avanza ese tiempo, va ejecutando los eventos mediante una llamada a sus manejadores. 3.2. Java Java es un lenguaje de programació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 más simple y no posee herramientas de bajo nivel, que suelen inducir a muchos errores, como es la manipulación de punteros y memoria. Se van a describir las librerı́as java utilizadas en la aplicación: 3.2.1. JDOM Provee una potente API para acceder, manipular y extraer datos de un fichero XML a partir de código Java. Interactúa bien con los estándares existentes como SAX y DOM, pero no es una capa de abstracción o mejora de dichos API’s. Por el contrario, proporciona un robusto y ligero medio de lectura y escritura de datos XML. 40 3.2. JAVA 3.2.2. JFreeChart JFreeChart es una librerı́a libre que permite que sea fácil para los desarrolladores mostrar gráficas en sus aplicaciones. El proyecto fue creado en el año 2000 por David Gilbert. Actualmente lo utilizan unos 50.000 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 número de tipos de gráficas Un diseño flexible y fácil de extender Ofrece soporte para diferentes tipos de formato de salida, inluyendo componentes Swing, archivos de imagen (PNG y JPEG) y gráficos vectoriales (PDF, EPS y SVG) Es software libre y se distribuye bajo los términos de GNU LGPL 1 , que permite su uso en aplicaciones propietarias. Hay que añadir que la librerı́a JFreeChart utiliza otra má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 gráficos. Entre sus usos está el centrado automático de ventanas en pantalla, por ejemplo. Algunos ejemplos de gráficas que se pueden realizar son las figuras 3.1 y 3.2. 3.2.3. Commons-Math Java provee una extensión matemática implementada sólo para los algoritmos matemáticos más básicos. Con esta librerı́a se consigue la implementación de muchos otros de más complejidad, tales como: Representación de números básicos complejos mediante operaciones algebraicas Método de Newton para aproximar raı́ces Coeficientes binomiales 1 http://www.gnu.org/licenses/lgpl.html 41 C AP ÍTULO 3. H ERRAMIENTAS Figura 3.1: Gráfica de barras y series con JFreeChart Figura 3.2: Histograma con JFreeChart Crecimiento y decrecimiento exponencial Interpolación polinómica Representación de matrices básicas con operaciones algebraicas Además, implementa algoritmos básicos de estadı́stica: Estadı́sticas de una variable simple 42 3.3. SND LIB Distribuciones de frecuencia Generación de números aleatorios siguiendo distribuciones Gauissiana, Exponencial y Poisson Regresión y correlación de dos variables 3.2.4. Entorno de desarrollo Para el desarrollo de la aplicación se ha elegido NetBeans 2 como entorno de trabajo. Es un entorno de desarrollo de có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 gráficos de Java Swing ha sido de gran ayuda a la hora de crear la aplicación, ya que basta con seleccionar el componente que se quiere introducir en la interfaz y colocarlo en la posición deseada para que automáticamente se cree. Además, con un sencillo menú desplegable, se puede acceder a las propiedades de dicho elemento y modificarlas según las necesidades. También genera el paquete jar para su posterior ejecución de una manera sencilla para el usuario. Basta con acceder al menú Ejecutar y seleccionar la opción Generar Main Project. En la figura 3.3 se muestra una captura de pantalla del entorno de trabajo utilizado. 3.3. 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 descripción se encuentra en formato XML, lo que facilita la creación de los ficheros de simulación en gran medida, ahorrando al usuario el trabajo de tener que generar él mismo dicho fichero elemento a elemento. Dicha librerı́a tiene varios propósitos: 2 http://netbeans.org/index.html 43 C AP ÍTULO 3. H ERRAMIENTAS Figura 3.3: NetBeans hacer diseños de pruebas de red reales para facilitar el trabajo de la comunidad de investigación servir como punto de referencia estándar para probar, evaluar y comparar los modelos de diseño de redes y algoritmos ser una fuente de información y recursos relacionados con el diseño de la red fija, y proporcionar una plataforma de contacto para los investigadores y los profesionales que trabajan en este campo 44 Capı́tulo 4 Descripción de la aplicación En este capı́tulo se realizará un análisis de las decisiones tomadas para la creación de la aplicación, ası́ como de las funciones que debe cumplir. 4.1. Funcionalidad En resumen, la funcionalidad principal que debe cumplir la aplicació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 simulación de NS. Tomando como referencia un fichero esqueleto, generar el fichero de NS y simularlo. Una vez terminada la simulación, leer los ficheros de resultados generados por el simulador y construir gráficas representativas de dichos resultados para su estudio. Además se pueden añadir funciones que no son primordiales, pero complementan la aplicación y la hacen más útil de cara al usuario: Posibilitar la modificación de cualquier aspecto del escenario, ya sean los enlaces o las demandas de tráfico. Cambiar el tipo de tráfico que se va a intercambiar entre nodos. 45 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Ofrecer la posibilidad al usuario de cambiar los parámetros de la simulación. Ofrecer una vista en la aplicación del esquema de la red. Creación y exportación de gráficas para el posterior estudio de la simulación realizada. Generación y simulación de diferentes topologı́as con las mismas prestaciones que el escenario inicial. 4.2. Simulador NS-2 En este apartado se explicará la configuración y ejecución del simulador NS-2 con el módulo para OBS y algunos ejemplos de cómo configurar los parámetros de los tipos de tráfico utilizados. 4.2.1. Integración Como se dijo en el Capı́tulo 2, se utilizará como simulador NS-2 en su versión 2.28, con el mó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 módulo de OBS para que su integración sea correcta [21] [22], y se detallan en el Apéndice D. Todo ello se realiza siguiendo una serie de pasos, descritos en el Manual de instalación en el Apéndice C. 4.2.2. Generadores de tráfico utilizados En el Capı́tulo 2 se estudiaron de manera teórica los diferentes tipos de tráfico utilizados, ası́ que ahora tan solo se explicará la forma de configurarlos y algún ejemplo de ello. 46 4.2. S IMULADOR NS-2 Módulo CBR Los parámetros configurables en NS para este tipo de tráfico son: rate : la tasa de tráfico enviada, medida en bits/s interval : el tiempo entre paquetes, medido en segundos packetSize : el tamañ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 está desactivado maxpkts : el número máximo de paquetes enviados, por defecto 228 Las variables rate y interval son mútuamente exclusivas. En una simulación con este tipo de tráfico se debe especificar una u otra, pero no ambas. En la aplicación se utilizan rate , packetSize y random . Un ejemplo para configurar tráfico CBR es: Se desea mandar trá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 fácil averiguar los parámetros que se deben configurar. Como rate se mide en bits/s, tan sólo se debe establecer el parámetro rate a 100mb, sin importar el tamaño de los paquetes, ya que el propio generador de tráfico calcula cuántos paquetes se deben mandar para poder alcanzar la tasa establecida. Otro ejemplo para este tráfico es: Se desea enviar tráfico entre dos nodos, C y D, durante dos segundos En concreto se desean enviar 10000 paquetes de 2000 bits cada uno Ahora se debe tener en cuenta que no se dice la cantidad de tráfico que se desea mandar, tan solo el número de paquetes y el tamaño de los mismos. Tras hacer un cálculo sencillo, se ve que en total se deben enviar 20Mb en toda la simulación, por lo tanto, si el rate se mide en Mb/s, se debe dividir el tráfico total entre los segundos de simulación, quedando una configuración de rate =10mb y packetSize =2000. 47 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Módulo Exponential Los parámetros que se pueden configurar en NS son: packetSize : el tamaño constante de los paquetes generados, medido en bits busrt time : el tiempo medio en el que el generador está “encendido”, medido en segundos idle time : el tiempo medio en el que el generador está “apagado”, medido en segundos rate : la tasa de tráfico enviada durante los tiempos de “encendido”, medido en bits/s La consecuencia más inmediata deducida, es que al ser un tráfico “on/off”, tal y como se explicó en el Capı́tulo 2, la tasa media de tráfico dependerá de la duración de las ráfagas, quedando una relación de la siguiente manera: rate∗burst time tasa media = burst time+idle time Para poder obtener una relación entre tasa media y rate sin conocer los valores de burst time y idle time, se ha diseñado un experimento. Se fija el valor rate a 100Mb/s, y con las estadı́sticas que ofrece la simulación al terminar, se calcula el número de bits enviados en un segundo, obteniendo que la tasa media es de 70,92Mb/s. Por lo tanto, se puede obtener la relación fácilmente con un sencillo cálculo: tasa media = rate 1,41594925 Hay que apuntar que esta relación sólo es válida para los valores de burst time y idle time configurados por defecto para este tipo de tráfico, en cuanto el usuario modifique alguno de estos valores la relación ya no será correcta. Como curiosidad, se puede configurar el trá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 ráfaga es 0s, al menos se enviará un paquete. 48 4.2. S IMULADOR NS-2 En el caso del proyecto, los parámetros configurados han sido rate y packetSize . Utilizando los mismos ejemplos que para el caso del tráfico CBR, en esta ocasión los pará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 ocasión debemos tener en cuenta la relació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 tamaño de los mismos, por lo que se debe calcular la tasa. En este caso, y teniendo en cuenta la relación mencionada antes, se deberá configurar el tráfico como rate =14.1mb y packetSize =2000. Módulo SelfSimilar Tras la explicación del tráfico en el Capı́tulo 2, se verán los pará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: desviación estándar del tiempo entre paquetes, dependiendo de la tasa establecida deberá tener un determinado orden de magnitud batchsize: el tamaño medio de los paquetes, medido en bytes Hb: exponente Hurst para el tamaño de los paquetes sb: parámetro de varianza de la distribución binomial negativa (número de distribuciones geométricas convolucionadas) En el proyecto se han configurado todos los parámetros, pero sólo son modificables rate, std dev inter batch time y batchsize, los demás están configurados en el fichero esqueleto, pero sin ser modificables por la aplicación. Se ha tomado esta decisión arbitrariamente, apoyándonos en la premisa de que el resto de parámetros podrı́an ser de 49 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN una complejidad mayor para un usuario inexperto. En cualquier caso, se pueden modificar mediante la edición del citado fichero esqueleto. Siguiendo los ejemplos de configuración anteriores, para el tráfico SelfSimilar se hará de la siguiente forma: Para el trá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 cálculo previo. Necesitamos conocer el tamaño de los paquetes, que lo estableceremos a 2000bits. Haciendo un cálculo sencillo, se obtiene que se deben mandar 50000 paquetes/s. También se deben configurar el resto de parámetros, como el std dev inter batch time y los parámetros de las distribuciones. Hay que tener en cuenta que el tamaño de los paquetes se mide en bytes. Los parámetros que se deben configurar para realizar la simulación son: rate=50000, batchsize=250, std dev inter batch time=1e-5, Ht=0,5, Hb=-0,5, sb=0. Para el tráfico entre C y D no se necesitan cálculos previos, ya que nos indican la cantidad de paquetes que se desean enviar en dos segundos, por lo tanto en un segundo, se deberán enviar la mitad para conseguir el tráfico deseado. Como std dev inter batch time depende de la magnitud de rate, también se modifica, pero el resto de parámetros sigue igual: rate=5000, batchsize=250, std dev inter batch time=1e-4, Ht=0,5, Hb=-0,5,sb=0. 4.3. Parser Se ha diseñ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. Además, se implementa un generador de ficheros con la topologı́a leı́da en formato NS listo para simular. 4.3.1. 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 4.3. PARSER de Java, está disponible la librerı́a JDOM, que facilita la lectura de ficheros XML, después, sólo se debe decidir lo que se hace con los datos leı́dos. Para guardar los datos de una forma sencilla e intuitiva, la aplicació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 tendrá un objeto Node con los atributos leı́dos, en este caso, la Id y las coordenadas. Hay que señalar, que, como se explicó 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 tendrá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 módulos de ampliación de capacidad y su coste asociado; y para las demandas, objetos Demand, que tendrán como atributos la cantidad de demanda y el origen y destino de la misma. Cuando se termine de leer el fichero XML, la aplicación dispondrá 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 Apé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 trá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 básicas de las mismas caracterı́sticas que la primera, habrá ocasiones en el que la creación de las otras topologı́as no se realice de manera directa o trivial. Para ello se ha tomado como decisión de diseñ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 continuación se explica la toma de decisiones que se han llevado a cabo para poder crear las topologı́as bá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 generarán las topologı́as con las mismas prestaciones. 51 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Figura 4.1: Ejemplo de topologı́a parseada Anillo Un anillo es una distribución de red en la cual un nodo está conectado a otros dos mediante sendos enlaces. La interconexión se realiza de tal manera que el primero se conecta con el ú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 tráfico en un sentido o en el contrario. Dadas las caraterı́sticas de la red original y del anillo, se ha tomado la decisió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 enlacei, j = min(∑ linksi ; ∑ links j ) En el ejemplo, la capacidad del nuevo enlace entre los nodos 1 y 2, se tendrá: min(3Gbps; 3Gbps + 3Gbps + 5Gbps) = 3Gbps 52 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 más restrictivo. Malla Una malla es una distribución de red en la que todos los nodos están conectados entre sı́ unos con otros, esto es, cada nodo está conectado directamente a los demá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 nú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. links linksi ∑ nuevo enlacei, j = min( ∑#links ; #links jj ) i Ası́, la capacidad del nuevo enlace entre los nodos 1 y 2, será: 53 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Figura 4.3: Ejemplo de topologı́a parseada en malla 3Gps 3Gbps+3Gbps+5Gbps ; ) = 3Gbps min( 1enlace 3enlaces y la malla quedará como la figura 4.3. Lo que se pretende, es seguir manteniendo la capacidad de cada nodo, pero como ahora tienen muchos má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 distribución en estrella se caracteriza por que todos los nodos están conectados a uno solo, que hace de concentrador, por el cual debe pasar todo el trá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 decisión que cada nodo se conecte al central con una capacidad calculada ası́: Se suman todas las capacidades del nodo en cuestión. El resultado será la nueva capacidad de enlace 54 4.3. PARSER Figura 4.4: Ejemplo de topologı́a parseada en estrella nuevo enlacei,central = ∑ linksi Es importante señalar que se tomó la decisió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 demá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 habrá una capacidad de: 3Gbps + 3Gbps + 5Gbps = 11Gbps quedando la nueva configuración de red como se aprecia en la figura 4.4. Para ayudar a la comprensión de los pasos que sigue la aplicació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 Apéndice E. 55 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Figura 4.5: Diagrama parseo de XML 56 4.3. PARSER 4.3.2. 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 tráfico, en un fichero Tcl. Se ha decidido que en la aplicación se puedan configurar ciertos parámetros de la simulación, tales como el retardo de los enlaces, el número de canales de OBS y el tamaño de los paquetes, pero hay muchos otros que no son configurables desde la misma. Aún ası́, esos parámetros no se dejan sin configurar, están preconfigurados, pero sin ser modificables desde la aplicación gráfica, en el fichero que posee el esqueleto con las declaraciones de los parámetros de las simulaciones a realizar. El fichero esqueleto no posee la declaración de los nodos, los enlaces, ni del tráfico de nuestra simulación, tan sólo es un fichero base, del que se cogerán los parámetros no modificables por el entorno gráfico y se rellenará con la topologı́a leı́da del fichero XML, creando el fichero final de la topologı́a, que será el que se vaya a simular. Para poder realizar esta tarea, se han tomado varias decisiones de diseño que se enumeran a continuación: Se han insertado marcas en el fichero esqueleto, a partir de las cuales se introduce la configuración modificable por la aplicación, como pueden ser los nodos, los enlaces, las demandas, los canales de OBS o el tamaño de los paquetes. Las marcas deben ser lo suficientemente intuitivas para que un desarrollador, que desee modificar la funcionalidad de la aplicación, sea capaz de hacerlo sin apenas esfuerzo, ya sea eliminando marcas para que esos parámetros no sean configurables o añadiendo marcas para poder modificar parámetros que actualmente no lo son. El fichero debe ser lo más genérico posible, ya que se van a simular diferentes topologı́as para su posterior comparación, por lo tanto no se puede utilizar un fichero especı́fico para cada una de ellas, debe ser una estructura común. La ejecución de la simulación puede ser desde cualquier lugar, por lo tanto, se deben establecer rutas completas tanto a los ficheros con el módulo de OBS como a la carpeta donde el usuario quiere almacenar los ficheros de trazas. 57 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Por poner algunos ejemplos de marcas, a partir de la marca ##NODOS## la aplicación introduce la declaración de los nodos y a partir de la marca ##ENLACES## la aplicación introduce la declaración de los enlaces, tanto los edge-core como core-core. En el Manual de Usuario, en el Apéndice B, se enumeran todas las marcas que se han insertado en el fichero esqueleto para que los parámetros que indican, sean modificables mediante la aplicación gráfica. Y en el Apéndice F podemos ver un ejemplo del fichero esqueleto para la simulación y el fichero final que se va a simular, una vez que la aplicación ha insertado todos los parámetros. Para ayudar a comprender cómo la aplicació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 Apéndice E. 4.3.3. Analizador de resultados Para generar las grá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 aplicación los lee, analiza las trazas y genera las gráficas con los resultados obtenidos. Un ejemplo de este fichero se encuentra en el Apé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: + 0.017818 2 17 IPKT 64 ------- 1 2.0.0.0 13.0.0.-1 0 73 0 A continuació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). 0.017818 indica el instante de tiempo, en segundos, en el que ocurre el evento. 58 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 tamaño, en bits, del paquete. 1 es el flow id 59 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Figura 4.7: Diagrama de simulación ------- indican los flags del paquete, en caso de tener alguno activo. 2.0.0.0 el primer número es el nodo que envı́a el paquete a nivel de red, el último es el puerto del nodo origen. 13.0.0.-1 el primer número es el nodo destino del paquete a nivel de red, el último es el puerto del nodo destino. 0 es el número de secuencia 73 es el id del paquete, único en toda la simulación. El inconveniente de analizar este tipo de ficheros es que puede haber ocasiones en el 60 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 aplicació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 aplicación se apoya en objetos Trace, que disponen de atributos útiles para analizar las trazas, y que se corresponde con cada uno de los campos de las lı́neas del fichero de trazas explicadas más arriba. Una vez se tienen los datos almacenados, se pasa a la creación de gráficas. En la figura 4.8 se puede ver el diagrama de flujo para el análsis y la posterior representación de los resultados en forma de gráficas, para entender mejor su funcionamiento. Como se detalla en el Apéndice E, la clase encargada de leer los ficheros de trazas y generar las gráficas es PanelGraficas.java. 4.4. GUI Se trata de un interfaz gráfico que proporciona ayuda a la hora de simular redes con diferentes topologı́as. A través de dicho interfaz se configuran los parámetros de la simulación, tales como el tipo de tráfico entre los nodos, la cantidad de tráfico, la capacidad de los enlaces, el factor de ocupación ρ de los enlaces y el tiempo de simulación, además del número de simulaciones que se desean realizar para obtener datos estadı́sticos aceptables. Además, la aplicación analiza los resultados obtenidos en cada una de esas simulaciones y genera gráficas para mostrar dichos resultados, de esta manera, se puede analizar las redes más sencillamente. Para saber cómo funciona la aplicación, en el Apéndice B se dispone del Manual de usuario de la aplicación, donde se explican las pantallas de las que disponemos para configurar las simulaciones a realizar. 61 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Figura 4.8: Diagrama de análisis de trazas 62 4.4. GUI 4.4.1. Interfaz de usuario Como ya se apuntó 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 rápida y sencilla. Se tomó como decisión de diseño dividir la interfaz en varias pestañas para separar las diferentes funcionalidades de la aplicación: Configuración: en esta pantalla se utilizan varios JTextField para solicitar al usuario los ficheros necesarios para la simulació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 módulo de OBS. Además se ofrece la posibilidad de ejecutar NAM, aunque el usuario será el encargado de decidir qué simulación quiere ver en el animador. Opciones de Simulación: en la segunda pestaña disponible, el usuario podrá seleccionar el tipo de tráfico que desea utilizar, ya sea CBR, Exponencial o Autosimilar, ası́ como varias opciones de la simulación, tales como el retardo de los enlaces o los canales disponibles para los nodos OBS. También se decisdió 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 tráficos fuese diferente con cada ρ. Esquema de Red: se mostrará al usuario un esquema dibujado de la red. Al tener cuatro topologı́as, la original, en anillo, en malla y en estrella; la mostrada será la que se seleccione en la pestaña de los enlaces. La posición de los nodos la podemos obtener del fichero XML, por lo que estaremos mostrando la distribución real de la red. Demandas: en esta pestaña se muestra una tabla con las demandas de tráfico entre los nodos. Además se ofrece la posibilidad de modificar una demanda, simplemente seleccionándola y utilizando el JTextField disponible en esta misma pestaña. Enlaces: aquı́ se puede ver una tabla con los enlaces de las topologı́as. Para seleccionar cuál se desea visualizar, está disponible un JComboBox con las topologı́as generadas, y basta con seleccionar la elegida para que la tabla cambie automáticamente. También existe la posibilidad de modificar los enlaces, ya sea uno seleccionado, todos, o tan sólo los que estén a 0Mb/s. Esta última funcionalidad se ha 63 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN añ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 estén a 0 no se pasarán al fichero NS ya que no distingue si el enlace tiene o no capacidad, e intenta mandar datos a través de un enlace con capacidad 0. También advertir que la aplicación, antes de pasar la topologı́a a NS, comprueba si algún nodo se ha quedado aislado, es decir si todos sus enlaces tienen capacidad 0. Gráficas: en la última pestaña es donde se muestran las gráficas para el estudio de la simulación. Señalar que las gráficas se generan de manera estadı́stica, es decir, cuantas más simulaciones se realicen, se obtendrán más datos, y los valores medios mostrados serán má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 gráficas se observa que la desviación tı́pica es muy grande, se pueden consultar estos ficheros para ver qué simulación es la que ha ocasionado este desvı́o. También se ofrece la posibilidad de exportar las gráficas a un fichero de texto para su posterior estudio en otras plataformas. Para una información más detallada de las diferentes pantallas de la aplicación se dispone del Manual de usuario en el Apéndice B. 4.4.2. Gráficas de resultados Para analizar los datos de una forma más sencilla, se decidió ofrecer al usuario un conjunto de gráficas para consultar, las cuales, ilustran algunos datos importantes de la simulación. La clase encargada de crear y mostrar las gráficas es PanelGraficas.java y en ella se hace uso del paquete JFreeChart, descrito en el Capı́tulo 3.2.2. Gracias a dicho paquete podemos crear gráficas de varios tipos, tales como barras, histogramas, lineales y otras. El usuario tiene disponibles tres conjuntos de gráficas: Gráficas de tráfico: en las que se da la posibilidad de analizar la cantidad de tráfico que procesan los nodos, ya sea por paquetes o por tráfico total, además de saber cuánto tráfico inserta cada nodo en el sistema. Para la generación de estas gráficas se ha decidido seguir los siguientes pasos: 64 4.4. GUI • A medida que se lee el fichero de trazas, se almacena el tamaño del paquete leı́do o se aumenta el número de paquetes leı́dos • Si es una recepción o un encolamiento para envı́o se mira el nodo que lo está 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 está 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 gráficas es ofrecer una vista sencilla e intuitiva de la cantidad de tráfico que debe procesar cada nodo. De esta manera, se puede modificar la capacidad de los nodos en función del porcentaje de tráfico que deban procesar, a mayor tráfico, mayor capacidad. Gráficas del estado de las colas en los nodos: en este grupo se muestran dos gráficas sencillas, la primera muestra el tiempo medio que espera un paquete en la cola de los nodos. Para este cálculo, NS impone una limitación, ya que en el fichero de trazas, la precisión del tiempo no va más allá de los µs. La manera de generar la grá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 representación La segunda grá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 simulación. Para poder realizar esta grá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 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN • Se aumenta el número de paquetes en cola del nodo en cuestión en el slot de 10ms correspondiente El motivo de este conjunto de gráficas es ofrecer al usuario una vista del estado de las colas en cada nodo. Con la primera grá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 rápida y visual, saber la cantidad de tráfico que le llega a un nodo cada 10ms, lo que da una idea de lo congestionado que se encuentra. Gráficas de retardo: en este ú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. Tambié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 más nodos deba atravesar un paquete, mayor será el tiempo empleado en llegar. Para poder generar estas grá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 tráfico • Si se recibe un paquete y no es el destino, se aumenta en uno el nú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 último conjunto de gráficas se pretende controlar a simple vista, posibles retardos en la recepción de los paquetes, lo que podrı́a venir dado por una alta congestión en uno de los nodos intermedios. También hay que señalar que por cada topologı́a simulada se muestran estos tres conjuntos de gráficas, pudiendo elegir en cada momento a través de un menú desplegable las gráficas que se quieren mostrar y de qué topologı́a en concreto. En el Manual de usuario, en el Apéndice B, se puede encontrar una descripción más detallada sobre la función de cada una de las gráficas. Al usuario se le ofrece la posibilidad de exportar las gráficas a un fichero de texto para su posterior procesamiento en otras plataformas capaces de representar gráficas, como 66 4.4. GUI pueden ser MATLAB 1 o gnuplot 2 , cada gráfica tiene un modelo de fichero de salida, ya que no todas las gráficas son iguales. Por ejemplo, las grá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 desviación tı́pica. En el Manual de usuario, en el Apéndice B, se detalla el formato de todos los ficheros para que su procesado sea más cómodo y ası́ facilitar su representación. Por supuesto, este formato no sigue ningún estándar, se ha tomado la decisión de exportar las gráficas de esa manera ya que era la más lógica. 4.4.3. Ampliar funcionalidad Durante la realización del proyecto surgieron otras posibles ampliaciones para la aplicación, algunas de ellas son: añadir más tipos de tráfico o tener la posibilidad de seleccionar entre más tipos de nodos, como ethernet o wifi; e incluso diferentes tipos de red, ya que la aplicación no está ligada a la tecnologı́a. Pero debido a que la funcionalidad principal era la simulación de redes ópticas con OBS, se dejaron para posibles lı́neas futuras de desarrollo, como se verá en el Capı́tulo 6. Aún ası́, se ha considerado que las descritas aquı́ poseen cierta relevancia e interés, y por esta razón se detalla su posible implementación. Añadir nuevo tipo de tráfico Para añadir un nuevo tipo de tráfico hay que seguir una sencilla serie de pasos: 1. Modificar la pestaña de Opciones de Simulación para que se pueda seleccionar el nuevo tráfico, además de poder elegir un valor para el tamaño de los paquetes. 2. Modificar el fichero esqueleto de la topologı́a en NS para poder introducir ese nuevo tipo de tráfico, basta con seguir la estructura de los procedimientos ya generados para los otros tráficos. 3. Cuando se vaya a escribir la topologı́a final de NS, escribir en el código de la aplicación un nuevo caso, para este nuevo tráfico, siguiendo la estructura de los que ya están. 1 http://www.mathworks.es/ 2 http://www.gnuplot.info/ 67 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN Añadir nuevo tipo de nodo Añadir un tipo nuevo de nodo no es tan sencillo como añadir trá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 pestaña de las Opciones de Simulación, ya que ahı́ es donde se configuran todos los parámetros. 2. Modificar el fichero esqueleto para añadir todos los parámetros de los nodos que no vamos a ofrecer al usuario para modificar. 3. Los parámetros modificables debemos mostrarlos en una pestaña. 4. A la hora de escribir los nodos en el fichero final NS, escribir una declaración u otra, dependiendo de la elecció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 elección del usuario. 4.4.4. Diagrama de clases simplificado En la figura 4.9 se muestra un diagrama de clases simplificado, en el que se ilustra la relación entre las clases, y en el que, a primera vista, se puede ver como la clase central de la aplicación es Interfaz.java. Para ver una descripción de la funcionalidad de cada una de las clases y un diagrama más detallado, consultar el Apéndice E. 68 4.4. GUI Figura 4.9: Diagrama de clases simplificado 69 C AP ÍTULO 4. D ESCRIPCI ÓN DE LA APLICACI ÓN 70 Capı́tulo 5 Validación En este capı́tulo se validará el funcionamiento de la aplicación y se analizarán las pruebas realizadas para ello. 5.1. Pruebas a realizar Para comprobar el correcto funcionamiento de la aplicación se han elegido una serie de pruebas: Prueba 1: Arrancar la aplicación sin fichero .lastConf para que no cargue ninguna configuración por defecto. Prueba 2: Una vez realizada una simulación, cerrar la aplicación y volver a abrirla para comprobar que se cargan los ficheros de la última simulació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 algún nodo aislado, es decir, sin ningún enlace con capcidad diferente de 0Mbps, intentar generar el fichero para la simulación y comprobar que la ventana de aviso se muestra. Prueba 6: Simulación de envı́o del tráfico leı́do del fichero XML con una capacidad de 1Gbps para cada uno de los enlaces con diferentes niveles de carga. 71 C AP ÍTULO 5. VALIDACI ÓN Figura 5.1: Red NFSNET (arriba), proyecto Nobel para Europa (abajo izquierda) y Polonia (abajo derecha) [20] Prueba 7: Simulación de una red cambiando los retardos entre los enlaces. Prueba 8: Simulación de una red para comprobar el estado de las colas de espera en los nodos. Prueba 9: Simulación de un escenario diferente en el que se puede aplicar teorı́a de colas. Prueba 10: Una vez realizada una simulación y mostradas sus gráficas, exportarlas a un fichero de texto. Las pruebas de robustez de la aplicación se han pasado con éxito, pero las que aportan una mejor visión de la funcionalidad de la aplicación son las de simulación y obtención 72 5.2. P RUEBAS DE CARGA de gráficas de resultados. Por ello, se va a explicar de manera más detallada los resultados obtenidos en las diferentes pruebas de simulación. Para más información de cómo configurar los parámetros de la simulación, consultar el Apéndice B. 5.2. 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 dimensió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 validación sea correcta, deberı́an mostrar resultados acordes. Para realizar las simulaciones se ha elegido el tráfico Exponential ya que es el modelo de tráfico teórico más conocido y estudiado. 5.2.1. Pruebas con carga baja en los enlaces Los parámetros configurados en la simulación para esta baterı́a de pruebas han sido: La capacidad de los enlaces es de 1Gbps. 1 , lo que en este caso es aproximadamente un La carga de los enlaces es de N−1 7 %. 4 canales de datos y 1 de control. Retardo de enlace de 1ms. Tamaño de paquete de 2000bits. La primera red, que consiste en 14 nodos, 21 enlaces y 91 demandas de trá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 gráficas de resultados se va a explicar su representación. Las gráficas representan los porcentajes de paquetes cursados o descartados en cada nodo en función del total cursado por la red, y cada una de ella se corresponde con 73 C AP ÍTULO 5. VALIDACI Ó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 señala el porcentaje de paquetes descartados. Para entender mejor la representación de dichas grá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 tráfico total que circula por la red; y descarta un porcentaje menor a 1 % del total de dicho trá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 representación de los resultados, se puede realizar una interpretación de los mismos, aunque hay que recordar que el objetivo no es elegir la mejor distribución de la red, si no aportar las herramientas de ayuda necesarias para 74 5.2. P RUEBAS 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 decisión. En el escenario simulado anteriormente se observa que la red no presenta apenas congestión en ninguna de sus variantes, como era de esperar antes de realizar la simulación, dado que la carga de entrada es baja. Para el segundo escenario, conformado por 28 nodos, 41 enlaces y 378 demandas de trá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 comparación con la simulación anterior, se puede ver fácilmente que al ser una red más grande, el tráfico es mayor, por lo que los nodos deben procesar muchos má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 tráfico, ubicada en [25], correspondiente a la red de Polonia, se han obtenido los resultados mostrados en la figura 5.4. 1 http://www.ist-nobel.org/Nobel2/servlet/Nobel2.Main 75 C AP ÍTULO 5. VALIDACI Ó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 aplicación. 5.2.2. Pruebas con carga media en los enlaces Los pará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. Tamaño de paquete de 2000bits. 76 5.2. P RUEBAS 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 parámetros de configuración a excepción de la carga en los enlaces. Para la red NFSNET, con 14 nodos, 21 enlaces y 91 demandas de tráfico [23], se han obtenido los resultados mostrados en la figura 5.5. En ella se puede observar cómo el porcentaje de tráfico descartado aumenta respecto a la prueba anterior, algo lógico si tenemos en cuenta que los nodos está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 trá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 ú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 5.7. 77 C AP ÍTULO 5. VALIDACI Ó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 5.2. P RUEBAS DE CARGA 5.2.3. Pruebas con carga alta en los enlaces Los parámetros configurados en esta ocasió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. Tamañ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 parámetros para la simulació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 aumentará 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 tráfico [23] se obtienen los resultados mostrados en la figura 5.8, y como se ha señ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 más a los de la red de estudio, pero esto es debido a que la primera red está saturada casi al completo, al igual que esta, por lo que los resultados será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 5.10. De nuevo, podemos observar, si comparamos los resultados con los de la primera red, que ambas son muy parecidas, lo que confirma la suposición inicial de que redes de una magnitud similar tienen resultados similares. 79 C AP ÍTULO 5. VALIDACI Ó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 5.3. P RUEBAS 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 gráficas de retardo mostrará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 aplicació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 tráfico Exponential, por las razones antes citadas. 5.3.1. Pruebas con tiempos de retardo bajo en los enlaces Los parámetros configurados para la simulación son los descritos a continuación: La capacidad de los enlaces es de 1Gbps. 81 C AP ÍTULO 5. VALIDACI ÓN La carga de los enlaces es de un 50 %. 4 canales de datos y 1 de control. Tamaño de paquete de 2000bits. Las primeras pruebas se harán con un retardo de enlace de 1ms. Cabe destacar que este retardo será el mismo para los enlaces edge-core y para los core-core. En la figura 5.11 se muestra el resultado de la simulación antes descrita. Para una mejor comprensión de las grá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 gráficas, la media del retardo entre dos nodos extremos, medida en ms, y los nodos intermedios entre nodos extremos. Cada grá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 posición 2:3, es el retardo o los nodos intermedios (según la gráfica que se esté 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 posición deseada y comprobarlo con la escala adjunta. Una vez explicado el formato de las gráficas y su manera de interpretación, vamos a poner un ejemplo. Si quisié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 gráfica de los nodos se muestra para comprobar que los picos en el retardo corresponden a un gran nú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 grá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 configuración de las gráficas, en forma de matriz triangular, se debe a que las demandas de tráfico sólo están configuradas en un sentido en el fichero XML. La aplicación no se encarga de duplicar esas demandas, tan sólo se limita a simular lo que haya en dicho fichero. Si observamos las gráficas detenidamente, es fácil saber de antemano la forma que tendrán. Los nodos en el anillo están unidos con el anterior y el siguiente, por lo que es 82 5.3. P RUEBAS 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 C AP ÍTULO 5. VALIDACI Ó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 5.3. P RUEBAS DE RETARDO fácil pensar que el retardo será pequeño en nodos cercanos y grande en nodos alejados, y como se muestra en las grá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 congestió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 5.12. 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 análisis es la diposició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 máximo, que está 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 más pequeñas, aunque como se ha señalado, depende de la disposición de los enlaces y de su retardo o longitud. 5.3.2. Pruebas con tiempos de retardo medio en los enlaces Los pará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. Tamañ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, có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 C AP ÍTULO 5. VALIDACI Ó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 5.3. P RUEBAS 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 C AP ÍTULO 5. VALIDACI Ó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 5.3. P RUEBAS 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 C AP ÍTULO 5. VALIDACI ÓN 5.3.3. Pruebas con tiempos de retardo altos en los enlaces Los parámetros con los que se ha configurado la simulació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. Tamaño de paquete de 2000bits. Para este tercer y último bloque de pruebas de retardo, se va a fijar el retardo de los enlaces a 100ms, que para redes de fibra óptica es mucho, pero el objetivo de la prueba era validar la aplicació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 patrón que las pruebas anteriores, pero en un orden de magnitud mucho mayor. Como ya se habı́a apuntado, este resultado era el esperado según el estudio de las anteriores pruebas. 5.4. 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 más paquetes, y por lo tanto, las colas de dichos nodos crecerán visiblemente. Para la realización de estas pruebas se toma como red de estudio la de Almenia, descrita en [26]. El tamaño de los enlaces se ha fijado a 50Mb/s, teniendo en cuenta que las demandas de tráfico no son muy grandes, y 4 canales de datos de OBS y 1 de control. El tráfico enviado a sido Exponential, con un tamaño de paquete de 2000bits. 5.4.1. Pruebas con demandas bajas Como ya se dijo, se van a estudiar las colas de los nodos, por lo que las gráficas interesantes serán las de número de paquetes en cola cada 10ms. Para esta prueba se han obtenido las gráficas mostradas en la figura 5.17. 90 5.4. E STUDIO 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 C AP ÍTULO 5. VALIDACI ÓN Este tipo de gráficas representan la cantidad de paquetes que tiene un nodo en cola cada 10ms. Para su mejor comprensión, se va a explicar brevemente su estructura. En el eje de ordenadas tenemos los instantes de tiempo y en el de abscisas el nú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 está 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 má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 congestión en esos instantes de tiempo. 5.4.2. Pruebas con picos de demanda Para poder realizar un estudio comparativo, se ha simulado la misma red, con los mismos parámetros, pero introduciendo picos de trá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 5.18. 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 gráfica, se podrı́a tomar la decisión de aumentar la capacidad de los enlaces involucrados en ese aumento de paquetes en cola, para evitar la saturación de las mismas en caso de que haya otros picos de demanda inesperados. 5.5. Simulación de otros escenarios Como se ha explicado en el Capı́tulo 2.2.1, la aplicación está basada en un simulador de eventos, que permite simular redes de colas. En general, estableciendo los pará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: análogamente, los paquetes serı́an coches, la capacidad del enlace serı́a la velocidad de incorporación a la vı́a, los nodos serı́an las entradas o salidas y la velocidad de propagación serı́a la velocidad de la vı́a. 92 5.5. S IMULACI Ó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 C AP ÍTULO 5. VALIDACI ÓN Figura 5.19: Esquema de la M-40 Concretamente se ha elegido un esquema de la M-40, mostrado en la figura 5.19. 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 más pequeño sólo entre ciertas salidas para aligerar el tráfico existente en la primera simulación. Para la de la topologı́a en anillo, sólo se utilizarán los enlaces de la M-40. Una vez establecida la topologı́a de la red y procesada por la aplicación, se deben introducir los parámetros de la simulación. Para ello, se harán las siguientes suposiciones: El tamaño de los coches: en este caso los coches equivalen a los paquetes, por lo que se debe introducir el tamaño de la unidad mı́nima en metros. Para este escenario, se ha elegido como tamaño de unidad de computació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 106 , y que las unidades de computación ocupan un tamaño de 6 unidades de medida, por lo que si, por ejemplo, se desea simular que del A1 al A4 van 50 unidades de computación, se debe poner una demanda de 300, y como la aplicación pide un orden de magnitud de 106 el dato correcto debe ser 0,000300. 94 5.5. S IMULACI ÓN DE OTROS ESCENARIOS El número de carriles: como se vió 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 número de carriles equivale al número de canales de datos disponibles para la transmisión de datos, de esta manera, se han estimado el número de canales en 3, por lo que se tienen que configurar 3 canales de datos y 1 de control, luego el sistema será un M/M/3, con entrada tráfico Exponential. La velocidad de incorporación: equivale a la capacidad del enlace. Para el caso planteado, se tienen 3 canales, y se asume que la velocidad de incorporació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 cálculos previos a la simulación se puede obtener la tasa de servicio del sistema, cú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 congestión de las incorporaciones: al tratarse de un sistema M/M/c, se puede representar este dato como el factor de ocupación de los nodos ρ, tal y como se explicó en el Capı́tulo 2.3, con lo que se puede indicar si es una hora con mucho tráfico o con tráfico menos congestionado. Se puede calcular la tasa de llegadas de los paquetes, o lo que es lo mismo cada cuánto tiempo llegan paquetes al sistema, utilizando la fórmula descrita en el Capı́tulo 2.3 para un sistema M/M/c, como: λ = ρ ∗ cµ Si se sustituyen los datos en la fórmula anterior se obtiene la tasa de llegadas para un determinado ρ. El tiempo de viaje: este último parámetro tiene relación con el retardo de los enlaces, el cual hay que configurar en el campo correspondiente de la pestaña de Opciones de Simulación de la aplicació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 pequeños cálculos, se obtiene que los tardan 360s desde un nodo al siguiente. De nuevo se debe tener cuidado al introducir este dato en la aplicación, ya que se deben introducir ms, por lo tanto si queremos establecer el retardo a 360s se debe poner 360000 en la casilla correspondiente al retardo de los enlaces. 95 C AP ÍTULO 5. VALIDACI ÓN Figura 5.20: Colas en los nodos con apoyo de anillo interior. Congestión 50 %. Figura 5.21: Colas en los nodos sin apoyo de anillo interior. Congestión 50 %. Una vez que se han establecido los parámetros para la simulación se procede a obtener los resultados gráficos. Se han realizado dos simulaciones para comprobar el funcionamiento. Una con un factor de ocupación del 50 % y otra del 90 %, obtenié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 únicamente. Ambas figuras se han obtenido mediante una simulación de 7 nodos, interconectados como se muestra en la figura 5.19, y con los parámetros que se han explicado anteriormente, además de un factor de ocupación del 50 %. Se puede apreciar cómo sin el apoyo del anillo interno la red está algo más cargada, pero dada la poca carga, apenas es relevante. Pero para la simulación realizada con los mismos parámetros descritos antes, pero con 96 5.5. S IMULACI ÓN DE OTROS ESCENARIOS Figura 5.22: Colas en los nodos con apoyo de anillo interior. Congestión 90 %. Figura 5.23: Colas en los nodos sin apoyo de anillo interior. Congestión 90 %. un factor de ocupación del 90 %, mostrado en las figuras 5.22 y 5.23, se puede apreciar como la red sin el anillo interior está algo más cargada. 97 C AP ÍTULO 5. VALIDACI ÓN 98 Capı́tulo 6 Conclusiones y trabajo futuro En la primera parte del capı́tulo se revisará el trabajo que se ha realizado y en la segunda se expondrán posibles mejoras para ampliar la aplicación. 6.1. 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 diseñó y desarrolló una aplicación con la que, a partir de una topologı́a de red, descrita en formato XML, se generasen las diferentes topologı́as básicas equivalentes y se pudiesen configurar de una manera fácil e intuitiva los diferentes parámetros de simulación. Una vez realizada la simulación, con un simulador bien conocido como es NS-2, se construirı́an los diferentes informes grá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 compilación del módulo de OBS supuestamente integrado en NS-2, lo que más tarde se comprobó que no era ası́, por lo que se tuvo que buscar posibles soluciones. Para ello, se intentó compilar el módulo original OWns, del cual procede la versión del actual módulo de OBS, pero no fue una solución correcta. Al final, se consiguió encontrar las modificaciones pertinentes que habı́a que hacer a los ficheros del módulo [21] [22] para su posterior compilación e integración. Dichos cambios están descritos en el Apéndice D y los pasos para poder compilar todo el simulador se encuentran en el Apéndice C. 99 C AP ÍTULO 6. C ONCLUSIONES Y TRABAJO FUTURO Además, se pueden sacar las siguientes conclusiones del trabajo realizado: Se ha desarrollado un proyecto de código abierto, por lo cual, cualquier persona puede modificar o ampliar funcionalidades de la aplicación de forma modular y escalable. Para poder ejecutar la aplicación sólo se necesita un equipo con Linux y la instalación del simulador NS-2 con el módulo para OBS, lo cual es bastante sencillo si se siguen las instrucciones descritas en el Manual de instalación en el Apéndice C. La aplicación permite la simulació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 través de los resultados obtenidos de la simulación, mediante gráficas que ilustran sus prestaciones: bloqueos, retardos, dimensión de colas y tráfico procesado. Uno de los enfoques para la aplicación, es que sirviese de ayuda para la docencia, por lo que posibilita a usuarios no familiarizados con NS-2 la realización de simulaciones de redes que de otra manera deberı́an realizar en lı́nea de comandos. Pero sin duda, la conclusión más importante, es que la piedra angular del proyecto reside en el fichero esqueleto, donde se encuentran los parámetros que va a utilizar la simulación y no se pueden modificar desde la aplicación gráfica. Además, servirá para generar las topologı́as en NS para su simulación, a partir de las cuales, se obtendrán los ficheros de trazas para poder mostrar de manera gráfica los resultados obtenidos y, como se dijo, facilitar el estudio comparativo de las topologı́as de red. 6.2. Trabajo futuro Gracias a que es una aplicación de código abierto, es posible la ampliación de funcionalidades, ası́ como la modificació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 realización más factible. 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 añadir más tipos de tráfico 100 6.2. T RABAJO FUTURO para enviar entre nodos. Esto darı́a mucha más flexibilidad a la aplicación, ya que el número de posibilidades de simulación crecerı́a desmesuradamente. Para realizarlo, bastarı́a con modificar el fichero esqueleto, añadiendo los parámetros de los nodos o del tráfico, y mostrándolos en el interfaz para su posible modificación. Una buena lı́nea de futuro serı́a añadir más parámetros para configurar desde el entorno gráfico, ofreciendo la posibilidad a un usuario avanzado, que sea capaz de modificar el esqueleto, de no tener que molestarse en cambiar los parámetros en el propio fichero, si no que serı́a la propia aplicación la encargada de hacerlo. Para realizarlo, tan sólo habrı́a que introducir más marcas en el fichero y posteriormente, mostrar los campos correspondientes en la aplicación, para permitir la modificació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 aplicación para establecer un retardo de enlace en funció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 simulación, calcular el retardo que tendrı́a y ponerlo en la declaración. Las redes permiten un estudio muy amplio de sus prestaciones, y los resultados mostrados por la aplicación pueden no ser suficientes, por lo que en una lı́nea de trabajo futuro, se podrı́an añadir más gráficas para un estudio má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 gráficas acordes. Como no todo el mundo utiliza sistemas Linux, se podrı́a ampliar su uso a otros sistemas operativos. Tan sólo habrı́a que modificar las rutas de acceso a los ficheros en función del sistema anfitrión, ya que como la aplicación es Java, que es multiplataforma, la ejecución de la aplicació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 qué simulador se desea utilizar, como por ejemplo OMNeT++ o NS-3 ampliando la compatibilidad del Generador de ficheros de simulación. Para esta lı́nea habrı́a que tener varios ficheros esqueleto, uno por cada simulador disponible en la aplicación, ya que al estar escritos en lenguajes diferentes, la compatibilidad entre ellos es nula. 101 C AP ÍTULO 6. C ONCLUSIONES Y TRABAJO FUTURO Otra posible ampliación es la generación de topologı́as sin necesidad de parsear ningún fichero, tan sólo introduciendo en la aplicación el nú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 número de nodos y los enlaces entre ellos, u ofrecer la posibilidad de arrastrar nodos a una pantalla y unirlos mediante flechas. 102 Bibliografı́a [1] M. Maier, Optical switching networks. Cambridge Univ Pr, 2008. ISBN 978-0-52186800-6. [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, 1999. ISSN 0926-6801. [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. 16–23, 2004. ISSN 0018-9529. [4] T. Battestilli and H. Perros, “An introduction to optical burst switching,” Communications Magazine, IEEE, vol. 41, no. 8, pp. S10–S15, 2003. ISSN 0163-6804. [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/, 1997. [En lı́nea; acceso el 25-Mayo-2011]. [7] U. of California-Berkeley, “The Network Simulator - ns-2.” http://www.isi.edu/ nsnam/ns/, 2000. [En lı́nea; acceso el 18-Mayo-2011]. [8] I. Martı́nez-Yelmo, “OBS-WLAN Simulator based on OWNs and NS 2.28.” http:// e-archivo.uc3m.es/handle/10016/7952, 2007. [En lı́nea; acceso el 31-Mayo-2011]. [9] U. of California-Berkeley, “The ns-3 network simulator.” http://www.nsnam.org/, 2006. [En lı́nea; acceso el 18-Mayo-2011]. [10] U. of California-Berkeley, “OMNeT++ Network Simulation Framework.” http://www. omnetpp.org/, 2003. [En lı́nea; acceso el 27-Mayo-2011]. 103 B IBLIOGRAF ÍA [11] I. O. Technologies, “Network Modeling — Network Simulation.” http://www.opnet. com/solutions/network_rd/modeler.html, 2007. [En lı́nea; acceso el 27-Mayo2011]. [12] T. L. Faubel, A. F. Zaragoza, J. M. Dı́az, O. Ferrer, and F. A. Candelas, “KivaNS.” http://www.aurova.ua.es/kiva/, 2009. [En lı́nea; acceso el 18-Mayo-2011]. [13] T. University of Western Australia, “The cnet network simulator.” http://www.csse. uwa.edu.au/cnet/, 2003. [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, 1987. ISBN 0-1320-09161. [15] W. Stallings, Data and computer communications. Pearson/Prentice Hall, 2009. ISBN 978-0-135-07139-7. [16] M. ALZATE and A. Monroy, “Introducción al tráfico autosimilar en redes de comunicaciones,” Revista de Ingenierı́a Universidad Distrital, 2001. ISSN 0123-921X. [17] P. P. de Pesteny, “The Hurst Exponent and Technical Analysis.” http://www. optimaltrader.net/hurst_exponent.htm, 2008. [En lı́nea; acceso el 5-Julio-2011]. [18] U. de Barcelona, “La distribución Gamma.” http://www.ub.edu/stat/ GrupsInnovacio/Statmedia/demo/Temas/Capitulo4/B0C4m1t7.htm, 2009. [En lı́nea; acceso el 5-Julio-2011]. [19] U. de Valencia, “DISTRIBUCION BINOMIAL NEGATIVA.” http://www.uv.es/ ceaces/base/modelos%20de%20probabilidad/binegativa.htm, 2009. [En lı́nea; acceso el 5-Julio-2011]. [20] Zuse-Institute Berlin, “SNDlib.” http://sndlib.zib.de/home.action, 2006. [En lı́nea; acceso el 31-Mayo-2011]. [21] J. Study, “Ubuntu 8.04 Study Notes (4)-NS2 installation.” http://hi.baidu.com/ jerry_916/blog/item/e0e7085516213d51d009065b.html, 2009. [En lı́nea; acceso el 13-Junio-2011]. [22] F. M. Heart, “NS2 learning (1)-ns2.29 installation.” http://hi.baidu.com/dazzae/ blog/item/ffcfa4fac9ba2c15a9d31153.html, 2010. [En lı́nea; acceso el 13-Junio2011]. 104 B IBLIOGRAF ÍA [23] SNDlib, “nobel-us.” http://sndlib.zib.de/coredata.download.action? objectName=nobel-us&format=xml&objectType=network, 2006. [En lı́nea; acceso el 5-Julio-2011]. [24] SNDlib, “nobel-eu.” http://sndlib.zib.de/coredata.download.action? objectName=nobel-eu&format=xml&objectType=network, 2006. [En lı́nea; acceso el 5-Julio-2011]. [25] SNDlib, “polska.” http://sndlib.zib.de/coredata.download.action?objectName= polska&format=xml&objectType=network, 2006. [En lı́nea; acceso el 5-Julio-2011]. [26] SNDlib, “nobel-germany.” http://sndlib.zib.de/coredata.download.action? objectName=nobel-germany&format=xml&objectType=network, 2006. [En lı́nea; acceso el 5-Julio-2011]. 105 Apéndice A Presupuestos En este capı́tulo se analizará el desarrollo de este proyecto en términos económicos. A.1. Tareas En este apartado se muestra una estimación de la duración de las distintas tareas que se han llevado a cabo para la realizació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 duración en horas estimadas para su realización. A.2. Costes Como se ha visto, la duració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 realizació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 A P ÉNDICE A. P RESUPUESTOS Descripción Investigación, documentación y análisis Despliegue y configuración del entorno de trabajo Diseño de la aplicación Integración del módulo de OBS en NS-2 Desarrollo del parser Desarrollo de la aplicación Desarrollo de las gráficas con los resultados Integración del sistema completo Realización de pruebas Redacción de la memoria Nú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: Duración estimada de las tareas hora. El jefe de proyecto será la tutor del mismo. Cargo Analista Diseñador Gestión de calidad y pruebas Jefe de proyecto Programador Coste (por hora) 35,00C 40,00C 35,00C 45,00C 25,00C Tabla A.2: Salarios de especialistas Si se aplican estos costes al número de horas dedicado por cada especialista en función de las fases de diseño y las tareas encomendadas, el resultado se puede ver en la tabla A.3. El coste del personal asciende a 28.850 C. A.2.2. Material En este apartado se detalla el coste de los materiales empleados durante la realización del proyecto. Estos costes se pueden dividir en equipo y licencias. 108 Actividad Investigación, documentación y análisis Despliegue y configuración del entorno de trabajo Diseño de la aplicación Integración del módulo de OBS Desarrollo del parser Desarrollo de la aplicación Desarrollo de las gráficas Integración Pruebas Redacción de la memoria Horas totales Costes 20 50 1.750 C 10 20 900C Tabla A.3: Coste del personal Analista 30 Jefe de proyecto 10 30 160 6.400 C 10 40 30 20 30 Diseñador 50 30 80 2.800C Pruebas 60 680 17.000 C 300 40 160 70 20 Programador 20 10 Totales 60 10 30 300 50 200 100 40 50 150 990 28.850C A.2. C OSTES 109 A P ÉNDICE A. P RESUPUESTOS Equipo El equipo utilizado consta de un ordenador personal con monitor de 20”, procesador de dos núcleos y 4GB de memoria RAM. Valorado en 750 C todo el conjunto. Licencias En la tabla A.4 se analiza el coste de las licencias que se han necesitado en la elaboración del proyecto. Concepto Ubuntu Linux Java Netbeans IDE Latex Licencias 1 1 1 1 Total Coste/licencia 0,00C 0,00C 0,00C 0,00C Coste 0,00C 0,00C 0,00C 0,00C 0,00C Tabla A.4: Coste de licencias Es coste total en licencias es de 0,00 C. 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 duró el proyecto. Concepto Alquiler del local Luz y agua Servicio de limpieza Teléfono fijo y conexión a internet Total Tabla A.5: Costes indirectos 110 Coste 1.800,00 C 420,00C 360,00C 120,00C 2.700,00 C A.3. R ESUMEN Los gastos ascienden a 2.700 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 32.300,00 C, tal y como se muestra en la tabla A.6. Concepto Mano de obra Equipo Licencias Costes indirectos Total Cantidad 28.850,00C 750,00C 0,00C 2.700,00 C 32.300,00 C Tabla A.6: Costes indirectos Esta cantidad no tiene en cuenta ni el análisis del riesgo ni los impuestos. 111 A P ÉNDICE A. P RESUPUESTOS 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 32.300,00C 6.460,00C 6.460,00C 45.220,00C 8.139,60C 53.359,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 TRESCIENTOS CINCUENTA Y NUEVE CON SESENTA euros. 112 Apéndice B Manual de usuario La aplicación pretende servir de ayuda a la hora de simular, comparar y estudiar los resultados de diferentes topologı́as mediante la simulació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 configuración de NS, simular tantas veces como se necesite para poder sacar resultados estadı́sticos. Además, la propia aplicación ofrece al usuario la posibilidad de analizar topologı́as en anillo, malla o estrella de prestaciones similares, utilizando los mismos parámetros para cada una de ellas, y una vez terminada la simulación consultar gráficas para ver el rendimiento de cada una de las mismas. B.1. Descripción La aplicación se divide en varias pestañas: Configuración: configuración de rutas y ficheros. Opciones de simulación: opciones ha introducir en la simulación. Esuqema de la Red: esquema dibujado de la red. Demandas de tráfico: tabla con las demandas de tráfico. Enlaces entre nodos: tabla con los enlaces entre nodos. Gráficas de resultados: gráficas para poder analizar los resultados. 113 A P ÉNDICE B. M ANUAL DE USUARIO Figura B.1: Pantalla de Configuración B.1.1. Pantalla Configuración En esta pantalla, figura B.1, se configurará las rutas de los ficheros a utilizar y el número de simulaciones a realizar. Para saber el número de simulaciones a realizar hay que tener en cuenta el funcionamiento interno de la aplicación. Se van a simular 4 topologı́as diferentes, todas con el mismo tráfico, para poder compararlas eficientemente. Por cada simulació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 simulació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 Apéndice F, se puede ver más en detalle cómo es la estructura del fichero. Si se introduce un fichero que no sigue este tipo de formato, no se realizará bien el parseo del mismo, por lo que no se obtendrán los resultados requeridos. La aplicación no se encarga de comprobar que el formato del fichero es correcto. 114 B.1. D ESCRIPCI ÓN Archivo esqueleto de NS: en este fichero se configura toda la simulación del NS a excepción de ciertos parámetros. Para poder realizar la configuración que quiere el usuario, debe haber ciertos flags dentro del fichero que actuarán como marcadores para que la aplicació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 corresponderá a la configuración del parámetro correspondiente. Estos flags son, por orden de aparición en el fichero: • ##EDGE COUNT##: el número de nodos edge de la red. Su número será igual al número de nodos parseados del fichero SNDlib. • ##CORE COUNT##: el número de nodos core de la red. Igual que los nodos edge, serán el mismo nú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 será el mismo tanto entre un edge y su core, como entre cores. • ##TOTAL CHANNELS##: el número total de canales por cada nodo, contando con los canales de datos y con los canales de control. • ##CONTROL CHANNELS##: el número de canales para el intercambio de mensajes de control en cada nodo. • ##DATA CHANNELS##: el número de canales para el intercambio de datos en cada nodo. • ##TOPOLOGIA JERARQUICA##: la configuración para hacer efectivo el direccionamiento jerárquico. • ##NODOS##: la declaración de los nodos. Primero se declaran los edge y después los core. • ##ENLACES##: la declaración de los enlaces. Primero se declaran los enlaces entre edge-core y después entre los core, siguiendo con la configuración de los enlaces requerida por el usuario, ya sea la misma que está parseada u otra diferente de las ofertadas. • ##UDP SIZE##: tamaño del paquete de UDP. • ##BATCHSIZE##: en caso de que estemos utilizando tráfico SelfSimilar, éste será el tamaño de los paquetes. 115 A P ÉNDICE B. M ANUAL DE USUARIO • ##CBR SIZE##: cuando se utilice el tráfico CBR, el tamaño de los paquetes será el que se configure a continuación de este flag. • ##EXPO SIZE##: cuando se seleccione el tráfico Exponential, este flag será el predecesor del tamaño de los paquetes. • ##DEMANDAS##: la declaración del trá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 guardarán todos los ficheros de la simulación (topologı́as, trazas y ficheros de NAM), los datos analizados para realizar las gráficas y las gráficas exportadas a fichero de texto para su posterior generación en otras plataformas si se desea. Instalación de NS: esta carpeta es donde se encuentra la instalación de NS, se pueden tener varias versiones del simulador instaladas, la versión que se utilizará es la seleccionada en este campo. Aún ası́, se recomienda tener como instalación predeterminada la utilizada por la aplicación. Número de simulaciones: es el número de simulaciones que se van a realizar. Como ya se ha comentado, el total de simulaciones será el número introducido por el usuario por 4 topologı́as en cada una de esas simulaciones. Tiempo de simulació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 añade un segundo al tiempo de finalización de la ráfaga de tráfico más tardı́a, de é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 lógica, ya que las topologı́as de una misma simulación tienen los mismos tiempos de ráfagas de tráfico. Hay que señalar, que los campos para introducir los ficheros y carpetas requeridos para la simulación, siendo la primera vez que se ejecuta la aplicación, aparecerán en blanco, pero una vez se realice una simulación, las siguientes veces aparecerán los datos de la última simulación. Esto es gracias a que cuando se pulsa el botón Simulación, se crea un fichero oculto, llamado .lastConf, que se almacena en la misma ruta donde se encuentra la aplicación. Se procede a explicar los botones disponibles en esta pantalla: 116 B.1. D ESCRIPCI ÓN Botones de Examinar y Guardar: evidentemente, estos botones abrirán un navegador de archivos para poder localizar y seleccionar los ficheros y carpetas que se requieren para la simulación, explicados más arriba. Parsear fichero SNDlib: con este botón se parsea el fichero XML con la declaración de los nodos, los enlaces y las demandas de tráfico. Como ya se dijo, éste fichero debe tener una estructura determinada para poder realizar bien el parseo. Hasta que que se ha parseado el fichero, la aplicación no deja hacer nada más, ya que antes de parsear no se tiene ningún dato de la red a simular. Una vez se tiene todo el esquema de la red almacenado, se habilitan el resto de pestañas y el botón para generar los ficheros para simular en el NS. Generar topologı́a NS: pulsando este botón se generan todos los ficheros para simular en NS. El lugar donde se crearán será la carpeta elegida como Carpeta de trabajo. Los ficheros tendrán un formato como topologyX-Y.tcl, donde X es el número de la simulación (empezando en 0) e Y es el nú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 simulación antes de generar los ficheros de NS, una vez generados, si se cambia algún parámetro, se debe volver a generar los ficheros (pulsar el botón) para que los cambios se apliquen. Es posible editar los ficheros una vez creados, pero corre a cuenta del usuario, y lo más seguro es que los datos de las gráficas a analizar no sean los deseados si las opciones en las simulaciones no son las mismas. Aún ası́, no se puede cambiar el nombre del fichero ya que la aplicación al ejecutar NS, llama a esos ficheros, con ese nombre. Cualquier otro nombre hará que la ejecución no sea correcta. Arrancar simulación: al pulsar este botón se arranca la simulación entera, es decir, se simulará de manera continuada todos los ficheros, de todas las topologı́as, de todas las tandas de simulación requeridas por el usuario. Hasta que no se termine de simular todos esos ficheros, no se empezará a analizar los ficheros de trazas. Mientras está simulando, podremos ver una ventana similar a la figura B.2. Una vez terminadas todas las simulaciones, la aplicación comenzará automáticamente a analizar los diferentes ficheros de trazas generados por NS. Mientras está analizando, se podrá 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 A P ÉNDICE B. M ANUAL DE USUARIO Figura B.2: Simulación en curso Figura B.3: Analizando y generando gráficas analizar, es decir, que si hemos decidido hacer 4 simulaciones, el 100 % de los ficheros a analizar será 16, 4 simulaciones por 4 topologı́as. La segunda barra de progreso se refiere a cada fichero por separado, contando el número de trazas que se han analizado respecto del total en el fichero que estamos analizando en ese momento. Mientras se está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 gráfica para cada una de las simulaciones y cada una de las topologı́as. Hay que apuntar que los datos de las gráficas se crean usando la media de los resultados de todas las simulaciones, por ejemplo, se hacen 4 simulaciones, y en la gráfica del Porcentaje de trá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 será 20,5 %, y se tendrá una desviación tı́pica representada al mismo tiempo. De esta manera, si se observa en una desviación tı́pica muy grande, se puede consultar los datos sacados para ver qué simulación es la que ha provocado esos puntos atı́picos que han hecho que la media se desvı́e tanto. Hasta que el análisis no termine, no se habilitará la pestaña de las gráficas, al igual que el resto de botones para realizar más simulaciones. Una vez las gráficas se hayan mostrado, la aplicación cambiará automáticamente de pestaña. 118 B.1. D ESCRIPCI ÓN Figura B.4: Topologı́a en anillo recién abierta Además, como ya se señaló, cuando se pulsa este botón, se genera el fichero .lastConf, que servirá para rellenar los campos donde se introducen los ficheros y carpetas la próxima vez que se ejecute la aplicación. Ejecutar NAM: una vez terminado todo el proceso de simulación y análisis de trazas, se habilitará este botón para ejecutar el NAM y poder visualizar la simulació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 botón ‘‘RE-LAYOUT’’. Por ejemplo, para la simulación 0 de la topologı́a en anillo, se abrirá el fichero topology0-1.nam para obtener una ventana como la figura B.4. Pulsando el botón ‘‘RE-LAYOUT’’, las veces necesarias, se puede reestructurar como se muestra en las figuras B.5 y B.6, para una mejor visualización. B.1.2. Pantalla Opciones de Simulación En esta pantalla, figura B.7, se pueden configurar algunos de los parámetros de las simulaciones. Hay disponibles varios cuadros para rellenar y configurar. Algunos son bastante intui- 119 A P ÉNDICE B. M ANUAL DE USUARIO Figura B.5: Topologı́a en anillo Figura B.6: Topologı́a en anillo estructurada 120 B.1. D ESCRIPCI ÓN Figura B.7: Pantalla Opciones Simulación tivos, pero otros no lo son tanto. Se procede a explicarlos un poco más detalladamente. Tipo de tráfico: define el tipo de tráfico que se va a utilizar, dándo a elegir entre SelfSimilar, CBR o Exponential. Según el tipo de tráfico elegido, la declaración de dicho tráfico en el fichero TCL será de una manera o de otra. Opciones Generales: se pueden configurar varios parámetros de la simulación que no se ven influidos por el tipo de tráfico que hayamos elegido. Básicamente son parámetros de configuració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 éstos datos. Hay que tener en cuenta que los datos serán iguales para todos los nodos y enlaces. • Retardo enlaces: es el retardo de los enlaces. Por defecto está configurado a 1ms. • Canales datos: son los canales de datos de los que disponen los nodos. 121 A P ÉNDICE B. M ANUAL DE USUARIO • Canales control: son los canales de control que disponen los nodos. Habitualmente, el número de canales de control es menor que el de datos. • Tamaño UDP: éste es el único parámetro de tráfico que es común a los tres tipos. Esto se debe a que todos los tráficos posibles de la simulación funcionan sobre el protocolo UDP debido a su sencillez. Opciones SelfSimilar: en este campo se configura el tamaño de los paquetes del tráfico SelfSimilar. Sólo se toma en cuenta cuando se selecciona el tráfico SelfSimilar. Opciones CBR: se configura el tamaño de los paquetes del tráfico CBR, siempre y cuando se haya seleccionado el tráfico CBR. Opciones Exponential: cuando se selecciona el tráfico Exponential, se utiliza para configurar el tamaño de los paquetes de dicho tráfico. Tiempo de Simulación: esta opción se utiliza para hacer simulaciones más cortas y rápidas. Se puede elegir “truncar” el tiempo de simulación a un tiempo elegido o se puede dejar que simule en su totalidad. Si se elige un tiempo menor del calculado, el tráfico que deberı́a enviarse a partir de ese tiempo no será simulado. Enlaces: se puede decir a la aplicación que ponga todos los enlaces iguales,o que deje los que haya recolectado del fichero. Como los enlaces originales son válidos só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 ésta manera ya que los enlaces son Dúplex, en caso contrario, habrı́a que calcular por separado los enlaces como origen y como destino para cada nodo y despué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 número de enlaces que tiene el nodo en la topologı́a original. 122 B.1. D ESCRIPCI ÓN • Estrella: para la estrella, primero de todo se ha añadido un nodo central, a modo de concentrador de tráfico. Se decidió hacerlo de ésta manera para evitar que se eligiese un nodo al azar y seleccionar uno malo para realizar éstas funciones. Los enlaces de é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 tráfico para todas Si se quiere modificar una sóla, debemos ir a la pestaña correspondiente de las demandas. Prob. Bloqueo: se configurar la probabilidad de bloqueo en los enlaces entre un 1 para evitar bloqueo, pero se puede edge y su core. Inicialmente se selecciona N−1 ajustar al porcentaje deseado. B.1.3. Pantalla Esquema de la Red En esta pantalla se muestra un dibujo esquemá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 geográ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 mostrará la figura B.8. B.1.4. Pantalla Demandas de Tráfico En esta pantalla, figura B.9, se muestra una tabla con todas las demandas de tráfico entre los nodos. El formato de la tabla es el siguiente: ID: es un identificador único para cada demanda. Source: es el ID del nodo que manda el tráfico. 123 A P ÉNDICE B. M ANUAL DE USUARIO Figura B.8: Pantalla Esquema de la Red Figura B.9: Pantalla Demandas de Tráfico 124 B.1. D ESCRIPCI ÓN Figura B.10: Modificación de la primera demanda de tráfico Target: es el ID del nodo que recibe el tráfico. Value(Mb): es la cantidad de tráfico, en media, medido en Mb, que se mandará desde el origen al destino durante la simulación. Al mismo tiempo, se ofrece al usuario la posibilidad de modificar cada una de estas demandas de trá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 botón Modificar. Por defecto, aunque no se vé reflejado, está seleccionada la primera demanda de la lista, ası́ que si nada más abrir la pestaña se modifica una demanda sin haber seleccionado nada, se modificará 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 A P ÉNDICE B. M ANUAL DE USUARIO Figura B.11: Pantalla de Enlaces entre nodos La tabla tiene el formato siguiente: ID: es un identificador del enclace, ú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 Dúplex, por lo que en realidad no hay un nodo origen y otro destino para el enlace, los dos extremos actúan como origen y destino al mismo tiempo, depende de la demanda de tráfico. Gracias al desplegable, se puede seleccionar cada una de las topologı́as para ver sus enlaces. Además, se ofrece al usuario la posibilidad de modificar los enlaces. Pulsando cada una de las opciones, se podrá añadir capacidad a un enlace seleccionado, a todos los enlaces o a los que estén con capacidad 0Mb/s. 126 B.1. D ESCRIPCI ÓN Figura B.12: Diálogo para añadir capacidad Seleccionado: marcando esta opción y pulsando el botón Añadir capacidad, se mostrará un diálogo como el de la figura B.12. En él se muestran los datos del enlace seleccionado y más abajo se le puede añadir capacidad. El propio formato SNDlib da la opción de añadirle módulos de capacidad al enlace, por lo que se reaprovecha esa capacidad. Para ello, se muestra un desplegable con los módulos que se pueden añadir, tan sólo se debe seleccionar qué tipo queremos añadir, seleccionar cuántos módulos se quieren añadir y pulsar el botón Añadir. Enseguida se modificarán los datos del enlace en ese mismo diálogo. También se le puede quitar módulos a la capacidad total, tan sólo es necesario decirle que el número de módulos a añadir es negativo, esto es, poniendo un número negativo en el contador. Ya sólo resta pulsar Aceptar para volver a la ventana con los enlaces, y el modificado aparecerá reflejado en la tabla. Todos: si se selecciona esta opción y se pulsa Añadir capacidad, se añadirá un módulo, del valor más bajo que nos ofrezca SNDlib, a cada uno de los enlaces. Actuales a 0: si se marca esta opción y se pulsa Añadir capacidad, se añadirá un módulo, del valor más bajo ofrecido por SNDlib, a cada enlace que actualmente tenga una capacidad de 0Mb/s. Como bien se muestra en la pestaña, los enlaces con capacidad 0Mb/s no se introducen en el fichero TCL, esto se debe a que NS no calcula rutas en función de la capacidad del enlace, tan sólo en función del número de saltos. De esta manera, si en el fichero TCL se introduce un enlace con capacidad 0Mb/s, NS intentará mandar tráfico por ese enlace, y no por ningún otro. 127 A P ÉNDICE B. M ANUAL DE USUARIO Hay que señalar que añadir capacidad a un enlace original, no hace que se modifiquen los enlaces del resto de topologı́as, como se explicaba en la descripción de la pantalla de Opciones de la Simulación. B.1.6. Pantalla de Gráficas de resultados En esta pantalla se muestran los resultados, obtenidos al realizar la simulación, en forma de grá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 gráficas, como un grupo de gráficas para analizar lo ocurrido durante la simulación. Para un mejor estudio de dichas grá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 ratón y arrastrar el cursor para seleccionar la zona a ampliar. Miestra se arrastra el cursor, se sombreará dicha zona. También se pueden guardar las gráficas a un fichero .png gracias a la librerı́a utilizada. Tan solo es necesario pulsar el botón derecho del ratón sobre la gráfica para ver diferentes opciones. Las gráficas están divididas en tres grupos: Gráficas de tráfico: muestra una pantalla como de la de la figura B.13. En ella, se encuentran cuatro gráficas analizando el porcentaje de trá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 algún nodo, incluso si ya se ha contabilizado en otro nodo diferente. • Porcentaje de tráfico cursado por nodo respecto al enviado: se muestra el porcentaje de tráfico cursado por cada nodo respecto del total enviado. El tráfico total enviado es la suma de tráfico que envı́an los edge, tan sólo se contabiliza una vez, en el momento en que se inyecta en la red. 128 B.1. D ESCRIPCI ÓN Figura B.13: Gráficas de Tráfico • Porcentaje de tráfico cursado por cada nodo: muestra el porcentaje de tráfico cursado por cada nodo respecto del total. Al igual que con la primera gráfica, el tráfico total es la suma de todos los paquetes que circulan por la red, contabilizándolos cada vez que son procesados por un nodo. • Porcentaje de tráfico enviado por cada nodo: ésta última gráfica muestra el porcentaje de tráfico que inyecta cada nodo en la red, respecto al total inyectado. Como ya dijimos en la segunda gráfica, el tráfico total se calcula sumando el tráfico una sóla vez, cuando se inyecta en la red. Como se puede ver en éstas gráficas, la desviación tı́pica que tienen las medias puede llegar a ser muy grande, esto es debido a que la cantidad de tráfico que circula por la red varı́a con cada simulación, ya que las demandas de tráfico son aleatorias y un nodo no siempre envı́a tráfico la misma cantidad de tiempo. Por eso se incluye la opción de realizar varias simulaciones, ya que cuantas más simulaciones, la media de tráfico enviado será más parecida a la que se tiene en la tabla de las demandas de tráfico. Como se explicó, los datos de cada simulación por separado se almacenan en la carpeta datos, ubicada dentro de la carpeta de 129 A P ÉNDICE B. M ANUAL DE USUARIO Figura B.14: Gráficas de Colas trabajo. Gráficas de Colas: muestra una pantalla como la figura B.14. En se pueden analizar las colas de trá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 desviació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 precisión del fichero de trazas de NS no va más allá de un 1µs. • Número de paquetes en cola cada 10ms: muestra un nú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. Grá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. Éstas gráficas son algo diferentes, ya que no son gráficas de barras o de series. En cambio, 130 B.1. D ESCRIPCI ÓN Figura B.15: Gráficas de Retardo son gráficas con códigos de colores, más concretamente, con escala de grises. Para poder analizarla, se debe mirar las ordenadas y las abscisas de la grá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 ésta tabla varı́a según la media máxima calculada. • Retardo medio entre nodos[µs](desviación): muestra la desviación tı́pica de la media calculada. Se mide en µs debido a que su precisión es muy alta y al medirla en ms se obtenı́an todos los valores negro, es decir muy próximos a 0. Al igual que la gráfica anterior, la escala de ésta gráfica varı́a según la desviación tı́pica má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. Ésta tabla es útil, ya que si encontramos una media muy alta, se puede 131 A P ÉNDICE B. M ANUAL DE USUARIO mirar y si el número de nodos intermedios es alto, tendrı́a lógica que el retardo entre extremos sea alto. La escala de ésta gráfica es diferente de las anteriores, ya que el máximo de ésta es el número de nodos. En el peor de los casos, un paquete tiene que pasar por todos los nodos para llegar a su destino. Además de mostrar las gráficas, también se dispone del botón Exportar datos de las gráficas, que como su nombre indica, realiza la función de exportar los datos de las gráficas a ficheros de texto, almacenados en la carpeta graficas, dentro de nuestra carpeta de tranajo. De ésta manera se pueden exportar a otras plataformas capaces de representar gráficas, siempre y cuando se procesen los ficheros. El nombre de los ficheros será el de las iniciales de la gráfica, seguido por un número de 0 a 3 que indica la topologı́a. Por ejemplo, el fichero PPPpN-0, son los datos de la gráfica de Porcentaje de Paquetes Procesados por Nodo(PPPpN) de la topolog´ia original(0). El formato de los ficheros varı́a según la gráfica exportada. Común a todos: todos los ficheros comienza con el nombre de la gráfica, la topologı́a que representan y la fecha en la que se han exportado los datos. La fecha está en formato AAAAMMDD HHMMSS. Gráfica porcentaje paquetes procesados 0-20110517 161524 Gráfica de Porcenataje de Paquetes Procesados por Nodo(PPPpN): tiene el siguiente formato. N1 12.124559116713902 3.2297212880249955 0.7798467029437938 0.6608122890841635 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 desviación tı́pica de los paquetes procesados, la cuarta, la media de los paquetes tirados y la quinta, la desviación de los paquetes tirados. Gráfica de Porcentaje de Tráfico Ponderado por Nodo(PTPpN): sigue el formato siguiente. N1 64.29999313160198 17.996817689043237 Al igual que la grá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 tráfico ponderado y la tercera, la desviación tı́pica. Gráfica de Porcentaje de Tráfico por Nodo(PTpN): tiene el siguiente formato. 132 B.1. D ESCRIPCI ÓN N1 12.587021390649825 3.5111132455082426 El formato es igual que la anterior, ya que ambas dos son gráficas de barras. La primera columna es el nombre del nodo, la segunda, es la media del tráfico y la tercera, la desviación tı́pica. Gráfica de Porcentaje de Tráfico Enviado por Nodo(PTEpN): N1 14.533532525449436 10.56430832790935 Igual que todas las grá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 tráfico enviado y la tercera, la desviación tı́pica. Gráfica de Tiempo de Espera en Cola(TEC): N1 0.5000000000000977 0.5000000000001109 De nuevo, al tratarse de una gráfica de barras, tiene el mismo formato que las anteriores. Gráfica de Número de Paquetes en Cola cada 10ms(NPCms): 0.487 1.5 1.6583123951777 ...0.25 0.4330127018922193 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 información de un nodo. Gráfica de Medias de Retardo entre Nodos(MRN): este fichero representa una tabla. Un ejemplo de una fila es. 1.0 0.0 4.002069767955361 ...4.002080835368733 4.0020769886363645 En este caso, la primera columna representa el número del nodo, no su nombre, y las columnas sucesivas son el retardo medio entre ese nodo y los demás. Hay que recordar que los datos se miden en ms. Gráfica de Desviación de Retardo entre Nodos(DRN): al igual que el anterior, este fichero representa una tabla. 1.0 0.0 2.0839079991625784 ...2.097003516166951 2.091093247586895 133 A P ÉNDICE B. M ANUAL DE USUARIO El formato es igual que el anterior, pero en este caso se tienen las desviaciones tı́picas, medidas en µs. Gráfica de Nodos Intermedios de Retardo entre Nodos(NIRN): al ser el mismo tipo de gráfica que las anteriores, este fichero representa la tabla. 1.0 0.0 3.0 3.0 3.0 4.0 2.0 2.0 2.0 3.0 3.0 4.0 4.0 3.0 3.0 3.0 De nuevo, el formato es igual que los anteriores, la primera columna es el número de nodo, y las sucesivas son los nodos intermedios entre éste y los demás. 134 Apéndice C Manual de instalación Para poder ejecutar la aplicación correctamente, se debe instalar el simulador NS, más concretamente la versión 2.28 y añadir el módulo de OBS modificado para poder realizar las simulaciones correctamente. Existe una versión del simulador con el módulo ya instalado, listo para compilar en nuestro propio sistema [8], previa modificación de los ficheros a compilar. Además, se recomienda tener instalado NAM (Network Animator) en su versión 1.15 ya que es una ayuda visual a la simulación. C.1. Instalación NS El sistema en el que se han instalado todos los requisitos para poder usar la aplicación es una distribución Linux Ubuntu 10.10. 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 versión 4.4 de ambas librerı́as, ya que es la versión probada. sudo apt-get install gcc g++ 3. Se deben añadir dos repositorios nuevos para instalar otcl y tclcl. Dichos repositorios son: deb http://bode.cs.uni-magdeburg.de/ aherms/debian sid ns2 135 A P ÉNDICE C. M ANUAL DE INSTALACI ÓN deb-src http://bode.cs.uni-magdeburg.de/ 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 dónde se encuentra la instalación de tcl con la opción --with-tcl=path. b) Hacer un enlace simbólico para que el script lo encuentre directamente: ln -s /usr/share/tcltk/tcl8.4 /usr/lib/tcl8.4 6. Al igual que con la instalación de tcl, pasa lo mismo con la instalación de tk, por lo que las maneras de solventar el problema son las mismas, tan sólo se deben usar las rutas de tk o la opción de tk: a) Opción --with-tk=path a la hora de ejecutar el .configure b) Enlace simbólico a la ruta de instalación de tk: ln -s /usr/share/tcltk/tk8.4 /usr/lib/tk8.4 7. Para que la compilación del módulo sea correcta, se deben efectuar ciertos cambios en los ficheros de NS [21] [22], detallados en el Apéndice D. 8. Ejecutar el configure para que genere el fichero Makefile para el sistema: ./configure En caso de que no encuentea la instalación de otcl o tclcl, se pueden poner opciones similares a las anteriores para configurar la ruta de é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 él. 136 C.2. I NSTALACI ÓN NAM Figura C.1: NAM C.2. Instalació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 ningún problema para instalarlo en el sistema. No es necesario ningún tipo de configuració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.1. 137 A P ÉNDICE C. M ANUAL DE INSTALACI ÓN 138 Apéndice D Cambios en ficheros para la compilación de NS En este apéndice se detallan los cambios necesarios que hay que realizar en ciertos ficheros para la compilación e integración del módulo de OBS con la instalación de NS-2. A partir de este momento, cada vez que se haga referencia a la ruta de un fichero, será la ruta relativa dentro de la ruta absoluta donde se encuentra la instalación de NS. Cuando se señale que hay que añadir una lı́nea a un fichero, la lı́nea en concreto será la resaltada en negrita, las demás son la referencia para saber dónde se debe añadir. queue/cbq.cc Añadir la lı́nea: #define POWEROFTWO 16 class CBQueue; class CBQClass : public Connector { tora/tora neighbor.h Añadir lı́nea: #define tora neighbor h class toraAgent; 139 A P ÉNDICE D. C AMBIOS EN FICHEROS PARA LA COMPILACI ÓN DE NS enum LinkStatus { dsr/dsragent.cc Añadir las lı́neas: #ifdef NEW SALVAGE LOGIC void XmitFlowFailureCallback(Packet *pkt, void *data); void XmitFailureCallback(Packet *pkt, void *data); diffusion/diffusion.cc Añadir: #include ‘‘routing table.h’’ void XmitFailedCallback(Packet *pkt, void *data); diffusion/omni mcast.cc Añadir: #include ‘‘god.h’’ void OmniMcastXmitFailedCallback(Packet *pkt, void *data); diffusion3/filter core/filter core.hh Añadir: class NeighborEntry; class DiffRoutingAgent; queue/red.cc En la lı́nea 872 cambiar: 140 char wrk[500], *p; por: char wrk[500]; const char *p; queue/rio.cc En la lı́nea 563 cambiar: char wrk[500], *p; por: char wrk[500]; const char *p; queue/pi.cc En la lı́nea 314 cambiar: char wrk[500], *p; por: char wrk[500]; const char *p; queue/vq.cc En la lı́nea 331 cambiar: char wrk[500], *p; por: char wrk[500]; const char *p; queue/rem.cc En la lı́nea 334 cambiar: 141 A P ÉNDICE D. C AMBIOS EN FICHEROS PARA LA COMPILACI ÓN DE NS char wrk[500], *p; por: char wrk[500]; const char *p; queue/gk.cc En la lı́nea 205 cambiar: char wrk[500], *p; por: char wrk[500]; const char *p; obs-0.9a/cpp/integrated agent.h En la lı́nea 92 cambiar: virtual void BurstTimer::expire(Event *e); por: virtual void expire(Event *e); sctp/sctp.h En la lı́nea 630 cambiar: void SctpAgent::DumpSendBuffer(); por: void DumpSendBuffer(); mobile/god.h En las lı́neas 88, 93, 98, 101, eliminar las calificaciones extras. Ejemplo, en la lı́nea 88 cambiar: 142 inline void vector::operator=(const vector a) por: inline void operator=(const vector a) tcp/tcp-sack-rh.cc En la lı́nea 68 cambiar: virtual void SackRHTcpAgent::newack(Packet* pkt); por: virtual void newack(Packet* pkt); pgm/pgm-agent.cc En la lı́nea 278 cambiar: void PgmAgent::trace event(char *evType, double evTime); por: void trace event(char *evType, double evTime); pgm/pgm-sender.cc En la lı́nea 160 cambiar: void PgmSender::trace event(char *evType, double evTime); por: void trace event(char *evType, double evTime); pgm/pgm-receiver.cc En la lı́nea 157 cambiar: void PgmReceiver::trace event(char *evType, double evTime); por: void trace event(char *evType, double evTime); 143 A P ÉNDICE D. C AMBIOS EN FICHEROS PARA LA COMPILACI ÓN DE NS 144 Apéndice E Clases En este Apéndice se describe de manera breve la función de cada una de las clases que intervienen en la aplicación. También se muestra el diagrama relacional de clases E.1. Clases Se pasa a enumerar, brevemente, las clases utilizadas por la aplicación, ası́ como una leve descripción de la funcionalidad de cada una: Demand.java Es la representación en Java de las demandas de tráfico cogidas del fichero XML. Tiene atributos para representar cada uno de los campos leı́dos, y poder acceder a ellos de manera sencilla, algunos de ellos son, la cantidad de tráfico a enviar o el origen y destino de ese tráfico. EsperaGrafica.java Esta clase se encarga de arrancar un hilo, diferente de la ejecución principal, que es el que va leyendo los ficheros de trazas y sacando datos para posteriormente acceder a los métodos para crear las gráficas. EsperaSimulacion.java Se encarga de la ejecución del hilo que ejecuta las simulaciones en ns. Cada vez que arranca una simulación, espera a que termine para arrancar la siguiente, de esta manera, aunque se tarda más tiempo, no saturamos el procesador del sistema. 145 A P ÉNDICE E. C LASES FiltroTCL.java Filtro para que el explorador de archivos sólo muestre los ficheros con extensión .tcl FiltroXML.java Filtro para que el explorador de archivos sólo muestre los ficheros con extensión .xml Interfaz.java Esta clase es la encargada de generar todo el interfaz gráfico, ası́ como implementar la funcionalidad de todos los botones y menús disponibles en la aplicación. También se encarga de tener instancias del resto de clases importantes para poder acceder a ellas siguiendo la filosofı́a de orientación a objetos. Otra funcionalidad es la de gestionar las ventanas adicionales de la aplicación, como los exploradores de archivos o las ventanas de espera mientras se está simulando o analizando los datos. En resumen, es la clase principal de nuestra aplicación, el centro neurálgico. Link.java Representación en Java de los enlaces. Los atributos son los parámetros del enlace, tales como la capacidad del enlace o los nodos extremos. MiTableModel.java Es el modelo en el que se basan las tablas que muestra la aplicación. La diferencia con las tablas por defecto es que en este modelo se pueden seleccionar filas, cosa que en el otro no. NS.java Es la encargada de generar el fichero de simulación de ns a partir de los datos obtenidos del XML, apoyándose en el fichero esqueleto. Se encarga de leer el fichero esqueleto y cuando encuentra las marcas correspondientes va introduciendo los elementos necesarios para la simulación, tales como los nodos, los enlaces y las demandas de tráfico. También se encarga de la generación de los tiempos en los que el tráfico se está enviando. Para ello, se apoya en el paquete Commons-Math, descrito en el Capı́tulo 3, que es capaz de generar números aleatorios siguiendo una distribución exponencial. Es obvio que los tiempos de envı́o de tráfico serán iguales entre las topologı́as de la misma simulación, es decir, si vamos a hacer 5 simulaciones para tener unos datos estadı́sticos aceptables, y tenemos cuatro topologı́as a estudiar, los tiempos de tráfico de la topologı́a en anillo de la simulación 146 E.1. C LASES 1 serán los mismos que los de la topologı́a en malla o en estrella, pero diferentes de las otras simulaciones. Node.java La representación en Java de los nodos de la red corre a cargo de esta red. Cada objeto de esta clase corresponde a un nodo cogido del fichero XML. Sus atributos son las coordenadas geográficas del nodo y su identificador. PanelGraficas.java Se encarga de leer el fichero de trazas generado por la simulación del ns y a la vez que va leyendo va obteniendo datos, además de llevar un recuento de las lı́neas leı́das. Una vez ha terminado de leer todos los ficheros de trazas generados comienza con la generación de las gráficas. Para ello, accede a los ficheros donde se han ido guardando los datos de las simulaciones, calcula los valores medios y las desviaciones tı́picas de esos valores y los introduce en la gráfica correspondiente. Por último, se encarga de mostrar esas gráficas en la aplicación. PanelRed.java El cometido de esta clase es la representación de forma gráfica de la distribución geográfica de la red parseada. Parser.java Como ya explicamos, esta clase es la encargada de leer el fichero XML y traducir todos los elementos de la red a objetos java. También se encarga de transformar la red original en las otras topologı́as siguiendo el proceso explicado anteriormente. Una vez ha cogido todos los elementos de la red, los almacena en un Vector, uno por cada elemento, es decir uno para los nodos, otro para las demandas y otro que contiene un array con los diferentes de las topologı́as. Progreso.java Se encarga de la actualización de las barras de progreso que se muestran con la ventana de espera mientras se están analizando los ficheros de trazas y generando las gráficas de resultados. Para llevar a cabo su cometido, calcula el número de lı́neas del fichero de trazas que se está leyendo y va calculando el porcentaje correspondiente, apoyándose en el recuento que lleva la clase encargada de leer estos ficheros. 147 A P ÉNDICE E. C LASES Trace.java Esta clase representa las trazas que se van leyendo de los ficheros con los resultados generados por ns. No se almacenan de ninguna manera, ya que puede haber ficheros con ocho millones de lı́neas, y es casi imposible almacenar tanta cantidad de objetos, sin hablar del coste computacional que supondrı́a recorrer un Vector de tales dimensiones. En lugar de almacenarlas, lo que hace esta clase es guardarlas temporalmente para su procesado inmediato, lo que consigue que no se sature la memoria y el coste computacional será el mismo. Como se ha visto, la clase más importante es Interfaz.java, que es la encargada de gestionar todo el entorno gráfico. Además, las clases Parser.java y NS.java también son de vital importancia para el desarrollo del proyecto, ya que ellas son las encargadas del parseo del fichero XML y de la generación del fichero para simular, respectivamente. E.2. Diagrama de clases En la figura E.1 podemos ver un diagrama con la relación entre las clases. 148 E.2. D IAGRAMA DE CLASES Figura E.1: Diagrama de clases 149 A P ÉNDICE E. C LASES 150 Apéndice F Ejemplos de ficheros En este capı́tulo se verá una serie de ejemplos de los ficheros utilizados por la aplicación, tales como el XML de donde se saca la red, el fichero que va a simular NS y el fichero de trazas que genera la simulación F.1. Fichero XML de SNDlib Éste es un ejemplo de los ficheros XML que la aplicación es capaz de parsear. Corresponde a la red NFSNET. <?xml version=‘‘1.0’’ encoding=‘‘ISO-8859-1’’?> <network xmlns=‘‘http://sndlib.zib.de/network’’ version=‘‘1.0’’> <networkStructure> <nodes coordinatesType=‘‘geographical’’> <node id=‘‘Palo-Alto’’> <coordinates> <x>-122.07</x> <y>37.25</y> </coordinates> </node> <node id=‘‘San-Diego’’> <coordinates> <x>-117.08</x> <y>32.42</y> 151 A P ÉNDICE F. E JEMPLOS DE FICHEROS </coordinates> </node> .. . </nodes> <links> <link id=‘‘L1’’> <source>Palo-Alto</source> <target>San-Diego</target> <additionalModules> <addModule> <capacity>20.0</capacity> <cost>6590.0</cost> </addModule> <addModule> <capacity>40.0</capacity> <cost>7590.0</cost> </addModule> <addModule> <capacity>60.0</capacity> <cost>14180.0</cost> </addModule> <addModule> <capacity>80.0</capacity> <cost>15180.0</cost> </addModule> <addModule> <capacity>100.0</capacity> <cost>21770.0</cost> </addModule> <addModule> <capacity>120.0</capacity> <cost>22770.0</cost> </addModule> <addModule> 152 F.1. F ICHERO XML DE SND LIB <capacity>140.0</capacity> <cost>29360.0</cost> </addModule> <addModule> <capacity>160.0</capacity> <cost>30360.0</cost> </addModule> <addModule> <capacity>180.0</capacity> <cost>36950.0</cost> </addModule> <addModule> <capacity>200.0</capacity> <cost>37950.0</cost> </addModule> <addModule> <capacity>220.0</capacity> <cost>44540.0</cost> </addModule> <addModule> <capacity>240.0</capacity> <cost>45540.0</cost> </addModule> <addModule> <capacity>260.0</capacity> <cost>52130.0</cost> </addModule> <addModule> <capacity>280.0</capacity> <cost>53130.0</cost> </addModule> <addModule> <capacity>300.0</capacity> <cost>59720.0</cost> </addModule> 153 A P ÉNDICE F. E JEMPLOS DE FICHEROS <addModule> <capacity>320.0</capacity> <cost>60720.0</cost> </addModule> <addModule> <capacity>340.0</capacity> <cost>67310.0</cost> </addModule> <addModule> <capacity>360.0</capacity> <cost>68310.0</cost> </addModule> <addModule> <capacity>380.0</capacity> <cost>74900.0</cost> </addModule> <addModule> <capacity>400.0</capacity> <cost>75900.0</cost> </addModule> <addModule> <capacity>420.0</capacity> <cost>82490.0</cost> </addModule> <addModule> <capacity>440.0</capacity> <cost>83490.0</cost> </addModule> <addModule> <capacity>460.0</capacity> <cost>90080.0</cost> </addModule> <addModule> <capacity>480.0</capacity> <cost>91080.0</cost> 154 F.1. F ICHERO XML DE SND LIB </addModule> <addModule> <capacity>500.0</capacity> <cost>97670.0</cost> </addModule> <addModule> <capacity>520.0</capacity> <cost>98670.0</cost> </addModule> <addModule> <capacity>540.0</capacity> <cost>105260.0</cost> </addModule> <addModule> <capacity>560.0</capacity> <cost>106260.0</cost> </addModule> <addModule> <capacity>580.0</capacity> <cost>112850.0</cost> </addModule> <addModule> <capacity>600.0</capacity> <cost>113850.0</cost> </addModule> <addModule> <capacity>620.0</capacity> <cost>120440.0</cost> </addModule> <addModule> <capacity>640.0</capacity> <cost>121440.0</cost> </addModule> <addModule> <capacity>660.0</capacity> 155 A P ÉNDICE F. E JEMPLOS DE FICHEROS <cost>128030.0</cost> </addModule> <addModule> <capacity>680.0</capacity> <cost>129030.0</cost> </addModule> <addModule> <capacity>700.0</capacity> <cost>135620.0</cost> </addModule> <addModule> <capacity>720.0</capacity> <cost>136620.0</cost> </addModule> <addModule> <capacity>740.0</capacity> <cost>143210.0</cost> </addModule> <addModule> <capacity>760.0</capacity> <cost>144210.0</cost> </addModule> <addModule> <capacity>780.0</capacity> <cost>150800.0</cost> </addModule> <addModule> <capacity>800.0</capacity> <cost>151800.0</cost> </addModule> </additionalModules> </link> .. . </links> 156 F.2. F ICHERO DE TRAZAS </networkStructure> <demands> <demand id=‘‘PaloAltoSanDiego’’> <source>Palo-Alto</source> <target>San-Diego</target> <demandValue>52.0</demandValue> </demand> <demand id=‘‘PaloAltoBoulder’’> <source>Palo-Alto</source> <target>Boulder</target> <demandValue>18.0</demandValue> </demand> .. . </demands> </network> F.2. Fichero de trazas En este apartado se puede ver una parte de ejemplo de un fichero de trazas generado por la simulación en ns. + + + + r + - 0.017818 2 0.017818 2 0.017857 2 0.017857 2 0.018314 2 0.018314 2 0.018353 2 0.018353 2 0.018819 2 0.01882 17 0.01882 17 17 17 17 17 17 17 17 17 17 22 22 IPKT IPKT IPKT IPKT IPKT IPKT IPKT IPKT IPKT IPKT IPKT 64 ------- 1 2.0.0.0 13.0.0.-1 0 73 0 64 ------- 1 2.0.0.0 13.0.0.-1 0 73 0 40064 ------- 2 2.0.0.0 13.0.0.-1 0 74 0 40064 ------- 2 2.0.0.0 13.0.0.-1 0 74 0 64 ------- 1 2.0.0.0 6.0.0.-1 1 85 0 64 ------- 1 2.0.0.0 6.0.0.-1 1 85 0 40064 ------- 2 2.0.0.0 6.0.0.-1 1 86 0 40064 ------- 2 2.0.0.0 6.0.0.-1 1 86 0 64 ------- 1 2.0.0.0 13.0.0.-1 0 73 0 64 ------- 1 2.0.0.0 13.0.0.-1 0 73 0 64 ------- 1 2.0.0.0 13.0.0.-1 0 73 0 157 A P ÉNDICE F. E JEMPLOS DE FICHEROS r + r + r + + r 0.018857 2 17 IPKT 40064 ------- 2 2.0.0.0 13.0.0.-1 0 74 0 0.018857 17 22 IPKT 40064 ------- 2 2.0.0.0 13.0.0.-1 0 74 0 0.018857 17 22 IPKT 40064 ------- 2 2.0.0.0 13.0.0.-1 0 74 0 0.019315 2 17 IPKT 64 ------- 1 2.0.0.0 6.0.0.-1 1 85 0 0.019316 17 22 IPKT 64 ------- 1 2.0.0.0 6.0.0.-1 1 85 0 0.019316 17 22 IPKT 64 ------- 1 2.0.0.0 6.0.0.-1 1 85 0 0.019353 2 17 IPKT 40064 ------- 2 2.0.0.0 6.0.0.-1 1 86 0 0.019353 17 22 IPKT 40064 ------- 2 2.0.0.0 6.0.0.-1 1 86 0 0.019353 17 22 IPKT 40064 ------- 2 2.0.0.0 6.0.0.-1 1 86 0 0.01979 2 17 IPKT 64 ------- 1 2.0.0.0 13.0.0.-1 2 110 0 0.01979 2 17 IPKT 64 ------- 1 2.0.0.0 13.0.0.-1 2 110 0 0.01982 17 22 IPKT 64 ------- 1 2.0.0.0 13.0.0.-1 0 73 0 F.3. Fichero esqueleto En esta sección se muestra un ejemplo de un fichero esqueleto para rellenar con nuestros datos de simulación. set set set set home path [lindex $argv 0] ns path [lindex $argv 1] simulacion [lindex $argv 2] topologia [lindex $argv 3] StatCollector set debug 0 Classifier/BaseClassifier/EdgeClassifier set type 0 Classifier/BaseClassifier/CoreClassifier set type 1 # Per node bhp processing time is 1 micro-second source $ns path/obs-0.9a/tcl/lib/ns-obs-lib-hierarchical.tcl source $ns path/obs-0.9a/tcl/lib/ns-obs-defaults.tcl source $ns path/obs-0.9a/tcl/lib/ns-optic-link.tcl set ns [new Simulator] set nf [open $home path/topology$simulacion-$topologia.nam w] set sc [new StatCollector] 158 F.3. F ICHERO ESQUELETO set tf [open $home path/topology$simulacion-$topologia.tr w] set ndf [open $home path/ndtopology$simulacion-$topologia.tr w] # dump all the traces out to the nam file $ns namtrace-all $nf $ns trace-all $tf $ns nodetrace-all $ndf #====================================================================# # constant definitions #v6 uses 1 - 70 mu s for offset time BurstManager offsettime 0.00004 #v6 uses 10000 - 70000 bytes BurstManager maxburstsize 40000 #v6 uses 0.1 s to 1 s BurstManager bursttimeout 0.5 # set the bhp processing time 1 microsecond (v6 test case not known) # 1 mu s was in initial example file Classifier/BaseClassifier/CoreClassifier set bhpProcTime 0.000001 Classifier/BaseClassifier/EdgeClassifier set bhpProcTime 0.000001 #assume 1 FDL per outgoing channel (on all links per node) Classifier/BaseClassifier set nfdl 16 #v6 fdl prop delay not known; 100 mu s is of order of trans delay Classifier/BaseClassifier set fdldelay 0.0001 Classifier/BaseClassifier set option 0 #v6 uses up to 10 FDL delays per node Classifier/BaseClassifier set maxfdls 5 Classifier/BaseClassifier set ebufoption 0 #this is a fixed delay line present at the ingress of every node OBSFiberDelayLink set FDLdelay 0.0 # total number of edge nodes ##EDGE COUNT## # total number of core routers ##CORE COUNT## 159 A P ÉNDICE F. E JEMPLOS DE FICHEROS # total bandwidth/channel (1mb = 1000000) set bwpc 1000000000 # delay in milliseconds ##DELAY## # total number of channels per link ##TOTAL CHANNELS## # number of control channels per link ##CONTROL CHANNELS## # number of data-channels ##DATA CHANNELS## #====================================================================# # support procedures ##TOPOLOGIA JERARQUICA## # finish procedure proc finish {} { global ns nf sc tf ndf $ns flush-trace $ns flush-nodetrace close $nf close $tf close $ndf $sc display-sim-list puts "Simulation complete"; exit 0 } #create a edge-core-edge topology Simulator instproc create topology { } { $self instvar Node global E C global edge count core count global bwpc maxch ncc ndc delay 160 F.3. F ICHERO ESQUELETO ##NODOS## ##ENLACES## $self build-routing-table } Simulator instproc create expo connection { selfsim udp null src dest start0 stop0 rate sdibt } { upvar 1 $udp udpr upvar 1 $selfsim selfsimr upvar 1 $null nullr upvar 1 $src srcr upvar 1 $dest destr set udpr [ new Agent/UDP] $self attach-agent $srcr $udpr set selfsimr [ new Application/Traffic/SelfSimilar ] $slefsimr attach-agent $udpr set nullr [ new Agent/Null ] $self attach-agent $destr $nullr $self connect $udpr $nullr $self at $start0 ‘‘$selfsimr start’’ $self at $stop0 ‘‘$selfsimr stop’’ puts ‘‘traffic stream between $src = $srcr and $dest = $destr created’’ } Simulator instproc create cbr connection { cbr udp null src dest start0 stop0 rate } { upvar 1 $udp udpr upvar 1 $cbr cbrr upvar 1 $null nullr upvar 1 $src srcr upvar 1 $dest destr set udpr [ new Agent/UDP] 161 A P ÉNDICE F. E JEMPLOS DE FICHEROS $self attach-agent $srcr $udpr set cbrr [ new Application/Traffic/CBR ] $cbrr attach-agent $udpr set nullr [ new Agent/Null ] $self attach-agent $destr $nullr $self connect $udpr $nullr $self at $start0 ‘‘$cbrr start’’ $self at $stop0 ‘‘$cbrr stop’’ puts ‘‘traffic stream between $src = $srcr and $dest = $destr created’’ } Simulator instproc create expo connection { expo udp null src dest start0 stop0 rate } { upvar 1 $udp udpr upvar 1 $expo expor upvar 1 $null nullr upvar 1 $src srcr upvar 1 $dest destr set udpr [ new Agent/UDP] $self attach-agent $srcr $udpr set expor [ new Application/Traffic/Exponential ] $expor attach-agent $udpr set nullr [ new Agent/Null ] $self attach-agent $destr $nullr $self connect $udpr $nullr $self at $start0 ‘‘$expor start’’ $self at $stop0 ‘‘$expor stop’’ puts ‘‘traffic stream between $src = $srcr and $dest = $destr created’’ } $ns create topology ##UDP SIZE## ##BATCHSIZE## 162 F.4. F ICHERO PARA SIMULAR Application/Traffic/SelfSimilar set sb 0 Application/Traffic/SelfSimilar set Hb -0.5 Application/Traffic/SelfSimilar set Ht 0.5 Application/Traffic/CBR set type CBR ##CBR SIZE## Application/Traffic/CBR set random true ##EXPO SIZE## ##DEMANDAS## .. . ##TIEMPO SIMULACION## $ns run F.4. Fichero para simular Como se observa, el fichero final para la simulación es muy parecido al base, pero se le han añadido todos los nodos, enlaces y demandas de tráfico a simular, además de algunos parámetros de la simulación. set set set set home path [lindex $argv 0] ns path [lindex $argv 1] simulacion [lindex $argv 2] topologia [lindex $argv 3] StatCollector set debug 0 Classifier/BaseClassifier/EdgeClassifier set type 0 Classifier/BaseClassifier/CoreClassifier set type 1 # Per node bhp processing time is 1 micro-second source $ns path/obs-0.9a/tcl/lib/ns-obs-lib-hierarchical.tcl source $ns path/obs-0.9a/tcl/lib/ns-obs-defaults.tcl source $ns path/obs-0.9a/tcl/lib/ns-optic-link.tcl 163 A P ÉNDICE F. E JEMPLOS DE FICHEROS set set set set set ns [new Simulator] nf [open $home path/topology$simulacion-$topologia.nam w] sc [new StatCollector] tf [open $home path/topology$simulacion-$topologia.tr w] ndf [open $home path/ndtopology$simulacion-$topologia.tr w] # dump all the traces out to the nam file $ns namtrace-all $nf $ns trace-all $tf $ns nodetrace-all $ndf #====================================================================# # constant definitions #v6 uses 1 - 70 mu s for offset time BurstManager offsettime 0.00004 #v6 uses 10000 - 70000 bytes BurstManager maxburstsize 40000 #v6 uses 0.1 s to 1 s BurstManager bursttimeout 0.5 # set the bhp processing time 1 microsecond (v6 test case not known) # 1 mu s was in initial example file Classifier/BaseClassifier/CoreClassifier set bhpProcTime 0.000001 Classifier/BaseClassifier/EdgeClassifier set bhpProcTime 0.000001 #assume 1 FDL per outgoing channel (on all links per node) Classifier/BaseClassifier set nfdl 16 #v6 fdl prop delay not known; 100 mu s is of order of trans delay Classifier/BaseClassifier set fdldelay 0.0001 Classifier/BaseClassifier set option 0 #v6 uses up to 10 FDL delays per node Classifier/BaseClassifier set maxfdls 5 Classifier/BaseClassifier set ebufoption 0 #this is a fixed delay line present at the ingress of every node 164 F.4. F ICHERO PARA SIMULAR OBSFiberDelayLink set FDLdelay 0.0 # total number of edge nodes ##EDGE COUNT## set edge count 15 # total number of core routers ##CORE COUNT## set core count 15 # total bandwidth/channel (1mb = 1000000) set bwpc 1000000000 # delay in milliseconds ##DELAY## set delay 1ms # total number of channels per link ##TOTAL CHANNELS## set maxch 10 # number of control channels per link ##CONTROL CHANNELS## set ncc 8 # number of data-channels ##DATA CHANNELS## set ndc 2 #====================================================================# # support procedures ##TOPOLOGIA JERARQUICA## $ns node-config -addressType hierarchical AddrParams set domain num 30 ;# number of domains lappend cluster num 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ;# number of clusters in each domain AddrParams set cluster num $cluster num lappend eilastlevel 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 AddrParams set nodes num $eilastlevel ;# number of nodes in each domain # finish procedure 165 A P ÉNDICE F. E JEMPLOS DE FICHEROS proc finish {} { global ns nf sc tf ndf $ns flush-trace $ns flush-nodetrace close $nf close $tf close $ndf $sc display-sim-list puts "Simulation complete"; exit 0 } #create a edge-core-edge topology Simulator instproc create topology { } { $self instvar Node global E C global edge count core count global bwpc maxch ncc ndc delay ##NODOS## set E(0) [$self create-edge-node 0 $edge count] set nid [$E(0) id] set string1 ‘‘E(0) node id: $nid’’ puts $string1 .. . set C(14) [$self create-core-node 29 $core count] set nid [$C(14) id] set string1 ‘‘C(14) node id: $nid’’ puts $string1 ##ENLACES## $self createDuplexFiberLink $E(0) $C(0) $bwpc $delay $ncc $ndc $maxch $self createDuplexFiberLink $E(1) $C(1) $bwpc $delay $ncc $ndc $maxch 166 F.4. F ICHERO PARA SIMULAR $self createDuplexFiberLink $maxch $self createDuplexFiberLink $maxch $self createDuplexFiberLink $maxch $self createDuplexFiberLink $maxch $E(2) $C(2) $bwpc $delay $ncc $ndc $E(3) $C(3) $bwpc $delay $ncc $ndc $E(4) $C(4) $bwpc $delay $ncc $ndc $E(5) $C(5) $bwpc $delay $ncc $ndc .. . $self createDuplexFiberLink $maxch $self createDuplexFiberLink $maxch $self createDuplexFiberLink $maxch $self createDuplexFiberLink $maxch $self createDuplexFiberLink $maxch $C(0) $C(5) 5000000000 $delay $ncc $ndc $C(0) $C(6) 11000000000 $delay $ncc $ndc $C(0) $C(7) 2000000000 $delay $ncc $ndc $C(1) $C(2) 1000000000 $delay $ncc $ndc $C(1) $C(4) 10000000000 $delay $ncc $ndc $self build-routing-table } Simulator instproc create expo connection { selfsim udp null src dest start0 stop0 rate sdibt } { upvar 1 $udp udpr upvar 1 $selfsim selfsimr upvar 1 $null nullr upvar 1 $src srcr upvar 1 $dest destr set udpr [ new Agent/UDP] $self attach-agent $srcr $udpr set selfsimr [ new Application/Traffic/SelfSimilar ] 167 A P ÉNDICE F. E JEMPLOS DE FICHEROS $slefsimr attach-agent $udpr set nullr [ new Agent/Null ] $self attach-agent $destr $nullr $self connect $udpr $nullr $self at $start0 ‘‘$selfsimr start’’ $self at $stop0 ‘‘$selfsimr stop’’ puts ‘‘traffic stream between $src = $srcr and $dest = $destr created’’ } Simulator instproc create cbr connection { cbr udp null src dest start0 stop0 rate } { upvar 1 $udp udpr upvar 1 $cbr cbrr upvar 1 $null nullr upvar 1 $src srcr upvar 1 $dest destr set udpr [ new Agent/UDP] $self attach-agent $srcr $udpr set cbrr [ new Application/Traffic/CBR ] $cbrr attach-agent $udpr set nullr [ new Agent/Null ] $self attach-agent $destr $nullr $self connect $udpr $nullr $self at $start0 ‘‘$cbrr start’’ $self at $stop0 ‘‘$cbrr stop’’ puts ‘‘traffic stream between $src = $srcr and $dest = $destr created’’ } Simulator instproc create expo connection { expo udp null src dest start0 stop0 rate } { upvar 1 $udp udpr upvar 1 $expo expor upvar 1 $null nullr 168 F.4. F ICHERO PARA SIMULAR upvar 1 $src srcr upvar 1 $dest destr set udpr [ new Agent/UDP] $self attach-agent $srcr $udpr set expor [ new Application/Traffic/Exponential ] $expor attach-agent $udpr set nullr [ new Agent/Null ] $self attach-agent $destr $nullr $self connect $udpr $nullr $self at $start0 ‘‘$expor start’’ $self at $stop0 ‘‘$expor stop’’ puts ‘‘traffic stream between $src = $srcr and $dest = $destr created’’ } $ns create topology ##UDP SIZE## Agent/UDP set packetSize 2000 ##BATCHSIZE## Application/Traffic/SelfSimilar set batchsize 250.0 Application/Traffic/SelfSimilar set sb 0 Application/Traffic/SelfSimilar set Hb -0.5 Application/Traffic/SelfSimilar set Ht 0.5 Application/Traffic/CBR set type CBR ##CBR SIZE## Application/Traffic/CBR set packetSize 2000 Application/Traffic/CBR set random true ##EXPO SIZE## Application/Traffic/Exponential set packetSize 2000 ##DEMANDAS## $ns create selfsim connection selfsim0(5:4) udp0(5:4) null(5:4) E(5) E(4) 5.019331700275444 5.186778154935088 2500.0 1.0e-4 $ns create selfsim connection selfsim0(5:13) udp0(5:13) null(5:13) E(5) E(13) 5.019331700275444 5.186778154935088 2500.0 1.0e-4 $ns create selfsim connection selfsim0(5:14) udp0(5:14) null(5:14) E(5) E(14) 5.019331700275444 5.186778154935088 2500.0 1.0e-4 169 A P ÉNDICE F. E JEMPLOS DE FICHEROS $ns create selfsim connection selfsim0(5:12) udp0(5:12) null(5:12) E(5) E(12) 5.020674161708899 5.036273513427956 2500.0 1.0e-4 .. . ##TIEMPO SIMULACION## $ns at 65.72 ‘‘finish’’ $ns run Leganés, a 10 de Julio de 2011 El ingeniero proyectista Fdo. José Miguel Vázquez Viejo 170

Aplicación para comparar topologías de red - e

Documentos relacionados

Productos

Apoyo

Aplicación para comparar topologías de red - e

Documentos relacionados

Añadir este documento a la recogida (s)

Añadir a este documento guardado

Sugiéranos cómo mejorar StudyLib