instituto politécnico nacional -...

Instituto Politécnico Nacional Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas

"COMPARACIÓN DE LA EFICIENCIA EN TIEMPOS DE ENTREGA EN ALGORITMOS DE RUTEO DE PAQUETES CON TÉCNICAS ADAPTIVAS"

Que para Obtener el Título de: "Ingeniero en Telemática"

Presenta: Carlos Iván

Gutiérrez Sánchez

Asesores: M. en C. Cyntia Enríquez Ortiz

Ing. Francisco Antonio Polanco Montelongo

México D.F., junio de 2008

RESUMEN.

El presente documento muestra el como se puede aplicar las técnicas de inteligencia artificial al ruteo. El

documento empieza con una descripción general de las redes y el ruteo presentando los algoritmos mas comunes

de ruteo en la actualidad. Luego se presenta la propuesta de Qrouting y se presenta el desarrollo que se siguió para poder replicar la simulación realizada por los doctores Justin A. Boyan y Michael L. Littman así como la

simulación de algunos protocolos de ruteo clásicos y el análisis de los resultados para encontrar la diferencia en cuestión de eficiencia en el tiempo de entrega de los diferentes algoritmos simulados. Así como también da un

panorama de los problemas que se presentaron en el intento de implementación física de dichos algoritmos y recaba las experiencias obtenidas de dicho esfuerzo.

PALABRAS CLAVE.

Qrouting, inteligencia artificial, ruteo, OSPF, RJP, vector distancias, estado de enlaces, NS2, simulación.

ABSTRACT.

This document describes the application of trie reinforcement learning principies to the routing algorithms in

networks. The document begins with a general description of what networks are composed of and where the routing comes into picture. We present the data about various popular algorithms, which exist in the networks at

present, Q routing is then described and discuss its implementation issues following the simulation done for Ph. D. Justin A. Boyan & Ph. D. Michael L. Littman. We evalúate the working of the algorithm. Finally we conclude

with the results of our analysis and the scope for further improvements and show the problems encountered during the process.

PALABRAS CLAVE.

Qrouting, reinforcement learning, routing, OSPF, RIP, distance vector, link states, NS2, simulation.

OBJETIVOS

General:

Implementar algoritmos de ruteo dinámico en una red con geometrías y niveles de tráfico diversos y comparar los resultados obtenidos en cuanto a la eficiencia en tiempos de entrega con los algoritmos adaptivos.

Específicos:

Instalar, configurar y probar el simulador NS2.

Compilar, configurar y correr el simulador desarrollado por Littman y Boyan para Qrouting.

Desarrollar simulaciones en NS2 de los algoritmos de ruteo convencionales.

Implementar el algoritmo adaptivo en NS2.

Implementar los algoritmos en una red para comparar los resultados con los obtenidos en la simulación.

TABLA DE CONTENIDOS

CAPITULO 1 : Antecedentes .............................................................................................................................................................................. 3

1.1 Marco Teórico 3 1.2 Introducción al ruteo 4 1.3 Algoritmos adaptivos de ruteo 5 1.4 La simulación 8 1.5 NS2 8

1.5.1 NAM 9

1.5.2 El archivo trace y la graficación ........................................................................................................ 10 1.5.3 Arquitectura de una red en NS-2 ....................................................................................................... 12

1.5.3.1 Nodos ........................................................................................................................................12 1.5.3.2 Enlaces ..................................................................................................................................... 13 1.5.3.3 Agentes ..................................................................................................................................... 13

1.5.4 Arquitectura propia del ruteo en NS2 ................................................................................................ 13

1.5.4.1 Clase RouteLogic ..................................................................................................................... 14 1.5.4.2 Clase rtObject ........................................................................................................................... 14 1.5.4.3 Clase rtPeer ...............................................................................................................................14 1.5.4.4 Clase Agent/rtProto .................................................................................................................. 14

1.5.5 LS y DV ........................................................................................................................................... 15

CAPITULO 2 : Planteamiento del problema ........................................................................................................ 16

CAPITULO 3 : Implementación .......................................................................................................................... 19

3.1 Implementación de la red física ................................................................................................................. 19 3.2 Simulaciones enNS2.................................................. - ............................................................................. 19

3.2.1 Preparación ............................................................ '. ......................................................................... 19

3.2.1.1 Instalando NS2 ......................................................................................................................... 19 3.2.1.2 Ejecutando NS2-NAM .............................................................................................................. 20

3.2.2 DV(Distance Vector) ........................................................................................................................ 20 3.2.3 LS (Link States) ................................................................................................................................ 29 3.2.4 Comparación en NS2......................................................................................................................... 32

3.3 Simulación de Qrouting ............................................................................................................................ 36 3.4 Implementación de un nuevo protocolo en NS-2 ....................................................................................... 39

CAPITULO 4 : Conclusiones ............................................................................................................................... 40

TABLA DE ILUSTRACIONES

Ilustración 1: Ejemplo de red............................................................................................................................................................................... 3

Ilustración 2: Esquema de un ruteador en el modelo OSI ........................................................................................4

Ilustración 3: Transmisión de un mensaje en una red de Qrouting con política de unitrayectoria ............................ 6

Ilustración 4: Regreso de la retroalimentación, para censar la red............................................................................7

Ilustración 5: Niveles de programación de NS2 ............................................................................................................................................................................... 9

Ilustración 6: Ventana principal de nam ................................................................................................................ 10

Ilustración 7: Gráfica en 3D generada con tracegraph ........................................................................................... 11 Ilustración 8: Ventana de selección de parámetros en tracegraph ..........................................................................12

Ilustración 9: Nodo de unicast en NS2 .................................................................................................................. 12

Ilustración 10: Enlace en NS2............................................................................................................................... 13

Ilustración 11: Red de prueba 1 ............................................................................................................................. 17



Ilustración 14: Red de prueba 4 ............................................................................................................................18

Ilustración 15: Proceso de una simulación ............................................................................................................ 20

Ilustración 16: Malla 1 con DV............................................................................................................................. 21

Ilustración 17: Malla 1 con DV con perdidas ........................................................................................................21

Ilustración 18: Gráfica de generación de trafico contra retardo en la malla 1 con DV ........................................... 22

Ilustración 19: Gráfica de paquetes perdidos contra el tiempo de simulación en la malla 1 con DV ...................... 22

Ilustración 20: Gráfica de paquetes reenviados por nodo en la malla 1 con DV .................................................... 23

Ilustración 21: Gráfica de paquetes perdidos por nodo en la malla 1 con DV ....................................................... 23

Ilustración 22: Malla 2 con DV ...............................................z ........................................................................... 24



Ilustración 25: Malla 3 con DV ............................................................................................................................ 26



Ilustración 28: Malla 4 con DV .............................................................................................................................27



Ilustración 31: Gráfica de paquetes reenviados por nodo en la malla 1 con LS ..................................................... 29




Ilustración 35: Gráfica de paquetes perdidos por nodo en la malla 1 con LS ........................................................ 31

Ilustración 36: Gráfica de paquetes perdidos por nodo en la malla 2 con LS ........................................................ 31

Ilustración 37: Gráfica de paquetes perdidos por nodo en la malla 3 con LS ......................................................... 31

Ilustración 38: Gráfica de paquetes perdidos por nodo en la malla 4 con LS ......................................................... 31

Ilustración 39: Retardos en la malla 1 ................................................................................................................... 32

Ilustración 40: Retardos en la malla 2 .................................................................................................................. 32

Ilustración 41: Retardos en la malla 3 ................................................................................................................... 33

Ilustración 42: Retardos en la malla 4 .................................................................................................................. 33

Ilustración 43: Paquetes perdidos para la malla 1 .................................................................................................. 34

Ilustración 44: Paquetes perdidos para la malla 2 ................................................................................................. 34



Ilustración 47: Efecto de alfa ............................................................................................................................... 37

Ilustración 48: Qrouting en la malla 1 ................................................................................................................... 37

Ilustración 49: Qrouting malla 2 .......................................................................................................................... 38

Ilustración 50: Qrouting malla 3 ........................................................................................................................... 38

Ilustración 51: Qrouting malla 4 .......................................................................................................................... 39

CAPITULO 1 : Antecedentes

La transmisión de información ha sido una prioridad para los humanos desde siempre, el comunicarse con las otras personas es una de las cosas que nos definen como seres pensantes y en la actualidad esa comunicación recibe ayuda de muchas herramientas como lo son las redes celulares o el teléfono; pero sin duda la mas impresionante de todas por el avance que ha presentado y por su potencialidad es el Internet o "la red de redes" que es la interconexión de diversas redes autónomas formando en conjunto una sola red ante el usuario final.

Los primeros intentos de formar una red de esas dimensiones son el Arpanet administrada por Estados Unidos, desde esos inicios de las redes se estudio la viabilidad de las dos modalidades en que estas funcionan: la conmutación de paquetes y la conmutación de circuitos, quedando hoy para la Internet en el protocolo IP la opción de conmutación de paquetes como la opción mas viable y dejando a TCP (Transmission Control Protocol) la gestión de un enlace orientado a conexión.

La conmutación de paquetes sugiere que la información se divida en pequeños paquetes o datagramas para ser enviados de forma individual. La palabra "datagrama" viene de usar una metáfora de "telegrama" para el envió de la información, cuando una computadora quería enviar información, esta ponía la información en un sobre (la cabecera del paquete) el cual contenía la dirección del destinatario y lo enviaba a través de la red y esta eventualmente entregaba el mensaje. De hay la palabra "datagrama" fue concebida como una analogía a "telegrama" denotando una comunicación rápida de la información en el sistema postal [HuiOl], actualmente este es el funcionamiento del protocolo UDP(User Datagram Protocol).

1.1 Marco Teórico.

En las redes de computadoras actuales que se pueden representar como nodos entrelazados entre si como en la ilustración 1, una de las tareas más importantes es la de una comunicación eficiente entre los nodos que la integran, una aproximación popular para solucionar este problema es el uso de segmentos de información [TomOl], los cuales son enviados a una computadora vecina y así estos pasan de nodo en nodo hasta llegar al destino el cual utilizara el mensaje.

En cada nodo se tiene que tomar una decisión de hacia cual vecino en la red será enviado el paquete para alcanzar el destino de la manera más eficiente posible. El proceso en el cual el nodo elige a cual vecino enviara el paquete es conocido como política de ruteo o simplemente "ruteo" y una política ineficiente de ruteo puede tener consecuencias desastrosas en el desempeño de la red, la congestión de paquetes puede resultar en largos retardos y mensajes perdidos.

3

Unas de las técnicas mas modernas y avanzadas de ruteo tienen que ver con algoritmos de aprendizaje implementados en cada nodo los cuales "aprenden " y evalúan cual sería el camino óptimo de un punto a otro en ese momento de acuerdo a las características de la red conocidos como algoritmos adaptivos. Y es de estos algoritmos de donde se desprende esta investigación ya que con el deseo de realizar una comparación contra los algoritmos clásicos surge este trabajo.

1.2 Introducción al ruteo.

El ruteo es el procedimiento mediante el cual se responde a una cuestión básica en las redes de conmutación de paquetes, la cual es la elección del camino óptimo para enviar la información de un nodo a otro para que esta información llegue lo más rápido, y seguro que sea posible, se pueden tener varios criterios para determinar el mejor camino como son: número de saltos, la distancia física, el retraso de la transmisión por un paquete de prueba, ancho de banda, trafico promedio, el costo del enlace, etc.

El ruteo es una necesidad que se manifiesta principalmente en redes con un gran número de nodos interconectados entre si como lo es la Internet pero es utilizado en redes de menor dimensión. Este se implementa en la capa de red de un sistema (nivel 3 en el modelo OSI. referenciar a ilustración 2 para ver el esquema completo) y es realizado casi siempre por equipos dedicados a esta tarea, algunos de los mayores fabricantes de routers son: Cisco, 3com, Linksys, Netgear, Dlink, Lucent, Nortel, Cabletron, Juniper. Estas compañías desarrollan equipo dedicado el cual es construido expresamente con el fin de correr algoritmos de ruteo y mantener en tablas una "fotografía" de la red para„poder decidir por donde enviar la información que reciben para que llegue eficientemente al destino deseado, aunque también existe software especializado como puede ser el caso de gnu zebra (www.zebra.org) una aplicación que pretende convertir cualquier computadora corriendo el sistema operativo Linux en un router completamente funcional.

Existen diversas formas de clasificar a los algoritmos de Ruteo o encaminamiento como también son conocidos, una es la siguiente:

