Implementación de los protocolos de enrutamiento OSPF y RIP en el simulador "Network Simulator 2"

Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 1 de 192 UNIVERSIDAD POLITECNICA DE VALENCIA ESCUELA POLITECNICA SUPERIOR DE GANDIA I.T. Telecomunicación (Sist. de Telecomunicación) “IMPLEMENTACION DE LOS PROTOCOLOS DE ENRUTAMIENTO OSPF Y RIP EN EL SIMULADOR NETWORK SIMULATOR 2” TRABAJO FINAL DE CARRERA Autor/es: Jesús Sevilla Vitoria Director/es:D.Jaime Lloret Mauri GANDIA, 2011 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 2 de 192 AGRADECIMIENTOS AGRADECIMIENTOSAGRADECIMIENTOS AGRADECIMIENTOS Este proyecto esta dedicado a José y Juana Carmen, mis padres., Pepe y juan Este proyecto esta dedicado a José y Juana Carmen, mis padres., Pepe y juan Este proyecto esta dedicado a José y Juana Carmen, mis padres., Pepe y juan Este proyecto esta dedicado a José y Juana Carmen, mis padres., Pepe y juan mis hermanos, mis hermanos, mis hermanos, mis hermanos, a toda mi familia a toda mi familiaa toda mi familia a toda mi familia. También quiero agradecer los grandes m . También quiero agradecer los grandes m. También quiero agradecer los grandes m . También quiero agradecer los grandes momentos vividos durante la carrera a omentos vividos durante la carrera a omentos vividos durante la carrera a omentos vividos durante la carrera a mis compañeros de estudios. Pedro, Emilio, Jose María, Miguel, Willy y Jose. mis compañeros de estudios. Pedro, Emilio, Jose María, Miguel, Willy y Jose.mis compañeros de estudios. Pedro, Emilio, Jose María, Miguel, Willy y Jose. mis compañeros de estudios. Pedro, Emilio, Jose María, Miguel, Willy y Jose. Sin su apoyo hubiera sido imposible terminar la carrera. Sin su apoyo hubiera sido imposible terminar la carrera. Sin su apoyo hubiera sido imposible terminar la carrera. Sin su apoyo hubiera sido imposible terminar la carrera. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 3 de 192 Índice Índice de figuras 1 INTRODUCCIÓN 1.1.- Introducción ……………………………………………………… 7 1.2.- Objetivos …………………………………………………………. 9 1.3.- Precedentes del proyecto ………………………………………… 10 1.4.- Estructura del proyecto …………………………………………. 12 2 EL SIMULADOR NETWORK SIMULATOR 2 2.1.- Introducción ……………………………………………………… 16 2.2.- Instalación de “NS2” ……………………………………………. 18 2.3.- Comandos del simulador ……………………………………….. 20 Creación del despachador de tareas …………………….. 21 Programar eventos y correr la simulación ……………… 21 Creación de la red ………………………………………… 23 Adhesión del Protocolo TCP …………………………….. 24 Adhesión de protocolo UDP ……………………………… 25 Tráfico sobre TCP ……………………………………….. 26 Tráfico sobre UDP ……………………………………….. 26 Registro de eventos ………………………………………. 27 Agrupación de comandos ………………………………… 27 3 APLICACIONES QUE SE PUEDEN EJECUTAR EN NS2 3.1.- NAM …………………………………………………………….. 32 3.2.- Tracegraph ……………………………………………………… 38 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 4 de 192 4 CONCEPTOS BÁSICOS DE PROTOCOLOS DE ENCAMINAMIENTO. 4.1.- Parámetros de encaminamiento …………………………….. 43 4.1.1.- Métrica de red ……………………………………… 43 4.1.2.- Encaminamiento en redes de circuito virtual y datagrama …………………………………………. 43 4.1.3.- Clasificación de métodos de encaminamiento ……. 44 4.1.4.- Encaminamiento adaptativo con algoritmo distribuido …………………………………………………. 45 4.1.4.1.- Vector distancia …………………. 46 4.1.4.2.- Estado de enlace …………………. 46 4.2.- OSPF y RIP …………………………………………………… 47 4.2.1.- Open shortest Path First …………………………… 47 4.2.1.1.- Estado de OSPF ………………….. 51 4.2.2.- RIP …………………………………………………... 54 4.2.2.1.- Funcionamiento de RIP …………. 55 4.2.2.2.- Ventajas y desventajas ………….. 57 4.3.- Distinción de protocolos en “NS2” ………………………….. 58 5 ¿COMO CREAR UN PROTOCOLO EN “NS2”? 5.1.- Empezando ……………………………………………………. 61 5.2.- El agente encaminador ……………………………………….. 63 5.3.- Ganchos del TCL ……………………………………………… 67 5.4.- Contadores de tiempo ………………………………………… 67 5.5.- Agente …………………………………………………………. 68 5.5.1.- Constructor …………………………………………. 68 5.5.2.- COMMAND ( ) …………………………….……….. 68 5.5.3.- recv ( ) ……………………………………………….. 70 5.5.4.- recv_protoname_pkt ( ) …………………………….. 71 5.5.5.- send_protoname_pkt ( ) ……………………………. 72 5.5.6.- reset_protoname_pkt_timer ( ) ……………………. 74 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 5 de 192 5.5.7.- forward_data ( ) ……………………………………. 74 5.6.- Tabla de enrutamiento ………………………………………. 76 5.7.- Cambio de escenario para adaptar el código ………………. 79 5.7.1.- Declaración del tipo de paquete …………………… 79 5.7.2.- Tracing Support ……………………………………. 80 5.7.3.- Librería TCL ……………………………………….. 82 5.7.4.- Orden de prioridad ………………………………… 83 6 RIP EN NS2 ………………………………………………………… 86 7 OSPF EN NS2 ……………………………………………………… 97 8 REDES INALÁMBRICAS 8.1.- Introducción…………………………………………………… 118 8.2.- Redes inalámbricas en “NS2”………………………………… 119 8.2.1.-DSDV……………………………………………………… 121 8.2.2.-DSR……………………………………………………….. 124 8.2.3.-AODV…………………………………………………….. 127 8.2.4.-TORA……………………………………………………… 131 9 CONCLUSIÓN 9.1.- Cumplimiento del objetivo…………………………………….. 136 9.2.- Conclusiones sobre el proyecto………………………………... 138 9.3.- Problemas encontrados y como se han solucionado………….. 139 9.4.- Aportaciones personales……………………………………….. 140 9.5.- Futuras líneas de trabajo/investigación……………………….. 141 BIBLIOGRAFÍA…………………………………………………………. 142 ANEXO 1………………………………………………………………….. 145 ANEXO 2………………………………………………………………….. 167 ANEXO 3………………………………………………………………….. 171 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 6 de 192 Índice de Figuras Figura 1. - Funcionamiento interno del simulador……………………………... 19 Figura 2. – Combinación de C ++ y Otcl a través de NS2 para obtener resultados……………………………………………. 21 Figura 3. – Estructura de la topología a distintos niveles OSI………………… 24 Figura 4. – Estructura de un nodo Unicast…………………………………….. 25 Figura 5. – Ventana principal del NAM……………………………………….. 34 Figura 6. – Formato de la estructura del archivó *.nam……………………….. 35 Figura 7. – Análisis de cada campo…………………………………………… 35 Figura 8. – Visualización de una simulación con 5 nodos en nam……………. 37 Figura 9. – Animación a mitad de su duración en el tiempo………………….. 37 Figura 10. – Nam editor………………………………………………………... 39 Figura 11. – Visualización del Tracegraph 2.02……………………………….. 40 Figura 12. – Descripción del paquete Hello……………………………………. 53 Figura 13. – Evaluación de la simulación sobre el protocolo DV anulando un enlace……………………………………………….. 88 Figura 14. – Demostración de la búsqueda alternativa de ruta y del conteo a infinito…………………………………………….. 89 Figura 15. – DV Multipaht……………………………………………………… 90 Figura 16. – Coste de enlace…………………………………………………… 93 Figura 17. – Numero de paquetes enviados con cada nodo……………………. 94 Figura 18. – Número de bits perdidos………………………………………….. 95 Figura 19. – Dijkstra.tcl………………………………………………………… 102 Figura 20. – Dikjstra.tcl con enlace caído……………………………………… 102 Figura 21. – OSPF.tcl de 30 nodos...................................................................... 110 Figura 22. – OSPF.tcl con enlaces caídos……………………………………… 111 Figura 23. - Redireccionamiento por caída de enlace………………………….. 112 Figura 24. - Sin bucles…………………………………………………………. 115 Figura 25.- DSDV……………………………………………………………… 123 Figura 26.- DSR………………………………………………………………… 126 Figura 27.- AODV……………………………………………………………… 130 Figura 28.- TORA………………………………………………………………. 133 Figura 29.- Comentario de la simulación en símbolo de sistema……………….. 150 Figura 30.- Topología 1…………………………………………………………. 150 Figura 31.- Topología 3………………………………………………………….. 159 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 7 de 192 CAPÍTULO 1 INTRODUCCIÓN Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 8 de 192 1.- INTRODUCCIÓN. 1.1.-Introducción. A la hora de empezar a desarrollar un proyecto en el que vamos a invertir una determinada cantidad de dinero, en el que este dinero se traduce en tiempo de investigación, equipos y desarrollo del proyecto; es conveniente poder prevenir los resultados que obtendremos con un cierto adelanto. Por ello la necesidad de crear aplicaciones que nos simulen las condiciones que nos encontraremos a la hora de ejecutar nuestro proyecto, ya que así no tendremos ningún imprevisto y evitaremos perdidas de tiempo y dinero. Estas aplicaciones son los denominados simuladores; la función principal de este software es la de crear las condiciones internas y externas más parecidas que se podrán dar en la realidad durante la ejecución de nuestro proyecto, obteniendo resultados iguales o parecidos antes de la ejecución del proyecto y durante la ejecución del proyecto. Cuando hablamos de simuladores en general, nos referimos a herramientas que nos pondrán en alerta ante posibles errores que cometamos o nos dará satisfacciones ante logros que consigamos y todo esto sin arriesgar prácticamente nada. En nuestro caso estudiaremos un simulador de redes que nos permitirá simular redes de diferentes tipologías. Entre las cualidades principales requeridas para un simulador destacan las siguientes: - Facilidad de manejo, en nuestro caso se agradecerá la facilidad a la hora de construir topologías y configurar los distintos parámetros que conlleve. - Visualización gráfica: o Topología. o Variación de valores entre distintos puntos (perdidas, longitud de cola, tiempo de retorno). o Rutas, trayectorias de paquetes pérdidas. - Multiplataforma: será de gran utilidad que el simulador no este ligado a un único Sistema Operativo, sino que nos de libertad a la hora de usar cualquier plataforma, por ejemplo linux o cualquier versión de Windows. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 9 de 192 - Fácil de instalar. - Nulo o bajo coste - Orientado a investigación y desarrollo. Debido a la necesidad de encontrar simuladores de redes cada vez mas potentes nos vimos en la necesidad de indagar, encontrando un simulador de software libre, (puede ser usado, copiado, estudiado, modificado y redistribuido libremente) en proceso de desarrollo por los usuarios denominado Network Simulator 2 (ns2). Este simulador está basado en la programación de scripts originados en lenguaje de programación tcl en que a su vez se pueden implementar nuevos objetos usando el lenguaje de programación C + +. Tcl (Tool Command Language) es un lenguaje de programación interpretado y multiplataforma. Fue creado por John K. Ousterhout y su equipo de la Universidad de California, pero actualmente es desarrollado por Sun Microsystems Laboratories (en concreto por su grupo SunScript, que lidera el propio Ousterhout) y distribuido de forma totalmente gratuita, aunque su uso sea para aplicaciones comerciales, a través de internet. La gran mayoría del software libre tiene como postulado la determinación de que el usuario no es un iletrado computacional. Parte del hecho de que confía en los conocimientos y habilidades del usuario para lograr su objetivo. Esta situación se observa desde el diseño de linux, decenas de pequeños comandos que hacen una tarea específica y se pueden conectar entre sí para realizar tareas más complejas. Ventajas. El uso de software libre ayuda a garantizar la educación de los individuos así como ayuda a la comunidad a garantizar el desarrollo. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 16 de 192 CÁPITULO 2 EL SIMULADOR NS2 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 17 de 192 2.- EL SIMULADOR NS 2. 2.1Introducción El network simulator 2 [3] [10] [18] [19] es un software simulador de eventos diseñado para la ayuda en la simulación de redes telemáticas y disponible en diversas plataformas. Se empezó a desarrollar en 1989 como una variante del ya existente simulador REAL Network Simulator. En 1995, bajo la supervisión del proyecto VINT (Virtual InterNetwork Testbed), finalmente acabo en manos de unos investigadores y desarrolladores de la universidad de California (Estados Unidos) en Berkeley. El ns2 es un simulador gratuito que suministra todo el código fuente. En la página Web http://www.isi.edu/nsnam/ns/ se puede descargar todo el código fuente, manuales básicos subscribirse al foro etc. Network simulator permite entre otras cosas trabajar tanto en redes cableadas como redes inalámbricas (simulando wifi etc..), redes vía satélite con una enorme cantidad de protocolos a distintos niveles, la capa de transporte (tcp, udp, etc…), la capa aplicación (ftp, cbr, http, etc…) o la capa de enlace de datos (como el CSMA/CA). Además permite trabajar en los modos Unicast o Multicast y utilizar diversos algoritmos para la planificación de colas (como el DRR (Deficit Round Robin), FIFO (First In First Out), FQ (Encolamiento justo) o SFQ (Encolamiento Estocástico Justo)) en caso de que se produzca el cuello de botella en algún nodo. El NS 2 es una herramienta tan potente que es útil tanto en entornos de investigación como en entornos de educación. En este proyecto además de la investigación que llevaremos a cabo acerca de nuevos protocolos para el ns2 destinaremos una serie de prácticas para utilizarlas en algunas asignaturas de telemática. El network simulator 2 es el simulador de redes más extendido tanto en investigación como para su utilización como herramienta educativa debido a su Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 18 de 192 condición de software libre. A continuación vamos a mostrar como instalarlo y como crear escenarios de simulación. Los usos más habituales que daremos a nuestro simulador serán:  Simular estructuras y protocolos de redes.  Desarrollar nuevos protocolos y algoritmos y comprobar su funcionamiento utilizando las herramientas que acompañan al ns2 (nam y tracegraph).  Comparar distintos protocolos en cuanto a prestaciones. Nuestro simulador es una de las herramientas más potentes para emular distintos escenarios por su arquitectura, en la cual utilizamos C++[4] para detallar la simulación de protocolos complejos, combinando este lenguaje con Otcl para programar las variables y parámetros de la simulación. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 19 de 192 Figura 1. Funcionamiento interno del simulador 2.2.- Instalación de ns2. En primer lugar debemos saber que existen versiones de “ns2” tanto para Windows XP como para Linux, nosotros procederemos a la instalación del paquete de ns2 para Windows ya que es el sistema operativo que utilizaremos para llevar a cabo el proyecto. Instalación de NS en Windows Esta instalación esta basada en la versión compilada para cygwin de NS[12][14]. Aunque no es necesaria la instalación del entorno de ejecución cygwin para emplear NS. Pasos a seguir Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 20 de 192 1. Instalar Active Tcl/TK 8.3.2. disponible en: http://prdownloads.sorceforge.net/tcl/tcl.exe?download. 2. Reiniciar el ordenador. 3. Crear un directorio en el que guardar los ejecutables de NS, por ejemplo C:\ns 4. Descargar el Cygwin de: http://www.it.uc3m.es/rcalzada/ns2/ns-allinone-2.27-cygwin-binaries.zip Descomprimir el fichero en el directorio creado en el paso anterior. 5. Copiar el fichero cygwin1.dll en el directorio c:\ns\usr\bin El fichero está disponible en http://www.it.uc3m.es/rcalzada/ns2/cygwin1.dll. 6. Copiar el fichero nam.exe en el directorio c:\ns\usr\bin El fichero está disponible en http://www.it.uc3m.es/rcalzada/ns2/nam.exe (En este paso se sobreescribe el fichero original). 7. Incluir en el PATH el lugar donde se encuentra el programa, en nuestro caso será el directorio c:\ns\usr\bin Esto se puede realizar ejecutando en el interfaz de comandos la siguiente instrucción: c:\> PATH=%PATH%;c:\ns\usr\bin Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 21 de 192 2.3. – Comandos de Network Simulator 2. El Network Simulator 2 es [11] [18] un simulador de eventos discretos orientado al estudio de redes: o Provee el soporte para simulación de protocolos de transporte (TCP y UDP). o Provee el soporte para simulación de aplicaciones y fuentes de tráfico (FTP, Web, Telnet, cbr, VBR, etc). o Política y manejo de colas (Drop Tail, Red, CBR). o Algoritmos de enrutamiento. Está desarrollado en Otcl y C++. Otcl es una extensión del lenguaje de programación Tcl (Tool Command Language) orientada a objetos. Tcl es un lenguaje de scripting (conjunto de comandos) interpretado. El ns2 es básicamente un intérprete de scripts Otcl. Figura 2. Combinación de c++ y otcl a través de ns2 nos da los resultados. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 22 de 192 Para comenzar una simulación primero debemos indicarle al simulador la topología de la red a simular, la cual tendrá una serie de componentes de red:  Nodos  Enlaces  Agentes (implementa protocolos de distintos niveles OSI)  Aplicaciones  Paquetes Para escribir una simulación en NS2, primero debemos crear el Despachador de Eventos, luego crearemos el registro de eventos (para ello, la forma de la topología será imprescindible), mas tarde debemos Agendar los eventos y correr la simulación. · Creación del despachador de tareas: Primero se crea una instancia de la clase simulador, esto crea el despachador de tareas. Los métodos de la clase Simulator permite después crear la topología y configurar la simulación. Set pruebaNS [new Simulator] · Programar Eventos y correr la simulación: Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 23 de 192 La sintaxis de programación de eventos es la siguiente: $pruebaNS at <tiempo> <evento> Donde <evento> es cualquier comando ns/tcl valido. Para iniciar el trabajo del despachador se corre el simulador: $pruebaNS run Nuestra primera simulación será holamundo.tcl y será un simple script que nos mostrará la frase hola mundo por pantalla. # Holamundo.tcl set ns [new simulator] $ns at 1 “puts\HOLA MUNDO\”” $ns at 1,5 “exit” $ns run C:\ns2\ns Holamundo.tcl HOLA MUNDO Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 24 de 192 · Creación de la red: Para crear la red o topología, primero debemos crear los nodos que serán los puntos desde donde saldrá o llegaran los paquetes que deseemos enviar. Posteriormente debemos crear los enlaces uniendo los nodos según la topología que deseemos (estrella, anillo, etc…). También indicaremos que política usaremos en el manejo de colas en los nodos. Figura 3. Estructura de la topología a distintos niveles OSI. Los nodos se realizaran de la siguiente manera: set n0 [$ns node] set n1 [$ns node] Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 25 de 192 Figura 4. Estructura de un nodo unicast. · Adhesion del protocolo TCP: Vamos a proceder a crear una conexión TCP entre dos nodos, donde TCP es un protocolo de control de transmisión, es fundamental en Internet. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmiten. #Crear conexión TCP #TCP set tcp [newAgent/TCP] set tcpSink [newAgent/TCPSink] $ns attach-agent $n0 $tcp Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 32 de 192 CAPÍTULO 3 APLICACIONES DE NS2 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 33 de 192 3.- APLICACIONES QUE SE PUEDEN EJECUTAR CON “NS2”. A la hora de correr un script con ns2 es evidente que esperamos unos resultados que nos ayuden a comprender todos y cada uno de los eventos realizados durante la simulación línea por línea, estos resultados los obtenemos ya que el ns2 nos proporciona una traza que nos indica en todo momento lo que ocurre en la simulación estado de los paquetes etc, pero todo esto escrito en una traza. Por lo tanto es poco lo que uno puede concluir. Es por ello que se usa el programa nam que tiene por objetivo interpretar estos valores y simularlos en una interfaz gráfica. Esta interfaz gráfica que nos ayuda a ver la simulación va acompañado de otra aplicación como el tracegraph, donde se registrarán todos los datos de la simulación y nos la mostrara en forma de gráfica. La diferencia entre el archivo .nam y el .tr es muy simple: .nam es el formato que debe tener un archivo para la lectura en el programa network animator mientras que .tr es un formato mas amigable para nosotros, ya que nos permitirá un análisis mas a fondo. 3.1.- El nam (network animator). El nam [5] [14] [18] es una aplicación que nos sirve para representar la simulación que hemos programado en ns2, podemos visualizar la topología de la red diseñada y el transito de los paquetes de un nodo hacia otro con las colas que se generan en cada nodo e incluso la perdida de dichos paquetes. Se ejecuta escribiendo en el símbolo de sistema: c:/ns2/nam *.nam (donde * representa el nombre del archivo de tipo nam). Para descargar he instalar el esta herramienta complementaria debemos acudir a la pagina web “oficial” de NS2 http://www.isi.edu/nsnam/nam/ , donde podremos encontrar la fuente del nam 1.11. Este será el archivo .tar.gz , este archivo está comprimido en formato *.rar, los descargaremos dentro de la carpeta C:\ns2, donde Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 34 de 192 tenemos el simulador instalado el Active tcl y el trace graph. Dentro de esta carpeta descomprimiremos el archivo y ejecutaremos el nam.exe quedando así instalado y listo para empezar a cargar archivos *.nam generados por los scripts. En cuanto a lo de instalarlo dentro de la carpeta C:\ns2, es por una sencilla razón, se nos abrirán directamente los archivos *.nam una vez terminado el simulador de ejecutar, leer scripts y generar archivos indicados en dichos scripts Figura 5. Ventana principal del NAM El archivo .nam [18] que nos servirá para editarlo en el nam lo generara el ns2 al correr el archivo .tcl que hemos programado previamente y normalmente le diremos que lo guarde en el directorio donde tenemos todos los archivos ejecutables. También podremos indicar en el archivo que programamos .tcl que nos abra directamente el Network Animator. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 35 de 192 evento tiempo Desde nodo A nodo Tipo de paquete Tamaño de paquete flags fid Dirección fuente Dirección destino Numero de secuencia Paquete identidad Figura 6. Formato de la estructura del archivo .nam Figura 7. Análisis de cada campo Las opciones de visualización del NAM son las siguientes: · Retroceso Rápido: la simulación se va retrocediendo multiplicando su paso del tiempo por 25. · Retroceso Normal: la simulación se retrocede según el paso del tiempo normal. · Stop: detiene la simulación. · Avance normal: se inicia la animación o la hace continuar si estaba pausada. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 36 de 192 · Avance rápido: la animación se va avanzando multiplicando el paso del tiempo por 25. · Tiempo: indica el instante en el que se encuentra la simulación. · Paso de tiempo: nos da una idea de la rapidez de la simulación. · Zoom: para aumentar o disminuir la simulación. · Tamaño de los nodos: permite variar el tamaño de los nodos, en caso de tener pocos nodos en la simulación podemos aumentarlos de tamaño para apreciar mejor el transito de los paquetes. · Indicador de tiempo: da idea del tiempo transcurrido en la simulación a través de una barra de tiempo, la cual visualmente nos da una imagen rápida del tiempo que queda y el tiempo transcurrido. · Flujo de enlace: si se pulsa en un enlace y se selecciona la opción “Graph” se puede ver durante que tiempo viajara la información por ese enlace en ambas direcciones y la información que se pierde. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 37 de 192 Figura 8. Visualización de una topología de 5 nodos al principio de la simulación con el Nam. Figura 9. Aquí la vemos la animación a mitad de su duración en el tiempo, donde el nodo 23 envía datos al nodo 1 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 38 de 192 Con estos ejemplos podemos comprobar la gran utilidad del Network Animator a la hora de visualizar las simulaciones y junto a otro programa complementario como es el Tracegraph las simulaciones serán objeto de estudio simplemente con el ojo humano. Además debemos hacer hincapié en una de las aplicaciones que adjunta Network Animator, es el llamado NAM editor. Como su propio nombre indica, esta herramienta es un editor para crear simulaciones *.nam. En lugar de tener que programar en Otcl un script, con el editor lo único que haremos será dibujar la topología añadiendo nodos y enlaces gráficamente, para posteriormente indicar todos los parámetros de la simulación, como fuentes de tráfico, protocolos tcp, ftp etc. Una vez dibujada la topología el editor nos da la opción de seleccionar el tipo de protocolo a nivel de aplicación o transporte que asignaremos a cada nodo, incluso si es un sumidero de tráfico ( es decir será receptor de tráfico). Esto lo haremos seleccionando con el ratón cada protocolo y arrastrándolo al nodo que queremos que desempeñe ese protocolo. También podremos elegir a nuestro gusto el número de enlaces entre nodos y los parámetros de cada uno de esos “link”. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 39 de 192 Figura 10. NAM editor 3.2.- Tracegraph. El ns2 genera un archivo de tipo trace (.tr), [18] este archivo nos servirá para ejecutar el tracegraph el cual se podrá abrir desde el menú del trazador de graficas o podremos ordenar que se abra desde las líneas de código del archivo tcl que hemos programado previamente. El tracegraph[6] [17] va acompañado de un programa llamado matlab, que es un programa de tratamiento matemático al cual se le pueden introducir funciones matemáticas para que las represente gráficamente, una de las ventajas de guardar los archivos generados en un archivo matlab será que incrementaremos la velocidad a la hora de cargar de nuevo el archivo. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 40 de 192 El archivo generado .tr será cargado por el trace graph 2.02, una vez cargado el programa genera los gráficos en el matlab como podemos apreciar en el siguiente ejemplo: Figura 11. En el tracegraph 2.02 se carga la información generada por ns2 y en el graph se visualizan las graficas en 2 y 3 dimensiones con los distintos parámetros. Para descargar Tracegraph 2.04 versión compilada para Windows lo haremos desde el enlace web http://diament.ists.pwr.wroc.pl/~tracegr/sciagnij.php donde además podremos encontrar el Matlab que será necesario para la ejecución del trazador de simulaciones. Una vez descargados estos dos ficheros los pegaremos dentro de la carpeta C:\ ns2 , donde tenemos el simulador y todas las simulaciones en Otcl, para luego instalarlos dentro de dicha carpeta. Instalando Tracegraph junto con matlab dentro de la carpeta donde tenemos instalados ns2 y Active TCL versión 8.4.7 conseguiremos Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 41 de 192 que se abran instantáneamente estos programas al ejecutar el script, ya que se lo indicamos dentro del programa TCL, sin necesidad de tener que ejecutar el trazador y cargar el archivo que ha generado la simulación. A continuación veremos por encima la información que nos puede dar visualmente el tracegraph tanto en 2 dimensiones como en 3 dimensiones enfrentando muchas variables. Gráficos en 3D. · Numbers of generated packets at all the nodes: Nos dará una información detallada de todos los paquetes de datos generados en todos los nodos de la red que previamente hemos creado con el ns2 indicandonos el nodo que genera esos paquetes y el nodo que recibira esos mismos datos. · Numbers of sent packets at all the nodes: Esta opción nos informará acerca de todos los paquetes enviados desde cualquier nodo de nuestra topología indicandonos en la gráfica el receptor de esos mismos paquetes enviados. En teoría la gráfica anterior debería ser igual a esta porque se supone que en la simulación todos los paquetes que son generados son destinados a ser enviados a un nodo receptor. · Numbers of received packets at all the nodes: Aquí podremos ver los nodos receptores de los paquetes que será un gráfico inverso al anterior. · Numbers of forwarded packets at all the nodes: Nos mostrara el gráfico de los paquetes expedidos en todos los nodos es decir aquí se cuentan todos los paquetes tanto los que son generados en el propio nodo como los que van de paso. · Numbers of dropped packets at all the nodes: Aquí podremos ver el numero de paquetes dejados de caer o descartados en todos los nodos. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 48 de 192 4.2.- OSPF y RIP 4.2.1.- Open shortest Path First . El protocolo “ Primero la ruta más corta” (OSPF)[7], es un protocolo de enrutamiento público basdo en el estado de los enlaces. Calcula las rutas óptimas basandose en el menor costo de los enlaces hasta un destino por el algoritmo de Dijkstra[8]. - Algoritmo de Dijkstra [21]. El algoritmo de Dijkstra, también llamado algoritmo de caminos mínimos, es un algoritmo para la determinación del camino más corto dado un vértice origen al resto de vértices en un grafo dirigido y con pesos en cada arista. Su nombre se refiere a Edsger Dijkstra , quien lo describió por primera vez en 1959. La idea subyacente en este algoritmo consiste en ir explorando todos los caminos más cortos que parten del vértice origen y que llevan a todos los demás vértices; cuando se obtiene el camino más corto desde el vértice origen, al resto de vértices que componen el grafo, el algoritmo se detiene. El algoritmo es una especialización de la búsqueda de costo uniforme, y como tal, no funciona en grafos con aristas de costo negativo (al elegir siempre el nodo con distancia menor, pueden quedar excluidos de la búsqueda nodos que en próximas iteraciones bajarían el costo general del camino al pasar por una arista con costo negativo). Implementación. #define INFINITY (MAX_INT - 1) typedef struct { int weight; int dest; } DijkEdge; Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 49 de 192 typedef struct { DijkEdge* connections; /* Un array de arcos */ int numconnect; int distance; int isDead; } Vertex; void Dijkstra(Vertex* graph, int nodecount, int source) { for(int i = 0; i < nodecount; i++) { if(i == source) { graph[i].distance = 0; graph[i].isDead = 0; } else { graph[i].distance = INFINITY; graph[i].isDead = 0; } } for(int i = 0; i < nodecount; i++) { int next; int min = INFINITY+1; for(int j = 0; j < nodecount; j++) { if(!graph[j].isDead && graph[j].distance < min) { next = j; min = graph[j].distance; } } for(int j = 0; j < graph[next].numconnect; j++) { if(graph[graph[next].connections[j].dest].distance > graph[next].distance + graph[next].connections[j].weight) { graph[graph[next].connections[j].dest].distance = graph[next].distance + graph[next].connections[j].weight; } Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 50 de 192 } graph[next].isDead = 1; } for(int i = 0; i < nodecount; i++) { printf("The distance between nodes %i and %i is %i", source, i, graph[i].distance); } } Cada router contacta con sus vecinos inmediatos y mide el coste hacia ellos, una vez calculado todos los costos, OSPF utiliza el costo como métrica para determinar la mejor ruta. Un costo se asocia con el lado de salida de cada interfaz de router; por lo general el costo de ruta se calcula mediante la formula 10^8/ancho de banda (expresado en bps). Cuanto más bajo sea el costo, mas probabilidad hay de que la interfaz sea utilizada para enviar tráfico de datos. Es posible cambiar el costo para cambiar el resultado de los calculos de los costes de OSPF, uns situación común que requieres un cambio de costo en un entorno de enrutamiento de diversos fabricantes, al cambiar estos costes podemos asegurar que el costo de un fabricante coincida con el valor de costo de otros fabricantes. Con la configuración por defecto, se asigna el valor de costo más bajo (1) a un enlace de 100 Mbps, el número de costo se puede establecer entre 1 y 65.535. Cada router envía los paquetes “hello” de manera multicast para realizar un seguimiento del estado de los routers vecinos. Los routers OSPF deben tener los mismos intervalos hello y los mismos intervalos muertos para intercambiar información. Por defecto, el intervalo muerto es de cuatro veces el valor del intervalo hello. Esto significa que un router tiene cuatro oportunidades de enviar un paquete hello antes de ser declarado muerto. En las redes OSPF de broadcast, el intervalo hello por defecto es de 10 segundos y el intervalo muerto por defecto es de 40 segundos, En las redes que no son de broadcast, el intervalo hello por defecto es de 30 segundos y el intervalo muerto es de 120 segundos. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 51 de 192 El intercambio [21] de LSA se desencadena por medio de un evento en la red en lugar de actualizaiones periodicas ( esto acelera el proceso de convergencia). Los Hellos se envian cada 10 segundos por defecto en las redes multiacceso de broadcast y punto a punto. En las interfaces que se conectan a las redes NBMA, como por ejemplo FRAME RELAY, el tiempo por defecto es de 30 segundos. Se recomienda que en cada area no se superen los 50 routers. Se contruye un paquete LSP (Link State Packet o tambien llamado LSA, Link State Adevertisement) donde se identifica y da la lista de sus vecinos y el coste que tiene con ellos. Envía un LSP por inundación a todos los routeres de la red: - Solo se envían cuando hay cambios. - Los LSP se numeran secuencialmente. Además tienen un tiempo de vida limitado. - Además se procura: o No enviar ningun LSP por donde se ha recibido. o Comparar el LSP con el que mantiene el nodo. Si es un duplicado se rechaza y no retransmite. - Cada router recoge el LSP y acutaliza una base de datos del estado de enlace o topológica. - Una vez se haya reunido toda la información cada router calcula las mejores rutas hacia todos los destinos de la red. - El algoritmo SPF contruye el árbol resultante de la topología con el router como raiz, y con todos las rutas posibles hacia cada red. - Un algoritmo de enrutamiento de estado de enlace conoce perfectamente los routers distantes y como se interconectan ( base de datos de información de topología). - Tras ejecutar SPF, se crea la tabla de enrutamiento. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 52 de 192 4.2.1.1.- Estados de OSPF. Los interfaces OSPF pueden encontrarse en uno de siete estados. Los vecinos OSPF progresan a través de estos estados, uno a la vez en el siguiente orden: · Estado desactivado. En el estado desactivado, el proceso OSPF no ha intercambiado información con ningún vecino. · Estado de Inicialización. Los encaminadores OSPF envían paquetes tipo 1, o paquetes Hello, a intervalos regulares con el fin de establecer una relación con los encaminadores vecinos. Cuando una interfaz recibe su primer paquete Hello, el encaminador entra al estado de inicialización. Esto significa que este sabe que existe un vecino a la espera de llevar la relación a la siguiente etapa. · Estado de Dos-Vias. Empleando paquetes Hello, cada enrutador OSPF intenta establecer el estado de dos-vías, o comunicación bidireccional, con cada enrutador vecino en la misma red IP. Entre otras cosas, el paquete Hello incluye una lista de los vecinos OSPF conocidos por el origen. Un enrutador ingresa al estado de Dos-Vias cuando se se ve a sí mismo en un paquete Hello proveniente de un vecino. · Estado ExStart. Técnicamente, cuando un encaminador y su vecino entran al estado ExStart, su conversación es similar a aquella en el estado de Adyacencia. ExStart se establece Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 53 de 192 empleando descripciones de base de datos tipo 2. Los dos encaminadores vecinos emplean paquetes Hello para negociar quien es el “maestro” y quien es el “esclavo” en su relación. Aquel encaminador con el mayo router ID “gana” y se convierte en el maestro. Cuando los vecinos establecen sus roles como maestro-esclavo entran al estado de intercambio y comienzan a enviar información de encaminamiento. · Estado de Intercambio. En el estado de intercambio, los encaminadores vecinos emplean paquetes tipo 2 para enviarse entre ellos su información de estado de enlace. En otras palabras, los encaminadores se describen sus bases de datos de estado de enlace entre ellos. Los encaminadores comparan lo que han aprendido con lo que ya tenían en su base de datos de estado de enlace. · Estado Cargando. Despues de que las bases de datos han sido completamente descritas ntre vecinos, estos pueden requerir información más completa empleando paquetes tipo 3, requerimiento de estado de enlace(LSR). Cuando un enrutador recibe un LSR este responde empleando un paquete de actualización de estado de enlace tipo 4 (LSU). Estos paquetes tipo 4 contienen las publicaciones de estado de enlace que son el corazón de los protocolos de estado de enlace.Los LSU tipo 4 son confirmados emleando paquetes tipo 5 conocidos como confirmaciones de estado de enlace (LSAcks). · Estado de Adyacencia. Cuando el estado de carga ha sido completada, los enrutadores se vuelven completamente adyacentes. Cada enrutador mantien una lista de vecinos adyacentes, llamada base de datos de adyacencia. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 54 de 192 El paquete hello es pequeño, consiste en un encabezado de paquete OSPF, este tipo de paquete retransmite la siguiente información. Figura 12. Descripción del paquete hello. Siempre que en una topología de estado de enlace cambia, el router que primero se da cuenta del cambio envía la información a los demás routers o a un router determinado que todos los demas routers pueden utilizar para realizar las actualizaciones. Las actualizaciones de enrutamiento producen un gran volumen de tráfico al ocurrir cambios en la topologia, cada vez que un paquete LSA provoca un cambio en la base de datos de estado de enlace, el algoritmo de estado de enlace (SPF) vuelve a calcular cuáles son las mejores rutas y acutariza la tabla de enrutamiento. Por esta razón es necesario limitar la cantidad de routeres de estado de enlace dentro de un área. - Principio de funcionamiento. Se requiere una relación de vecino para compartir la información de enrutamiento. Un router tiende a ser adyacente (o vecinos) con por lo menos un router en cada red IP a la cual está conectado. Los routeres OSPF determinan con que routers pueden intentar formar adyacencias tomando como base el tipo de red a la cual están conectados. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 55 de 192 Algunos routers tratarán de tender a la adyacencia con respecto a todos los routeres vecinos. Una vez que se forma una adyacencia entre vecinos, se intercambia la información del estado de enlace. Las interfaces OSPF reconocen 3 tipos de redes: - Multiacceso de broadcast como or ejemplo ethernet. - Redes punto a punto. - Multiacceso sin broadcast, como por ejemplo Frame Relay. En un segemento de red multiacceso de broadcast, se pueden conectar muchos routers, si cada router tuviera que establecer adyacenccia completa con cada uno de los otros routers e intercambiar información del estado de enlace con cada vecino, el procesamiento tendría un gasto demasiado grande (para n routers, se necesitan n* (n1)/2 adyacencias). Para reducir la cantidad de intercambios de la información de enrutamiento entre los distintos vecinos de una misma red, los routeres de OSPF selecionan un router designado (DR) y un router designado de respaldo (BDR) que sirven como puntos de enfoque para el intercambio de información de enrutamiento. 4.2.2.- RIP. El origen del RIP[9] fue el protocolo de Xerox , el GWINFO, RIP evolucionó como un protocolo de encaminamiento de internet, y otros protocolos propietarios utilizan versiones modificadas de RIP. La última mejora hecha al protocolo es la especificación RIP2, que permite incluir más información en los paquetes y provee un mecanismo de autenticación muy simple. Es el protocolo mas común para transferir información de enrutamiento entre routers ubicados en la misma red. Fue utilizado por ARPANET desde 1969. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 56 de 192 4.2.2.1.- Funcionamiento del RIP. RIP utiliza UDP para enviar sus mensajes, este recalcula las rutas o caminos mas cortos de enrutamiento utilizando el algoritmo de vector distancia. La distancia o métrica está determinada por el número de saltos del router hasta alcanzar la red de destino (Bellmand-Ford). Bellmand-Ford El algoritmo de Bellman-Ford [21] genera los caminos mínimos desde un nodo origen de un grafo ponderado al resto de nodos del mismo. Existen dos versiones: Versión no optimizada para grafos con ciclos negativos, cuyo coste de tiempo es O(VE) Versión optimizada para grafos con aristas de peso negativo, pero en el grafo no existen ciclos de coste negativo, cuyo coste de tiempo, es también O(VE). Teóricamente no se notan los órdenes de tiempo entre ambas versiones, pero en ejecución sí. El algoritmo de Dijkstra logra esta misma tarea con un coste de tiempo menor, pero requiere que los pesos de las aristas no sean negativos. Es por eso, que el algoritmo de Bellman-Ford se utiliza únicamente cuando hay aristas negativas presentes en el grafo. Implementación. BellmanFord(Grafo G, nodo_fuente s) // inicializamos el grafo. Ponemos distancias a INFINITO menos el nodo fuente que // tiene distancia 0 for v ∈ V[G] do distancia[v]=INFINITO padre[v]=NIL distancia[s]=0 // relajamos cada arista del grafo tantas veces como número de nodos -1 haya en el grafo for i=1 to |V[G]-1| do Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 57 de 192 for (u,v) ∈ E[G] do if distancia[v]>distancia[u] + peso(u,v) then distancia[v] = distancia[u] + peso (u,v) padre[v] = u // comprobamos si hay ciclos de coste negativo for (u,v) ∈ E[G] do if distancia[v] > distancia[u] + peso(u,v) then print ("Hay ciclo de coste negativo") return FALSE return TRUE Los routers deben actualizar la información de las tablas de enrutamiento para tomar siempre decisiones correctas sobre la determinación de ruta. Si los routers no están al tanto de los cambios producidos dentro de la red, pueden conmutar paquetes a los interfaces que ya no están conectados a la mejor ruta. Cuando un router recibe una actualización de enrutamiento con cambio en esta, actualiza dicha tabla para reflejar la nueva ruta. El valor recibido de la métrica de la ruta aumenta en 1 y la interfaz de origen de la actualización se señala como el salto siguiente en la tabla de enrutamiento. Los routers RIP conservan sólo la mejor ruta hacia un destino, pero puede conservarse más de una ruta al mismo destino siempre y cuando el coste sea el mimo. La métrica de un nodo destino se calcula como la métrica comunicada por un vecino más su propia distancia a ese mismo vecino. Teniendo en cuenta lo anteriormente mencionado, donde recordábamos el límite de 15 saltos como máximo; las métricas se actualizan sólo en caso de que la métrica anunciada más el coste en alcanzar sea estrictamente menor a la almacenada. Solo se actualizará a una métrica mayor si proviene del nodo que anunció la ruta. El protocolo tiene una distancia administrativa de 120, la distancia administrativa indica el grado de confiabilidad de un protocolo de enrutamiento por ejemplo EIGRP tiene una distancia administrativa de 90, lo cual indica que a menor valor mejor es el protocolo utilizado. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 64 de 192 En las líneas 10-12 podemos ver las 3 principales cualidades de nuestro paquete, en las líneas 14-16 son funciones para las cualidades anteriormente definidas. La línea 4 incluye el campo común /packet.h del archivo que define la clase del paquete. Para interconectar nuestro paquete al TCL [13] [15] creamos en el directorio protoname, el archivo protoname.cc con el código siguiente. Como podemos apreciar estamos haciendo directamente accesible nuestro paquete al TCL. protoname/protoname.cc 1: int protoname_pkt::offset_; 2: static class ProtonameHeaderClass : public PacketHeaderClass { 3: public: 4: ProtonameHeaderClass() : PacketHeaderClass("PacketHeader/Protoname", 5: sizeof(hdr_protoname_pkt)) { 6: bind_offset(&hdr_protoname_pkt::offset_); 7: } 8: } class_rtProtoProtoname_hdr; 5.2.- EL AGENTE ENCAMINADOR. Ahora comenzaremos a programar el Agente en si, dentro de protoname, en el archivo protoname.h definiremos una nueva clase llamada Protoname que contiene las funciones necesarias para ayudar al protocolo a hacer su trabajo. Para ilustrar el uso de contadores de tiempo asumimos que el protoname es un protocolo proactivo que requiere enviar hacia fuera algunos paquetes de control. El código siguiente lo demuestra. protoname/protoname.h 1: #ifndef __protoname_h__ 2: #define __protoname_h__ 3: 4: #include "protoname_pkt.h" 5: #include <agent.h> 6: #include <packet.h> Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 65 de 192 7: #include <trace.h> 8: #include <timer-handler.h> 9: #include <random.h> 10: #include <classifier-port.h> 11: 12: #define CURRENT_TIME Scheduler::instance().clock() 13: #define JITTER (Random::uniform()*0.5) 14: 15: class Protoname; 16: 17: /* Contadores de tiempo*/ 18: 19: class Protoname_PktTimer : public TimerHandler { 20: public: 21: Protoname_PktTimer(Protoname* agent) : TimerHandler() { 22: agent_ = agent; 23: } 24: protected: 25: Protoname* agent_; 26: virtual void expire(Event* e); 27: }; 28: 29: /* Agent */ 30: 31: class Protoname : public Agent { 32: 33: /* Friends */ 34: friend class Protoname_PktTimer; 35: 36: /* Private members */ 37: nsaddr_t ra_addr_; 38: protoname_state state_; 39: protoname_rtable rtable_; 40: int accesible_var_; 41: u_int8_t seq_num_; 42: 43: protected: 44: 45: PortClassifier* dmux_; // para pasar paquetes a niveles superiores. 46: Trace* logtarget_; // For logging. 47: Protoname_PktTimer pkt_timer_; // Timer for sending packets. 48: 49: inline nsaddr_t& ra_addr() { return ra_addr_; } 50: inline protoname_state& state() { return state_; } 51: inline int& accessible_var() { return accessible_var_; } 52: 53: void forward_data(Packet*); 54: void recv_protoname_pkt(Packet*); 55: void send_protoname_pkt(); 56: Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 66 de 192 57: void reset_protoname_pkt_timer(); 58: 59: public: 60: 61: Protoname(nsaddr_t); 62: int command(int, const char*const*); 63: void recv(Packet*, Handler*); 64: 65: }; 66: 67: #endif Las líneas 4-10 se utilizan para incluir los archivos.h requeridos para nuestro nuevo Agente. Ahora veremos para que son utilizados: Protoname/protoname pkt.h: define el paquete del protocolo e indica el paquete que se utilizará en nuestro protocolo. Campocomun/agent.h : define la clase baja del agente. Campocomun/packet.h : define la clase del paquete. Campocomun/timerhandler.h : define la clase baja de Timerhandler, lo utilizaremos para crear nuestros propios contadores de tiempo. Rastro/trace.h : define la clase del rastreador nos indicara el resultado de la simulación en un archivo traza. Herramientas/random.h definen la clase al azar, útil para generar números pseudoaleatorios. Clasificador/classifier-port.h define la clase de PortClasifier, usado para pasar los paquetes a capas superiores. La línea 12 define un macro útil para conseguir tiempo actual en el reloj del simulador, otro macro está en la línea 13, es una manera fácil de obtener al azar Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 67 de 192 números entre el intervalo 0-0,5. Con esto evitaremos que los paquetes de control se envíen todos al mismo tiempo de forma sincronizada evitando así colisiones entre ellos. Las líneas 19-27 declaran nuestro contador de tiempo para enviar los paquetes periódicos de control. Nuestra clase Protoname PktTimer [13] [15] hereda de Timerhandler y tiene una referencia al agente de encaminamiento que envía el paquete de control nuevo y programa el siguiente. La clase de Protoname se define dentro de las líneas 31-65, encapsula la propia dirección , estado interno, tabla de encaminamiento, una variable accesible desde TCL. Un objeto Portclassifier se declara en la línea 45, este objeto consiste en un nodo de un clasificador de la dirección y un clasificador portuario. El primero se utiliza para dirigir los paquetes entrantes a un acoplamiento conveniente o pasarlos al clasificador portuario, que los llevará al agente de la capa superior. En la línea 46 veremos otra cualidad importante que es el objeto rastro, se utiliza para generar un archivo en el cual serán almacenados todos los datos de la simulación. La línea 47 declara nuestro contador de tiempo, y las líneas 49-51 son funciones que nos permiten tener acceso a algunas cualidades internas. La función que podemos ver en la línea 53 será utilizada para remitir los paquetes de datos a su destino correcto, la función de la línea 54 será llamada siempre que se reciban paquetes de control. A partir de la línea 57 se declara una función la cual será usada para programar el contador de tiempo, de la 61 a la 63 podemos encontrar funciones publicas de la clase Protoname. Protoname hereda dos de las funciones principales de la clase: recv() y command(). Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 68 de 192 5.3.- GANCHOS DEL TCL. Vimos anteriormente como asociar nuestro propio paquete al TCL, ahora haremos lo mismo para nuestra clase del Agente, podremos instanciar “Protoname” desde TCL. protoname/protoname.cc 1: static class ProtonameClass : public TclClass { 2: public: 3: ProtonameClass() : TclClass("Agent/Protoname") {} 4: TclObject* create(int argc, const char*const* argv) { 5: assert(argc == 5); 6: return (new Protoname((nsaddr_t)Address::instance().str2addr(argv[4]))); 7: } 8: } class_rtProtoProtoname; El constructor de la clase esta en la línea 3 y llama simplemente la clase baja con secuencia “agent/Protoname”, esto representa la jerarquía de la clase para este agente de manera textual. En líneas 4-7 ponemos una función en ejecución llamada create ( ) , que devuelve un objeto de Protoname pero en TCLobject. 5.4.- CONTADORES DE TIEMPO. Todo lo que debemos descifrar en protoname/protoname.cc sobre contadores de tiempo es l método “expire ( )”. Poner esto en ejecución es bastante fácil porque deseamos solamente enviar un paquete nuevo de control y cambiar la hora del contador de tiempo. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 69 de 192 protoname/protoname.cc 1: void 2: Protoname_PktTimer::expire(Event* e) { 3: agent_->send_protoname_pkt(); 4: agent_->reset_protoname_pkt_timer(); 5: } 5.5.- AGENTE. 5.5.1.- CONSTRUCTOR. Comencemos con la puesta en practica del constructor, como podemos ver en la línea 1, nosotros empezaremos llamando a el constructor para pasarle PT_Protoname como argumento. Esta constante será definida más adelante y será usada para identificar paquetes de control enviados y recibidos por el agente enrutador. En la misma línea nosotros creamos nuestro objeto Protoname_PktTimer. La línea 3 guarda el identificador dado como una dirección del agente enrutador. protoname/protoname.cc 1: Protoname::Protoname(nsaddr_t id) : Agent(PT_PROTONAME), pkt_timer_(this) { 2: bind_bool("accessible_var_", &accessible_var_); 3: ra_addr_ = id; 4: } 5.5.2.- COMMAND ( ). El siguiente código es algo mas complejo, consiste en la puesta en marcha del método command ( ). protoname/protoname.cc 1: int 2: Protoname::command(int argc, const char*const* argv) { 3: if (argc == 2) { 4: if (strcasecmp(argv[1], "start") == 0) { Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 70 de 192 5: pkt_timer_.resched(0.0); 6: return TCL_OK; 7: } 8: else if (strcasecmp(argv[1], "print_rtable") == 0) { 9: if (logtarget_ != 0) { 10: sprintf(logtarget_->pt_->buffer(), "P %f _%d_ Routing Table", 11: CURRENT_TIME, 12: ra_addr()); 13: logtarget_->pt_->dump(); 14: rtable_.print(logtarget_); 15: } 16: else { 17: fprintf(stdout, "%f _%d_ If you want to print this routing table " 18: "you must create a trace file in your tcl script", 19: CURRENT_TIME, 20: ra_addr()); 21: } 22: return TCL_OK; 23: } 24: } 25: else if (argc == 3) { 26: // Obtains corresponding dmux to carry packets to upper layers 27: if (strcmp(argv[1], "port-dmux") == 0) { 28: dmux_ = (PortClassifier*)TclObject::lookup(argv[2]); 29: if (dmux_ == 0) { 30: fprintf(stderr, "%s: %s lookup of %s failed\n", 31: __FILE__, 32: argv[1], 33: argv[2]); 34: return TCL_ERROR; 35: } 36: return TCL_OK; 37: } 38: // Obtains corresponding tracer 39: else if (strcmp(argv[1], "log-target") == 0 || 40: strcmp(argv[1], "tracetarget") == 0) { 41: logtarget_ = (Trace*)TclObject::lookup(argv[2]); 42: if (logtarget_ == 0) 43: return TCL_ERROR; 44: return TCL_OK; 45: } 46: } 47: // Pass the command to the base class 48: return Agent::command(argc, argv); 49: } Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 71 de 192 5.5.3.- recv ( ). La función siguiente es la función recv ( ) y como sabemos se invoca siempre que el agente de encaminamiento recibe un paquete. Cada paquete tiene una cabecera llamada hdr_cmn definida en common/packet.h. Para tener acceso a esta cabecera hay un macro que nosotros definimos antes para nuestro propio tipo de paquete y nosotros usamos en la línea 3 del siguiente código, en la línea 4 hacemos igual para conseguir la IP, hdr_ip está descrito en ip.h. 1: void 2: Protoname::recv(Packet* p, Handler* h) { 3: struct hdr_cmn* ch = HDR_CMN(p); 4: struct hdr_ip* ih = HDR_IP(p); 5: 6: if (ih->saddr() == ra_addr()) { 7: // Si existe un bucle, debe caer el paquete 8: if (ch->num_forwards() > 0) { 9: drop(p, DROP_RTR_ROUTE_LOOP); 10: return; 11: } 12: // si esto es un paquete que estoy generando debe añadir la ip 13: else if (ch->num_forwards() == 0) 14: ch->size() += IP_HDR_LEN; 15: } 16: 17: // si es un paquete del protoname debe ser procesado 18: if (ch->ptype() == PT_PROTONAME) 19: recv_protoname_pkt(p); 20: // de esta manera debemos remitir el paquete ( a menos que la TTL alcance 0) 21: else { 22: ih->ttl_--; 23: if (ih->ttl_ == 0) { 24: drop(p, DROP_RTR_TTL); 25: return; 26: } 27: forward_data(p); 28: } 29: } Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 72 de 192 Lo primero que deberíamos hacer es comprobar si no recibimos un paquete que enviamos nosotros mismos. Si es esto lo que ocurre entonces deberíamos dejar caer el paquete y retornar, como hacemos en las líneas 8-11. Además si el paquete ha sido generado dentro del nodo (por las capas superiores del nodo) nosotros deberíamos añadir a la longitud del paquete el número de bytes que añadiría el protocolo de encaminamiento. Cuando el paquete recibido es del tipo PROTONAME entonces llamaremos a la función pkt( ) del protoname del recv para procesarlo (líneas 18-19). Si es un paquete de datos entonces debemos remitirlo, si es destinado lo entregamos al siguiente nodo o lo entregaremos a los niveles altos en caso de que el destinatario sea ese mismo nodo. También podemos observar la función drop ( ) que la utilizaremos cuando tengamos que desechar paquetes, sus argumentos son unas constantes que indican la razón de desechar el paquete. 5.5.4.- recv_protoname_pkt ( ). Asumimos que el agente de enrutamiento ha recibido un paquete protoname, construyendo el recv_protoname_pkt ( ) para ser invocado. La implementación de esta función variará dependiendo del tipo de protocolo que implementemos, pero nosotros podremos ver un esquema general en el siguiente ejemplo. Las líneas 3 y 4 nos muestran como conseguir la cabecera IP y la cabecera del paquete protoname, después de esto construiremos los puertos fuente y destino RT_PORT en las líneas 8-9. Estas constantes son definidas en commond/packet.h y son iguales 255. Después de esto el paquete protoname debe ser procesado de acuerdo a la especificación de nuestro protocolo de encaminamiento. 1: void 2: Protoname::recv_protoname_pkt(Packet* p) { 3: struct hdr_ip* ih = HDR_IP(p); Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 73 de 192 4: struct hdr_protoname_pkt* ph = HDR_PROTONAME_PKT(p); 5: 6: // All routing messages are sent from and to port RT_PORT, 7: // so we check it. 8: assert(ih->sport() == RT_PORT); 9: assert(ih->dport() == RT_PORT); 10: 11: /* ... procesamiento del paquete protoname ... */ 12: 13: // Release resources 14: Packet::free(p); 15: } 5.5.5.- send_protoname_pkt ( ). protoname/protoname.cc 1: void 2: Protoname::send_protoname_pkt() { 3: Packet* p = allocpkt(); 4: struct hdr_cmn* ch = HDR_CMN(p); 5: struct hdr_ip* ih = HDR_IP(p); 6: struct hdr_protoname_pkt* ph = HDR_PROTONAME_PKT(p); 7: 8: ph->pkt_src() = ra_addr(); 9: ph->pkt_len() = 7; 10: ph->pkt_seq_num() = seq_num_++; 11: 12: ch->ptype() = PT_PROTONAME; 13: ch->direction() = hdr_cmn::DOWN; 14: ch->size() = IP_HDR_LEN + ph->pkt_len(); 15: ch->error() = 0; 16: ch->next_hop() = IP_BROADCAST; 17: ch->addr_type() = NS_AF_INET; 18: 19: ih->saddr() = ra_addr(); 20: ih->daddr() = IP_BROADCAST; 21: ih->sport() = RT_PORT; 22: ih->dport() = RT_PORT; 23: ih->ttl() = IP_DEF_TTL; 24: 25: Scheduler::instance().schedule(target_, p, JITTER); 26: } Para enviar un paquete nosotros necesitamos primero asignarlo, usaremos la función allocpkt ( ) para realizar esta tarea. Esta función es definida para todos los Agents, luego nosotros comúnmente conseguiremos la IP y las cabeceras de los Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 80 de 192 1: u_int32_t 2: protoname_rtable::size() { 3: return rt_.size(); 4: } 5.7.- CAMBIOS NECESARIOS PARA ADAPTAR EL CODIGO. Casi hemos terminado con el ejemplo de nuestro protocolo, ya hemos puesto en ejecución un agente de encaminamiento para el protocolo “protoname”. Pero hay algunos cambos que necesitamos hacer para integrar nuestro código dentro del simulador. 5.7.1.- DECLARACIÓN DEL TIPO DE PAQUETE. Encontraremos numeración packet_t, donde todos los tipos de paquetes están visibles en una lista. Entonces añadiremos PT_PROTONAME a la lista como mostramos en el siguiente código (línea 6). common/packet.h 1: enum packet_t { 2: PT_TCP, 3: PT_UDP, 4: PT_CBR, 5: /* ...todos los tipos de paquetes... */ 6: PT_PROTONAME, 7: PT_NTYPE // This MUST be the LAST one 8: }; La siguiente pieza de código nos servirá para asignar un nombre más sencillo a nuestro nuevo tipo de paquete, para hacer un mejor manejo a la hora de realizar los scripts en tcl. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 81 de 192 common/packet.h 1: p_info() { 2: name_[PT_TCP]= "tcp"; 3: name_[PT_UDP]= "udp"; 4: name_[PT_CBR]= "cbr"; 5: /* ... muchos más nombres ... */ 6: name_[PT_PROTONAME]= "protoname"; 7: } 5.7.2.- TRACING SUPPORT. Dado que el objetivo de la simulación es tratar de describir lo que ocurre durante la ejecución mediante e archivo rastro. Utilizaremos un objeto Trace para escribir toda la información de los paquetes todo el tiempo, si es recibido, enviado o descartado. Para registrar la información de nuestro tipo de paquete, implementaremos la función format_protoname ( ) dentro de la clase CMUTrace. Agregaremos la función en la línea 6 del siguiente código. trace/cmu-trace.h 1: class CMUTrace : public Trace { 2: /* ... definiciones ... */ 3: private: 4: /* ... */ 5: void format_aodv(Packet *p, int offset); 6: void format_protoname(Packet *p, int offset); 7: }; La siguiente pieza de código (extraída de trace/cmu_trace.cc) muestra diferentes tipos e trazas. trace/cmu-trace.cc 1: #include <protoname/protoname_pkt.h> 2: 3: /* ... */ 4: 5: void 6: CMUTrace::format_protoname(Packet *p, int offset) 7: { 8: struct hdr_protoname_pkt* ph = HDR_PROTONAME_PKT(p); 9: 10: if (pt_->tagged()) { Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 82 de 192 11: sprintf(pt_->buffer() + offset, 12: "-protoname:o %d -protoname:s %d -protoname:l %d ", 13: ph->pkt_src(), 14: ph->pkt_seq_num(), 15: ph->pkt_len()); 16: } 17: else if (newtrace_) { 18: sprintf(pt_->buffer() + offset, 19: "-P protoname -Po %d -Ps %d -Pl %d ", 20: ph->pkt_src(), 21: ph->pkt_seq_num(), 22: ph->pkt_len()); 23: } 24: else { 25: sprintf(pt_->buffer() + offset, 26: "[protoname %d %d %d] ", 27: ph->pkt_src(), 28: ph->pkt_seq_num(), 29: ph->pkt_len()); 30: } 31: } Podemos deducir del anterior código que hay tres tipos de formatos para los archivos traza: traza marcadas con etiquetas, trazas con nuevo formato y trazas clásicas. La sintaxis seguida para cada uno, aunque es diferente es muy fácil e intuitiva. Para llamar a esta función que hemos creado anteriormente debemos cambiar la función format ( ) en trace/cmu_trace.cc. trace/cmu-trace.cc 1: void 2: CMUTrace::format(Packet* p, const char *why) 3: { 4: /* ... */ 5: case PT_PING: 6: break; 7: 8: case PT_PROTONAME: 9: format_protoname(p, offset); 10: break; 11: 12: default: 13: /* ... */ 14: } Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 83 de 192 5.7.3.- LIBRERÍA TCL. Ahora nosotros una vez terminado la parte más dura, es decir programar el protocolo, lo siguiente y ultimo que debemos hacer es llevar a cabo algunos cambios en los archivos TCL. A continuación vamos a añadir nuestro tipo de paquete que hemos programado especialmente para el protocolo “protoname”. Para ello nos situaremos en tcl/lib/ns_packet.tcl debemos localizar el siguiente código y añadir protoname a la lista (en nuestro caso lo colocaremos en la línea 2) ya que vimos en common/packet.h como simplificábamos el nombre del paquete a “protoname”. tcl/lib/ns-packet.tcl 1: foreach prot { 2: Protoname 3: AODV 4: ARP 5: # ... 6: NV 7: } { 8: add-packet-header $prot 9: } Los valores por defecto tenemos que introducirlos dentro de tcl/lib/ns_default.tcl. Debemos ir al final del archivo y escribir algo como el siguiente código. tcl/lib/ns-default.tcl 1: # ... 2: # Defaults defined for Protoname 3: Agent/Protoname set accessible_var_ true Finalmente tenemos que modificar tcl/lib/ns_lib.tcl. Nosotros necesitamos añadir los procedimientos para crear un nodo. Nuestro interés se centrará en crear un nodo wireless con “protoname” como protocolo de enrutamiento. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 84 de 192 tcl/lib/ns-lib.tcl 1: Simulator instproc create-wireless-node args { 2: # ... 3: switch -exact $routingAgent_ { 4: Protoname { 5: set ragent [$self create-protoname-agent $node] 6: } 7: # ... 8: } 9: # ... 10: } Luego create_protoname_agent será código cifrado como mostramos en el siguiente ejemplo. tcl/lib/ns-lib.tcl 1: Simulator instproc create-protoname-agent { node } { 2: # Create Protoname routing agent 3: set ragent [new Agent/Protoname [$node node-addr]] 4: $self at 0.0 "$ragent start" 5: $node set ragent_ $ragent 6: return $ragent 7: } La línea 3 crea un nuevo agente protoname con la dirección del nodo. Este agente es programado para empezar la simulación (línea 4) y es asignado el agente enrutador del nodo en la línea 5. 5.7.4ORDEN DE PRIORIDAD. A la hora de dar paso a una simulación debemos aplicar algún método para dar prioridad a los paquetes dentro de la cola. Es decir gestionaron los paquetes de alta prioridad insertándolos al principio de la cola. Pero necesitamos decirle a la clase priQueue que paquetes son de enrutamiento normal y cuales de alta prioridad. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 85 de 192 Debemos modificar la función recv ( ), función que encontraremos en el archivo queue/priqueue.cc. En la línea 13 veremos la única modificación que haremos a la siguiente pieza de código. queue/priqueue.cc 1: void 2: PriQueue::recv(Packet *p, Handler *h) 3: { 4: struct hdr_cmn *ch = HDR_CMN(p); 5: 6: if (Prefer_Routing_Protocols) { 7: 8: switch(ch->ptype()) { 9: case PT_DSR: 10: case PT_MESSAGE: 11: case PT_TORA: 12: case PT_AODV: 13: case PT_PROTONAME: 14: recvHighPriority(p, h); 15: break; 16: 17: default: 18: Queue::recv(p, h); 19: } 20: } 21: else { 22: Queue::recv(p, h); 23: } 24 24: } Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 86 de 192 CAPÍTULO 6 RIP EN EL SIMULADOR Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 87 de 192 6.- RIP EN NS2. Network Simulator [18] puede simular enlaces caídos, desconectando en un cierto intervalo de tiempo. Para simular una desconexión de un enlace entre dos nodos para un intervalo de tiempo por ejemplo de 1 a 4,5 segundos, nosotros deberíamos programar el siguiente código: $ns rtmodel-at 1.0 down $n1 $n4 $ns rtmodel-at 4.0 up $n1 $n4 #distvec1.tcl set ns [new Simulator] $ns rtproto DV set nf [open distvec1.nam w] $ns namtrace-all $nf proc finish { } { global ns nf $ns flush-trace close $nf exec nam distvec1.nam & exit 0 } set n0 [$ns node] $n0 color "green" set n1 [$ns node] $n1 color "blue" set n2 [$ns node] $n2 color "darkcyan" set n3 [$ns node] set n4 [$ns node] $n4 color "violet" $ns duplex-link $n0 $n1 1Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 10ms DropTail $ns duplex-link $n2 $n3 1Mb 10ms DropTail $ns duplex-link $n3 $n4 1Mb 10ms DropTail #Nivel de transporte Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 88 de 192 set udp1 [new Agent/UDP] $ns attach-agent $n1 $udp1 $udp1 set fid_ 1 $ns color 1 blue set udp2 [new Agent/UDP] $ns attach-agent $n2 $udp2 $udp2 set fid_ 2 $ns color 2 darkcyan set udp4 [new Agent/UDP] $ns attach-agent $n4 $udp4 $udp4 set fid_ 4 $ns color 4 violet set null0 [new Agent/Null] $ns attach-agent $n0 $null0 $ns connect $udp1 $null0 $ns connect $udp2 $null0 $ns connect $udp4 $null0 #Nivel de aplicación set cbr1 [new Application/Traffic/CBR] $cbr1 attach-agent $udp1 set cbr2 [new Application/Traffic/CBR] $cbr2 attach-agent $udp2 set cbr4 [new Application/Traffic/CBR] $cbr4 attach-agent $udp4 puts "DV" puts "0.5 : cbr4 starts" puts "0.6 : link 0-1 down; cbr4 transmite igualmente" puts "0.7 : cbr4 stops" puts "1.0 : link 0-1 up" puts "1.5 : link 0-1 down" puts "1.6 : cbr2 starts; puts "1.8 : cbr2 stops" puts "1.8 : cbr1 starts; #Temporización de la simulación $ns at 0.5 "$cbr4 start" $ns rtmodel-at 0.6 down $n1 $n0 . $ns at 0.7 "$cbr4 stop" $ns rtmodel-at 1.0 up $n1 $n0 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 89 de 192 $ns rtmodel-at 1.5 down $n1 $n0 $ns at 1.6 "$cbr2 start" $ns at 1.8 "$cbr2 stop" $ns at 1.8 "$cbr1 start" #n1 el unico que no envía paquetes $ns at 2.0 "finish" $ns run Al poder eliminar enlaces a intervalos de tiempo para después poder reestablecerlos podremos comprobar el funcionamiento del algoritmo vector distancia, que es el que utiliza RIP por lo tanto podremos analizar el protocolo, en el código anterior lo que hemos hecho ha sido, en una topología en anillo con cinco nodos haremos caer un enlace, y podremos ver como los nodos empiezan a enviarse paquetes de control con las nuevas distancias entre vecinos, pero como no hay ruta alternativa seguirán así hasta que se vuelva a restablecer el enlace. Figura 13. Evaluación del protocolo DV anulando un link Con las tres imágenes anteriores podemos apreciar como en esta topología primero se crean las tablas de encaminamiento enviando los paquetes de control, entonces cada nodo crea su propia tabla con la distancia a todos los demás nodos. En la segunda imagen podemos ver como empiezan a enviar información desde 0 a 4 para después de un cierto tiempo cae el enlace entre 0 y 1 y se vuelven a enviar paquetes de control para recalcular rutas. A continuación añadiendo una línea de código veremos uno de los principales problemas que tiene este protocolo, que es el conteo a infinito y la formación de bucles. El código que añadiremos será el necesario para crear un enlace entre el nodo 2 y 4, Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 96 de 192 Ahora veremos en la figura 18 otro gráfico (que hace referencia a la simulación de la figura 14), donde se nos muestra el número de bits perdidos durante la simulación, aquí podremos apreciar como se pierden bits (paquetes) de los nodos 4, 2 y 1 enviados al nodo 0, esto se produce desde el momento en que cae el enlace 10, hasta que se vuelve a restaurar dicho enlace. Figura 18. Número de bits perdidos. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 97 de 192 CAPÍTULO 7 OSPF EN EL SIMULADOR Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 98 de 192 7.- OSPF EN NS2. OSPF [16] [18] usa el costo como métrica para determinar la ruta óptima. Cada router tendrá distintas salidas o interfaces que conectarán a su vez con otros routers de la red, cada interface tendrá asignado un determinado coste. En el simulador Network Simulator 2 es posible cambiar los costes de cada enlace, a la vez que podremos remarcar la velocidad en Mbps de cada link. De esta manera, el protocolo utilizará esos parámetros que introduciremos en el script para crear las tablas de enrutamiento de cada nodo. Así cada nodo conseguirá conocer la ruta óptima a todos los nodos de la topología. Previamente antes de conocer las rutas óptimas, el protocolo OSPF se encargará de que cada nodo envíe los paquetes “hello” de manera multicast. Esto quiere decir que cada nodo enviará dicho paquete por todos sus interfaces o puertos. Este paquete esta recogido dentro del protocolo HELLO, que es un protocolo de adyacencia. El protocolo HELLO se usa para establecer y mantener vecindades, sobre redes multiacceso elegidas por un router determinado. En redes tipo broadcast cada router envía paquetes HELLO multicast. Sobre redes "no broadcast" los mensajes HELLO son enviados a una lista configurada de routers designados potenciales. Para hacer una adyacencia dos vecinos primero sincronizan sus bases de datos por medio del database exchange process. Este es un intercambio de secuencia de información con una relación master/slave entre dos routers (el master será el router del ID más alto). Después de este proceso cada router tiene una lista de avisos de link state más recientes de su vecino, siendo estos solicitados con el link state request. Cuando se completa los dos routers han completado la adyacencia plenamente y la han avisado como tal. La adyacencia queda establecida si: · La red es punto a punto. · La red es un enlace virtual Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 99 de 192 · El router es un router designado · El vecino es un router designado · El vecino es un router designado como backup A continuación mostraremos el proceso de enviar los paquetes “HELLO” mediante la herramienta del simulador NAM. Pero antes mostraremos la manera de programar el script para el protocolo OSPF. La tipología del script para OSPF será la siguiente: • Instanciar el simulador y crear los archivos traza. • Crear los nodos o routers con todos los enlaces con sus correspondiente ancho de banda y tipo de cola, resumiendo a esto lo llamaremos crear la topología de red. • Crear los agentes de transporte, aplicación y nodos receptores. • Algo muy importante será determinar los costes de los enlaces, esto lo elegirá el usuario atendiendo a diversos criterios como ancho de banda del enlace tipo de agente de transporte etc… • Por ultimo programar temporalmente la simulación, es decir, debemos indicar duración total de la simulación (indicándole el instante donde comienza y el instante donde termina), instantes exactos donde cada nodo empezará transmitir información a un nodo destino, caídas de enlace , restauraciones de enlaces caidos y por ultimo poner el comando “run” que será el que nos ejecute el script en el simulador. El script que veremos a continuación cumple todos los requisitos anteriormente descritos, en el incluiremos el algoritmo de Dijkstra. #Dijkstra.tcl set ns [new Simulator] set nf [open routeStatic.nam w] $ns namtrace-all $nf #Defino el protocolo de enrutamiento que utilizaran todos los nodos Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 100 de 192 #$ns rtproto Static proc finish {} { global ns nf $ns flush-trace close $nf exec nam routeStatic.nam & exit 0 } #Creación de la topología for {set i 0} {$i < 6} {incr i} { set n($i) [$ns node] } for {set i 0 } {$i < 6} {incr i} { $ns duplex-link $n($i) $n([expr ($i+1)%6]) 1Mb 10ms DropTail } $ns duplex-link $n(0) $n(4) 1Mb 10ms DropTail #Coste de los enlaces $ns cost $n(0) $n(1) 2 $ns cost $n(1) $n(0) 2 $ns cost $n(1) $n(2) 1 $ns cost $n(2) $n(1) 1 $ns cost $n(2) $n(3) 5 $ns cost $n(3) $n(2) 5 $ns cost $n(3) $n(4) 10 $ns cost $n(4) $n(3) 10 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 101 de 192 $ns cost $n(4) $n(5) 10 $ns cost $n(5) $n(4) 10 $ns cost $n(5) $n(0) 10 $ns cost $n(0) $n(5) 10 $ns cost $n(4) $n(0) 10 $ns cost $n(0) $n(4) 10 #Monitorización de la cola en el enlace 0 4 $ns duplex-link-op $n(0) $n(4) queuePos 0.5 $ns queue-limit $n(0) $n(4) 10 #Nivel de transporte set udp0 [new Agent/UDP] $ns attach-agent $n(0) $udp0 $udp0 set fid_ 0 $ns color 0 darkgreen set udp1 [new Agent/CBR] $ns attach-agent $n(1) $udp1 $udp1 set fid_ 1 $ns color 1 red #Destinatario set null4 [new Agent/Null] $ns attach-agent $n(4) $null4 #set loss0 [new Agent/LossMonitor] #$ns attach-agent $n(0) $loss0 #$ns connect $cbr1 $loss0 $ns connect $udp0 $null4 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 102 de 192 $ns connect $udp1 $null4 #Nivel de aplicación set cbr0 [new Application/Traffic/CBR] $cbr0 attach-agent $udp0 set cbr1 [new Application/Traffic/CBR] $cbr1 attach-agent $udp1 #Comentarios puts "\n\n##### COMENTARIO #####\n" puts "0.1 :cbr0 starts" puts "0.3 :cbr1 starts" puts "0.7 :link 0-4 down" puts "1 :link 0-4 up\n" #Temporización de la simulación $ns at 0.1 "$cbr0 start" $ns at 0.3 "$cbr1 start" $ns rtmodel-at 0.7 down $n(0) $n(4) $ns rtmodel-at 1 up $n(0) $n(4) $ns at 1.5 "finish" $ns run En el ejemplo anterior a pesar de utilizar el algoritmo de dijkstra no podemos equipararlo con el protocolo ospf ya que ante cambios de topologías no se producen cambios en las tablas de enrutamiento. A continuación mostraremos las figuras con los resultados obtenidos para el nam. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 103 de 192 Figura 19. Dijkstra.tcl En esta figura podemos apreciar como el se envían paquetes de 04 y de 14 utilizando la ruta de menor coste, esto lo podemos apreciar en el código anteriormente programado, donde hemos puesto los costes de cada enlace. Figura 20. Dijkstra.tcl con enlace caido En esta otra figura vemos como en el segundo 0,74 el enlace 04 cae, por lo que los paquetes que estaban por enviar en ese link caen. El nodo 1 sigue enviando paquetes a cuatro a través de 0 ya que no existe actualización de tablas de enrutamiento. Una vez visto el algoritmo de Dijkstra en tcl, ahora veremos el protocolo OSPF con las ventajas y desventajas que presenta. Para indicarle al simulador ns2 compilado para Windows xp que utilizaremos el protocolo de link state para nuestra simulación deberemos hacer una llamada al agente Agent/rtprotoSession. Una vez indicado que utilizaremos este agente, es muy importante indicar todos los costes entre los enlaces de Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 104 de 192 la topología sobre la que ejecutaremos la simulación. Ya que así crearemos inicialmente unas tablas de enrutamiento necesarias para que el protocolo cumpla su función. A continuación mostraremos una topología de 26 nodos adjunta en el anexo, a la cual aplicaremos el protocolo ospf. #OSPF.tcl# set ns [new Simulator] #Activar las trazas set tf [open outospf.tr w] $ns trace-all $tf set nf [open outospf.nam w] $ns namtrace-all $nf #Utilizzo il protocollo di routing Session $ns rtproto Session proc finish {} { global ns nf $ns flush-trace close $nf exec nam routeSession.nam & exit 0 } #UNA VEZ REALIZADOS LOS PASOS PERTINENTES PARA INICIALIZAR EL SCRIPTS ESCRIBIREMOS LA TOPOLOGIA #COMO TENEMOS UNA TOPOLOGÍA GRANDE CON 30 NODOS. for {set i 0} {$i<30} {incr i} { set n($i) [$ns node] } #EL SIGUIENTE PASO ES UNIR PRIMERO LOS NODOS QUE ESTAN UNIDOS DE FORMA CIRCULAR, QUE SON LOS NODOS DEL 1 AL 21 for {set i 0} {$i<21} {incr i} { $ns duplex-link $n($i) $n([expr ($i+1)%21]) 1Mb 4ms DropTail } #AHORA HAREMOS LAS DEMAS CONEXIONES #"""""""""""""""""""""""""""""""" $ns duplex-link $n(0) $n(21) 1Mb 4ms DropTail $ns duplex-link $n(1) $n(21) 1Mb 4ms DropTail Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 105 de 192 $ns duplex-link $n(1) $n(22) 1Mb 4ms DropTail $ns duplex-link $n(2) $n(22) 1Mb 4ms DropTail $ns duplex-link $n(2) $n(23) 1Mb 4ms DropTail $ns duplex-link $n(3) $n(23) 1Mb 4ms DropTail $ns duplex-link $n(3) $n(24) 1Mb 4ms DropTail $ns duplex-link $n(4) $n(24) 1Mb 4ms DropTail $ns duplex-link $n(4) $n(25) 1Mb 4ms DropTail $ns duplex-link $n(5) $n(25) 1Mb 4ms DropTail $ns duplex-link $n(5) $n(26) 1Mb 4ms DropTail $ns duplex-link $n(6) $n(26) 1Mb 4ms DropTail $ns duplex-link $n(6) $n(27) 1Mb 4ms DropTail $ns duplex-link $n(7) $n(27) 1Mb 4ms DropTail $ns duplex-link $n(7) $n(28) 1Mb 4ms DropTail $ns duplex-link $n(8) $n(28) 1Mb 4ms DropTail $ns duplex-link $n(8) $n(29) 1Mb 4ms DropTail $ns duplex-link $n(9) $n(29) 1Mb 4ms DropTail $ns duplex-link $n(9) $n(10) 1Mb 4ms DropTail $ns duplex-link $n(29) $n(11) 1Mb 4ms DropTail $ns duplex-link $n(29) $n(12) 1Mb 4ms DropTail $ns duplex-link $n(28) $n(12) 1Mb 4ms DropTail $ns duplex-link $n(28) $n(13) 1Mb 4ms DropTail $ns duplex-link $n(27) $n(13) 1Mb 4ms DropTail $ns duplex-link $n(27) $n(14) 1Mb 4ms DropTail $ns duplex-link $n(26) $n(14) 1Mb 4ms DropTail $ns duplex-link $n(26) $n(15) 1Mb 4ms DropTail $ns duplex-link $n(25) $n(15) 1Mb 4ms DropTail $ns duplex-link $n(25) $n(16) 1Mb 4ms DropTail $ns duplex-link $n(24) $n(16) 1Mb 4ms DropTail $ns duplex-link $n(24) $n(17) 1Mb 4ms DropTail $ns duplex-link $n(23) $n(17) 1Mb 4ms DropTail $ns duplex-link $n(23) $n(18) 1Mb 4ms DropTail $ns duplex-link $n(22) $n(18) 1Mb 4ms DropTail $ns duplex-link $n(22) $n(19) 1Mb 4ms DropTail $ns duplex-link $n(21) $n(19) 1Mb 4ms DropTail Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 112 de 192 Figura 22. ospf.tcl con enlaces caidos Para el instante 0,8 segundos, hemos programado que el enlace 43 caiga. Esto tendrá consecuencias para el envío de paquetes 260, ya que tendrá que recalcular la ruta para al final obtener la trayectoria 416173. Esto tendrá un coste total de 7, dos más que en la ruta inicial. Pero esta no será la ruta final, ya que por aquí solo se enrutarán los paquetes que se estaban procesando en el nodo cuatro. Además se perderán los datos que circulaban en el instante 0,7 segundos por el enlace 43. Los paquetes que salen después de caer el enlace 43 se enviarán por 251516173210. Además en la siguiente figura mostraremos el momento en que cae el enlace entre 21, hemos hecho caer este enlace ya que es aquí donde se concentra todo el tráfico que proviene de 18 y de 26. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 113 de 192 Figura 23. Redireccionamiento por caídas de enlace A continuación mostraremos una topología que vimos en el punto anterior para el protocolo RIP, con la cual vimos la gran desventaja de este protocolo del conteo a infinito. Ahora con OSPF sobre esta topología veremos que ocurre al caer un enlace y ser imposible alcanzar el nodo destino. El código es el siguiente: #dvmodificado.tcl set ns [new Simulator] $ns rtproto Session set nf [open distvec1.nam w] $ns namtrace-all $nf set tf [open out.tr w] $ns trace-all $tf proc finish { } { Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 114 de 192 global ns nf $ns flush-trace close $nf exec nam distvec1.nam & exit 0 } set n0 [$ns node] $n0 color “green” set n1 [$ns node] $n1 color “blue” set n2 [$ns node] $n2 color “darkcyan” set n3 [$ns node] set n4 [$ns node] $n4 color “violet” $ns duplex-link $n0 $n1 1Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 10ms DropTail $ns duplex-link $n2 $n3 1Mb 10ms DropTail $ns duplex-link $n3 $n4 1Mb 10ms DropTail $ns duplex-link $n2 $n4 1Mb 10ms DropTail $ns cost $n0 $n1 3 $ns cost $n2 $n1 3 $ns cost $n2 $n3 1 $ns cost $n2 $n4 15 $ns cost $n3 $n4 1 #Nivel de transporte set udp1 [new Agent/UDP] $ns attach-agent $n1 $udp1 $udp1 set fid_ 1 $ns color 1 blue Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 115 de 192 set udp2 [new Agent/UDP] $ns attach-agent $n2 $udp2 $udp2 set fid_ 2 $ns color 2 darkcyan set udp4 [new Agent/UDP] $ns attach-agent $n4 $udp4 $udp4 set fid_ 4 $ns color 4 violet set null0 [new Agent/Null] $ns attach-agent $n0 $null0 $ns connect $udp1 $null0 $ns connect $udp2 $null0 $ns connect $udp4 $null0 #Nivel de aplicación set cbr1 [new Application/Traffic/CBR] $cbr1 attach-agent $udp1 set cbr2 [new Application/Traffic/CBR] $cbr2 attach-agent $udp2 set cbr4 [new Application/Traffic/CBR] $cbr4 attach-agent $udp4 #Temporización de la simulación $ns at 0.5 “$cbr4 start” $ns rtmodel-at 0.6 down $n1 $n0 . Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 116 de 192 $ns at 0.7 “$cbr4 stop” $ns rtmodel-at 1.0 up $n1 $n0 $ns rtmodel-at 184.0 down $n1 $n0 $ns at 1.6 “$cbr2 start” $ns at 1.8 “$cbr2 stop” $ns at 1.8 “$cbr1 start” $ns at 190.0 “finish” $ns run El resultado que obtendremos con el nam será el siguiente: Figura 24. No se producen bucles Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 117 de 192 En esta figura podemos apreciar como no se produce conteo a infinito, si no que a pesar de haber caído el enlace 01 el nodo 4 sigue enviando paquetes, pero no se producirá ningún bucle. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 118 de 192 CAPÍTULO 8 REDES INALÁMBRICAS AD-HOC Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 119 de 192 8.- REDES INALÁMBRICAS. 8.1.-Introducción. Dentro del sector de las redes inalámbricas nos centraremos en las redes móviles ad-hoc o MANET [18] (Mobile Adhoc NETwork), también denominadas redes de sensores. El auge de esta tecnología se debe principalmente a que este tipo de redes se componen de terminales inalámbricos móviles que se comunican entre si, sin la necesidad de ninguna infraestructura previamente desplegada. Debido al corto alcance de la tecnología inalámbrica, cuando la comunicación se establece entre terminales demasiado alejados, son los demás dispositivos de la red los que se encargan de hacer de puente entre esos 2 dispositivos, a la vez que hacen de dispositivos de enrutamiento. De acuerdo a la forma de elegir los dispositivos intermedios así como la forma de detectar posibles cambios de la topología, podremos distinguir o los distintos protocolos de encaminamiento ad-hoc utilizados. Por un lado tenemos los protocolos proactivos, estos protocolos están basados en que los terminales de red envían periódicamente información de la topología de red. Los protocolos reactivos solo buscan la información necesaria de encaminamiento a la hora de establecer comunicación con otro dispositivo, para ello inundan la red con paquetes de petición de ruta RREQ, los cuales son respondidos por paquetes RREP. Los resultados de utilizar un tipo de protocolo u otro son interesantes remarcarlos, ya que tendremos unos comportamientos de la red totalmente diferentes a la hora de utilizar uno u otro. Así pues es razonable que un protocolo proactivo cargue la red mientras que las pérdidas de paquetes y retrasos sean escasos. El efecto contrario se producirá con un protocolo reactivo. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 120 de 192 8.2.- Redes inalámbricas en NS2. Para llevar a cabo una simulación de red inalámbrica con NS2, el usuario necesitara especificar un escenario inalámbrico donde los dispositivos o nodos poseen una serie de características sencillamente configurables con las siguientes sentencias. $ns_ node-config -addressingType flat or hierarchical or expanded -adhocRouting DSDV or DSR or TORA or AODV -llType LL -macType Mac/802_11 -propType "Propagation/TwoRayGround" -ifqType "Queue/DropTail/PriQueue" -ifqLen 50 -phyType "Phy/WirelessPhy" -antType "Antenna/OmniAntenna" -channelType "Channel/WirelessChannel" -topoInstance $topo -energyModel "EnergyModel" -initialEnergy (in Joules) -rxPower (in W) -txPower (in W) -agentTrace ON or OFF -routerTrace ON or OFF -macTrace ON or OFF -movementTrace ON or OFF El usuario especificará ciertos aspectos de las redes móviles. De esta manera, la configuración del nodo incluye la determinación del nivel MAC a emplear, el tipo de cola, modelo de propagación de la señal así como el tipo de protocolo ad-hoc que seguirán los terminales de red. Si especificamos AODV (Ad hoc Demand Distance Vector) o DSR (Dynamic Source Routing), se podrá realizar el análisis de la red bajo un protocolo reactivo. Por otro lado el empleo de DSDV (Dynamic Destination-Sequence Distance Vector) permite el estudio de protocolos proactivo. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 121 de 192 A la hora de especificar el escenario inalámbrico en el apartado adhocrouting, tendremos que indicar el protocolo que utilizaremos. El simulador soporta cuatro protocolos DSDV, DSR, TORA y AODV. A continuación veremos uno por uno e implementaremos un script para cada uno. 8.2.1.- DSDV. Es una modificación del algoritmo de encaminamiento vector distancia de Bellmand-Ford. En este algoritmo, los nodos están intercambiando periódicamente (proactivo) sus tablas de encaminamiento para determinar en cada momento las distancias entre todos los nodos. DSDV [18] siempre elige el camino más corto basándose en el número de salto hacia ese destino. # DSDV.tcl # ejemplo con 3 nodos para simulación ad-hoc con protocolo DSDV # Define options set val(chan) Channel/WirelessChannel ; # Tipo de canal set val(prop) Propagation/TwoRayGround ;# Modelo de radio-propagation set val(netif) Phy/WirelessPhy ; # Tipo de interface de red set val(mac) Mac/802_11 ; # MAC type set val(ifq) Queue/DropTail/PriQueue ;# Tipo de cola set val(ll) LL ; # link layer type set val(ant) Antenna/OmniAntenna ;# modelo de antena set val(ifqlen) 50 ; # maximo numero de paquetes dentro set val(nn) 3 ; # numero de nodos móviles set val(rp) DSDV ; # routing protocol set val(x) 500 ;# X dimensión del escenario set val(y) 400 ;# Y dimensión del escenario set val(stop) 150 ;# fin de la simulación set ns [new Simulator] set tracefd [open simple.tr w] set windowVsTime2 [open win.tr w] set namtrace [open simwrls.nam w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $val(x) $val(y) # set up topography object Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 128 de 192 8.2.3.- AODV. En este protocolo los nodos poseen una tabla de encaminamiento para los destinos conocidos (empleando el algoritmo vector distancia). Inicialmente esta tabla estará formada por sus vecinos, solamente se le añadirán destinos nuevos cuando sea necesario, es decir cuando un nodo necesite comunicarse con otro que no está en su tabla, entonces inicia un proceso de descubrimiento de ruta hacia el destino concreto. Para ello se emiten mensajes de descubrimiento de ruta RREQ que van propagándose entre todos los nodos de manera similar al DSR [18]. En cambio, aquí los nodos generan una tabla de encaminamiento inversa para que puedan regresar las contestaciones RREP a las solicitudes de ruta al nodo que la originó. # AODV.tcl # ejemplo con 3 nodos de una red ad-hoc AODV # Define options set val(chan) Channel/WirelessChannel ;# Tipo de canal set val(prop) Propagation/TwoRayGround ;# modelo de radio propagación set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC set val(ifq) Queue/DropTail/PriQueue ;# Tipo de cola set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# modelo de antena set val(ifqlen) 50 ;# maximo numero de paquetes dentro set val(nn) 3 ;# numero de nodos set val(rp) AODV ;# routing protocol set val(x) 500 ;# X dimension set val(y) 400 ;# Y dimension set val(stop) 150 ;# fin de la simulación set ns [new Simulator] set tracefd [open simple.tr w] set windowVsTime2 [open win.tr w] set namtrace [open simwrls.nam w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $val(x) $val(y) # objeto topografía set topo [new Topography] $topo load_flatgrid $val(x) $val(y) Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 129 de 192 create-god $val(nn) # # Creamos nn nodos mobiles y los asociamos al canal [$val(nn)] . # # Configuramos los nodos $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace ON for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Posición inicial de los nodos $node_(0) set X_ 5.0 $node_(0) set Y_ 5.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 490.0 $node_(1) set Y_ 285.0 $node_(1) set Z_ 0.0 $node_(2) set X_ 150.0 $node_(2) set Y_ 240.0 $node_(2) set Z_ 0.0 # Generación de movimientos $ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(1) setdest 45.0 285.0 5.0" $ns at 110.0 "$node_(0) setdest 480.0 300.0 5.0" # Conexión TCP entre los nodos n (0) y n(1) set tcp [new Agent/TCP/Newreno] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns attach-agent $node_(0) $tcp Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 130 de 192 $ns attach-agent $node_(1) $sink $ns connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns at 10.0 "$ftp start" # Imprimimos el tamaño de pantalla proc plotWindow {tcpSource file} { global ns set time 0.01 set now [$ns now] set cwnd [$tcpSource set cwnd_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotWindow $tcpSource $file" } $ns at 10.1 "plotWindow $tcp $windowVsTime2" # Definimos la posición inicial de los nodos en el nam for {set i 0} {$i < $val(nn)} { incr i } { # 30 defines the node size for nam $ns initial_node_pos $node_($i) 30 } # Decimos a los nodos cuando empieza la simulación for {set i 0} {$i < $val(nn) } { incr i } { $ns at $val(stop) "$node_($i) reset"; } # fin de la simulación $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.01 "puts \"end simulation\" ; $ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace close $tracefd close $namtrace } $ns run Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 131 de 192 Figura 27. AODV En la imagen anterior podemos apreciar como el nodo 0 y el nodo 2 tienen constancia de que ambos están presentes, tendrá que ser necesario que el nodo 1 entre dentro del radio de cobertura. Entonces el nodo 0 podrá tener conocimiento de la existencia del nodo 1 adjuntándolo así dentro de su tabla de encaminamiento. 8.2.4.- TORA. (Temporally-Ordered Routing Algorithm), es un ejemplo de los protocolos multipath. La principal caracteristica de los protocolos multipath es que mantienen diversas rutas hacia cada destino. # TORA.tcl # 3-nodos ad-hoc para la simulación con protocolo tora . # Definimos las opciones set val(chan) Channel/WirelessChannel ;# tipo de canal set val(prop) Propagation/TwoRayGround ;# radio-propagación modelo set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(ifq) Queue/DropTail/PriQueue ;# tipo de cola Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 132 de 192 set val(ll) LL ;# tipo de enlace set val(ant) Antenna/OmniAntenna ;# modelo de antena set val(ifqlen) 50 ;# max. numero de paquete dentro set val(nn) 4 ;# numero de nodos mobiles set val(rp) TORA ;# routing protocol set val(x) 500 ;# X dimension set val(y) 400 ;# Y dimension set val(stop) 150 ;# final de la simulación set ns [new Simulator] set tracefd [open simple.tr w] set windowVsTime2 [open win.tr w] set namtrace [open simwrls.nam w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $val(x) $val(y) # set up objeto de topografía set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) # # Creamos nn nodos móviles [$val(nn)] y los atamos al canal. # # configuramos los nodos $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace ON for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Posición inicial de los nodos $node_(0) set X_ 5.0 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 133 de 192 $node_(0) set Y_ 5.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 490.0 $node_(1) set Y_ 285.0 $node_(1) set Z_ 0.0 $node_(2) set X_ 150.0 $node_(2) set Y_ 240.0 $node_(2) set Z_ 0.0 $node_(3) set X_ 250.0 $node_(3) set Y_ 240.0 $node_(3) set Z_ 0.0 # Generación de movimientos $ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(1) setdest 45.0 285.0 5.0" $ns at 110.0 "$node_(0) setdest 480.0 300.0 5.0" # Creamos connexion tcp entre nodo 0 y nodo 1 set tcp [new Agent/TCP/Newreno] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns attach-agent $node_(0) $tcp $ns attach-agent $node_(1) $sink $ns connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns at 10.0 "$ftp start" # Imprimimos tamaño de ventana proc plotWindow {tcpSource file} { global ns set time 0.01 set now [$ns now] set cwnd [$tcpSource set cwnd_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotWindow $tcpSource $file" } $ns at 10.1 "plotWindow $tcp $windowVsTime2" # Definimos la posición inicial de los nodos en el nam for {set i 0} {$i < $val(nn)} { incr i } { # 30 tamaño del nodo para el nam $ns initial_node_pos $node_($i) 30 } # Decimos a los nodos cuando empieza la simulación for {set i 0} {$i < $val(nn) } { incr i } { $ns at $val(stop) "$node_($i) reset"; Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 134 de 192 } # Fin de la simulación en nam $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.01 "puts \"end simulation\" ; $ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace close $tracefd close $namtrace } $ns run Figura 28. TORA Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 135 de 192 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 136 de 192 CAPÍTULO 9 CONCLUSIONES. Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 137 de 192 9.- Conclusiones 9.1.-Cumplimiento del objetivo Hemos cubierto completamente los objetivos que nos propusimos al principio. Hemos enseñado al lector a programar su propio protocolo en ns2, hemos creado topologías donde podemos comprobar la funcionalidad de dos protocolos como RIP y OSPF, además de mostrar las principales ventajas y desventajas de los protocolos con el simulador, hemos añadido distintas topologías en el anexo para que el usuario pueda aplicar en cada una de ellas los conocimientos adquiridos mediante la lectura de este proyecto. Hemos introducido dichas prácticas para los alumnos de la EPSG con la intención de fijar conceptos básicos acerca de los protocolos aquí vistos, RIP y OSPF. Una vez hecho un planteamiento teórico a cerca del funcionamiento de estos protocolos los hemos programado en Otcl para generar un script y así poder simularlos con “ns2”, pudiendo visualizarlos con el nam y hacer gráficas utilizando el tracegraph [18]. En estos scripts hemos modificado la topología para poder mostrar con el nam las ventajas y desventajas de estos protocolos a la hora de encaminar los paquetes de control y los paquetes de datos. Y algo también muy importante, hemos introducido al lector a conocer el uso de NAM y TRACEGRAPH para el análisis detenido de las distintas simulaciones, que será muy útil a la hora de analizar las prácticas propuestas en este proyecto o para la simulación de redes en otros proyectos. Por otra parte, hemos hecho un breve inciso sobre las posibilidades del simulador, sobre las redes ad-hoc o de sensores, que se encuentran en alza en estos momentos. Hemos introducido los protocolos que ya vienen adjuntos en las librerías del simulador ns 2.29 como AODV, DSR, DSDV y TORA, dejando la puerta abierta con este proyecto a continuar indagando acerca de este tipo de redes y buscando nuevos protocolos de encaminamiento,. Esta introducción se realiza en el capitulo 5 de este Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 144 de 192 [8] Unicast routing algorithm with multiple quality-of-service parameters, KOUNDINYA K Amarnath (1) ; NEGI Atul (1) ; SASTRY V. N. (2) ; Hsu D. Frank ; Hiraki Kei ; Shen Sherman ; Sudborough Hai ; 1) DCIS University of Hyderabad, INDE (2) IDRBT, INDE [9]Página web Protocolos de enrutamiento y Simulador de tráfico de redes, María Julieta Goitia, David Luis La Red Martínez, http://www.sappiens.com/pdf/comunidades/informatica/SimuRedes.pdf [10]Página web Tutorial de NETWORK SIMULATOR 2. Marc grei´s Tutorial for the UCB/LNCB/VINIT Network Simulator http://www.isi.edu/nsnam/ns/tutorial/index.html [11]Página web Curso de evaluación de performance en redes de Telecomunicación. http://iie.fing.edu.uy/ense/asign/perfredes/2.htm [12] Página web de Instalación de Network Simulator 2 en Windows. Pagina de la Universidad Carlos tercero de Madrid. http://www.it.uc3m.es/~rcalzada/ns/windows/ [13] Página web de Practicas de NS Universidad Politécnica de Madrid, Pagina: Laboratorio DIP y UPM. http://www.lab.dit.upm.es/~labrst/04-05/p.int/pracint.htm [14]Página web de Students homepages at University of Valencia. http://mural.uv.es/jovapin/pg0 [15] Pagina web del Dipartamento di informatica e automociones, Universitá degli Studi Roma Tre. http://www.dia.uniroma3.it [16] http://www.solont.com/z-net/ospf/ospf.htm Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 145 de 192 [17] http://diament.ists.pwr.wroc.pl/~tracegr/sciagnij.php [18] Fall, K. y Varadhan, K. (2002), The NS Manual. http://www.isi.edu/nsnam/ns/doc/index.html. [19]Pagina web del Departamento de radiación electromagnetica, Instituto de fisica aplicacada CSIC. http://w3.iec.csic.es/ursi/articulos_gandia_2005/articulos/TE2/396.pdf [20] Altman, E. y Jiménez, T. (2003), NS Simulator for Beginners, Universidad de Los Andes ULA y Sophia-Antipolis, France . [21] Apuntes de la asignatura Redes y Servicios Telemáticos Autor: Fernando Boronat, Seguí Editorial U.P.V Ref.: 20011595 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 146 de 192 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 147 de 192 ANEXO 1.- TOPOLOGIAS DE RED PARA EL NAM. A continuación veremos algunas topologías [20] que hemos generado en Otcl, obteniendo a posteriori el resultado en el nam. Estas topologías nos servirán mas tarde para generar practicas en el laboratorio. #TOPOLOGIA 1 #ESCRIBIREMOSLOS TCL SCRIPTS EN CUALQUIER EDITOR DE TEXTO #CREAMOS UN OBJETO SIMULADOR set ns [new Simulator] #Define different colours for data flows (for NAM) $ns color 1 Blue $ns color 2 Red #ABRIMOS UN ARCHIVO NAM TRACE DATA set nf [open out.nam w] $ns namtrace-all $nf #EL SIGUIENTE PASO AÑADE UN PROCEDIMIENTO FINAL QUE CIERRA EL ARCHIVO TRAZA Y COMIENZA EL NAM proc finish {} { global ns nf $ns flush-trace close $nf exec nam out.nam & exit 0 } #UNA VEZ REALIZADOS LOS PASOS PERTINENTES PARA INICIALIZAR EL SCRIPTS ESCRIBIREMOS LA TOPOLOGIA Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 148 de 192 #COMO TENEMOS UNA TOPOLOGÍA GRANDE CON 30 NODOS UTILIZAREMOS COMANDOS DE C++ COMO EL for for {set i 0} {$i<30} {incr i} { set n($i) [$ns node] } #YA TENEMOS LOS 30 NODOS CREADOS AHORA LOS CONECTAREMOS PARAA CREAR UNA TOPOLOGIA CIRCULAR for {set i 0} {$i<30} {incr i} { $ns duplex-link $n($i) $n([expr ($i+1)%30]) 1Mb 2ms DropTail } #DAMOS LA POSICIÓN A LOS NODOS PARA EL NAM $ns duplex-link-op $n(0) $n(1) orient right $ns duplex-link-op $n(1) $n(2) orient right $ns duplex-link-op $n(2) $n(3) orient right $ns duplex-link-op $n(3) $n(4) orient right $ns duplex-link-op $n(4) $n(5) orient right $ns duplex-link-op $n(5) $n(6) orient right $ns duplex-link-op $n(6) $n(7) orient right $ns duplex-link-op $n(7) $n(8) orient right $ns duplex-link-op $n(8) $n(9) orient right $ns duplex-link-op $n(9) $n(10) orient right $ns duplex-link-op $n(10) $n(11) orient right $ns duplex-link-op $n(11) $n(12) orient right $ns duplex-link-op $n(12) $n(13) orient right $ns duplex-link-op $n(13) $n(14) orient right $ns duplex-link-op $n(14) $n(15) orient down Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 149 de 192 $ns duplex-link-op $n(15) $n(16) orient left $ns duplex-link-op $n(16) $n(17) orient left $ns duplex-link-op $n(17) $n(18) orient left $ns duplex-link-op $n(18) $n(19) orient left $ns duplex-link-op $n(19) $n(20) orient left $ns duplex-link-op $n(20) $n(21) orient left $ns duplex-link-op $n(21) $n(22) orient left $ns duplex-link-op $n(22) $n(23) orient left $ns duplex-link-op $n(23) $n(24) orient left $ns duplex-link-op $n(24) $n(25) orient left $ns duplex-link-op $n(25) $n(26) orient left $ns duplex-link-op $n(26) $n(27) orient left $ns duplex-link-op $n(27) $n(28) orient left $ns duplex-link-op $n(28) $n(29) orient left $ns duplex-link-op $n(29) $n(0) orient up #AHORA ENVIAREMOS DATOS DEL NODO 0 A UN NODO DE LA TOPOLOGÍA #CREAMOS UN AGENTE UDP Y LO ASOCIAMOS AL NODO N0 set udp0 [new Agent/UDP] #ASIGNO EL NOMBRE udp0 AL AGENTE $ns attach-agent $n(0) $udp0 #CREAMOS UNA FUENTE DE TRÁFICO CBR Y LO ASOCIAMOS A udp0 Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 150 de 192 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 500 $cbr0 set type_ CBR $cbr0 set interval_ 0.005 $cbr0 set rate_ 1mb $cbr0 set random_ false $cbr0 attach-agent $udp0 #LAS PROXIMAS LINEAS CREAN UN AGENTE NULO QUE ACTÚA COMO EL FREGADERO DEL TRÁFICO Y LO ASOCIAMOS A UN NODO set null0 [new Agent/Null] $ns attach-agent $n(15) $null0 #AHORA CONECTAMOS LOS AGENTES udp0 y null0 $ns connect $udp0 $null0 $udp0 set fid_ 2 #EL SIGUIENTE PASO ES DECIRLE AL AGENTE CBR CUANDO ENVIAR DATOS Y CUANDO PARAR EL ENVIO $ns at 0.5 "$cbr0 start" $ns at 4.5 "$cbr0 stop" #AHORA ENVIAREMOS DATOS DEL NODO 0 A UN NODO DE LA TOPOLOGÍA #CREAMOS UN AGENTE UDP Y LO ASOCIAMOS AL NODO N0 set udp5 [new Agent/UDP] #ASIGNO EL NOMBRE udp0 AL AGENTE $ns attach-agent $n(5) $udp5 #CREAMOS UNA FUENTE DE TRÁFICO CBR Y LO ASOCIAMOS A udp5 set cbr5 [new Application/Traffic/CBR] Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 151 de 192 $cbr5 set packetSize_ 500 $cbr5 set type_ CBR $cbr5 set interval_ 0.005 $cbr5 set rate_ 1mb $cbr5 set random_ false $cbr5 attach-agent $udp5 #LAS PROXIMAS LINEAS CREAN UN AGENTE NULO QUE ACTÚA COMO EL FREGADERO DEL TRÁFICO Y LO ASOCIAMOS A UN NODO set null16 [new Agent/Null] $ns attach-agent $n(16) $null16 #AHORA CONECTAMOS LOS AGENTES udp5 y null16 $ns connect $udp5 $null16 $udp5 set fid_ 2 #EL SIGUIENTE PASO ES DECIRLE AL AGENTE CBR CUANDO ENVIAR DATOS Y CUANDO PARAR EL ENVIO $ns at 0.5 "$cbr5 start" $ns at 4.5 "$cbr5 stop" #CERRAMOS EL PROGRAMA $ns at 5.0 "finish" #Print CBR packet size and interval puts "CBR packet size = [$cbr0 set packet_size_]" puts "CBR interval = [$cbr0 set interval_]" $ns run Y este es el resultado en el nam: Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 152 de 192 Figura 29. Comentario de la simulación en símbolo de sistema Figura 30. Topología 1 #TOPOLOGIA 2 #ESCRIBIREMOSLOS TCL SCRIPTS EN CUALQUIER EDITOR DE TEXTO #CREAMOS UN OBJETO SIMULADOR set ns [new Simulator] #Define different colors for data flows (for NAM) Implementación de OSPF y RIP con NS2 Jesús Sevilla Vitoria 153 de 192 $ns color 1 Blue #ABRIMOS UN ARCHIVO NAM TRACE DATA set tf [open out.tr w] $ns trace-all $tf set nf [open out.nam w] $ns namtrace-all $nf #EL SIGUIENTE PASO AÑADE UN PROCEDIMIENTO FINAL QUE CIERRA EL ARCHIVO TRAZA Y COMIENZA EL NAM proc finish {} { global ns tf nf $ns flush-trace close $tf close $nf exec nam out.nam & exit 0 } #UNA VEZ REALIZADOS LOS PASOS PERTINENTES PARA INICIALIZAR EL SCRIPTS ESCRIBIREMOS LA TOPOLOGIA #COMO TENEMOS UNA TOPOLOGÍA GRANDE CON 30 NODOS UTILIZAREMOS COMANDOS DE C++ COMO EL for for {set i 0} {$i<30} {xp. i} { set n($i) [$ns node] } #YA TENEMOS LOS 30 NODOS CREADOS AHORA LOS CONECTAREMOS PARAA CREAR UNA TOPOLOGIA CIRCULAR for {set i 0} {$i<30} {xp. i} { $ns duplex-link $n($i) $n([xp. ($i+1)%30]) 1Mb 3ms DropTail