IGP (Internal Gateway Protocol) o protocolo de pasarela interno que son los protocolos utilizados en sistemas autónomos como son los que se trataran en este trabajo de investigación

4

http://www.zebra.org/

EGP (Exterior Gateway Protocol) o protocolo de pasarela externo que son los utilizados para intercambiar información entre sistemas autónomos actualmente BGP (Border Gateway Protocol) es el protocolo que desplazo a EGP2 como líder en esta categoría.

Otra división de los protocolos de ruteo es por el como se construyen las tablas de ruteo y es:

Ruteo estático: estos algoritmos requieren la intervención del administrador de la red el cual decide que ruta debe de seguir un paquete para llegar a su destino y lo incorpora expresamente en los paquetes de información o bien en las tablas de los ruteadores que se encuentran en toda la trayectoria.

Ruteo dinámico: este tipo de ruteo es el mas utilizado y es en el cual el router toma la decisión de poique ruta enviar la información que recibe de los nodos de la red así se permite que la red se adapte a las condiciones que existan en ese momento.

Este tipo de algoritmos es el que se trataran en el presente trabajo debido principalmente al interés en una nueva generación de estos algoritmos impulsados por la implementación de técnicas de inteligencia artificial las cuales hacen que la red tenga una mejor adaptabilidad a las condiciones como puede ser el trafico y ya no solo a si los enlaces están activos o no.

Pero los algoritmos dinámicos también se pueden dividir dependiendo del protocolo que ocupen para realizar la toma de decisiones en cuanto a que camino tomar para un paquete en especifico. Y existen dos protocolos básicos los cuales son:

Vector de distancias: cada router se comunica con sus vecinos para indicarles las distancias estimadas hacia los nodos de toda la red y con la información que un nodo recibe de sus vecinos puede estimar cuales son los caminos óptimos ejemplos de este protocolo son los algoritmos RIP (Routing Information Protocol) y lGRP(Interior Gateway Routing Protocol).

Estado de los enlaces: en este protocolo un router se comunica con sus vecinos diciéndoles cuales nodos están conectados a el y cada router conserva una copia de un "mapa" de red con esto calcula la ruta óptima. Ejemplo de este protocolo es el algoritmo OSPF (Open Shortest Path First).

Estos protocolos y algunos de los algoritmos serán vistos a profundidad mas adelante en el anexo A. Pero es importante notar que un router es en esencia una computadora de propósito especifico el cual cuenta con varias interfases de red y con el software que pueda ejecutar los algoritmos de ruteo que se pretenden implementar. otra cosa a notar es que algunos de los algoritmos son propietarios de alguna compañía como es el caso de EIGRP (Enhanced Interior Gateway Routing Protocol) propiedad de Cisco, esto quiere decir que si otra compañía o un tercero desea implementar este algoritmo para que su producto sea compatible con los routers Cisco se necesita llegar a un acuerdo entre las partes, si es que este acuerdo se puede alcanzar.

1.3 Algoritmos adaptivos de ruteo.

Existen hoy en día varias alternativas experimentales para el ruteo basadas en técnicas de inteligencia artificial para ofrecer una solución mas adaptable al problema del ruteo algunos de estos algoritmos son :

Qrouting

Pqrouting (variación de Qrouting predectiva)

Antz

Planar-Adaptive routing

Bubbles

5

Chaotic routing

Todos prometen una eficiencia mayor a la ofrecida por los algoritmos clásicos de ruteo que se vieron en capítulos anteriores, se analizo en este trabajo uno en especial ya que por su eficiencia mostrada en pruebas realizadas por sus diseñadores y la sencillez del algoritmo se muestra como una interesante opción frente los algoritmos clásicos, este algoritmo es el de Qrouting propuesto por Justin A. Boyan y Michael L. Littman, este algoritmo se pudiese clasificar dentro de la familia de vectores de distancias, pero con modificaciones importantes.

Este protocolo emerge de lo que se conoce como aprendizaje reforzado, RL por sus siglas en ingles (Reinforcement Learning) , la principal característica que distingue a estas técnicas de inteligencia artificial en el caso de ruteo es el implementar un enfoque probabilístico en contraposición al enfoque determinista de los algoritmos clásicos en este caso no se tiene en la tabla de ruteo una interfase y un costo sino mas bien se tienen todas las interfaces y la probabilidad que refleja bajo los cálculos hechos así una probabilidad mayor reflejaría que esa ruta tiende a ser la óptima la mayoría del tiempo pero no excluye a las demás, de esta forma el router puede utilizar estas probabilidades para tomar decisiones de una forma no determinista por ejemplo si se tiene una tabla de ruteo:

Y nuestro nodo quiere enviar 10 tramas de datos hacia el nodo b si esta en sus políticas un ruteo multitrayectoria entonces podría enviar 7 paquetes por la interfaz 1 y 1 por cada una de las interfaces 2, 3 y 4 o bien si la política es la de usar un ruteo de una sola trayectoria entonces pudo mandar los 10 paquetes por la interfaz 1, de lo contrario en una política de ruteo unitrayectoria como en la ilustración 3 la ventaja principal es que esta trayectoria no es tan fija en el tiempo como lo seria en los protocolos clásicos.

6

El algoritmo es el que sigue:

Se tiene una tabla en la que se almacenan: destino, siguiente y el valor Q para esa ruta siendo este valor el tiempo estimado que tarda el paquete en llegar a su destino, dependiendo de la implementación se envía un mensaje de actualización de esta tabla, el cual consiste en el mínimo estimado del nodo vecino por el cual se esta enviando la información. Y con este valor y un factor de aprendizaje se va actualizando la tabla para adaptar las rutas a las condición de la red en un momento en especifico.

Se tiene entonces Qx(d,y) que es el tiempo que el nodo x estima que tomara la entrega del paquete de Información hasta el nodo d a través del nodo vecino y.

7

Cuando y recibe el paquete envía de regreso un mensaje hacia el nodo x el cual contiene su mejor tiempo estimado

hasta el destino(ilustración 4). /=min (Qy (d, z))para todo z evecinos (y)

Entonces x actualiza su tabla con el nuevo valor.

QAd, y)acl = Q.x(d,ylH + K*(s + q + t-Qx(d, y\J

Donde:

K= el factor de aprendizaje con un valor común de 0.5. s= tiempo de transmisión desde x hacia y. q = Tiempo en la cola de x. t = nuevo estimado de y.

En lo que a los demás aspectos básicos se refiere el funcionamiento del algoritmo es muy similar a el descrito para los algoritmos de la familia "Bellman-Ford" o de vectores de distancias.

Se ve claro que no se pueden estar mandando paquetes Q todo el tiempo ya que podrían casi igualar la carga generada por trafico de información y en ninguna situación esto es deseable ya que lo que deseamos transportar de antemano es información no así meros datos de control, esto además de que al iniciar la tabla de ruteo se utilizan valores totalmente aleatorios y esto conduce en algunas ocasiones a cosas como caminos sin salida o a rutas desorbitantemente largas, por esto en un protocolo de estas características se maneja algo parecido al inicio en frío de los protocolos de vectores de distancias y es su principal similitud en este caso se conoce como etapa de "exploración" a este proceso en el cual el trafico de paquetes Q es muy alto y el tiempo que dura es un factor de diseño que es decidido al implementarlo.

Después de que esta etapa es concluida se dice que se entra en una etapa de "explotación" en esta etapa los paquetes Q ya no son tan frecuentes y el implementador puede decidir su periodicidad o bien si solo serán enviados como respuesta a un detonador especifico. Ambos procesos la exploración y la explotación son deseables para una política de ruteo exitosa.

Mas aun ambos procesos nunca se detienen en un ambiente dinámico simplemente, modifican su intensidad en relación a la respuesta del ambiente y este balance es un tema de estudio por si mismo.

En ambos procesos la decisión de por donde enviar el paquete es tomada por el router y el algoritmo RL es el que le proporciona el aprendizaje, reforzado con la respuesta del ambiente (la red) y en respuesta las probabilidades son incrementadas o disminuidas para reflejar la señal de refuerzo.

Una característica distintiva de este tipo de algoritmo de inteligencia artificial es que no cuenta con dos procesos separados de aprendizaje y evaluación, sino que se asume que pasan ambos continuamente de hecho .

1.4 La simulación.

Primero habría que especificar que es a lo que se le conoce como simulación. Se define simulación como la técnica de reproducir la esencia de un fenómeno sin reproducir el fenómeno en sí, con la ventaja adicional de poder hacerlo en una escala de tiempo muy pequeña o comprimida, si nos valemos de una computadora para realizar su procesamiento [PacOl].

Parte de lo desarrollado fue la búsqueda de opciones para la simulación de los algoritmos para compararlos y como resultado de esa búsqueda se encontraron varias opciones entre ellas:

8

• SIMPROCESS 4.2. • OPNET Modeler. • NS2.

Y la programación del simulador así como de los algoritmos como las mas destacadas, por cuestiones de tiempo de implementación se opto por utilizar NS2, el cual implementa ya varias clases de simulaciones por eventos y además es un software libre con un uso muy difundido en la comunidad científica lo cual respaldaba esta decisión, de hecho este simulador es una excelente opción para ser implementado en materias como Telemática II y algunas otras.

1.5 NS2.

NS2-NAM como debe ser llamado es el resultado de una larga evolución que de hecho aun no termina, ya que esta en fase de desarrollo en los momentos en que se realiza este trabajo lo que sera llamado NS3, pero volviendo a NS2, sus inicios fueron como una variación del simulador de los 80's llamado REAL network ñmulator la primera iteración del simulador después de desprenderse de REAL fue llamada simplemente NS o Network Simulator con la misión de convertirse en una multiherramienta de la simulación de redes, actualmente proporciona funcionalidad de diversos protocolos de la capa de aplicación como lo son (Http, ftp, cbr, etc), así ;omo de transporte (TCP, UDP, etc), de enrutamiento (LS, DV, etc), tanto para redes cableadas como para inalámbricas locales o vía satélite. [MigOl]

NS2 como lo llamaremos por simplificación ha sido objeto de desarrollo desdel año de 1989 por DARPA t Defense Advanced Research Project Agency) con ayuda de diversas instituciones y empresas como lo son: LBL, Xerox, UC Berkley, USC, ISI (principal desarrollado!- el día de hoy) todos estos bajo un el nombre de proyecto VINT.

El simulador se compone de cuatro herramientas separadas: NS2: simulador de eventos en tiempo discreto, se encarga de procesar la simulación para su posterior

interpretación. NAM: es como se conoce al network animator con este programa nosotros podemos ver la

representación gráfica de la simulación . AWK: es el la aplicación encargada de convertir el log de simulación entregado por NS2 en datos

graficables. Xgraph: esta aplicación o bien GNUplot son las mas ampliamente utilizadas para mostrar los resultados

en una gráfica para poder utilizarlos.

Para gráficas de uso general y por lo difícil que es en proyectos cortos la utilización de AWK y Xgraph existen herramientas como tracegraph que son herramientas especializadas en convertir los logs en gráficas para su análisis principalmente educativo y de investigación básica.

Pero, ¿Como funciona NS2?, Bueno NS2 lo veremos como dos capas de programación, primero el script TCL o mejor dicho OTCL (tcl orientado a objetos) que es lo que el usuario común utiliza, este es enlazado por el modulo tclcl a una implementación de C++(ilustración 5).

El nivel de programación de C++ es el utilizado en la implementación de nuevos protocolos mientras TCL es utilizado al modelar una red.

9

1.5.1 NAM.

Como habíamos dicho nam es la herramienta para poder ver nuestra red de manera gráfica Su pantalla principal(ilustracion 6) se compone de tres barras, una zona de simulación y una zona de mensajes. Primero esta la baña de menús con las opciones file, view y analysis. Siendo el mas importante de estos los que se encuentran en view donde entre otras cosas se pueden filtrar los paquetes por:

Tipo de paquete . Tipo de trafico. Nodo de inicio. Nodo de destino. Identificador de flujo.

La barra de herramientas superior están las opciones de reproducción de la animación son muy intuitivos al ser como de un reproductor de vídeo con una barra para ajustar la velocidad de cada paso de simulación. En la baña de herramientas de la izquierda se controla el zoom así como podemos habilitar las opciones de edición con lo cual se pueden mover los nodos.

10

En el área de simulación cuando no esta habilitada la opción de editar se puede filtrar los paquetes de un nodo de forma rápida así como granear el uso de un enlace cuando se selecciona este y se selecciona la dirección (en caso de ser un enlace dúplex) y cuando se da click en un paquete se puede poner un monitor el cual nos ayudara a revisar el recorrido de ese paquete.

1.5.2 El archivo trace y la graficación.

El archivo trace es el equivalente a un log y es lo que nos da NS2 como resultado para ser utilizado en investigaciones, cabe destacar que este archivo puede ser enorme en mis simulaciones sobrepasaron los 30 Mb en un archivo de texto con el siguiente formato:

Tipos: + el paquete entra en la cola del enlace. - el paquete se sale de la cola del enlace. r el paquete es recibido por el destino. d el paquete fue descartado o perdido.

Este archivo puede ser procesado como uno lo decida el proyecto VINT nos proporciona la herramienta

AWK el cual es muy parecido a c por ejemplo un script sencillo podrida ser: II I

1. BEGIN { totsent=0; totrecv=0; }

2. { 3. if ($1=="+") { totsent=totsent+$6; }

4. if ($l=="r") { totrecv=totrecv+$6; }

5. }

6. END { print "Bytes enviados:" totsent"\nBytes recibidos: " totrecv; }

Esto se guarda en un archivo por ejemplo tot.awk y se ejecuta: Sawk -f tot.awk tracefile.tr Lo cual nos daría un resultado en pantalla mostrándonos los totales de bytes enviados y recibidos en toda la red, agregando solo una resta por ejemplo tendríamos el número de Bytes perdidos este resultado también se puede usar en un archivo para grafícar algún aspecto que nos sea de interés de la simulación, para granear se nos presentan dos opciones: Xgraph o GNUplot, la primera viene incluida en los paquetes de NS2&NAM pero aun así la segunda tiene un mejor acogimiento por la comunidad científica ya que es de fácil acceso en cualquier distribución Linux y además de esto la gráfica resultante es fácilmente manipulable en LÁTEX.

Pero como mencionamos anteriormente existen opciones como tracegraph el cual es esencialmente una interfaz gráfica amigable de scripts hechos en base a un motor matlab para Linux con potencialidades desde gráficas sencillas a complejas gráficas en 3D (ilustración 7) con posibilidades de zoom.

Para generar estas gráficas basta con escoger un par de parámetros el la pantalla principal (ilustración 8): Que tipo de paquete nos interesa estudiar en este caso puede ser de datos (TCP) o de ruteo siendo mas

útiles en este caso los resultados obtenidos de analizar los paquetes de datos. Elegimos si deseamos estudiar todos los paquetes o solo los que tienen un tamaño especifico. Que paquete se envió y cual se recibió (tep, ack). y podemos delimitar la gráfica a un espacio de tiempo

limitado en la simulación o si se limita a un solo nodo.

12

http://tracefile.tr/

1.5.3 Arquitectura de una red en NS-2.

Básicamente una red en NS2 se conforma por: Nodos: son la representación de un elemento de red puede ser un router o una computadora

indistintamente. Enlaces: es el medio de comunicación entre dos nodos. Agentes: es la parte principal son los que generan el trafico o lo utilizan.

1.5.3.1 Nodos

Existen dos tipos de nodos en NS2. Los nodos de Unicast (ilustración 9) que tiene un clasificador de direcciones y un clasificador de puertos mientras los nodos de multicast además tienen un clasificador de multicast pero en este trabajo nos centraremos en los nodos unicast.

El nodo se debe de ver como dos demultiplexores: adr cías: es responsable de direccionar un paquete de datos y si un paquete es para ese nodo darle salida al siguiente demux, cabe destacar que es aquí donde se utilizan los algoritmos de ruteo, port cías: es responsable de direccionar un paquete de datos que le pertenece a el nodo hacia el agente que le dará salida en el puerto correspondiente.

13

1.5.3.2 Enlaces.

Estos son los segundos protagonistas en una red, en NS2 solo existe un tipo de enlace y este es el Simplex (ilustración 10) esto por cuestión de simplificación de diseño entonces cuando un usuario requiere un enlace bidireccional como es común en las redes de hoy en día lo que NS2 hace es crear dos enlaces en direcciones opuestas. Un enlace tiene características precisas como son:

Su ancho de banda en Mb/s. Su tiempo de retardo interno en ms. Su costo representado por un entero.

Así mismo los enlaces cuentan con una cola que es donde ponen a los paquetes que por falta de ancho de banda no han podido darles salida pero esta cola es finita así que si llega a su limite los paquetes que lleguen al enlace después de esto serán perdidos por la red.

Como vemos en la imagen el enlace cuenta con la cola, un retardo, un agente nuil que sirve para desechar los paquetes que no puedan ser procesados y un modulo para controlar los TTL de los paquetes, a estos se suman en o de requerir el guardar un archivo .Tr en la simulación los elementos que se encargaran de escribir esa información ya que como recordaremos los logs .tr que prácticamente son los depositarios de la información de los enlaces en cada estado de la simulación .

11 punto que debemos de pensar es que la cola esta en el enlace y no en el nodo como se podría pensar ya que el enlace en teoría solo representaba a un medio de comunicación pero también representa un elemento con una memoria dada.

1.5.3.3 Agentes

Un agente es la entidad de la red que le da tratamiento a los paquetes de datos, sea cual sea su naturaleza (datos del usuario, información de ruteo . . .). Esta es la entidad, que genera y recibe paquetes. Un agente es asignado a un nodo por un número de puerto. De esta forma podemos ver a un servidor HTTP como un agente en el puerto 80 en el nodo.

1.5.4 Arquitectura propia del ruteo en NS2.

Para el ruteo en NS2 cuatro clases son usadas principalmente:

RouteLogic : esta clase esta en el nivel mas alto de NS y tiene una vista global de la red se encarga de

inicializar todos los algoritmos de ruteo usados en la red cualesquiera que sean.

14

rtObject : esta clase esta en el nivel de los nodos de red, existe una instancia en cada nodo que use al menos un algoritmo dinámico de ruteo. Cada instancia es encargada de coordinar los protocolos de ruteo que operan en el mismo nodo.

rtPeer : esta clase esta en el nivel de los nodos de red pero en un nivel inferior que la anterior pueden haber varias en el mismo nodo y es utilizada para almacenar información de ruteo.

Agent/rtProto : esta clase esta en el nivel de los nodos de red y cada una de estas instancias esta asignada a un puerto en especifico. Es usada para intercambiar paquetes de ruteo del protocolo en cuestión .

Habrá que profundizar en cada una de estas importantes clases .

1.5.4.1 Clase RouteLogic.

Esta clase es el principal pilar del ruteo porque en el momento de la simulación su instancia va a inicializar el algoritmo de ruteo en el nodo.

Generalmente solo hay una instancia por red. Esta almacena en una tabla interna el algoritmo de ruteo que conoce cada nodo.

Además, esta encargada de inicializar los agentes de ruteo en los nodos que los usan; esto se hace llamando los métodos de las clases. Por ejemplo, 'Agent/rtProto/DV init-all [[Simulator instance] all-nodes-list ] ' para inicializar el agente para el protocolo de ruteo de vector distancias en cada nodo de la red.

7.5.4.2 Clase rtObject.

Esta clase se usa con ruteo dinámico como es nuestro caso. Cada nodo tiene una instancia de esta porque es la coordinadora de todos los protocolos de ruteo, que pudiesen trabajar en el mismo nodo. Esta clase calcula y almacena la mejor ruta para cada posible destino por cada protocolo, en otras palabras, toma la mejor ruta dependiendo de que algoritmo esta facultado para encontrar rutas de costo mínimo y en caso de que haya varias opciones decide por la de mayor prioridad.

Otra función vital es la de alertar a los protocolos de ruteo de cambios en la topología de la red así estos pueden actuar en consecuencia.

Además es la encargada de avisar al clasificador de direcciones de las rutas actuales. Así mismo como es el clasificador de direcciones el encargado del ruteo si la dirección de destino de un paquete es el mismo nodo el resultado del clasificador no sera un enlace con un vecino sino el enlace con el clasificador del puertos del mismo nodo. En resumen cada instancia de rtObject supervisa la tabla de ruteo usada por el nodo para transmitir |os paquetes de datos.

1.5.4.3 Clase rtPeer.

Esta clase se usa por los agentes de ruteo como la clase de contenedor en otras palabras cada una de sus instancias sirven para almacenar información de ruteo para un agente de ruteo en un nodo.

1.5.4.4 Clase Agent/rtProto.

Todas las implementaciones de agentes de ruteo debe de ser implementadas como una subclase de la clase Agent

15

(C++) y como una subclase de Agent/rtProto (Otcl ). Un agente de ruteo desdel punto de vista de NS, es un agente el cual tiene la responsabilidad de informar a su "supervisor" (su objeto rtObject) de cual es la ruta óptima según su algoritmo.

Además es responsable por el intercambio de información de ruteo para el protocolo que implementa, esta información es llevada en forma de paquetes de ruteo enviados en la red y sus puertos de destino corresponden a los asignados por los agentes de ruteo del algoritmo en cuestión; en resumen cada objeto de la subclase Agent/rtProto/¡¡proto¿¿ es adjuntado a un nodo en el clasificador de puertos y es el encargado de la tabla de ruteo de algoritmo en cuestión. Este comunica su tabla de ruteo con rtObject el cual lo supervisa. Finalmente, calcula sus propias rutas usando paquetes de ruteo que puede enviar o recibir de una contra parte en otro nodo.

1.5.5 LSyDV.

Antes que nada es bueno saber que son y que no son los algoritmos de ruteo implementados en NS2 llamados LS . DV.

DV routing.

Jerarquía en NS: Agent/rtProto/DV.

DV significa Distance Vector routing o ruteo de vector distancias que como vimos es la clasificación general de ruteo a la cual pertenece RIP esta implementación en general maneja la técnica de horizonte dividido que vimos en el pasado al asignar un valor infinito al nodo el cual transmite el mensaje. Los mensajes de actualización se envían cada 2 segundos pero este intervalo es ajustable por la variable advertlnterval. También se tiene contemplado el enviar mensajes de actualización cuando la recepción de una actualización involucra el descubrimiento de una nueva ruta.

LS routing.

Jerarquía en NS: Agent/rtProto/LS.

De acuerdo con la explicación proporcionada por el autor de este algoritmoh esta es una implementación del algoritmo de ruteo de información de estado de enlaces con las siguientes restricciones:

No soporta ruteo jerárquico. No soporta multicasting. No suporta subredes

No informa acerca de si mismo a los vecinos pero usa información interna del simulador (rtObject).

Las restricciones mencionadas no obstruyen o no deben obstruir en nada el estudio porque no usamos subredes y solo se usara un ruteo en unicast. Un requisito básico para el uso adecuado del algoritmo es el tener en el compilador de nuestra plataforma la librería estándar STL5 muy común en las distribuciones Linux.

16

CAPITULO 2 : Planteamiento del problema

El problema era encontrar las diferencias entre algoritmos de ruteo y comparar en base a estas diferencias la eficiencia en el tiempo de entrega entre estos, para ello se realizarían la simulación y la implementación de los algoritmos en computadoras que funcionarían como enrutadores al instalarles un número determinado de tarjetas de red y el software requerido, a lo largo de las siguientes paginas se plasma como se planteo resolver este problema.

Lo que se planteo como inicio fue empezar a trabajar con las implementaciones de los algoritmos para la red física esto presento varios problemas de diseño así como del nivel de dificultad que resulto ser varias veces mayor al previsto.

En el momento de proponer este trabajo aun estaba mas o menos activa la comunidad de desarrollo del proyecto www.zebra.org el cual al poco tiempo cayo en el abandono, este proyecto tenia como meta precisamente convertir una computadora Linux en un router capaz de entender los principales algoritmos de ruteo con código abierto (OSPF, RIP, etc), tarea nada sencilla que por falta de apoyo no pudo concretarse.

El principal problema al implementarlo fue siempre el reloj para poder tener los relojes "Sincronizados" y así poder contar bien los tiempos estimados, tan vitales para Qrouting, otro problema importante fue el acceso a la capa de red de Linux para poder elegir a que interfaz física dirigir el trafico nosotros y no el sistema operativo (una de las principales características que se utilizarían a partir de las aportaciones del proyecto zebra).

Estos no fueron los únicos problemas también se vio la necesidad de que la los elementos de la red fueran lo mas homogéneos para que sus diferencias no influyeran en los resultados obtenidos.

Lo anterior utilizo buena parte del tiempo, dejando experiencias valiosas para el que suscribe, pero al mismo tiempo sinsabores al no haber vislumbrado la dimensión real del trabajo que se pretendía desde un inicio. OpenOSPFD, implementación del protocolo OSPF en Open BSD, actualmente consiste de alrededor de 12'000 lineas de código en C.

Después de esto se planteo trabajar con la simulación y fue cuando se empezó a trabajar con la incrustación del nuevo protocolo (Qrouting) y debido a los problemas antes mencionados, a la complejidad de implementar los protocolos de acuerdo a los RFC y a que para redes pequeñas como las propuestas se opto por utilizar los algoritmos ya implementados en NS2.

Y utilizar la simulación de Littman/Boyan como vector de comparación.

Para realizar las comparaciones se seleccionaron cuatro geometrías (Ilustraciones 11 a la 14):

17

http://www.zebra.org/

^tas mallas tendrán todas una generación de trafico en cada elemento por una aplicación FTP, para todos los

tocólos la red sera la misma y con las mismas características de trafico, ancho de banda en los enlaces y distribución en la generación de trafico.

Los resultados de estas simulaciones serian analizados después con el programa tracegraph.

19

CAPITULO 3 : Implementación.

3.1 Implementación de la red física

Al principio de Trabajo Terminal 1 se propuso implementar en una red física los algoritmos de ruteo esto en buena media fue el causante del retaso en la presentación del trabajo final, esto sin concretar la implementación pero considero para un trabajo futuro rescatar de este código la estructura que se implemento para Qrouting en base a aplicaciones cliente-servidor con tres procesos principales:

EAR el cual escuchaba paquetes de datos en un socket y enviaba de vuelta un ack cabe destacar que en ese momento de la implementación no se había pensado en balancear las etapas que en este documento manejamos como exploración y explotación sino que siempre estaba la red en una fase de exploración constante esto ahora con el tiempo y continua investigación se que hubiera repercutido en una baja de eficiencia general de la red influyendo en los resultados finales.

QEAR esta función escuchaba los ack enviados por EAR y actualizaba los valores de la tabla Q; Q[from][best][to]+=NAMBLA(tiempoxay+estimadoy-Q[from][best][to]); donde Nambla era el factor de aprendizaje tiempoxay era el tiempo que ocurrió para que el paquete le llegara al nodo vecino y este lo retransmitiera y estimadoy es el tiempo que nodo vecino calcula como valor Q para el destino final del paquete juntos estos dos últimos son el nuevo estimado y actualizan al estimado anterior (Q[from][besfJ [to]) como se puede ver la implementación estaba pensada para poder almacenar el peso de todos los caminos posibles y así poder hacer un protocolo multitrayectoria.

SAY esta función se encargaba de la creación y envío de paquetes y solo era un método aleatorio de creación de trafico y un servidor que enviaba paquetes para que EAR los recibiera.

Estos procesos coordinaban al protocolo en si y corrían simultáneamente .

Simulaciones en NS2

3.2.1 Preparación.

Lo primero es la instalación del sistema operativo yo opte por Ubuntu ya que he trabajado con Linux por cerca de 4 años y en este tiempo la distribución africana ha ido mejorando cada vez mas su usabilidad.

3.2.1.1 Instalando NS2.

Este simulador al ser posible encontrarlo en código fuente

(http://nsnam.isi.edu/nsnam/index.php/Downloading_and_installing_ns-2) es fácilmente instalable en casi todas las plataformas, pero debido al uso de TCL y a la utilización tan difundida en los ambientes UNIX de este lenguaje de programación, conjuntamente a la evolución de Linux en los últimos años esta plataforma es la ideal para instalar y correr el simulador, para hacer este proceso que de otra manera podría ser tortuoso para muchos no acostumbrados a la compilación de códigos tan complejos existe una forma simplificada de instalación conocida como ns-allinone-xxx el cual ayuda a instalar:

• Tk.

20

http://nsnam.isi.edu/nsnam/index.php/Downloading_and_installing_ns-2

• Ote. • TclCL. • Ns. Nam.

Xgraph. Cweb.

• SGB. Gt-itm gt-itm and sgb2ns.

• Zlib.

Todas estas herramientas necesarias para la simulación, caso aparte Xgraph que como mencione antes puede ser sustituida por otras herramientas similares. Después de tener el paquete correspondiente la instalación es muy sencilla basta con correr el archivo ejecutable "./install" que acompaña al paquete.

Después de esto solo queda poner en las variables de entorno las rutas ~/ns2/otcl-1.12, ~/ns2/lib, en la variable LDLIBRARYPATH, lo cual se logra con el comando export LD_LIBRARY_PATH=<paths> o bien poniéndolo en el archivo (.bashrc) para no ponerlo siempre. Lo mismo para la variable TCL_L1BRARY con la ruta ~/ns2/tcl8.4.13/library.

Por separado instalamos tracegraph el cual se consigue en el sitio web oficial del proyecto (http://www.tracegraph.com) y consta de dos archivos uno con el motor de matlab y el segundo con el binario del programa.

3.2.1.2 Ejecutando NS2-NAM.

Lo primero que hay que saber es el ciclo de ejecución de una simulación con estas herramientas o en otras palabras que información ocupamos darle a que programa para obtener un resultado.

Se "compila"' el script de TCL con NS2 ($ns filename).

Esto nos otorga (si en el script así es indicado) dos archivos, uno con terminación .tr y otro terminación .nam, ñero veremos que es el .nam este archivo es el que utiliza el programa nam para hacer una "animación " de la ulación y después el archivo .tr es un log de la simulación en si hay se guardan todos los pormenores de que

paso en la red y es con esto con lo que las herramientas harán las gráficas para su estudio, a continuación se

presenta gráficamente este proceso.

3.2.2 DV (Distance Vector)

Malla l Aunque el código suscrito esta debidamente comentado cabe hacer incapie en algunas partes del mismo de la

linea 78 hasta la 139 en la primer malla(ilustración 16), es donde se especifica el trafico a generar estas lineas

21

http://www.tracegraph.com/

pudieran ser considerablemente mas compactas con un for anidado pero NS2 no parece permitir esta estructura de programación y no se encontró nada de información al respecto ni en toda la documentación oficial (http://www.isi.edu/nsnam/ns/ns-documentation. html ) ni en los principales sitios de información sobre el simulador (http ://www. i si. edu/nsnam/nstutorial/. y otros). En resumen lo que se pretende es generar trafico de los nodos de la izquierda que sera dirigido hacia los nodos de la derecha de la red provocando así una congestión de los únicos dos nodos que unen a estos segmentos.

Al continuar la simulación se ve como se empiezan a perder paquetes especialmente los que pasan por el enlace que une 4 con 8.

Después de ver la animación podemos proceder a hacer un análisis del archivo trace con el programa trace graphic

de este análisis se puede obtener los siguientes resultados:

22

Como se aprecia en la imagen la cola de los enlaces se empiezan a saturar.

http://www.isi.edu/nsnam/ns/ns-documentation

En la gráfica de la ilustración 18 observamos la eficiencia con la que se enviaron paquetes contra el retardo en la entrega de estos paquetes o en otras palabras el retardo de entrega contra el trafico en la red presentando un patrón exponencial claramente. •

esta gráfica lo que podemos ver es como influye el trafico en la perdida de paquetes en nuestra red con ación al tiempo transcurrido de simulación. Presentando un patrón lineal dentado.

23

Las dos gráficas anteriores nos dan una clara idea de en donde están y que tan importantes son los cuellos de botella en nuestra red por ejemplo en la ilustración 20 (paquetes reenviados) se ve claramente el trafico que circula en el enlace entre 4 y 8 así como el que existe entre 0 y 5, siendo un caso interesante el enlace entre 2 y 0 que es el inicio del cuello de botella que se podría definir como el camino de 2 a 5 que es el camino que comunica la mayoría de la información en la red y la ilustración 22 nos lo comprueba al mostrarnos que los nodos 4 y 0 respectivamente son los únicos que pierden paquetes.

24

La ultima observación nos adentra a un curioso efecto interno en el funcionamiento de NS2, como se ve, los paquetes que mas se pierden son los generados por el mismo nodo que esta congestionado esto nos muestra que se da cierta prioridad a los paquetes provenientes de un enlace y no a los provenientes de un agente posiblemente por la estructura de como se genera trafico dentro del agente del nodo y la congestión que se genera en el demultiplexor de direcciones (ver ilustraciones 10 y 9).

Malla 2

El código Tcl no necesita demasiada explicación pero aun así se incluye al final del documento un apéndice con

las funciones mas utilizadas. La salida al simular la red es la que sigue.

En esta malla los nodos del 0 al 5 y el nodo 12 son los que generan el trafico saturando el enlace de los nodos 6 y 7 y dejando sin utilizar la ruta 6-8-10-11 esta como las demás mallas se pensaron como idóneas para demostrar las

potencialidades de Qrouting.

Con la siguiente gráfica corroboramos las congestiones.

25

Aquí vemos claramente una zona de conflicto en el enlace de-7 hacia 2 y un nudo entre los enlaces 2, 5, 6 y 7 de las mismas dimensiones, la diferencia entre la cantidad de paquetes de 7 hacia 2 y a la inversa obedece únicamente a la implementación pseudoaleatoria en la generación de paquetes que presenta Ns2.

Aquí vemos como los nodos que pierden paquetes son tanto el 6 como el 7 (unión de las dos regiones de la red).

Malla 3

A continuación se presenta la animación obtenida.

26

Esta malla es importante entre otras cosas debido a su similitud con la malla propuesta por los creadores de Qrouting en su trabajo los doctores Littman y Boyan para demostrar su propuesta. En este caso los nodos del 0 al 5 transmiten hacia los nodos comprendidos entre el 6 y el 11 y en sentido contrario la parte derecha de la red transmite hacia la izquierda.

Como era de esperarse los nodos 1 y 6 son los que presentan picos en el reenvió de paquetes al ser los enlaces

27

centrales y la primera conexión entre las dos secciones de la red. En la parte de la perdida de datos tenemos:

Podemos ver en esta gráfica como la perdida de paquetes se da de manera mas o menos similar en cada uno de los enlaces de las escuadras conformadas por 0,1,3 y 6,7,8 que es donde se da salida al trafico.

Malla 4

En esta malla muy similar a la anterior aunque se suma un nuevo elemento, el nodo 16 el cual proporciona un ■KVO camino entre las dos redes el cual se convierte en el mas directo para algunos nodos dividiendo así el

28

Se nota claramente la similitud con la malla anterior a excepción de las cuatro nuevas barras que representan el trafico circulado por el nodo 16 hacia los nodos 3 y 8, trafico que es equivalente al que pasa por el enlace 1,6.

Se puede ver como a diferencia de la malla anterior se dejaron de perder paquetes en los nodos 0 y 7.

29

trafico. Y esto se ve en la gráfica de paquetes reenviados

3.2.3 LS (Link States)

A continuación presentamos los resultados que se obtuvieron en las mallas con el protocolo de ruteo de estado de enlaces como se ve en las siguientes ilustraciones, la distribución del trafico no varia de la que se tenia en el protocolo de vector distancias, no así la cantidad de trafico pero con una diferencia prácticamente nula.

30

La similitud entre las distribuciones de trafico se debe principalmente a que ambos protocolos manejan una métrica muy similar.

Analizando el caso de las gráficas de perdida de paquetes en la red, al igual que en el caso de el reenvío de paquetes, la distribución es muy similar a la que se presenta en la red con vector distancias pero es mas notable que son menos los paquetes perdidos.

32

3.2.4 Comparación en NS2

A continuación se analizan las redes con LS y DV frente a frente, empezando con los retardos en donde se ve como a pesar de que la diferencia es poca el protocolo de estado de enlaces presenta un menor retardo como se esperaba.

33

Al comparar el acumulado de los paquetes perdidos en la malla 1 podemos ver que solo en esta RIP presentaba

menos paquetes perdidos que OSPF con lapsos en los que se- nivelaban los protocolos.

En el caso de la malla 2 los dos protocolos tienen una perdida de paquetes prácticamente idéntica, con un pequeño desfase ya para el final de la simulacion.b

35

Ahora procederemos a analizar las gráficas de paquetes perdidos.

En la malla 3 que es la que mas trafico transmite por el menor numero de enlaces (el trafico de 6 nodos pasa solo

por un enlace ya que el otro no se utiliza), se nota la diferencia en la perdida de datos para los algoritmos siendo claramente mejor OSPF.

En la ultima malla al incluir un nuevo puente por el enlace 16 la perdida de paquetes se reduce y la diferencia tre protocolos se atenúa visiblemente.

36

Í

3.3 Simulación de Qrouting

Al percatarnos de la complejidad del proyecto se opto en apoyamos replicando la simulación de Boyan, Littman esta simulación fue desarrollada en una conjunción de C y TK,TCL utilizando las bondades de el gestor de objetos gráficos WISH.

El poner a funcionar la simulación presento varias complicaciones la primera fue que la simulación se hizo en C con un compilador previo a la estandarización que supuso el paso de Gcc 2.X hacia Gcc 3.X entonces se tuvieron que buscar las librerías de compatibilidad debido a que la compilación presento varios problemas el primero que la librería varargs.h dejo de estar implementada siendo sustituida por stdarg.h suponiendo un nuevo tipo de programación, el segundo problema es que WISH no es igualmente implementado en las diferentes ramas UNIX existentes en la actualidad, razón por la cual se tuvo que correr en Solaris.

La opción fue montar una maquina virtual de solaris 10 sobre la estructura proveída por Virtual Box OSE sobre Linux, aquí cabe mencionar que en los últimos años el tema de la virtualización ha tenido un gran auge en el ambiente de los sistemas operativos haciendo relativamente fácil virtualizar todo, desde gráficos, hasta tarjeta de red pasando por el CD y tarjeta de sonido.

Después de compilarlo e instalar WISH, tcl y tk, ponemos las rutas en las variables de entorno.

Ahora podemos ejecutar la simulación esto se hace con el comando:

# ./router.tcl graphname nombre.net

donde nombre.net es el nombre con el que nombramos la red en un archivo de texto especificando cada nodo, su posición y cada enlace.

Al correrlo nos aparece una ventana donde podemos interactuar con la red moviendo la carga, el factor alfa, deshabilitando enlaces y viendo rutas hacia un nodo en especifico.

El factor alfa o Nambla como lo pusimos en capítulos previos es el que se conoce como factor de aprendizaje y determina que tan rápido converge la red. Así como se ve en la siguiente ilustración a un alfa mayor corresponde una etapa de acoplamiento menos, mas no así una mayor eficiencia ya en el estado estable.

37

http://nombre.net/

http://nombre.net/

Como vemos en las siguientes ilustraciones utilizando Qrouting el trafico se distribuye de una forma mas eficiente logrando asi reducir el tiempo de retardo en la entrega de paquetes.

En la ventana de simulación podemos distinguir el trafico por el grosor de el enlace en ese instante.

38

En la ilustración podemos observar como en la malla 2 se empiezan a utilizar enlaces que en los protocolos clásicos eran desperdiciados.

Al igual en la malla 3 así como en la 4 se ve como el lazo superior se utiliza, liberando al enlace principal del trafico que presentaba.

39

3.4 Implementación de un nuevo protocolo en NS-2.

A pesar de no funcionar haberse podido incrustar el protocolo de la extensa investigación realizada asi como de la experiencia me permito exponer una breve introducción a los pasos necesarios para implementar protocolos de ruteo nuevos al simulador. Lo primero para poder poner un nuevo protocolo de ruteo en NS-2 es crear un directorio con el nombre de nuestro nuevo protocolo en este caso Qrouting dentro del cual pondremos los archivos:

qrouting.h: esta es la librería donde se definirán todos los timers así como el agente de ruteo. qrouting.cc: es la implementación de los timers y del agente de ruteo. qrouting_pkt.h: aquí se definen los paquetes necesarios para que Qrouting intercambie información. qrouting_rtable.h: librería donde se declara la tabla de ruteo. qrouting_rtable.cc implementación de la tabla de ruteo

El primer y principal paso al implementar un protocolo es el agente ya que como se lee en la documentación "los agentes representan los puntos finales donde los paquetes de la capa de red son creados o utilizados y se utilizan en la construcción de diversos protocolos".

Nuestro agente es el que se encargara de mantener nuestra tabla de ruteo la cual es manejada como una clase

qrouting_rtable. Para que esta tabla se alimente se necesitan paquetes nuevos y procesarlos estos paquetes son los

que definimos en qrouting_pkt la propuesta de este paquete es la que sigue en concordancia con lo propuesto enO

flag ret: 0 si el paquete es un envío, 1 si es una respuesta a un envío

back Q: la dirección del nodo que envía el paquete (para ayudar a enviar el estimado Q de vuelta)

estim Q: valor del mejor Q estimado

dest: la dirección de red del destino final del paquete de datos

reach: tiempo de transmisión del paquete

40

etique: tiempo en el cual el paquete se agrego a la cola

send: tiempo en el cual el paquete dejo la cola

recv: tiempo en el cual el paquete fue recibido

back: tiempo en el cual el paquete se transmitió de regreso

CAPITULO 4 : Conclusiones.

Como conclusión a este trabajo puedo expresar que el mundo del ruteo es amplio e interesante. Es en si la columna vertebral de la comunicación en una red permitiendo comunicación eficiente para dar lugar a servicios como VoIP, WWW, Email, etc.. adquiriendo una importancia vital en las telecomunicaciones.

También encontré que es un área de las muy interesante a pesar que en realidad la investigación en el área es reducida ya que como en otras áreas de las telecomunicaciones el costo derivado de la implementación de mejoras es muchas veces impositivo y es por eso que los algoritmos de ruteo evolucionan de una manera tan lenta y los fabricantes de equipo como Cisco prefieren darle continuidad a sus algoritmos propietarios como IGRP, para así continuar con un control del mercado que implementar técnicas de un perfil abierto.

Otra cosa interesante en este trabajo es que la información es enorme e involucra muchas veces conceptos matemáticos avanzados los cuales en la carrera no se ven y seria interesantes que se conocieran como son la matemáticas derivada de la teoría de colas. Un punto malo, tal vez el principal causante de que el trabajo terminal no se concretara en su totalidad es el hecho que esa información muchas veces es imprecisa o incorrecta por ejemplo en mucha de ella se asegura que los protocolos de ruteo RIP y OSPF están implementados (http://networks.ecse.i-pi.edu/--sunmin/rtProtoLS/) para en una investigación mas profunda descubrir que solo están las versiones mínimas de un protocolo de estados de enlaces (LS) y de vector distancias (DV) (http://mailman.isi.edu/pipermail/ns-users/2002-March/02I220.html).

Lo mismo ocurrió con el proyecto Zebra y la poca información respecto a la inclusión de nuevos protocolos en el simulador NS2.

Como trabajos futuros puede quedar sin lugar a dudas incluir Qrouting en NS2 pero sin desviarse en la implementación física.

41

http://networks.ecse.i-pi.edu/--sunmin/rtProtoLS/

http://mailman.isi.edu/pipermail/ns-users/2002-March/02I220.html

BIBLIOGRAFÍA

HuiOl :Libro Routing in the Internet - Huitema, Christian, Prentice Hall 1995

Tom01:Libro Sistemas de comunicaciones electrónicas - Wayne Tomasi, Pearson Educación 2003

PacOl:Artículo Modelos y Simulación - G. Pace, UNNE 1998

MigOhRevista Simulador de redes telemáticas - Juan Manuel Miguel Jiménez; Revista española de electrónica

583, 0482-6396 2003, Paginas 66-74

42

ANEXOS

ANEXO A: Protocolos de ruteo clásicos.

Protocolos de vectores de distancia. Comúnmente conocidas como de "Bellman - Ford" puesto que están basados en el calculo del camino mas corto

descrito por R.E. Bellman y la primera implementación del algoritmo es atribuida a Ford y Fulkerson. Este tipo

de protocolos han sido utilizados en varias redes de distribución de paquetes desde la Arpanet o Cyclades, desde

entonces han evolucionado hasta algoritmos tan notables como PUP y XNS RIP de Xerox pero conservando sus

fundamentos.

Empezaremos Revisando su funcionamiento. Suponiendo que tenemos una red muy simple como la de la

ilustración:

Inicio en frío.

En el supuesto de iniciar todos los nodos desde cero al mismo tiempo cada nodo solo dispondría de su información

local desconocen cuantos nodos están en la red y demás información global pero si conocen su dirección y así

mismo conocen cuantas conexiones tienen entonces iniciarían con una tabla de ruteo de una sola entrada en el caso

del nodo A su tabla seria:

El nodo A en ese momento abstraería la tabla de ruteo en un vector de distancias de una sola entrada: A=0 Entonces el Nodo A envía su vector de distancia a todos sus vecinos con una conexión local en este caso A enviaría este vector a B y D así ellos incrementarían sus tablas en la siguiente forma: Para B:

Aquí se esta asumiendo que el costo de la comunicación a través de un enlace local es de 1 entonces B preparara su

vector de distancias como:

B=0, A=l

En este periodo de tiempo D recibirá la misma información que B y actualizara su tabla de la misma manera:

43

Y de la misma manera transmitirá su vector de distancias: D=0, A=l

El mensaje de B será recibido por A, C y E mientras que el mensaje proveniente de D lo tomaran A y E.

Para el caso de A recibirá un vector de B con las distancias: B=l, A=2. Este vector contiene una entrada

desconocida en la tabla de ruteo de A la cual es B pero incluye una entrada con un costo distinto para una entrada conocida (A), al compararlas la entrada anterior tiene un costo menor y por esto solo incluye el valor para la nueva

entrada y lo mismo pasa con el mensaje proveniente de D dejando una tabla:

Cabe destacar que en este supuesto se planteo que el paquete con los nuevos pesos llegara primero del nodo B y

enseguida del nodo D.

En el caso del nodo C recibirá de B el mismo vector pero para el los dos nodos son desconocidos así que los

agregara a su tabla quedando:

En el nodo E se recibirá el vector de distancia de B: B=0, A=l en el enlace 4 y actualizara su tabla en

consecuencia:

Enseguida recibe el paquete de D en este caso a diferencia de lo que paso en el nodo A las distancias son iguales aquí

se asume que el nodo opta por no actualizar sus tablas de tal forma que quedarían como:

44

ANEXOS

A este punto A, C y E ya tienen nuevas tablas de ruteo ahora generaran sus propios vectores de distancias y los

enviaran a sus vecinos:

Ahora B, D, y E pueden preparar sus vectores de distancias: Desde B: B=0, A=l, D=2, C=l, E=l que viajara en los enlaces 1, 3 y 4 Desde D: D=0, A=l, B=2, E=l que viajara en los enlaces 3 y 6 Desde E: E=0, B=l, A=2, D=l, C=l

que viajara en los enlaces 4, 5 y 6 Estos mensajes al ser recibidos por A, C y D actualizaran las tablas de la siguiente forma:

45

ANEXOS

Estos envíos de pesos provocaran la actualización de las tablas de ruteo de la siguiente manera:

Ahora A, C y D prepararan nuevos vectores de pesos pero al ser enviados estos no provocaran ya cambios en sus

vecinos, así en este punto podemos decir que la red ya aprendió desde los recursos locales la topología de la red

gracias a un computo distribuido y la comunicación entre los nodos.

Actualización en fallas.

Existen varias situaciones en las que un enlace puede dejar de ser funcional para la red desde una desconexión

accidental por un operador hasta un error en un equipo entre otras, es por esto que se tiene que contemplar el como

se van a modificar las tablas de ruteo de un nodo cuando un enlace queda fuera de servicio, en este caso

supongamos que el enlace 1 quedo fuera de servicio.

Suponiendo que ambos nodos conectados al enlace (A y B) descubren la falla en la comunicación por algún

monitoreo que mantengan de su equipo de transmisión. Deberían inmediatamente actualizar sus tablas de ruteo

denotando ese enlace (1) como con un coste infinito y así mismo cualquier nodo que fuera alcanzado

anteriormente a partir de ese enlace tiene un costo infinito para ruteo, las nuevas tablas serian:

46

ANEXOS

Ahora los nodos A y B se preparan para enviar sus vectores de distancias a los vecinos, el mensaje enviado por A es

recibido en D y se da cuenta que todas la distancia a B es mayor a la que tiene almacenada en sus tablas pero en este caso es precisamente el enlace 3 quien manda las nuevas tablas y es este el que se usaba para alcanzar a B

debido a esto se actualizara la tabla para quedar:

Ahora estos tres nodos se prepararan a enviar sus vectores respectivos propiciando la actualización de las tablas de A, B, D, y E como sigue:

47

ANEXOS

De manera similar C y E actualizaran sus tablas para quedar:

Ahora A, B y C prepararan sus vectores de pesos pero al ser enviados estos no tendrán efectos en los nodos vecinos

y de este modo las nuevas rutas se calcularon con éxito restaurando la conectividad global de la red.

El efecto de rebote.

Este es un fenómeno que puede ocurrir en una red con características especificas en la cual un enlace o conjunto de

estos es mas pesado que el enlace óptimo pero este enlace óptimo se cae disparando actualizaciones que si no llegan

en el orden idóneo provocaran que se cree un bucle empezando a elevar los valores de las rutas hasta exceder a la ruta cuyo valor era mas pesado pero que en esta nueva geometría es el camino mas corto y así "rebotar" o regresar

al valor de esta ruta.

Supongamos que no todos los enlaces son iguales y que para este ejemplo el enlace 5 tiene un peso de 10 mientras

todos los otros enlaces siguen con pesos de 1. Y nos concentraremos en las distancias de las distintos nodos hacia C

después del inicio en frió se tendrían los siguientes pesos.

Y entonces se rompe el enlace 2.

49

ANEXOS

ANEXOS

En este momento como ya se vio entra en acción el algoritmo para la actualización de las tablas: B enviaría a A la

notificación de que su costo hacia C es infinito y si por implementación en ese momento A enviara su vector de pesos a sus vecinos B tomaría el valor que le manda A debido a que este es menos que el de infinito que tiene

registrado dejando las tablas:

Los paquetes enviados de A a C serán enviados por el link 1 hacia B pero B los regresara por el mismo enlace hasta

que el TTL (Time To Live) se termine. Este rebote termina solo con la convergencia de la red a una nueva tabla de

ruteo coherente. El cambio de estado de la tabla a un estado coherente se dispara dependiendo de la implementación pero en este caso C envía su vector de distancias a E y este se percata que es 10 y que esto es

mayor que lo que tiene en su tabla e ignora el mensaje. Ahora si A y E transmiten sus nuevo vectores de pesos y propicia la actualización de las tablas en B y D.

50

Como se puede ver en este momento ya existe un bucle en la tabla

Así seguirán las actualización de las tablas aumentando los valores hasta converger a:

ANEXOS

Ahora si E recibe un aviso de C entonces lo tomara en cuenta bajando su lista de pesos y empezando a converger a

la tabla estable.

Finalmente el calculo se completo, después de una serie de pasos en los cuales la red va actualizando sus tablas cabe destacar que este es un proceso aleatorio ya que el envió de mensajes de actualización depende de la

implementación de un algoritmo así como del estado de la red misma además de que los pasos intermedios en los que existen bucles son causantes de perdidas de información.

Cuenta a el infinito.

Este es un procedimiento precautorio con el cual se previene como se vera mas adelante que la red continué

actualizando sus tablas de ruteo sin un alto y al mismo tiempo sin llegar a una convergencia.

Consideremos el siguiente ejemplo donde se rompen los enlaces 1 y 6 dejando incomunicados dos grupos de nodos:

Si D tiene la oportunidad de transmitir su nuevo vector de distancias inmediatamente; en ese momento A

actualizara su tabla y notara que todos los nodos a excepción de D tienen una distancia infinita y el algoritmo entonces habrá convergido, pero si A tuvo oportunidad de transmitir su ultimo vector de distancias:

Desde A: A=0, B=3, D=3, C=3, E=3

51

Enfocándose en lo que pasa con los nodos A y D, D nota que el enlace 6 ha fallado y actualiza sus tablas de

ruteo como sigue:

ANEXOS

En ese momento D actualizaría su tabla a la que sigue:

Este proceso se denomina cuenta al infinito ya que debido a que A y D están incomunicados, esto provocara que

solo vayan aumentando sus valores indefinidamente, la única forma de evitar esto es que se utilice un número mas

grande que la peor ruta como infinito y si un nodo llega a ese valor se considerara inalcanzable.

Técnica de horizonte dividido.

Esta Técnica esta basada en una simple precaución. Si el nodo A esta enviando paquetes a el nodo X a través del

nodo B

Entonces no tiene sentido para A el anunciar a B que X esta cerca de A.

Una segunda técnica es conocida como "split horizon with poisonous reverse" en este método enviara en el vector

todos sus nodos como a una distancia infinita al detectar un error y así elimina cualquier ciclo entre dos nodos aunque aun hay bucles los cuales no pueden ser eliminados.

52

En este caso se vuelve a generar un ciclo entre el nodo A y D en el que los costos se irán incrementando sin fin:

No tiene sentido para B el intentar llegar a X a través de A

ANEXOS

Triggered updates

En muchas implementaciones de estos algoritmos se incluye timer que esta asociado a cada entrada de la tabla de

ruteo, si la información no ha sido refrescada por la recepción de un nuevo paquete antes de que expire este timer, asumimos que el nodo encargado de esta ruta posiblemente ha fallado y se envía a infinito el peso en nuestra tabla

para esa ruta. La selección de este timer es complicada ya que debe de ser mayor que el periodo de transmisión de la información, de lo contrario se podría marcar una ruta como infinita solo por la perdida de un paquete, por ejemplo

RIP propone un timer de seis veces el intervalo de transmisión.

Un periodo muy largo entre el envió de paquetes de distancias puede ser muy nocivo especialmente porque si el

error ocurre justo después de que ocurre una transmisión entonces tardara mucho en darse la convergencia de las

tablas hacia un estado coherente. El procedimiento llamado "Triggered updates" es un esfuerzo para incrementar la

velocidad de respuesta del protocolo pidiendo a los nodos enviar mensajes de actualización tan pronto como

detecten un cambio en tablas de ruteo aun sin esperar el fin del periodo para transmitir.

RIP, versión 1

RIP: es el algoritmo mas ampliamente usado para ruteo interior en la Internet [HuiOl] sus siglas significa:

"Routing Information ProtocoP, es un protocolo muy simple de la familia de "vector de distancias". RIP fue

inicialmente desarrollado como un componente del código del nivel de red de la versión BSD de UNIX

incorporado en un programa llamado "routed" para "routed management daemon " este algoritmo fue

documentado por primera vez en el RFC 1058 en 1988 por Charles Hedrick.

RJP fue diseñado como un IGP "Infernal Gateway Protocol'"para intercambiar información dentro de una AS

"Autonomous System" osease una red con un tamaño relativamente pequeño.

Por omisión RIP usa una métrica muy simple para priorizar rutas: la distancia es el número de enlaces que deben de ser utilizados para alcanzar el destino, esta distancia suele expresarse como una variable entera entre 1 y 15 denotando el infinito con un valor de 16.

Los paquetes con los pesos de los vectores son transmitidos usando UDP sobre el puerto 520 tanto para emisión

como para recepción de mensajes, el uso de este puerto en especifico obedece a que dentro del sistema BSD-UNIX los puertos menores a 1024 solo pueden ser utilizados por procesos privilegiados por el usuario Root, estos

paquetes son enviados cada 30 segundos, o mas rápido en caso de implementar triggered updates, si una ruta no ha sido actualizada en 180 segundos, la distancia se modificara a infinito.

En RIP las tablas de ruteo contienen al menos: La

dirección de destino El peso asociado a ese destino la dirección del siguiente

router una bandera de "recién actualizado" timéis

Al recibir un router un vector de pesos verifica que sea valido en especifico que la dirección no sea una

reservada como la 127.0.0.1 después de verificarla ejecuta el proceso común del algoritmo de vectores de distancias:

53

El protocolo RIP también permite solicitudes. Una solicitud es normalmente enviada cuando un router inicia

operaciones para obtener de sus vecinos un valor inicial para su tabla de ruteo, en esencia hay dos formas de

solicitud, pedir toda la información de ruteo disponible por un router o la información para una ruta en particular.

RIP, versión 2.

RIP-2 fue definido por Gary Malkin en el RFC 1388, esta versión de RIP mejora algunas fallas del RIP, versión 1 en especial sobre seguridad ya que RIP 1 no es un protocolo seguro, ya que cualquier ordenador enviando paquetes

UDP en el puerto 520 puede ser considerado un router por sus vecinos, haciendo caso a sus mensajes, debido a la ausencia de cualquier esfuerzo de identificación de la fuente.

A pesar de todas las mejoras que pudo meter RIP-2, no puede resolver un problema medular el cual es el tener que contar al infinito cuando algún enlace se rompe. De hecho el protocolo de vectores de distancia puede ser mejorado con el algoritmo denominado "rastreo de fuentes ", este algoritmo fue presentado simultáneamente por

dos grupos durante SIGCOMM en 1989, la idea esencial es el incrementar la información contenida en las tablas de ruteo añadiendo un indicador, del lazo anterior con el cual el router puede hacer un rastreo recursivo para saber si la

ruta no tiene un loop en ella ambos papers contienen demostraciones de como al agregar este factor

54

ANEXOS

ANEXOS

los ciclos se pueden identificar de manera inmediata.

RIP es simple, y esa es la razón principal por la que es tan utilizado aun ahora, su implementación es relativamente

rápida sin la necesidad de implementar algoritmos demasiado complejos además solo existen dos mensajes y una tabla, y el resultado final es muy aceptable para una topología de red relativamente simple y sin muchos riesgos de

que los enlaces se rompan.

Pero para una red mayor y más compleja RIP sería sumamente inadecuado, ya que calcula muy lentamente en

algunos casos los cambios en la topología de la red, además de que por definición del algoritmo no puede implementarse en redes con más de 15 saltos debido al establecimiento de 16 como infinito.

Protocolos de estado de enlace. El protocolo de estado de enlace está basado en un mapa distribuido en el cual todos los nodos tienen una copia del

mapa de red, en vez de intentar calcular las "mejores rutas" de forma distribuida, todos los nodos tienen una copia

completa del mapa de red y realizan un cálculo completo de las mejores rutas para este mapa, este mapa se guarda

en una base de datos en el nodo en la cual cada renglón representa un enlace entre dos nodos por ejemplo para red:

Cada entrada es insertada por un nodo responsable de esto y contiene: identificador de la interfase, e información

describiendo el estado del enlace (destino y peso), con esta información cada nodo puede fácilmente calcular la ruta óptima del mismo hacia cualquiera de los nodos de la red. Con los procesadores disponibles este calculo se

logra en pocos milisegundos en redes de dimensiones razonables. Al todos los nodos tener las mismas bases de datos y ejecutar el mismo algoritmo de generación de rutas, las rutas son coherentes y los ciclos no pueden ocurrir

por ejemplo al enviar un paquete hacia c en nuestra red las trayectorias serian:

55

ANEXOS

Ilustración 14: Trayectorias hacia C calculadas en la red

Se puede ver en el diagrama que no se utilizaran los enlaces 3 o 4 en cambio, si A quiere transmitir hacia C

transmitirá siempre por el enlace 1 y B le hará por el enlace 2.

Protocolo de transmisión de actualizaciones.

El propósito de un protocolo de ruteo es adaptar los routers a las condiciones cambiantes de la red. Y esto solo se

puede lograr si la base de datos esta apropiadamente actualizada después de cada cambio en el estado de la red.

Justo después de detectar que el enlace 1 se ha caído. A

enviara a D un mensaje de actualización a través del enlace número 3.

Desde A, hacia B, enlace 1, distancia = infinito.

D entonces automáticamente retransmitirá el mensaje a E en el enlace 6, el cual lo enviara a B en el enlace 4 y a C

por el enlace 5.

El algoritmo general para la transmisión de los mensajes de actualización seria:

56

En este algoritmo la operación de transmisión implica el enviar la información en todas las interfaces menos en la

que se recibió el aviso y añadiendo un número de secuencia al mensaje, este número es vital para conservar la

coherencia de la red.

Después de llegar los respectivos mensajes la tabla quedaría:

57

ANEXOS

ANEXOS

Los números de secuencia son aumentados comúnmente de una forma lenta después de un cambio de estado en un enlace o bien después de un tiempo muy largo.

Alineamiento de base de datos.

En el análisis del protocolo de vectores de distancias, se considero el caso de que existieran dos fallas en los enlaces dejando la red dividida en dos secciones incomunicadas Ilustración: 8, esto tuvo como consecuencia lo que

se vio como cuenta a infinito en el caso del protocolo de estado de enlace la falla en el enlace 6 sera detectada por D y E, pero cada uno de ellos podrán transmitir la información de la falla a sus nodos vecinos, después de ejecutar

la actualización, tendremos dos versiones de las bases de datos que reflejaran que ahora la red estará dividida en dos redes una con los nodos A, D y otra con B, C y E.

Para A y D:

Para B, C y E:

Debido a que cualquier ruta que parta de A y D hacia B, C o E tendría que pasar por un enlace con una distancia

infinita los nodos A y D notaran que están aislados al igual que harán B, C y E, de hecho los nodos podrán calcular

este nuevo estatus de la red en seguida de recibir la notificación de cambio en el estado de la red sin entrar a algo

parecido a la cuenta a infinito.

Pero hay que considerar que pasa cuando alguno de los dos enlaces vuelve a funcionar, en este caso la sola

transmisión de la información del nuevo enlace no sera suficiente. Suponiendo que el enlace 1 se reconecta, los

58

ANEXOS

mensajes describiendo el cambio de estado aun dejarían incoherencias en las tablas. Por eso se debe de garantizar

que las dos secciones terminen con bases de datos alineada a este proceso se le denomina "Bringing up adjacencies" en OSPF.

Las dos secciones deben de sincronizar sus bases de datos y mantener solo las versiones mas actualizadas de de cada registro. OSPF resuelve este problema definiendo paquetes de "'descripción de base de datos", los cuales contienen solo los identificadores de enlace y su correspondiente número de secuencia. Durante la primer fase de la

sincronización ambos routers enviaran una completa descripción de sus bases de datos con esta información y en seguida el router compara los números de secuencia con los que tiene almacenados en su propia base de datos y así

obtiene una lista de elementos interesantes como pueden ser aquellos en los que el número de secuencia externo es mayor que el que se tiene registrado o bien los enlaces que no están presentes en la base de datos, cada router pedirá

una copia completa de esos registros a través de paquetes de solicitud de estado del enlace.

Como una consecuencia de esta sincronización, varios registros serán actualizados, esos registros actualizados serán

transmitidos a los demás nodos adyacentes usando el procedimiento normal de actualización.

Asegurando las bases de datos.

La idea detrás del protocolo de ruteo por estado de enlace es mantener sincronizada una copia de la base de datos

que describe la red en todos los nodos de la red. Por ello es esencial que todas las copias sean idénticas de otra

forma la coherencia en el ruteo no estaría asegurada. De hecho existen momentos en los cuales algunos nodos

estarán mas actualizados que otros, como por ejemplo justo después de una falla en un enlace. Pero el

procedimiento regular de actualización es mas que suficiente para que este estado "incoherente" de las bases de

datos no afecte el desempeño de la red.

En 1983, Radia Perlman demostró la necesidad de proteger la integridad de la base de datos contra una

corrupción accidental o provocada por un tercero[Hui01]. OSPF incluye algunas protecciones para este fin:

El procedimiento de actualización incluye el reconocimiento del nodo que nos envía la información.

Los paquetes con la descripción de la base de datos se transmiten de manera segura.

Cada registro esta protegido por un timer y si no llega una actualización antes que se acabe el tiempo es

eliminado.

Todos los registros están protegidos por un checksum.

Los mensajes pueden ser autentificados.

El algoritmo de Dijkstra.

En el caso del protocolo de vectores de distancias están basados en el algoritmo de Bellman-Ford para el calculo de

la ruta mas corta en el caso del protocolo de estado de enlaces se utiliza un algoritmo mas eficiente para calcular esta ruta de manera local después de tener la base de datos y una elección natural para esta tarea es implementar el

algoritmo que propuso E. W. Dijkstra llamado "Shortest Path First" del cual provienen las siglas SPF que ostentan algunas implementaciones del protocolo como lo es OSPF. El algoritmo de Dijkstra calcula la ruta mas corta desde

un nodo hasta cualquier otro nodo de la red y el algoritmo es como sigue:

59

El algoritmo SPF converge en O(MlogM) iteraciones mientras que el de Bellman-Ford utiliza 0(N*M) donde N

60

ANEXOS

ANEXOS es el número de nodos, para una

red con muchos enlaces la diferencia puede ser muy grande.

Las ventajas del protocolo de estado de enlace.

Muchos especialistas en redes prefieren el protocolo de estado de enlace por encima del de vectores de distancia y

existen varias razones para esto:

Velocidad y convergencia sin ciclos:

Inmediatamente después de realizado el envió de actualizaciones y el calculo de rutas todas las rutas en la red son

coherentes, sin ciclos intermedios, sin cuentas hasta el infinito esto principalmente a que los nodos solo envían

información de la cual están seguros dejando los cálculos solo de forma local.

Soporte para varios tipos de pesos:

Si los costos de los enlaces varían mucho las cuentas a infinito pueden demorar mucho tiempo y es la razón

principal por la cual RIP tiene un infinito tan pequeño (16), este problema no se presenta en los protocolos de estado

de enlace permitiendo una gama de pesos mayor así se puede considerar:

Ancho de banda

Tiempo de espera

Menor costo

Mejor BER en la transmisión

El incorporar diferentes pesos es algo que de no ser bien controlada puede provocar algo parecido a ciclos. Imaginemos que en nuestra red los enlaces que proporcionan mayor ancho de banda de E a C son el 2,4 y se elije esa trayectoria pero B elige para sus paquetes una trayectoria con menor costo que seria la 4,5 un porcentaje de los

paquetes que le envié E a B para que lleguen a C serán devueltos por B a E por la discrepancia de un acuerdo en cuanto a como ponderar las rutas y esto nos propone que el criterio de ponderación debe ser uniforme en todo el

AS.

División de carga:

En muchas ocasiones la red tiene mas de una ruta óptima como en nuestra red de ejemplo que es simétrica y si los

enlaces pesan lo mismo la elección de un camino desde A hacia E es simplemente por convención ya que A, B, E

seria equivalente a A,D,E, pero esta elección tiene un contra implícito ya que el trafico se puede dividir en las dos

rutas trayendo muchas ventajas.

Una mejora en el algoritmo de SPF nos puede entregar una lista de las rutas mas eficientes a un destino de la red.

En el caso de OSPF se especifica que el trafico debe de dividirse equivalentemente entre las rutas con el mismo

costo.

En el caso de conexiones TCP se puede ver que a pesar de que las diferentes rutas tienen los mismos costos esto no

garantiza que los paquetes lleguen en la secuencia necesaria para una comunicación orientada a conexión, el

remedio que se implementa para este contratiempo es discriminar los paquetes que tienen una conexión TCP y

estos no dividirlos sino siempre enviarlos por la misma ruta.

Rutas externas: Se han estado tratando sistemas autónomos para analizar las técnicas de ruteo pero en casos mas complejos como el Internet esta aproximación no es valida en la Internet la conectividad sale de la escala integrando

diversos sistemas autónomos en una sola red compleja alcanzando millones de nodos al rededor del mundo.

61

ANEXOS

Cuando la salida a el mundo externo es solo por un gateway la solución es simple solo tenemos que saber como llegar a el pero si se tienen diversos proveedores de servicio. Esta aproximación es insuficiente ya que, la llegada a

el gateway del proveedor mas cercano no garantiza la mayor eficiencia de la transmisión, puesto que se desconoce la trayectoria que tendrá la información a partir de este punto hasta su destino.

Una solución es que cuando un gateway anuncia que tiene conectividad hacia un destino, puede inicializar una

distancia de algún valor que refleje el peso de la ruta externa. Pero se vio que en el protocolo de vectores de

distancias, el valor de las métricas debe de conservarse pequeño para las cuentas a infinito, entonces es imposible

incorporar un valor que refleje bien esa distancia externa lo cual no sucede en el protocolo de estado de enlaces.

OSPF

Las primeras redes como fueron Arpanet y Cyclades, usaban protocolos de vectores de distancias similares a

RIPfHuiOl], pero por esa época empezó a hacerse la pregunta de como hacer un protocolo de ruteo que transmitiera

la tabla de ruteo a los nodos para así evadir los problemas que se mencionaron acerca de RIP.

La tecnología de estado de enlace fue desarrollada para su uso en Arpanet en vez de intercambiar distancias a los

destinos, todos los nodos mantienen un "mapa" de la red que puede ser actualizado después de cualquier cambio en

la topología Esos mapas pueden ser utilizados para calcular rutas mas adecuadas de las que se podrían calcular con las técnicas de los vectores de distancias de hecho las rutas son tan precisas como si fueran calculadas de una

manera centralizada, a pesar de que el calculo sigue siendo distribuido. OSPF (Open Short Path Fisrst) es el protocolo de estado de enlace desarrollado por el IETF(Internet Engineering Task Forcé) para uso en el Internet y

ahora es el protocolo recomendado por la IAB(Internet Architecture Board) como un remplazo de RIP.

OSPF es un algoritmo basado en el protocolo de estado de enlaces y sigue su filosofía, hay una base de datos

distribuida, un procedimiento de actualización de esa base de datos, y registros especiales para rutas externas.

Las redes modernas de computadoras usan tecnologías muy variadas desde conexiones punto a punto hasta redes

Ethernet, token ring, entre otras, OSPF ha sido diseñado con soporte especifico para:

Diferenciar entre host y routers:

Una estructura común hoy en día es la conexión de redes locales. OSPF permite como una simplificación que sea

suficiente el establecer un enlace entre el router y la subred debido a que toda la Ethernet pertenece a una sola IP

Redes tipo Broadcast como Ethernet:

Las redes locales que utilizan Ethernet o token ring ofrecen dos servicios característicos:

Conectividad total, cualquier estación puede enviar paquetes a cualquier otro nodo.

Capacidad de Broadcast, una estación puede enviar paquetes que lleguen a todas las demás integrantes

de la red o a todas las pertenecientes a un grupo por medio del multicast.

OSPF incluye soporte genérico para redes con soporte de Broadcast.

establecer tantos enlaces como existen pares de routers

enlaces hacia los restantes elementos:

. Cada router tendría entonces N-l

62

El problema que se necesita solucionar es llamado "N cuadrado". Dados N routers en una red local se puede

ANEXOS

Para simplificar el proceso de encontrar las rutas OSPF reduce a N enlaces designando uno de los routers como

central así los otros routers establecerán una enlace con este router designado.

El primer paso es seleccionar a este router. Esta elección esta establecida en el protocolo de "Helio", que es por el

cual OSPF descubre sus vecinos en un enlace dado. Después de esta selección, los otros routers establecen

enlaces con el router designado,. Se puede demostrar que si todas las bases de datos están sincronizadas con la del

router designado entonces todas estarán sincronizadas en conjunto, v en esa forma no existe la

necesidad de

implementar las

Están establecidas las direcciones especiales: 224.0.0.6 "todos los routers designados", y 224.0.0.5 "todos los

routers OSPF" como direcciones reservadas para facilitar este enfoque de solución.

Pero el poner toda la confianza en un solo elemento nunca ha sido una buena idea y es de hay que no existe un

único router designado sino que existe un suplente para esta función, este se elige al mismo tiempo que el titular y escucha todas las transmisión es hacia el router designado como propias pero de una forma lo mas silenciosa

posible, manteniendo todos los routers conexiones hacia estos dos routers el número de enlaces requeridos para sincronizar se reduce y en redes con altos costos por enlace esta es una gran ventaja y debido a que cualquier falla

en el router principal se detectaría casi inmediatamente por el protocolo "Helio", y el router de respaldo esta siempre listo para entrar como principal no existe perdida de sincronía.

Redes como de circuitos virtuales.

Algunas redes utilizan redes por circuitos virtuales para enlazar sus router, montar IP sobre X.25 fue muy popular

en los 80's y aunque ahora ya no se utilice tecnologías modernas como ATM son ampliamente usadas en algunas zonas, en este tipos de redes el problema "N cuadrado" es mucho mas importante ya que el

establecimiento decircuitos virtuales suele ser demasiado costoso.

63

negociaciones.

ANEXOS

y se aplica la misma solución de implementar un router designado en este caso se crean solo los 2N enlaces

necesarios de los routers para el mantenimiento de las bases de datos y se establecerán conexiones como se

ocupen para la transmisión de información de los usuarios.

Dividir redes demasiado grandes en áreas para su manejo:

El tamaño de la base de datos, el tiempo del calculo de las rutas, y el trafico de mensajes de actualización se incrementa cuando la red crece,en redes de grandes dimensiones todos esos factores se vuelven excesivos, se

requiere demasiada memoria y el calculo de las rutas toma mucho tiempo, esto aparte de todo el trafico inducido por la actualización de las bases de datos. Es por esto que OSPF implementa el dividir redes muy grandes en secciones

o áreas mas pequeñas, así la mayoría de los ruteadores solo tienen que mantener y calcular las rutas para la sección de red a la que pertenecen y solo algunos cuantos son usados para unir las secciones y estos ruteadores mantendrán

dos bases de datos independientes, y son conocidos como ruteadores de borde de zona.

Debe de existir al menos un ruteador de borde de zona por cada zona el cual la comunique con el resto a través de un

backbone.

Esta aproximación al problema resuelve los problemas acarreados por áreas muy grandes pero acarrea otros:

En la mas pura implementación de un ruteo jerárquico los ruteadores no distinguen entre destinos en una misma

zona y dejan el trabajo de distribuir los paquetes a los routers que unen la zona con el backbone, pero esto puede ser

muy dañino por ejemplo:

En este ejemplo se rompe el enlace entre Al y A3 lo que provoca que si BBO quiere enviar un paquete a A3 se lo

envié a AB2 y dependiendo de los pesos de cada enlace lo podría enviar a A1 provocando trafico innecesario o

bien la perdida de los paquetes. OSPF resuelve este problema muy simple, porque no implementa un modelo de

jerarquía estricta ya que los routers que están en los bordes de las áreas no guardan en su base de datos todos los

datos de los routers de área sino solamente de aquellos con los que pueden tener acceso.

Y también existe otro posible fallo aun mas complicado que seria el que se puede presentar en el backbone como

por ejemplo:

64

En este ejemplo ya no existe una conectividad entre todos los elementos del backbone por si mismos sino que para

actualizarse tienen que enviar paquetes a través de áreas externas al backbone a través de un enlace virtual, es importante que los nodos pertenecientes al backbone puedan seguir conectados a pesar de este tipo de fallas ya que

de lo contrario se perdería toda la conectividad de la red, cabe destacar que se tiene que actualizar el coste de ese enlace virtual como la suma de toda la trayectoria que recorre.

La mayoría de las entradas en la base de datos de un protocolo de estados de enlace son por lo general los

registros externos.

La base de datos de OSPF

Los routers de OSPF se intercambian su bases de datos compuestas de entradas que describen el estado de los

enlaces de al red, el formato general de un registro en la base de datos seria el siguiente:

El campo advertising router lleva una de las direcciones IP del router y sera usado como el identificador OSPF para

ese router.

LS age es un entero de 16 bits el cual indica el tiempo en segundos desde que registro fue introducido.

El campo option de 8 bits describe las características del router pero solo se utilizan actualmente los últimos dos bits:

E para indicar si tiene enlaces externos y T para indicar el tipo de servicio, el valor de E es utilizado por Helio y T

se utiliza para indicar si el router soporta TOS (tipo de servicio) si se encuentra en 0 solo soporta TOS-0 como es el caso de los ruteadores Cisco.

65

ANEXOS

ANEXOS

LS type es un valor de 8 bits el cual actualmente puede tomar uno de 5 valores: Router link

Network link. Sumary link (red IP). Summary link (hacia los bordes). External link.

Link state ID este valor es seleccionado por el router que envió la información pero por lo regular es una

dirección IR

LS checksum es calculado de acuerdo a los estándares de IPy protege tanto la cabecera como el contenido.

Lenght es la longitud total en bytes de todo el registro incluyendo la cabecera.

LS sequence number es un valor de 32 bits con signo que toma la secuencia denominada de paleta en la cual la

secuencia varia entre 1-N y N-2 donde N= 231 =2,147 '483,648 en esta implementación de numeración cuando

un router publica por primera vez un enlace utiliza el número -N y se ira incrementando hasta que llegue al valor de

N-2 el siguiente valor sera 0 debido a que N-l se toma como un valor ilegal. La comparación se hace respetando las

reglas de este especial espacio si se quiere comparar dos números positivos a y b con a < b

calculamos b-a si el resultado es menor , entonces se decide que b es mas nuevo que a.

Entonces tenemos 5 tipos de LS veamos que se almacena en el registro dependiendo de cada tipo.

Protocolos de comunicación en OSPF:

OSPF tiene tres protocolos internos para crear y mantener la base de datos.

Helio, Exchange, y Flooding para realizarlos de manera correcta los routers que ejecutan OSPF utilizan la

siguiente cabecera común:

66

Versión number: identifica la versión de OSPF utilizada.

Type: Identifica el tipo de paquete OSPF:

Helio: Establece y mantiene ios enlaces entre routers vecinos.

Datábase description: Describe el contenido de la base de datos de manera breve.

Link-state request: Solicita registros de la base de datos a un router vecino.

Link-state update: Responde a una solicitud.

Link-state acknowledgment: Paquetes de actualización.

Packet length: Especifica la longitud del paquete incluyendo la cabecera.

Router ID: Identifica la fuente del paquete.

Área ID: Identifica el área a la que pertenece el paquete.

Checksum: Verifica la integridad del contenido del paquete.

Autype: Indica el tipo de identificación y existen tres.valores: sin

identificación, identificación simple, identificación cifrada.

Authentication: información necesaria para la identificación.

Data: contiene la información ocupada por los algoritmos como Helio, Exchange y Flooding.

EIGRP.

EIGRP es un protocolo de ruteo híbrido propiedad de Cisco Systems, que ofrece lo mejor de los algoritmos de vectores de distancias y del estado de enlace. Se considera un protocolo avanzado que se basa en las características normalmente asociadas con los protocolos del estado de enlace. Algunas de las mejores funciones de OSPF se usan

de forma similar con EIGRP. EIGRP mejora las propiedades de convergencia y opera con mayor eficiencia que RIP. EIGRP usa el siguiente calculo de métrica:

donde:

B=ancho de banda.

L=carga. D=retardo.

R= confiabilidad.

EIGRP mantiene las siguientes tres tablas:

67

ANEXOS

ANEXOS

Tabla de vecinos.

Cada router EIGRP mantiene una tabla de vecinos que enumera a los routers adyacentes. Esta tabla puede

compararse con la base de datos de adyacencia utilizada por OSPF. Existe una tabla de vecinos por cada protocolo que admite EIGRP.

Tabla de topología.

La tabla de topología se compone de todas las tablas de encaminamiento EIGRP recibidas de los vecinos. EIGRP

toma la información proporcionada en la tabla de vecinos y la tabla de topología y calcula las rutas de menor costo

hacia cada destino. EIGRP rastrea esta información para que los routers EIGRP puedan identificar y conmutar a

rutas alternativas rápidamente. La información que el router recibe de los vecinos se utiliza para determinar la ruta

del sucesor, que es el ténnino utilizado para identificar la ruta principal o la mejor. Esta información también se

introduce a la tabla de topología.

Tabla de ruteo.

La tabla de ruteo EIGRP contiene las mejores rutas hacia un destino. Esta información se recupera de la tabla de

topología.

Los campos de la tabla de encaminamiento son:

• Distancia factible (FD): Esta es la métrica calculada más baja hacia cada destino.

• Origen de la ruta: Número de identificación del router que publicó esa ruta en primer lugar. Este campo se

llena sólo para las rutas que se aprenden de una fuente externa a la red EIGRP.

• Distancia informada (RD): La distancia informada (RD) de la ruta es la distancia informada por un

vecino adyacente hacia un destino específico.

• Información de interfaz: La interfaz a través de la cual se puede alcanzar el destino.

• Estado de ruta: El estado de una ruta. Una ruta se puede identificar como pasiva, lo que significa que la

ruta es estable y está lista para usar, o activa, lo que significa que la ruta se encuentra en el proceso de

recalculo por parte de DUAL (distributed update algorithm).

Protocolos que utiliza EIGRP.

Cuando un router detecta que un vecino no está disponible, intenta encontrar rutas alternativas para todas

aquellas que en la tabla de encaminamiento están dirigidas a ese nodo.

Lo que se utiliza para saber si utilizar una ruta de un vecino o no es comparar la distancia factible de la ruta (la que

tenía el router antes de perder la conectividad con el vecino) con la distancia informada por cada vecino alternativo.

Si un vecino alternativo tiene una distancia informada menor que la distancia factible, significa que está más cerca que el router que calcula del destino y por tanto no puede dar origen a un bucle porque no puede volver al router que

recalcula. En este caso se puede usar como encaminamiento alternativo. Si un vecino tiene una distancia informada mayor que la factible, es posible que su camino hacia el destino pase por el router que hace el recalculo, por lo que

no es conveniente utilizarla ya que hay la posibilidad de que de lugar a un bucle de encaminamient.

Cuando no se encuentra un camino alternativo con la información disponible localmente, se desencadena el algoritmo DUAL (Diffusing Update Algorithm), que es el proceso de búsqueda de rutas alternativas de EIGRP.

68

ANEXOS

El proceso funciona de la siguiente manera:

El router que ha detectado la caída marca la ruta como parte del proceso de recalculo.

A continuación, pregunta a todos sus vecinos por una ruta alternativa para llegar a ese destino.

Cada vecino que recibe una pregunta por una ruta, mira en su tabla de encaminamiento si tiene alguna ruta para

llegar a ese destino que no sea el vecino que pregunta. Si la encuentra, contesta al vecino con ese dato y el proceso

se acaba.

Si no la encuentra, marca a su vez la ruta como activa y pregunta a todos los vecinos menos el que originó la

pregunta por una ruta alternativa. Si no tiene vecinos, responde que no encuentra una ruta. Así, la pregunta se va

difundiendo por toda la parte de la red que sigue accesible, hasta que se encuentra una ruta alternativa o se

determina que la ruta no está accesible porque todos los vecinos responden negativamente.

69

ANEXOS

ANEXO B: Breve introducción a los comandos de simulación en NS-2.

La siguiente es una introducción a la secuencia de comandos básicos e es la explicación de la secuencia de

comandos. En general, un script NS2 comienza con un objeto simulador.

Set ns [nuevo simulador]: genera un objeto simulador NS, y lo asigna a la variable ns. Lo que hace esta

línea es la siguiente:

o Iniciar el formato de paquetes. o Crear un planificador.

o Seleccione el formato de dirección predeterminada

$ Ns color FID color: se encarga de establecer el color de los paquetes de un flujo especificado por el flujo

de id (FID). Esta función miembro de "Simulador" tiene como objetivo mostrar la visualización en NAM, y

no tiene ningún efecto real en la simulación.

5 Ns namtrace-all descriptor de archivo: Esta función miembro le dice al simulador que tiene que registrar las huellas de simulación de NAM en formato de log. También da el nombre de archivo que el log utilizara

para grabar esta información después por el comando $ ns flush-trace. Del mismo modo, la función miembro trace-all es para el registro de la huella de simulación en un formato general. Proc finish (): se

llama después de finalizada la simulación.

Set nO [$ ns node]: La función miembro node crea un nodo. Un nodo en el NS está compuesto de

dirección y el puerto de clasificación.

S Ns duplex-link nodel node2 ancho de banda demora tipo-cola: crea dos conexiones simplex se

especifica el ancho de banda y retraso, y conecta los dos nodos especificados. En NS. la cola de salida de un nodo se ejecuta como parte de un enlace, por lo tanto, los usuarios deben especificar el tipo de cola.

Ademas se especifica el tipode cola las cuales pueden ser, DropTail o RED.

5 Ns queue-limit nodel node2 número: Esta línea establece el límite de la cola de los dos enlaces simples

que conectan nodel y node2.

Set tcp [new Agent / TCP]: Esta línea muestra cómo crear un agente TCP. Pero en general, los usuarios pueden crear cualquier agente o las fuentes de tráfico de esta manera. Los agentes y las fuentes de tráfico son, los objetos básicos. Para crear los agentes o las fuentes de tráfico, un usuario debe saber los nombres

de estos objetos (Agent/ TCP, Agent / TCPSink, Application / FTP, etc). Esta información se puede encontrar en la documentación NS.

5 Ns atfach-agent nodo agente: La función para adjuntar una agente a un nodo.

5 Ns connect agentl agent2: Después de que dos agentes están creadas, el siguiente paso es establecer una

conexión lógica entre ellos.

$ Ns at tiempo "cadena": Esta función miembro de el objeto Simulador hace que el planificador programe

la ejecución de los comandos especificados en la cadena en un determinado tiempo de simulación. Por

ejemplo, $ 0,1 ns at "$ CBR start" hará que el planificador llame a una función miembro CBR haciendo que comience a generar el trafico.

70

instituto politécnico nacional -...

Documents