INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA

MECÁNICA Y ELÉCTRICA

EVALUACIÓN DEL DESEMPEÑO DE LOS

PROTOCOLOS DE ENRUTAMIENTO AODV Y DSDV EN

UNA RED AD HOC

T E S I S

QUE PARA OBTENER EL GRADO DE

INGENIERO EN COMUNICACIONES Y ELECTRÓNICA

PRESENTAN:

JHONATAN JOSE ESPIRITU CASTRO

MARCO ANTONIO ESTRADA BURGOS

JOEL VÁZQUEZ GONZÁLEZ

ASESORES:

M. EN C. ERIC GÓMEZ GÓMEZ

ING. EDUARDO SILVA DORAY ESPINOSA

NOVIEMBRE 2012

Índice General

Abstract .................................................................................................................. I

Resumen ............................................................................................................... II

Objetivo ................................................................................................................ III

Antecedentes ....................................................................................................... III

Justificación ......................................................................................................... V

1. Redes ad hoc inalámbricas ................................................................................ 1

1.1. Introducción .................................................................................................. 1

1.1.1. Definición ............................................................................................ 1

1.2. Aplicaciones ................................................................................................. 2

1.3. Enrutamiento ad hoc .................................................................................... 2

1.4. Clasificación de los protocolos de encaminamiento para redes ad hoc ........ 3

1.4.1. Planificación ........................................................................................ 5

1.4.2. Modelo de información de estado ........................................................ 5

1.4.3. Modelo de transmisión ........................................................................ 6

1.4.4. Direccionamiento ................................................................................ 6

1.4.5. Estructura ............................................................................................ 7

1.4.6. Modelo de comunicación ..................................................................... 7

1.4.7. Modos de actualización ....................................................................... 8

1.4.8. Número de caminos buscados ............................................................ 8

1.4.9. Método de cálculo de rutas ................................................................. 9

1.5. Estudio comparativo ..................................................................................... 9

1.6. Eficiencia de enrutamiento .......................................................................... 11

2. Protocolos de enrutamiento AODV y DSDV ..................................................... 14

2.1. Protocolo DSDV .......................................................................................... 14

2.1.1. Ventajas de DSDV ............................................................................. 19

2.1.2. Limitaciones de DSDV ....................................................................... 19

2.2. Protocolo AODV .......................................................................................... 19

2.2.1. Información de enrutamiento .............................................................. 20

2.2.2. Descubrimiento de rutas .................................................................... 21

2.2.3. Mantenimiento de rutas ...................................................................... 24

2.2.4. Alcance de los mensajes de control del protocolo AODV ................... 26

2.2.5. Parámetros ........................................................................................ 27

3. Simulador NS-2 .................................................................................................. 28

3.1. Ventajas y desventajas de la simulación ..................................................... 28

3.2. Elección del simulador................................................................................. 29

3.3. Generalidades sobre NS-2 .......................................................................... 29

3.3.1. Instalación .......................................................................................... 31

3.3.1.1. Configurar variables de entorno .............................................. 33

3.3.1.2. Validación de la instalación ..................................................... 34

3.3.2. Funcionamiento de NS-2 .................................................................... 34

3.3.3. Ventajas y desventajas del simulador NS-2 ....................................... 35

3.3.3.1. Ventajas .................................................................................. 36

3.3.3.2. Desventajas ............................................................................ 36

3.3.4. Herramienta NAM de NS-2 ................................................................. 36

3.4. Ejemplos de script TCL ............................................................................... 37

3.4.1. Ejemplo de dos nodos Wireless comunicándose en modo ad-hoc ..... 38

3.5. Archivo de trazas ......................................................................................... 40

3.6. Programa Trace graph ................................................................................ 44

3.7. Gráficos en 3D ............................................................................................ 44

4. Evaluación del desempeño de los protocolos AODV y DSDV ........................ 45

4.1. Parámetros .................................................................................................. 45

4.2. Medidas de desempeño .............................................................................. 46

4.2.1. Througput ........................................................................................... 46

4.2.2. Tasa promedio de entrega ................................................................. 46

4.2.3. Retardo promedio de extremo a extremo ........................................... 46

4.3. Escenarios de simulación ............................................................................ 47

4.3.1. Escenario 1: Restablecimiento de la comunicación entre dos nodos .. 47

4.3.2. Escenario 2: Establecimiento de la comunicación entre dos nodos a

través de un nodo intermedio ............................................................. 51

4.3.3. Escenario 3: Comunicación entre dos nodos frente a cambios

continuos en una red de 5 nodos ....................................................... 55

Conclusiones ................................................................................................................... 59

Glosario ............................................................................................................... 61

Acrónimos .......................................................................................................... 63

Bibliografía.......................................................................................................... 65

ANEXO Código de las simulaciones ................................................................. 67

Índice de Figuras

Figura A.1. Red ad hoc .......................................................................................... IV

Figura A.2. Aspecto bidimensional de la formación de redes ad hoc ...................... V

Figura 1.1. Clasificación de los protocolos de enrutamiento para redes ad hoc ..... 4

Figura 2.1. Un ejemplo de las redes ad hoc ......................................................... 15

Figura 2.2. Enrutamiento de paquetes DSDV ...................................................... 17

Figura 2.3. Un ejemplo de la actualización de la información de ruta ................... 18

Figura 2.4. Inundación con mensajes RREQ ........................................................ 22

Figura 2.5. Generación de caminos de vuelta potenciales .................................... 23

Figura 2.6. Reenvió de mensajes RREP .............................................................. 24

Figura 2.7. Diagrama de flujo para la actualización de rutas en los nodos

intermedios durante la fase de formación del caminos de ida ............................... 25

Figura 2.8. Envió de paquetes de datos sobre el camino de ida finalmente

establecido ........................................................................................................... 25

Figura 2.9. Mensajes de enrutamiento en AODV .................................................. 26

Figura 3.1. Jerarquía parcial de clases del NS-2 .................................................. 30

Figura 3.2. Estructura de NS-2 ............................................................................. 31

Figura 3.3. Ventana mostrada al ejecutar NS-2 .................................................... 33

Figura 3.4. Ventana desplegada al terminar la validación ..................................... 34

Figura 3.5. Jerarquía parcial de clases del NS-2 .................................................. 35

Figura 3.6. Herramienta NAM ............................................................................... 37

Figura 3.7. Análisis de cada campo ...................................................................... 43

Figura 4.1. Escenario 1: Conexión mediante el protocolo AODV y DSDV ............ 47

Figura 4.2. Escenario 1: Desconexión entre los nodos 0 y 1 ................................ 48

Figura 4.3. Escenario 1: Restablecimiento de la conexión .................................... 48

Figura 4.4. Escenario 1: Throughput usando el protocolo AODV .......................... 49

Figura 4.5. Escenario 1: Throughput usando el protocolo DSDV .......................... 49

Figura 4.6. Escenario 1: Jitter usando el protocolo AODV .................................... 50

Figura 4.7. Escenario 1: Jitter usando el protocolo DSDV .................................... 50

Figura 4.8. Escenario 1: Paquetes perdidos usando el protocolo AODV .............. 51

Figura 4.9. Escenario 1: Intento de conexión sin éxito de los nodos 0 y 1 ............ 51

Figura 4.10. Escenario 2: Establecimiento de la conexión mediante un nodo

intermedio ............................................................................................................ 52

Figura 4.11. Escenario 2: Throughput usando el protocolo AODV ........................ 52

Figura 4.12. Escenario 2: Throughtput usando el protocolo DSDV ....................... 53

Figura 4.13. Escenario 2: Jitter usando el protocolo AODV .................................. 53

Figura 4.14. Escenario 2: Jitter usando el protocolo DSDV .................................. 54

Figura 4.15. Escenario 2: Paquetes perdidos usando el protocolo AODV ............ 54

Figura 4.16. Escenario 2: Paquetes perdidos usando el protocolo DSDV ............. 55

Figura 4.17. Escenario 3: Comunicación entre dos nodos usando el protocolo

AODV ................................................................................................................... 55

Figura 4.18. Escenario 3: Comunicación entre dos nodos usando el protocolo

DSDV ................................................................................................................... 56

Figura 4.19. Escenario 3: Throughput usando el protocolo AODV ........................ 56

Figura 4.20. Escenario 3: Throughput usando el protocolo DSDV ........................ 57

Figura 4.21. Escenario 3: Jitter usando el protocolo AODV .................................. 57

Figura 4.22. Escenario 3: Jitter usando el protocolo DSDV .................................. 58

Figura 4.23. Escenario 3: Paquetes perdidos usando el protocolo AODV ............ 58

Figura 4.24. Escenario 3: Paquetes perdidos usando el protocolo DSDV ............. 58

Índice de Tablas

Tabla 1.1 Aplicaciones de las redes ad hoc ........................................................... 2

Tabla 1.2. Estudio comparativo de los protocolos de enrutamiento ad hoc

proactivos ............................................................................................................. 12

Tabla 1.3. Estudio comparativo de los protocolos de enrutamiento ad hoc

reactivos ............................................................................................................... 13

Tabla 2.1. Tabla de enrutamiento del nodo H6 en un instante .............................. 16

Tabla 3.1. Ventajas y Desventajas del simulador NS-2 ........................................ 35

Tabla 3.2. Campos de los archivos de trazas ....................................................... 41

Tabla 3.3. Archivo traza ........................................................................................ 43

I

Abstract The wireless field has been experiencing exponential growth in the past decade. We have seen advances in network infrastructures, growing availability of wireless applications and the emergence of wireless devices such as portable or handheld computers, PDA´s and cellphones, all getting more powerful in their capabilities. These devices are now playing an important role in our lives. Due to the demand of ad hoc networks the routing protocols play an important role in this field because they have to meet all demands the networks require. Even though the ad hoc networks do not have a total implementation around the world, they have started to be more popular specially their routing protocols due to the importance they will have in the future for future technologies. The main aim of this document is to present a complete analysis of the routing protocols existed in ad hoc networks. There are many categories of those protocols though this document focuses on two pro-active and reactive routing protocols. The most popular protocols of each category are AODV and DSDV protocols so that this document has not only an information of how they work, but also the way they behave in different scenarios with different changes such as mobility, number of nodes, kind of traffic and of course kind of protocol. This project uses a simulating tool called network simulator to develop three scenarios in which both protocols AODV and DSDV show their advantages and disadvantages. To measure the performance each protocol has we use three main parameters such as throughput, jitter and dropped packets.

II

Resumen El campo inalámbrico ha experimentado un crecimiento exponencial en la última década. Hemos visto avances en las infraestructuras de red, la disponibilidad cada vez mayor de aplicaciones inalámbricas y la aparición de dispositivos móviles como computadoras portátiles, PDA y teléfonos móviles, todos cada vez más poderoso en sus capacidades. Estos dispositivos están jugando un papel importante en nuestras vidas. Debido a la demanda de las redes ad hoc, los protocolos de enrutamiento juegan un papel importante en este campo, ya que tienen que cumplir con todas las demandas que las redes requieren. A pesar de que las redes ad hoc no tienen una implantación total en todo el mundo, comienzan a ser populares por sus protocolos de enrutamiento debido a la importancia que tendrán las tecnologías en el futuro. El objetivo principal de este trabajo es presentar un análisis completo de los protocolos de enrutamiento existentes en las redes ad hoc. Hay muchas categorías de los protocolos aunque este trabajo se centra en dos protocolos de enrutamiento proactivos y reactivos. Los protocolos más populares de cada categoría son los protocolos AODV y DSDV, éste trabajo no sólo tiene información del funcionamiento, sino también la forma en que se comportan con diferentes escenarios y cambios como la movilidad, el número de nodos, tipo de tráfico y por supuesto tipo de protocolo. Este proyecto utiliza el software de simulación NS-2 (Network Simulator) para desarrollar tres escenarios en los que ambos protocolos AODV y DSDV muestran sus ventajas y desventajas. Para medir el desempeño de cada protocolo se utilizan tres parámetros principales, tales como el rendimiento, jitter y pérdida de paquetes.

III

Objetivo Evaluar el desempeño de los algoritmos de enrutamiento AODV y DSDV en un entorno inalámbrico ad hoc mediante un simulador de eventos discretos.

Antecedentes También conocidas como MANET “Mobile Ad hoc Networks”. Ad hoc viene del latín y se refiere a algo improvisado, mientras que en comunicaciones el propósito de ad hoc es proporcionar flexibilidad y autonomía aprovechando los principios de auto-organización. Una red móvil ad hoc es una red formada sin ninguna administración central o no hay un nodo central, sino que consta de nodos móviles que usan una interface inalámbrica para enviar paquetes de datos. Las computadoras están en igualdad de condiciones. La conexión es establecida por la duración de una sección. Los dispositivos descubren otros dispositivos cercanos o en rango para formar el “network”, estos dispositivos pueden buscar nodos que están fuera del área de alcance conectándose mediante los dispositivos que ya se encuentran conectados a la red y estén a su alcance. Las conexiones son posibles por múltiples nodos. Las redes ad hoc presentan cambios de topología. Estos cambios son frecuentes debido a su movilidad. Estas características impiden la utilización de protocolos de enrutamiento. Y esto crea nuevos retos de investigación que permitan ofrecer soluciones para problemas tales como topología dinámica y recursos de ancho de banda entre otros. Se pretende utilizar una topología jerárquica la cual se puede lograr utilizando un proceso conocido como clustering; este es un proceso en el cual los nodos de una red se organizan en grupos llamados clusters. Que es la forma en la que los nodos en MANET se organizan. Sin embargo, la mayoría de los estudios técnicos sobre “clustering” en redes ad hoc o MANET asumen el conocimiento sobre la posición de los nodos. Las raíces de la formación de redes ad hoc se pueden seguir hasta 1968, cuando se iniciaron los trabajos en la red ALOHA (el objetivo de esta red era conectar centros educativos). En 1973 en la PRnet (Packet Radio Network en su traducción del ingles “red de paquetes de radio”) fue una red de salto múltiple. En este contexto, salto múltiple significa que los nodos cooperaban en la retransmisión del tráfico en beneficio mutuo para llegar a estaciones distantes que de otra manera habría fuera de su alcance. Cuando se desarrolló IEEE 802.11, un estándar para redes de área local inalámbrica (Wireless Local Area Network WLAN) el Instituto de Ingeniería Eléctrica y Electrónica (Institute for Electrical and Electronic Engineering IEEE) sustituyó el término red de paquetes de radio por el de red ad hoc. Asociadas con las redes saltos múltiples de las operaciones militares o de rescate a gran escala y mediante la adopción de un nuevo nombre.

IV

Hoy día, nuestra visión de la formación de redes ad hoc incluye escenarios tales como los que se representan en la Figura A.1.

Figura A.1. Red Ad hoc.

Donde las personas llevan dispositivos que puedan conectarse en red en régimen ad hoc. Los dispositivos de un usuario pueden tanto interconectarse entre sí como conectarse a punto de información local por ejemplo, para consultar actualizaciones de salidas de vuelos, cambios de puerta, etc. Los dispositivos ad hoc pueden también retransmitir tráfico entre dispositivos que estén fuera de su alcance. Por lo tanto, el escenario del aeropuerto contiene una mezcla de saltos de radios simples y múltiples. La Figura 1.2 representa el aspecto bidimensional de la formación de redes ad hoc.

V

Figura A.2. Aspecto bidimensional de la formación de redes ad hoc. A medida que disminuimos la gestión centralizada, o nos alejamos de ella, nos encontramos moviéndonos en la dirección de una operación ad hoc pura, que también puede ser clasificada en términos de saltos simples o múltiples. Las tecnologías de radio, de acceso, y de encaminamiento completamente descentralizada habilitadas por Bluetooth, el modo ad hoc IEEE 802.11, el modo sin estación PRnet, la red móvil ad hoc (MANET), y los conceptos tales como la red de área personal (Personal Area Network – PAN) o la comunicación PAN a PAN se adaptan más o menos enteramente al dominio ad hoc.

Justificación Debido al crecimiento en las redes móviles y dar una posible solución para brindar internet a todo lugar y en todo momento; Este trabajo pretende principalmente analizar los algoritmos de las redes móviles DSDV y AODV con sus características correspondientes, es decir, rendimiento, complejidad del algoritmo, tráfico, etc. En la actualidad los algoritmos de enrutamiento son implementados con mayor frecuencia debido al gran avance de las redes de computadoras. En más lugares, la mayor demanda de mejor flujo de información con el mismo tiempo, la mejor calidad crece y es ahí donde los algoritmos toman su importancia. Por otro lado el entorno de las redes móviles se hace mas popular debido a esto crece la necesidad de mejorar los algoritmos existentes para poder así agilizar el tráfico de información en redes móviles. Las ventajas de analizar los algoritmos es que primeramente se pueda documentar para posibles trabajos de investigación, ya que no son tan comunes como los que existen para

VI

redes fijas. Segundo, comprender mejor el desempeño que estos tienen desde el punto de vista de complejidad, rapidez, funcionalidad, etc. Por otro, lado la ventaja de realizar un nuevo algoritmo viendo las características que tienen los anteriores es la de poder combinar y así mejorar el desarrollo de uno nuevo que junte las mejores características de cada uno y pueda sustituir a los existentes. Dentro de las desventajas es que el desarrollo de nuevos algoritmos pueda resultar complejo, también podría cubrir unas características pero al final descuidar las características básicas. Al final se espera haber cubierto completamente con la parte de análisis en la cual además se trabajara con un simulador de eventos discretos que facilitará la simulación de los algoritmos. El análisis será detallado y más aún se comparará las ventajas y desventajas que existen entre ellos.

1

Capítulo 1 Redes ad hoc inalámbricas 1.1. Introducción A diferencia de las redes cableadas tradicionales, en una red ad hoc inalámbrica, cada uno de los componentes o nodos funcionan simultáneamente como estación y como enrutador. Para que cada nodo sea capaz de comunicarse con el resto, es necesario que mantenga información de la red a la que pertenece y disponga de algún algoritmo que rija él envió y recepción de paquetes. El conjunto que forma el algoritmo de enrutamiento y la información sobre las condiciones de la red recibe el nombre de protocolo de enrutamiento. Los protocolos de enrutamiento en redes ad hoc deben adaptarse de manera rápida y correcta a los frecuentes e imprevisibles cambios de la topología de la red, haciendo un uso mínimo de memoria, potencia de transmisión y ancho de banda. 1.1.1. Definición El termino ad hoc es una locución latina que significa literalmente “para esto”. El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE, Institute of Electrical and Electronics Engineers) define las redes ad hoc como aquellas redes compuestas únicamente por estaciones, estando cada una de ellas dentro del rango de cobertura de alguna de las otras a través de un medio inalámbrico. Una red ad hoc se crea típicamente de manera dinámica y su principal singularidad es su limitación tanto temporal como espacial. Estas restricciones permiten crear y disolver redes de manera suficientemente sencilla y práctica. Formalmente, una red ad hoc inalámbrica puede parametrizarse considerando los siguientes calificativos: Inalámbrica: Los nodos se comunican a través de medios de transmisión sin cables (radio, infrarrojos, etc.). Ad hoc: La red es temporal y se establece dinámicamente de manera arbitraria por un conjunto de nodos según se necesita. Autónoma y sin infraestructura: La red no depende de ninguna infraestructura establecida ni de ninguna administración centralizada. Cada nodo opera de manera distribuida de par a par, actúa como un enrutador independiente y genera datos por sí mismo. Multisalto: No se necesitan enrutadores dedicados, cada nodo actúa como un enrutador y reenvía paquetes hacia otros nodos para facilitar el intercambio de información entre los integrantes de la red. Adicionalmente, los nodos pueden estar dotados de movilidad. En este caso, estas redes reciben el nombre de redes ad hoc móviles (MANETs, Mobile Ad hoc NETworks). La topología en este tipo de redes es dinámica debido al constante movimiento de los nodos participantes, haciendo que los patrones de comunicación entre los miembros de la red evolucione constantemente.

2

En definitiva, las redes ad hoc inalámbricas eliminan las restricciones impuestas por las infraestructuras fijas, permitiendo a los dispositivos crear y adherirse a redes improvisadamente, haciéndolas adecuadas para adaptarse virtualmente a cualquier aplicación. 1.2. Aplicaciones La cualidad más notable de las redes ad hoc es su flexibilidad. El hecho de que puedan establecerse en cualquier lugar y en cualquier momento sin infraestructura, administración o reconfiguración, las hace muy atractivas para un amplio rango de campos de aplicación. La Tabla 2.1, muestra una clasificación de las aplicaciones presentes y futuras de las redes ad hoc, así como de los servicios que ofrecen:

Tabla 1.1. Aplicaciones de las redes ad hoc.

1.3. Enrutamiento ad hoc En esencia, el proceso de enrutamiento se define como el proceso de selección de rutas desde un origen hasta un destino dentro de una red. Un protocolo de enrutamiento para redes ad hoc permite que la red se organice completamente por sí sola, y su objetivo principal es el establecimiento correcto y eficiente de rutas entre un par de nodos, de tal modo que los mensajes sean entregados de manera fiable y a tiempo. La construcción de

APLICACIONES SERVICIOS OFRECIDOS

Redes TácticasComunicaciones en operaciones militares.

Campos de batalla automatizados.

Redes de sensoresRecogida de datos en tiempo real, generalmente altamente relacionados

en espacio y tiempo.

Servicios de salvamento y

emergencia

Operación de búsqueda y rescate.

Sustitución de redes con infraestructura en caso de catástrofes

naturales.

Entornos comerciales

Comercio electrónico.

Acceso remoto a los registros de los clientes desde una base de datos

centralizada.

Oficina móvil.

Servicios Vehiculares.

Redes para particulares

Redes de área local inalámbricas (WLAN, Wirless Local Area Network)

para hogares u oficinas.

Redes de área personal (PAN, Personal Area Network).

Aplicaciones educativas

Configuración de clases virtuales.

Configuración de comunicaciones ad hoc en reuniones, conferencias y

congresos.

Ocio

Juegos multi-usuario.

Robots mascota.

Acceso en internet en exteriores.

Servicios de localizaciónServicio de Seguimiento.

Servicio de información.

3

rutas debe producirse con una mínima sobrecarga en las cabeceras de los paquetes de control y un mínimo consumo de ancho de banda. Las consideraciones que han de tenerse en cuenta en el diseño y estudio de los nuevos protocolos de enrutamiento incluyen:

Simplicidad y facilidad de implementación.

Convergencia rápida de rutas, libres de bucles y óptimas. Incluso, puede que sea posible establecer diferentes rutas entre el mismo par de nodos origen y destino, para aumentar la robustez.

Naturaleza distribuida y ligera, de tal forma que, ante cambios en la topología y en los patrones de tráfico, la reacción del protocolo implique una mínima sobrecarga de cabeceras.

Eficiencia en términos de ancho de banda, potencia de transmisión y tiempo de procesamiento, con una sobrecarga de cabeceras mínima.

Escalabilidad, de tal forma que si la red aumenta significativamente en número de nodos, no se degraden las prestaciones de servicio.

Seguridad a nivel de confidencialidad, control de acceso y denegación de ataques de servicio producidos por nodos maliciosos.

Capacidad de soportar requerimientos de calidad de servicio (QoS, Quality of Service).

La garantía de calidad de servicio es esencial para la entrega a tiempo de tráfico multimedia.

1.4. Clasificación de los protocolos de enrutamiento para redes ad hoc Se han propuesto numerosos protocolos de enrutamiento con la finalidad de cubrir las diferentes necesidades en función de los distintos entornos y condiciones de tráfico. La gran variedad de protocolos existentes hace que existan diversos criterios para su clasificación, que a su vez, reflejan los aspectos más importantes considerados para su diseño. Se proponen diferentes clasificaciones que en muchos casos son incompletas, ya que no contemplan todos los criterios existentes. Es por esto por lo que se ha considerado oportuno realizar un estudio pormenorizado de los protocolos que más frecuentemente aparecen en esta literatura para confeccionar una nueva clasificación que incorpore todos los criterios mencionados. Para complementar todo ello, se ha elaborado una gráfica que, a modo de resumen, ilustra esta clasificación y que se muestra en la Figura 2.1.

4

Figura 2.1. Clasificación de los protocolos de enrutamiento para redes ad hoc.

5

1.4.1. Planificación

El criterio de planificación supone la clasificación más ampliamente empleada en la literatura y atiende al momento en el que se calcula la ruta desde un nodo origen hasta un nodo destino. Mientras que en los protocolos proactivos se conserva la información actualizada en todo momento, en los reactivos se busca la ruta hacia el destino sólo cuando surge la necesidad de establecer una comunicación.

Protocolos de enrutamiento proactivos. Mantienen información consistente y actualizada desde cada nodo hacia todos los demás, propagando proactivamente actualizaciones de rutas. Puesto que la información de enrutamiento se suele mantener en tablas, es común referirse a estos protocolos como protocolos dirigidos por tabla (table-driven routing protocols). Se diferencian entre ellos en el número de tablas necesarias y en los métodos utilizados para difundir los cambios de la red.

Protocolos de enrutamiento reactivos. Establecen una ruta hacia el destino solamente cuando se precisa, generalmente iniciada por el nodo origen a través de un procedimiento de descubrimiento de rutas. Una vez que se ha establecido la ruta, el nodo se ocupa de mantenerla hasta que ya no se necesita o caduca. También se conocen como protocolos de enrutamiento iniciados en origen bajo demanda (source-iniciated demand driven).

1.4.2. Modelo de información de estado Al igual que ocurre en los protocolos de enrutamiento de las redes cableadas tradicionales, los protocolos ad hoc pueden clasificarse atendiendo a cuál es la información mantenida en cada nodo y cuáles son los destinatarios de esa información, distinguiendo entre la familia de estado de enlaces y la familia de vector de distancias. Basados en topología o de estado de enlaces (EE). La información de enrutamiento se transmite en forma de paquetes de estado de enlaces (LSP, Link State Packet). Los paquetes que envía cada nodo incluyen información acerca de sus nodos vecinos y cualquier cambio en alguno de sus enlaces provoca inmediatamente la actualización de la red. Cada nodo es así capaz de reconstruir y mantener un mapa de la topología global de la red a través de los paquetes de estado de enlace que recibe, pudiendo calcular por sí mismo las rutas hacia cualquier otro nodo. El principal inconveniente es que se puede producir sobrecarga si la naturaleza de la red es altamente dinámica. Un caso particular son los protocolos basados en asociatividad de estado de enlaces, en los que los nodos mantienen información sobre el nivel de señal recibida en periodos espacio-temporales. Otra modalidad consiste en mantener información de estado de enlaces nivel de enlace, intercambiando información de bajo nivel. Basados en destino o de vector de distancias (VD). Cada nodo mantiene una estructura de datos a modo de array denominada vector de distancias en la que se incluye cierta información. Los campos que como mínimo deben aparecer en este vector son la tripleta formada por la dirección IP del nodo destino, la dirección IP del siguiente salto y la distancia más corta para alcanzarlo. Cada componente de la red intercambia periódicamente sus vectores de distancias con sus nodos vecinos. Cuando un nodo

6

recibe los vectores de distancias de los nodos que le rodean, calcula de nuevo las rutas y actualiza su propio vector de distancias. La principal desventaja es la lenta convergencia y la tendencia a crear bucles. Un caso particular son los protocolos basados en inversión de enlaces (IE), en los que cuando se detecta una fallo en un enlace, es el nodo afectado el que se encarga de encontrar una ruta hacia el origen. 1.4.3. Modelo de transmisión El modelo de transmisión atiende qué destinatarios deben recibir los paquetes. Cabe señalar que en un canal inalámbrico, todos los nodos dentro del rango de cobertura del nodo origen recibirán los paquetes, estableciendo un modelo de comunicación broadcast. No obstante, se pueden establecer otros mecanismos para restringir el grupo de destinatarios. De hecho, el modelo de comunicación más ampliamente extendido para la transmisión de mensajes de control es el método unicast.

Unicast. Se refiere a la comunicación uno a uno, es decir, de un nodo origen a un único nodo destino. La mayor parte de los protocolos de enrutamiento para redes ad hoc se ubica dentro de esta categoría, ya que se trata del modo de operación normal en cualquier red.

Multicast. Este modelo de comunicación se emplea cuando un nodo necesita enviar información idéntica a varios destinos. Un nodo puede incorporarse o disgregarse de un grupo multicast cuando lo desee, pero en contrapartida, los nodos deben mantener información adicional sobre los nodos que se adhieren o abandonan su grupo multicast. En este tipo de protocolos, se suele emplear la técnica de envió nombrada inundación (flooding), por la que cuando un nodo recibe un paquete por un interfaz, lo reenvía por todos los interfaces salvo por el que le llegó.

Geocast. Se trata de un caso particular de envío multicast que se utiliza para entregar paquetes a un grupo de nodos situados dentro de un área geográfica especifica. Un nodo puede adherirse o abandonar un grupo geocast simplemente entrando o saliendo de esa área geográfica. Este tipo de protocolos facilita el procedimiento de descubrimiento de rutas al proporcionar información sobre la localización física de los nodos.

Broadcast. Se trata del modo de operación básico en un canal inalámbrico, ya que cada mensaje emitido por un nodo en un canal inalámbrico es recibido por todos sus vecinos. Sin embargo, sólo algunos protocolos implementan este tipo de modelo de transmisión y siempre a modo de apoyo. Emplear exclusivamente el modo de transmisión broadcast no es prudente, ya que se consume un ancho de banda excesivo y en muchas ocasiones de forma innecesaria.

1.4.4. Direccionamiento El direccionamiento hace alusión a la organización de la red en niveles jerárquicos lógicos, según todos los nodos estén al mismo nivel, dando lugar a un direccionamiento plano o no lo estén, originando un direccionamiento estratificado o jerárquico.

7

Plano. No existe jerarquía en la red, todos los nodos están al mismo nivel. Si un nodo falla, no afecta a todos los demás.

Jerárquico. Existen nodos de niveles superiores y nodos de niveles inferiores. Los primeros pueden clasificarse en nodos clusterhead, que gestionan la comunicación dentro de un cluster o agrupación, y nodos de puerta de enlace (Gateway-Node), responsables de la comunicación entre agrupaciones. Los nodos de niveles superiores devienen en un punto único de fallo, ya que si uno de estos nodos falla, perjudica todos sus nodos subordinados.

1.4.5. Estructura La estructura de la de la red está relacionada con la uniformidad de los roles que desempeñan los nodos que la integran. Mientras que unos protocolos tratan a todos los nodos de igual modo, estructurándolos uniformemente, otros hacen distinciones entre diferentes nodos de la red, estableciendo una estructura no uniforme.

Uniforme. Todos los nodos cumplen idénticas funciones, enviando mensajes de control y respondiendo a los mismos de igual modo.

No uniforme. Algunos nodos ejercen papeles específicos en cuanto al tratamiento de la información de enrutamiento. Dentro de los protocolos no uniformes, se puede distinguir entre los que hacen uso del método de selección de vecinos, si los nodos centran su actividad de enrutamiento solo en algunos de sus vecinos; y los que emplean el método de particionalmente, por el que la red se divide lógicamente en subredes.

1.4.6. Modelo de comunicación Dependiendo del uso del espectro, los protocolos de enrutamiento en redes ad hoc se pueden catalogar según la tecnología de acceso al medio empleada y a los mecanismos para compartir dicho medio de transmisión. Se trata de una clasificación que atiende a características de nivel de enlace, distinguiendo entre modelos de comunicación multicanal y monocanal.

Multicanal. Son protocolos de bajo nivel que, además de funcionalidad de enrutamiento, incorporan mecanismos para la asignación de canal. Se suelen emplear en redes basadas en las técnicas de reparto del canal de acceso múltiple por división de tiempo (TDMA, Time División Múltiple Access) y de acceso múltiple por división de código (CDMA, Code División Múltiple Access).

Monocanal. La mayoría de los protocolos asumen que los nodos se comunican sobre un único canal lógico inalámbrico y comúnmente emplean la técnica de acceso múltiple por detección de portadora con evasión de colisiones (CSMA/CA, Carrier Sense Múltiple Access, Collision Avoidance).

8

1.4.7. Modos de actualización La información de enrutamiento necesita diseminarse por la red para asegurar que la información sobre el estado del canal y la topología de la red se mantiene actualizada en los nodos. Según cuando se difunde esta información, se puede distinguir entre protocolos que envían actualizaciones periódicamente, protocolos que activan las actualizaciones cuando se produce un evento, y protocolos que emplean una mezcla de ambas técnicas: Actualizaciones periódicas. Los nodos distribuyen la información de enrutamiento cada cierto periodo fijo de tiempo. Las actualizaciones periódicas implican los protocolos y sobre todo facilitan que los nuevos nodos que se adhieren a la red aprendan la topología y el estado de la misma. Sin embargo, si el periodo entre actualizaciones es demasiado alto, la información no siempre será válida, ya que los cambios en la red no serán detectados inmediatamente. Por el contrario, si el periodo es excesivamente pequeño, se enviará un número de mensajes considerable, consumiendo un ancho de banda excesivo. Actualizaciones dirigidas por eventos. Cuando un nodo detecta un evento, tal como el fallo de un enlace o la aparición de un nuevo enlace, envía un paquete de actualización en modo broadcast para difundir el nuevo estado de la red. En contrapartida, si la naturaleza de la red es altamente dinámica, se deberán enviar abundantes paquetes de actualización, degradando la red. Ocasionalmente, puede incluso desencadenar la fluctuación de rutas. Actualizaciones híbridas. Algunos protocolos hacen un uso conjunto de las dos técnicas anteriores, creando un mecanismo denominado actualización hibrida. Por ejemplo, en un protocolo con modelo de información de estado basado en destino, un nodo puede difundir su vector de distancias periódicamente y si descubre que un enlace ha fallado, distribuye un mensaje de manera inmediata. 1.4.8. Número de caminos buscados La mayoría de los protocolos de enrutamiento para redes ad hoc se limitan a buscar una única ruta desde un nodo origen hasta un nodo destino, pero otros descubren varios caminos hacia el mismo nodo destino, de tal forma que el nodo origen, atendiendo a diferentes criterios, puede elegir el que considere más oportuno

Único camino. Los protocolos que hayan una sola ruta permiten un ahorro en el almacenamiento de la información y la simplificación del algoritmo de búsqueda.

Múltiples caminos. Los protocolos de enrutamiento que buscan múltiples rutas son más robustos y confiables, ya que cuentan a su favor con una rápida recuperación ante fallos de enlaces. Además, el enrutamiento con rutas múltiples ocasiona un mayor rendimiento, puesto que el nodo origen, al disponer de varias rutas hacia el destino, puede realizar reparto de carga.

9

1.4.9. Método de cálculo de rutas En función de cómo y dónde se calcula una ruta, se definen dos categorías de protocolos de enrutamiento para redes ad hoc. El cálculo de rutas puede realizarse en cada nodo de manera independiente o bien puede llevarse a cabo de forma cooperativa entre varios nodos.

Cálculo descentralizado. Cada nodo mantiene información global y completa sobre la topología de la red, siendo capaz de computar una ruta hacia cualquier nodo destino cuando lo desee.

Cálculo distribuido. Cada nodo de la red mantiene sólo información local sobre la topología de la red. Cuando un nodo necesita descubrir el camino hacia un destino, varios nodos deben colaborar para calcular la ruta.

1.5. Estudio comparativo Con el fin de ofrecer una perspectiva global sobre el panorama actual de los protocolos de enrutamiento para redes ad hoc, se ha elaborado un estudio comparativo de los protocolos más representativos. Para la confección de esta revisión, se ha seguido el siguiente procedimiento:

1. Elección de los protocolos bajo análisis. La elección de los protocolos bajo estudio se ha determinado en función de su popularidad, escogiendo aquellos que aparecen en la mayoría de las fuentes consultadas.

2. Revisión de documentos. Se han examinado los artículos y publicaciones

originales en los que se describen los protocolos elegidos, así como otras referencias adicionales.

3. Elaboración de la información extraída. Se han elaborado las Tablas 2.2 y 2.3

con el fin de mostrar de manera resumida y estructurada la información obtenida. Existe un gran número de protocolos para redes ad hoc inalámbricas. Esa variedad se debe a que cada protocolo posee ciertas particularidades que lo hacen apropiado para cubrir las necesidades de los diferentes escenarios y condiciones de tráfico que se pueden dar en este tipo de redes. En este estudio se comparan los protocolos de enrutamiento para redes ad hoc escogidos atendiendo a esas características distintivas, construyendo para ello las Tablas 2.2 y 2.3. La primera de ellas reúne los protocolos proactivos elegidos, la segunda concentra los protocolos reactivos. Las ocho primeras filas definen cada protocolo según la clasificación recogida en la sección 2.2.1. Las tres filas siguientes señalan para qué tipo de red está indicado cada protocolo, considerando conceptos como la escalabilidad, mencionada anteriormente, y que se define como la propiedad de los protocolos a adaptarse al crecimiento de la red. Las tres filas posteriores hacen alusión a qué información se almacena, se envía y se recibe. El término altura de los vecinos se refiere a la estructura de datos que se intercambia en los algoritmos de IE. Las cuatro filas siguientes se refieren a términos relacionados con la complejidad, el uso de ancho de banda y la longitud de los mensajes de control. La complejidad de

10

almacenamiento se define como el tamaño de almacenamiento que cada nodo necesita para mantener la información necesaria. La complejidad temporal es el número de pasos necesarios para realizar una operación del protocolo. Por último, el requerimiento de ancho de banda depende del número de mensajes necesarios para realizar una operación del protocolo. Todos estos parámetros están expresados en notación de Landau. La notación de Landau, denotada por O (), permite describir el comportamiento asintótico de una función cuando su argumento tiende a un valor particular o a infinito, generalmente en términos de funciones más simples. La notación de Landau permite expresar funciones de manera simplificada, prestando atención sólo a su tasa de crecimiento, de tal forma que diferentes funciones se pueden representar bajo la misma notación si su tasa de crecimiento es idéntica. Formalmente, la notación de Landau se define a partir de dos funciones reales, f(x) y O(g(x)), de tal manera que: f(x) = O(g(x)) cuando x → ∞. Los símbolos empleados en esta notación asintótica se presentan a continuación: N: Número total de nodos en la red. M: Número medio de nodos en una agrupación o cluster. A: Grado de un nodo, esto es, número de nodos adyacentes o primeros 4 vecinos. A: Grado medio de un nodo. D: Diámetro de la red. Dd: Número máximo de destinos deseados en el caso de protocolos que buscan múltiples caminos. W: Diámetro del camino por el que se transmite el paquete de respuesta. Y: Número total de nodos que forman el camino por donde se transmite el paquete de respuesta. Seguidamente, se presentan otros parámetros que no son agrupables bajo ninguna categoría y cuyo significado conviene aclarar. En los protocolos con enrutamiento en origen, se indica el camino completo en la cabecera de los paquetes de control, de tal modo que los nodos intermedios sólo se limitan a reenviarla. La reconfiguración de rutas apunta a la capacidad del protocolo para actuar ante fallos de enlace. Los mensajes hello, también denominados mensajes beacon, son aquellos mensajes que los nodos intercambian para informar de su presencia en la red. El parámetro de calidad de servicio se refiere a si el protocolo dispone o puede incorporar mecanismos para garantizar una tasa de bit constante que haga posible el intercambio de tráfico multimedia. Por su parte, la existencia de un único punto de fallo alude a la vulnerabilidad del protocolo, de tal modo que si falla un nodo, todos los demás se ven perjudicados. Para finalizar, se incluye el acrónimo del protocolo antecesor, de quien hereda las características más significativas, el año de aparición de la primera propuesta, y las referencias originales y complementarias que han servido de referencia para este estudio.

11

1.6. Eficiencia de enrutamiento Medir las prestaciones de un protocolo de enrutamiento para redes ad hoc no es una tarea trivial puesto que es necesario seleccionar aquellas variables que evalúan cualitativa y cuantitativamente sus bondades. No obstante, el Grupo de Trabajo en Ingeniería de Internet (IETF, Internet Engineering Task Force) ofrece en su documento una lista de métricas cuantitativas que pueden ser empleadas para valorar las prestaciones de cualquier protocolo de enrutamiento:

Throughput y retardo. Esta métrica se basa en medir la efectividad de enrutamiento de datos desde una perspectiva externa, realizando medidas estadísticas tales como media o varianza.

Tiempo de adquisición de rutas. Esta medida calcula el tiempo necesario para establecer una ruta desde que se solicita, por lo que sólo tiene sentido en protocolos en los que el procedimiento de descubrimiento de rutas se realiza bajo demanda.

Porcentaje de entregas desordenadas. Se trata de otra medida externa que mide el rendimiento del enrutamiento cuando algunas de las conexiones no están operativas. Es especialmente relevante desde el punto de vista de la capa de transporte.

Eficiencia. Si la efectividad de enrutamiento de datos es la medida externa del rendimiento de una política de enrutamiento, la eficiencia es su medida interna.

A su vez, para evaluar estas prestaciones, no ha de olvidarse el contexto de red en el que trabaja el protocolo de enrutamiento bajo estudio. Los parámetros esenciales que definen un contexto de red incluyen:

Tamaño de la red. Medido en número de nodos.

Conectividad de la red. Grado medio de un nodo.

Tasa de cambio en la topología. Velocidad a la que varía la topología de la red.

Capacidad de los enlaces. Velocidad efectiva del enlace medida en bits/segundo.

Fracción de enlaces unidireccionales. Cómo responde el protocolo cuando un porcentaje de los enlaces trabaja solamente en una dirección.

Patrones de tráfico. Cómo se adapta el protocolo cuando el patrón no es uniforme.

Movilidad. Cuándo y bajo qué circunstancias la correlación temporal y espacial afecta al rendimiento de un protocolo de enrutamiento.

Porcentaje y frecuencia de nodos no operativos. Cómo responde el protocolo

en presencia de nodos que dejan de estar activos o vuelven a estarlo tras un periodo de inactividad.

12

Tabla 1.2. Estudio comparativo de los protocolos de enrutamiento ad hoc proactivos.

Pro

toc

olo

D

SD

VC

GR

SW

RP

GS

RO

LS

RFS

RH

SR

No

mb

re

De

stin

atio

n-

Se

qu

en

ce

d

Dis

tan

ce

-Ve

cto

r

Ro

utin

g P

roto

co

l

Clu

ste

r- H

ea

d

Ga

tew

ay

Sw

itch

Ro

utin

g

Pro

toco

l

Wir

ele

ss

Ro

utin

g

Pro

toco

l

Glo

ba

l S

tate

Ro

utin

g

Pro

toco

l

Op

tim

ize

d L

ink

Sta

te R

ou

tin

g

Pro

toco

l

Fis

he

ye

Sta

te

Ro

utin

g P

roto

co

l

Hie

rarc

hic

al

Sta

te

Ro

utin

g

Pro

toco

l

Pla

nif

ica

ció

nP

roa

ctivo

P

roa

ctivo

P

roa

ctivo

P

roa

ctivo

P

roa

ctivo

P

roa

ctivo

P

roa

ctivo

Mo

de

lo d

e in

form

ac

ión

de

es

tad

o

VD

VD

VD

EE

EE

EE

EE

Mo

de

lo d

e T

ra

ns

mis

ión

B

roa

dca

st

Bro

ad

ca

st

Bro

ad

ca

st

Bro

ad

ca

st

Inu

nd

ació

nB

roa

dca

st

Bro

ad

ca

st

Dir

ec

cio

na

mie

nto

P

lan

o

Je

rárq

uic

oP

lan

o

Pla

no

P

lan

o

Pla

no

Je

rárq

uic

o

Es

tru

ctu

ra

Un

ifo

rme

No

Un

ifo

rme

Un

ifo

rme

Un

ifo

rme

No

Un

ifo

rme

No

Un

ifo

rme

No

Un

ifo

rme

Mo

de

lo d

e c

om

un

ica

ció

n

Mo

no

ca

na

l M

ultic

an

al

Mo

no

ca

na

l M

on

oca

na

l M

on

oca

na

l M

on

o/M

ultic

an

al

Mo

no

ca

na

l

Pe

rio

do

de

ac

tua

liza

cio

ne

s

Hib

rid

o

Pe

rio

díc

oH

ibri

do

P

eri

od

íco

Hib

rid

o

Pe

rio

do

co

n

dife

ren

tes

fre

cu

en

cia

s

Hib

rid

o

Nu

me

ro

de

ca

min

os

bu

sc

ad

os

Ú

nic

o

Ún

ico

Ú

nic

o

Ún

ico

/Mú

ltip

les

Ún

ico

/Mú

ltip

les

Ún

ico

/Mú

ltip

les

Ún

ico

Ad

ec

ua

cio

ne

s p

ara

re

de

s

alt

am

en

te d

iná

mic

as

N

oN

oN

oS

iS

iS

iS

i

Ad

ec

ua

ció

n p

ara

re

de

s

re

de

s d

en

sa

s y

ex

ten

sa

sN

o

Si

No

Si

Si

Si

Si

Es

ca

lab

ilid

ad

Me

dia

Mu

y b

ue

na

L

imita

da

Bu

en

as

Bu

en

a

Mu

y m

ala

B

ue

na

Info

rm

ac

ión

alm

ac

en

ad

aV

DV

D,T

ab

la m

iem

bro

s

de

la

ag

rup

acio

n

Ta

bla

dis

tan

cia

s.

Ta

bla

de

en

ca

min

am

ien

to,

co

ste

de

l

en

lace

,MR

La

To

po

log

ía

co

mp

leta

To

po

log

ía

co

mp

leta

To

po

log

ía

co

mp

leta

To

po

log

ía

jerá

rqu

ica

Info

rm

ac

ión

de

la

s

ac

tua

liza

cio

ne

s

VD

VD

,Ta

bla

mie

mb

ros

de

la

ag

rup

acio

n

VD

, lis

ta d

e

res

pu

es

tas

EE

de

to

do

s lo

s

no

do

s

EE

de

lo

s

ve

cin

os

EE

de

l a

lca

nce

de

fis

he

ye

EE

vir

tua

l

De

sti

na

tario

s d

e la

s

ac

tua

liza

cio

ne

s

Ve

cin

os

Ve

cin

os

y n

od

os

pri

ncip

al

Ve

cin

os

Ve

cin

os

To

do

sV

ecin

os

No

do

s d

e

ag

rup

ació

n

Co

mp

lejid

ad

de

alm

ac

en

am

ien

to

O(N

)O

(2N

)O

(NxA

)O

(NxA

)O

(NxA

)O

(NxA

)O

(Nx lo

gM

N)

Co

mp

lejid

ad

te

mp

ora

l

O(D

)O

(D)

O(D

)O

(D)

O(D

)O

(D)

O(D

)

Co

ns

um

o d

e a

nc

ho

de

ba

nd

aO

(N)

O(N

)O

(N)

O(N

)O

(N)

O(N

)O

(N)

Ta

ma

ño

de

l p

aq

ue

te d

e

co

ntr

ol

O(N

)O

(N)

O(N

+A

-)O

(N)

O(N

)D

ete

rm. P

or

pro

toco

lo

O(M

)

En

ca

min

am

ien

to e

n o

rig

en

N

oN

oN

o g

en

era

lme

nte

No

ge

ne

ralm

en

teN

o g

en

era

lme

nte

No

do

s d

e

ag

rup

ació

n

Re

co

nfi

gu

ra

ció

n e

n r

uta

s

No

a

plica

N

o a

plica

N

o a

plica

N

o a

plica

N

o a

plica

N

o a

plica

N

o a

plica

Ne

ce

sid

ad

de

me

ns

aje

s

he

llo

N

oN

oS

i N

oN

oN

oN

o

Ca

lid

ad

de

se

rvic

io

No

Si

No

Si

Si

Si

Si

Ún

ico

pu

nto

de

fa

llo

N

oS

i N

oN

oN

oN

oS

i

An

tec

es

or

DB

FD

SD

VD

BF

GS

RG

SR

Añ

o d

e la

prim

era

pro

pu

es

ta1

99

41

99

71

99

51

99

81

99

82

00

01

99

9

Re

efe

re

nc

ia o

rig

ina

l[2

0]

[24

][2

5]

[26

][2

7]

[28

][2

9]

Re

fere

nc

ias

ad

icio

na

les

[1

9]

[37

,38

]

Pro

toc

olo

s d

e e

nc

am

ina

mie

nto

pro

ac

tivo

s p

ara

re

de

s a

d-h

oc

13

Tabla 2.3. Estudio comparativo de los protocolos de enrutamiento ad hoc reactivos.

Pro

toco

lo

DS

RA

OD

VT

OR

AA

BR

SS

A

No

mb

re

Pla

nif

ica

ció

nR

eactivo

R

eactivo

R

eactivo

R

eactivo

R

eactivo

Mo

de

lo d

e i

nfo

rma

ció

n d

e e

sta

do

EE

VD

IEE

E a

sociá

tivo

EE

a n

ivel 2

Mo

de

lo d

e t

ran

smis

ión

U

nic

ast

Unic

ast/

Bro

adcast

Bro

adcast

Unic

ast/

Bro

adcast

Unic

ast

Dir

eccio

na

mie

nto

P

lano

Pla

no

Pla

no

Pla

no

Pla

no

Est

ructu

raU

nifo

rme

Unifo

rme

Unifo

rme

Unifo

rme

Unifo

rme

Mo

de

lo d

e c

om

un

ica

ció

n

Monocanal

Monocanal

Monocanal

Monocanal

Monocanal

Mo

de

lo d

e a

ctu

ali

za

ció

n

Dirig

ido p

or

eve

nto

sD

irig

ido p

or

eve

nto

sD

irig

ido p

or

eve

nto

sH

ibrido

Hib

rido

Nu

me

ro d

e c

am

ino

s b

usc

ad

os

Múltip

les

Múltip

les

Múltip

les-D

AG

Únic

aÚ

nic

a

Ad

ecu

acio

ne

s p

ara

re

de

s a

lta

me

nte

din

ám

ica

s N

oS

iM

edia

Si

Si

Ad

ecu

ació

n p

ara

re

de

s re

de

s d

en

sas

y e

xte

nsa

s

Esc

ala

bil

ida

dM

edia

Buena

Muy B

uena

Buena

Muy B

uena

Info

rma

ció

n a

lma

ce

na

da

Ruta

s a

l destino

deseado

Pró

xim

o s

alto a

l

destino d

eseado

Altura

de los v

ecin

os

Info

rmació

n

asocia

tiva

de los v

ecin

os

Esta

bili

dad d

e la

señal

tabla

de r

uta

s

Info

rma

ció

n d

e l

as

actu

ali

za

cio

ne

s E

rror

de r

uta

E

rror

de r

uta

A

ltura

de los n

odos

Info

rmació

n

vecin

os o

err

or

de

ruta

Err

or

de r

uta

De

stin

ata

rio

s d

e l

as

actu

ali

za

cio

ne

s O

rigen

Origen

Vecin

os

Vecin

os/O

rigen

Origen

Co

mp

leji

da

d d

e a

lma

ce

na

mie

nto

O

(D)

O(D

d)

O(D

d x

A)

O(D

+A

)O

(D+

A)

Co

mp

leji

da

d t

em

po

ral

O(2

D)

O(2

D)

O(2

D)

O(D

+W

)O

(D+

W)

Co

nsu

m L

a i

nfo

rma

ció

n d

e

en

ca

min

am

ien

to n

ece

sari

o d

e a

nch

o

de

ba

nd

a

O(2

N)

O(2

N)

O(2

N)

O(N

+Y

)O

(N+

Y)

Ta

ma

ño

de

l p

aq

ue

te d

e c

on

tro

l

En

ca

min

am

ien

to e

n o

rig

en

S

iN

oN

oS

iN

o

Re

co

nfi

gu

ració

n e

n r

uta

s

Ne

ce

sid

ad

de

me

nsa

jes

he

llo

N

oS

iN

oS

iS

i

Ca

lid

ad

de

se

rvic

io

Si

Si

Si

Si

Si

Ún

ico

pu

nto

de

fa

llo

No

No

No

No

No

An

tece

sor

DS

DV

LM

R

Añ

o d

e l

a p

rim

era

pro

pu

est

a1996

1999

2001

1996

1996

Re

efe

ren

cia

ori

gin

al

[30,3

1]

[32,3

3]

[34]

[35]

[36]

Re

fere

ncia

s a

dic

ion

ale

s [3

9]

[39]

[37]

Pro

toco

los d

e e

ncam

inam

ien

to r

eacti

vo

s p

ara

re

de

s a

d-h

oc

14

Capítulo 2 Protocolo de enrutamiento DSDV y AODV El protocolo de enrutamiento AODV (Ad hoc On-demand Distance Vector Routing Protocol) y el protocolo DSDV (Destination-Sequenced Distance-Vector) son dos de los protocolos más mencionados en las redes móviles, y ambos están basados en el algoritmo de vector distancia. El objetivo de este capítulo es mencionar las características técnicas de estos dos protocolos. 2.1. Protocolo DSDV El DSDV es un protocolo de direccionamiento de tipo proactivo que pertenece a la familia de los algoritmos vector distancia. Cada nodo perteneciente a la red tiene una tabla de enrutamiento que indica para cada destino cuantos saltos (hop) hacen falta atravesar y cuál es el sucesivo. Derivando del vector distancia, la actualización de las tablas de enrutamiento se produce mediante el intercambio de información entre nodos cercanos y re aplicando los algoritmos de ruta mínimo a menor costo. Cada camino viene etiquetado con un número de secuencia (sequence number), que da una indicación temporal sobre la validez de aquel camino: a números de secuencia más altos corresponden caminos más fiables. Cuando dos caminos tienen el mismo número de secuencia viene elegido aquel que tiene el menor costo (por ejemplo el que menor número de saltos tenga que atravesar). En caso de que un nodo notase que un trayecto hacia un destino no funciona, asigna al número de salto un valor alto (que significa infinito) y al número de secuencia un número impar. Un número de secuencia identificado con un número impar señala que aquel camino es inalcanzable mientras que, por el contrario, un número par indica que el destino sí es alcanzable. En DSDV, cada nodo móvil de una red ad hoc mantiene una tabla de enrutamiento, que enumera todos los disponibles destinos, el salto métrico y junto a cada destino y un número de secuencia generado por el nodo destino. Utilizando las tablas de enrutamiento almacenadas en cada nodo móvil, se transmiten los paquetes entre los nodos de una red ad hoc. Cada nodo de la red ad hoc actualiza la tabla de enrutamiento con notificación periódicamente o cuando la nueva información importante está disponible para mantener la consistencia de la tabla de enrutamiento con el cambiar dinámicamente la topología de la red ad hoc. Periódicamente o inmediatamente cuando la topología de red se detectan cambios, cada nodo móvil anuncia información de enrutamiento mediante la radiodifusión o multidifusión de un enrutamiento de paquetes modificando la tabla de actualización. El paquete de actualización se inicia con una métrica de uno para dirigir los nodos conectados. Esta indica que cada vecino receptor es una métrica (Hop) fuera del nodo. Es diferente de las métricas convencionales de algoritmos de enrutamiento. Después de recibir el actualizar de paquetes los vecinos actualizan su tabla de enrutamiento incrementando con la métrica por uno y retransmiten la actualización de paquetes a los vecinos correspondientes de cada uno de los ellos.

15

El proceso se repite hasta que todos los nodos en la red ad hoc ha recibido una copia de la actualización del paquete con una correspondiente métrica. La actualización de los datos también se mantiene durante un tiempo para esperar la llegada de las mejores rutas para cada nodo destino en particular, en cada nodo antes de actualizar su tabla de enrutamiento y retransmisión de actualización de paquetes. Si un nodo recibe múltiples paquetes de actualización para un mismo destino durante el periodo de tiempo de espera, las rutas con más números de secuencia de los últimos son siempre preferidas como base para las decisiones de envío de paquetes, pero la información de enrutamiento no está necesariamente anunciada inmediatamente, si sólo los números de secuencia han sido cambiados. Si los paquetes de actualización tienen la misma secuencia número con el mismo nodo, el paquete de actualización que contenga la métrica más pequeña será utilizado y será la ruta existente la que será desechada o se almacena como una ruta menos preferible. En este caso, los paquetes de actualización se propagarán con la secuencia de números a todos los nodos móviles ad hoc de la red. El anuncio de las rutas que están a punto de hacer cambio puede ser retrasado hasta que las mejores rutas hayan sido encontradas. El retraso en el anuncio de la posible inestabilidad de ruta puede amortiguar las fluctuaciones de la tabla de enrutamiento y reducir el número de retransmisiones de ruta posible a las entradas que llegan con el mismo número de secuencia. Los elementos en la tabla de enrutamiento de cada nodo móvil cambia dinámicamente para mantener la coherencia con el cambio dinámico en la topología de una red ad hoc. Para llegar a esta coherencia, la información de enrutamiento publicada debe ser frecuente o lo suficientemente rápida para asegurar se de los demás nodos móviles en la red dinámica ad hoc. Sobre la información de enrutamiento actualizada, cada nodo tiene transmisión de paquetes de datos a otros nodos a petición en la red de forma dinámica ad hoc.

Figura 2.1. Un ejemplo de las redes ad hoc.

16

Tabla 2.1. Tabla de enrutamiento del nodo H6 en un instante.

La figura 2.1, muestra un ejemplo de una red ad hoc antes y después del movimiento de los nodos móviles. La tabla 2.1, es la tabla de enrutamiento del nodo H6 en el momento antes del movimiento de los nodos. El tiempo de instalación del campo en la tabla de enrutamiento ayuda a eliminar rutas obsoletas.

17

Figura 2.2. Enrutamiento de paquetes DSDV.

La figura 2.2 muestra un ejemplo del procedimiento de enrutamiento de paquetes en DSDV. El nodo H5 quiere enviar un paquete al nodo H5 como se muestra en la figura 2.1. El nodo H4 revisa su tabla de enrutamiento y localiza que el siguiente salto para encaminar el paquete es el nodo H6. Después el nodo H4 envía el paquete a H6 como se muestra en caso a de la figura 2.1. El nodo H6 busca el siguiente salto en su tabla de enrutamiento para llegar al nodo destino H5 cuando se recibe el paquete (caso b). El nodo H6 luego envía el paquete al siguiente nodo H7 como es especificado en la tabla de enrutamiento (caso c). El procedimiento de enrutamiento es repetido a lo largo del camino hasta que el paquete finalmente llega al nodo destino H5. En los procesos de actualización de la información de enrutamiento, las etiquetas de nodo originales de cada actualización de paquete contienen un número de secuencia para distinguir actualizaciones viejas de una nueva. El número de secuencia es un número que incremente monóticamente e identifica únicamente cada actualización de un nodo dado. Como resultado, si un nodo recibe una actualización de otro nodo, el número de secuencia será igual o mayor que el número de secuencia correspondiente ya en la tabla de enrutamiento, o de otro modo la reciente información recibida de enrutamiento en la actualización del paquete es vieja y deberá desecharse. Si el número de secuencia de un nodo en la recién información de enrutamiento recibida de la actualización de paquetes es la misma en la tabla de enrutamiento, entonces la métrica será comparada y la ruta con la métrica más pequeña será usada.

18

Figura 2.3. Un ejemplo de la actualización de la información de ruta.

Además del número de secuencia y la métrica para cada entrada del paquete de actualización, la información de las rutas de actualización contiene también tanto la dirección del destino final y la dirección del siguiente salto. A pesar de la simplicidad y eficiencia de este algoritmo, es bien sabido que este puede ocasionar la creación de bucles. Una de las primeras causas que propician este problema es que los nodos seleccionan, basados en información que se obtiene de manera distribuida, al nodo inmediato que permite enviar un paquete de datos hasta un nodo destino; sin embargo esta decisión puede estar basada en información antigua y muy probablemente incorrecta. Cuando esto sucede, un paquete puede ser enviado por un bucle y continuar transitando en el mismo aun cuando el nodo destino a donde va dirigido es inalcanzable en la red y su ausencia no fue detectada a tiempo. En una red ad hoc, la movilidad, y en consecuencia la ausencia de un nodo con el fin de evitar el envió de la información a través de bucles en las trayectorias.

19

Para atender este problema, DSDV utiliza números de ausencia y al mismo tiempo mantiene la simplicidad del algoritmo de BF. Dado que este protocolo es de carácter proactivo, el intercambio de información de encaminamiento, y el cálculo de rutas de comunicación se realiza de manera periódica, de este modo, cada nodo obtiene y procesa información actualizada y confiable de la organización de la red. El funcionamiento distribuido de este protocolo demanda que cada uno de los nodos que componen la red comparta su tabla de encaminamiento con sus nodos vecinos. Solo de este modo, cada nodo podrá calcular, para cada destino dentro de la red, al nodo vecino que proporcione la mejor ruta de comunicaciones. 2.1.1. Ventajas de DSDV

DSDV garantías en el protocolo a no formar bucles.

Cuenta hasta el infinito problema se reduce en DSDV.

Selección de trazado: DSDV mantiene sólo la mejor ruta en lugar de mantener varias rutas de acceso a todos los destinos. Con esto, la cantidad de espacio en la tabla de enrutamiento se reduce.

2.1.2. Limitaciones de DSDV

Desperdicio de ancho de banda debido a la cantidad innecesaria de información de enrutamiento, incluso si no hay cambio en la topología de la red.

DSDV no admite enrutamiento multi-camino.

Es difícil determinar un intervalo de tiempo para el anuncio de las rutas.

Es difícil mantener la publicidad de la tabla de enrutamiento para la red más amplia. Todos y cada host en la red debe mantener una tabla de enrutamiento para la información. Pero para las grandes redes que esto llevaría a los gastos de más consumo de ancho de banda.

2.2. Protocolo AODV El protocolo de enrutamiento AODV fue proyectado en 1999 por Charles E. Perkins, del grupo de desarrollo avanzado de Sun Microsystems, y Elizabeth M. Royer, de la Universidad de California, Santa Barbará. Su propósito fue diseñar un protocolo de enrutamiento para redes ad hoc formadas por nodos móviles tomando como punto de partida el protocolo DSDV, con el fin de solventar sus deficiencias: el alto número de envíos en modo broadcast y la latencia de transmisión. A su vez, el protocolo DSDV también había sido concebido por Perkins en colaboración con Pravin Bhagwat cuatro años antes. El documento oficial vigente que describe las especificaciones del protocolo AODV, la RFC3561 (Request For Comments) número 3561, se publicó en Julio de 2003 con la categoría de experimental.

20

El protocolo AODV combina técnicas extraídas de los protocolos DSDV y DSR, dando lugar a un algoritmo que usa el ancho de banda de manera eficiente y que responde con rapidez a los cambios en la red al tiempo que garantiza la ausencia de bucles. Con el fin de mantener sólo la información de encaminamiento más reciente, el protocolo AODV toma prestado de su predecesor, el protocolo DSDV, el concepto de número de secuencia. Tanto en el protocolo AODV como en el protocolo DSDV, cada nodo se encarga de mantener su propio contador o número de secuencia. Este número no es más que un valor entero que cada nodo incrementa monótonamente antes de generar un mensaje de control para copiarlo en éste antes de enviarlo. De manera complementaria al número de secuencia, cada nodo se distingue por un identificador único dentro de la red. De este modo, con la pareja de valores formada por el identificador del nodo y el número de secuencia, es posible distinguir la información valida de la anticuada. Si un nodo recibe dos paquetes con el mismo identificador de nodo pero con diferentes números de secuencia, la información más reciente será la incluida en el paquete de mayor número de secuencia. Puesto que cada nodo es responsable de su propio contador, no es necesario mantener un reloj único y común a toda la red, lo cual simplifica enormemente la implementación del protocolo. El uso de estos números de secuencia garantiza la ausencia de bucles en todo momento y evita problemas como el de la “cuenta al infinito”. En los protocolos que no incluyen ningún mecanismo de prevención, esta anomalía se produce cuando cae un enlace, afectando al menos a dos nodos. Considérese un primer nodo con dos enlaces: uno de ellos le conecta con un segundo nodo y el otro ha dejado de estar operativo. El segundo nodo, que desconoce que ha fallado el enlace, desea acceder a un destino al otro lado del enlace averiado, por lo que tendría que pasar por el primero de los nodos. Sin embargo, como el primer nodo no puede usar el enlace dañado, reenvía el paquete al segundo. Cada nodo cree equivocadamente que puede llegar a su destino a través del otro, por lo que ambos degeneran en un bucle infinito. Este problema de cuenta al infinito está típicamente asociado a los protocolos clásicos de vector de distancias, ya que con este modelo de información de estado, los nodos sólo conocen el siguiente salto y no mantienen la topología completa de la red. El protocolo AODV emplea un mecanismo de descubrimiento de rutas en modo broadcast que también emplea el protocolo DSR aunque con ciertas modificaciones. En el protocolo DSR, es el nodo origen quien se encarga de calcular la ruta completa hasta el nodo destino. Esto puede degradar las prestaciones de la red cuando ésta es muy extensa, ya que cada paquete incluye en su cabecera la secuencia de nodos por los que debe pasar desde el origen hasta el destino. Por el contrario, en el protocolo AODV, el camino se forma gracias a la información mantenida en las tablas de rutas de los nodos intermedios, como se explica en la Sección 2.2.2. 2.2.1. Información de encaminamiento El protocolo AODV almacena la información de encaminamiento en forma de tablas de rutas. Cada uno de los nodos de la red mantiene su propia tabla, que tiene tantas entradas como destinos conoce el nodo. Una entrada consta típicamente de los siguientes campos:

Dirección IP del destino.

21

Número de secuencia del nodo destino. Número de secuencia asociado al nodo destino, cuyo valor se obtiene de los mensajes de control.

Indicador de validez del número de secuencia del nodo destino. Si se pretende alcanzar un nodo destino y ha fallado uno de los enlaces implicados, o la ruta ha expirado, el número de secuencia asociado a ese nodo destino se marca como inválido.

Otros indicadores sobre estado y rutas. Por ejemplo, indicadores sobre si la ruta es o no válida, y en este último caso si es reparable, no es reparable y se debe buscar un camino alternativo, o bien, si está siendo reparada.

Interfaz de red.

Número de saltos. Número de saltos necesarios para alcanzar el destino desde este nodo.

Siguiente salto. Nodo adyacente al que se debe enviar el paquete para llegar al destino deseado.

Lista de precursores. Lista de nodos que forman el camino resultante del proceso de descubrimiento de rutas.

Tiempo de vida de la ruta. Tiempo en el que la ruta caduca o debe ser borrada.

2.2.2. Descubrimiento de rutas El proceso de descubrimiento de caminos se inicia cuando un nodo origen desea comunicarse con otro nodo pero desconoce cómo acceder a él, es decir, no tiene información de encaminamiento en su tabla de rutas acerca de ese nodo destino. Para ello, se intercambian principalmente dos tipos de mensajes: mensajes de solicitud o petición de ruta (RREQ, Route REQuest) y mensajes de respuesta de ruta (RREP, Route REPly). En esta operación de búsqueda de rutas se pueden distinguir a su vez dos fases: la formación del camino de vuelta y la formación del camino de ida, ambas explicadas a continuación. En primer lugar, la formación del camino de vuelta establece todos los itinerarios posibles desde el origen hasta el destino, trazados por el recorrido de los mensajes RREQ. En segundo y último lugar, la formación del camino de ida determina la ruta que finalmente seguirán los paquetes desde el nodo origen hasta el nodo destino una vez finalizado el descubrimiento de caminos. Cuando un nodo origen desea alcanzar un nodo destino y desconoce cómo acceder a él, genera un mensaje RREQ. En él se incluyen las direcciones IP y los números de secuencia de los nodos origen y destino. Antes de enviar esta solicitud, el nodo origen incrementa su número de secuencia para evitar conflictos con peticiones anteriores. En el campo correspondiente al número de secuencia de destino, el nodo incluye el último valor aprendido, en caso de que ya hubiese solicitado esa ruta con anterioridad, o bien indica que es desconocido. El mensaje RREQ se difunde por inundación. La inundación es una técnica de envió de paquetes por la que cuando un nodo tiene información dirigida a un destino concreto, la transmite a sus vecinos. Si el nodo que la recibe no es el destinatario de esta información, la reenvía de nuevo. Este proceso continúa sucesivamente hasta

22

alcanzar el nodo destino. En complemento a la técnica de inundación y con el objeto de evitar un consumo excesivo del ancho de banda, el nodo origen emplea el algoritmo de búsqueda expansiva en anillo (expanding ring search). De acuerdo a este algoritmo, inicialmente el mensaje RREQ tiene asociado un valor pequeño de su tiempo de vida TTL (Time-To-Live), de tal manera que el mensaje se descarta cuando este tiempo expira. Si no se encuentra el destino antes de un plazo determinado, este valor se incrementa progresivamente en el envió de las posteriores solicitudes de rutas. Con el fin de que un nodo no permanezca eternamente intentando alcanzar un destino inaccesible, se tiene un número máximo de intentos, cuyo valor es típicamente dos. La Figura 2.4 representa una red compuesta por diez nodos, en la que se indica mediante flechas el recorrido de los mensajes RREQ. El nodo origen inicia el proceso de inundación con mensajes RREQ, que llegan a sus dos vecinos, quienes a su vez renvían sucesivamente la solicitud. En este caso, se considera que ninguno de los nodos intermedios conoce el camino, por lo que la inundación se propaga hasta alcanzar el nodo destino.

Figura 2.4. Inundación con mensajes RREQ.

Cada vez que un nodo recibe el mensaje RREQ, comprueba si es el destino buscado o si al menos conoce cómo acceder a él. Si no es así, el nodo recoge un registro de la solicitud y vuelve a reenviar el mensaje RREQ a sus vecinos, continuando con el proceso de inundación. Los nodos toman nota de los mensajes RREQ recibidos para no reenviar la misma solicitud varias veces, ya que esto sobrecargaría la red de manera innecesaria. La Figura 2.5 ilustra la fase de formación de los caminos de vuelta. Puesto que los nodos intermedios anotan de dónde proviene la solicitud, se forman cuatro caminos de vuelta, representados con líneas continuas. Como se puede apreciar, los caminos en colores rosados no son factibles, sólo las dos rutas trazadas en colores azulados comunican

23

origen y destino. El proceso de inundación, y en consecuencia, la formación del camino de vuelta, se detiene cuando el nodo que recibe la solicitud es el nodo destino o conoce cómo llegar al mismo, dando lugar a la siguiente fase, la formación del camino de ida.

Figura 2.5. Generación de caminos de vuelta potenciales.

Si el nodo que recibe la solicitud es el propio nodo destino o es un nodo intermedio que tiene una ruta activa hacia el destino, se genera un mensaje de respuesta de ruta. Se considera que un nodo intermedio tiene una ruta activa hacia el destino cuando el número de secuencia del nodo destino almacenado en la tabla de rutas es mayor o igual al número de secuencia del nodo destino de la solicitud. Cuando es el nodo destino quien genera la respuesta, incluye en el mensaje RREP como número de secuencia el valor máximo entre su propio número de secuencia y los números de secuencia de destino incluidos en los mensajes de solicitud de rutas. A diferencia de la solicitud, el mensaje RREP se reenvía de vuelta al origen de forma unicast. Un mensaje RREP siempre sigue el camino inverso de su mensaje RREQ correspondiente, por lo que los nodos típicamente asumen que los enlaces son bidireccionales. La Figura 2.6 detalla la trayectoria de las respuestas para completar la fase de formación del camino de ida, en la que se indica mediante flechas el recorrido de los mensajes RREP. En este caso, puesto que se supone que ninguno de los nodos intermedios conoce la ruta, es el nodo destino quien genera la respuesta, por lo que los dos mensajes RREP que llegan al nodo origen tienen el mismo número de secuencia de destino. Para escoger una de las dos rutas posibles, se atiende al menor número de saltos, y así se selecciona el camino trazado en verde azulado, de tres saltos, en lugar del de color turquesa, que consta de cuatro.

24

Figura 2.6. Reenvió de mensajes RREP.

Cuando los nodos intermedios por los que pasó previamente la solicitud reciben la respuesta de rutas, pueden verse en la necesidad de actualizar su tabla de rutas. En la Figura 2.7 se muestra la lógica que siguen los nodos intermedios para decidir si actualizar o no la entrada en la tabla correspondiente al nodo destino. Un nodo intermedio procede a la actualización de rutas en dos casos. En primer lugar, refresca su ruta si el nuevo número de secuencia asociado al nodo destino que se incluye en el mensaje RREP es mayor que el que figura en su tabla para ese destino. En segundo lugar, cuando ambos números de secuencia coinciden, se procede a la actualización cuando el número de saltos indicado en la respuesta es inferior al indicado en su tabla. Para computar el número real en función del número de saltos que aparece en la respuesta ha de sumarse una unidad para incluir al propio nodo. Los mensajes RREP redundantes o con un número de secuencia de destino menor se descartan automáticamente. Cuando finalmente el nodo origen recibe el mensaje de respuesta, guarda la ruta hacia el destino y puede comenzar a transmitir paquetes de datos. La Figura 2.8 muestra el camino de ida definitivo. Sobre él se muestra el recorrido de los paquetes de datos mediante flechas. 2.2.3. Mantenimiento de rutas El protocolo AODV, al igual que otros protocolos de encaminamiento, emplea mensajes hello o beacons para que los nodos anuncien a sus vecinos su pertenencia a la red.

25

Figura 2.7. Diagrama de flujo para la actualización de rutas en los nodos intermedios durante la

fase de formación del caminos de ida.

Figura 2.8. Envió de paquetes de datos sobre el camino de ida finalmente establecido.

26

Y, de esa manera, se pueda monitorizar en una ruta activa el estado del enlace hacia el siguiente salto. Los mensajes hello se envían de manera periódica, lo que permite detectar fallos de enlace. Cuando un nodo deja de recibir estos mensajes por parte de alguno de sus vecinos, puede concluir que el enlace ha dejado de estar operativo. En el momento en el que un nodo advierte un fallo en un enlace, difunde por broadcast un mensaje de error de ruta (RERR, Route Error) a sus vecinos, que a su vez lo propagan hacia nodos cuyas rutas podrían verse afectadas por esta eventualidad. Puesto que el mensaje RERR se propaga hacia el nodo origen, cada nodo intermedio marca como inválida la ruta cuando recibe el mensaje de error. No obstante, el nodo origen perjudicado puede reiniciar su operación de descubrimiento de rutas en caso de que aún necesite alcanzar ese nodo destino. 2.2.4. Alcance de los mensajes de control del protocolo AODV Los mensajes RREQ y RREP, descritos en la Sección 2.2.2, junto con los mensajes hello y RRER, explicados en la Sección 2.2.3, son los mensajes de control más comúnmente intercambiados en el protocolo AODV. La Figura 2.9 toma como referencia el camino de ida formado sobre la red de ejemplo ilustrada en las Figuras 2.4, 2.5, 2.6 y 2.7. En ella, se señala qué sentido de la comunicación toman los mensajes de hello, RREQ, RREP, datos y RRER, desde el nodo origen hacia el nodo destino.

Figura 2.9. Mensajes de enrutamiento en AODV.

Adicionalmente, los nodos también pueden intercambiar otros mensajes denominados mensajes de confirmación de respuesta de rutas, (RREP-ACK, Route REPly ACKnowledgment). Se trata de mensajes mucho más infrecuentes ya que sólo se emplean cuando la red está formada por enlaces unidireccionales.

27

2.2.5. Parámetros La implementación del protocolo AODV goza de ciertos grados de libertad para adaptarse a las peculiaridades de la red real a la que se aplica. Previo a la instalación del protocolo en los nodos de la red, es posible modificar el valor numérico de las constantes indicadas en el documento RFC3561. Se presentan a continuación algunos de los parámetros cuyo valor conviene alterar:

NET DIAMETER: Número máximo de saltos que para establecer un camino entre un nodo origen y un nodo destino. Por defecto su valor es 35.

ACTIVE ROUTE TIMEOUT: Tiempo de validez de una ruta activa. Por defecto su valor es de 3 segundos.

MY ROUTE TIMEOUT: Cada nodo elige el tiempo de validez de las rutas en las que él es el nodo destino. Este valor se copia en el campo del tiempo de vida en el mensaje RREP que se genera previamente a la formación del camino de ida. Por defecto su valor es el doble de ACTIVE ROUTE TIMEOUT.

ALLOWED HELLO LOSS: Número máximo de mensajes hello no recibidos antes de considerar que un enlace no está operativo. Por defecto su valor es 2.

RREQ RETRIES: Número máximo de intentos de descubrimiento de rutas antes de considerar un destino inalcanzable. Por defecto su valor es 2.

TTL START: Tiempo de vida inicial del mensaje RREQ empleado con el algoritmo de búsqueda expansiva en anillo, computado en número de saltos. Por defecto su valor es de 1.

TTL INCREMENT: Incremento del valor de TTL START empleado con el algoritmo de búsqueda expansiva en anillo. Por defecto su valor es de 2.

28

Capítulo 3 Simulador NS-2 3.1. Ventajas y desventajas de la simulación La simulación es una manera práctica de obtener una estimación de los resultados que obtendríamos al poner en marcha un nuevo sistema, así como observar de una manera más fácil su comportamiento. Para que el estudio del sistema que se esté analizando mediante la simulación sea positivo, los resultados que se obtienen en las salidas de dicha simulación deben corresponder con los datos que se obtendrían en el sistema real. A continuación se exponen una serie de ventajas y desventajas a la hora de realizar cualquier simulación. Las principales ventajas son:

La simulación permite analizar grandes problemas complejos que no se pueden resolver de forma analítica.

Permite estudiar los efectos interactivos de los componentes individuales variables para determinar las más importantes.

Permite incluir posibles complicaciones de un sistema real que no son evaluadas en un principio por la simulación.

La simulación permite experimentar y tomar decisiones sin estar en contacto directo con el sistema real.

Analizar los resultados obtenidos durante un año al realizar alguna modificación en cualquier equipo no es muy práctico, por lo que la mejor alternativa sería realizar este mismo análisis mediante la simulación en mucho menos tiempo.

Utilizar técnicas analíticas requieren experiencia matemática tanto para utilizarlas como para comprenderlas. Mediante una simulación se pueden analizar los resultados de forma más intuitiva y sin necesidad de utilizar excesivas técnicas matemáticas.

A la hora de realizar el diseño de un nuevo sistema es muy útil responder a la pregunta ¿Qué pasaría si….? Mediante una simulación.

Ayuda a comprender el funcionamiento del sistema, no como se cree que funciona.

Realizar simulaciones para responder ¿Qué debo hacer? O ¿Cómo debo hacerlo? ante una situación compleja.

Permite analizar donde se encuentran los cuellos de botella y determinar donde se paran los procesos.

Las principales desventajas de la simulación son:

Los valores finales que se obtienen al realizar una simulación son solo estimaciones de los valores reales del sistema analizado.

29

Para dar más exactitud a las estimaciones obtenidas se debería repetir un gran número de veces la simulación, que repercute en una gran disponibilidad de tiempo y gran capacidad de procesado por parte de los equipos.

Cada simulación requiere un diseño especializado ya que no se puede seguir un patrón común. Se debe emplear un tiempo elevado y experiencia para desarrollo y programación del diseño aunque existan paquetes de software especializado.

Los resultados que se obtienen a la salida de la simulación son principalmente aleatorios que dependen de las variables de entrada, es difícil saber si dependen la relación de las variables son aleatorios.

Simular un nuevo sistema puede ser una tarea costosa. A menudo el sistema a desarrollar es largo y complicado.

Pueden quedar al finalizar la simulación variables sueltas que pueden cambiar el funcionamiento del sistema real una vez implantado. Se pueden reducir riesgos pero no evitarlos.

Para solucionar el problema del desarrollo complejo existen una gran variedad de software que solo necesitan datos de entrada para comenzar la simulación y facilitan la comprensión de los resultados obtenidos. Cada día, mejora el hardware y se abaratan más los costos, permitiendo una mayor rapidez de ejecución de los escenarios de simulación. 3.2. Elección del simulador El simulador elegido para este trabajo es NETWORK SIMULATOR 2 (NS-2) en la versión 2.34. La razón principal de la elección se encuentra en que es un software muy versátil y permite su utilización en muchas topologías de redes, incluyendo las redes móviles y diferentes sistemas de movilidad como los que se estudiaran en este trabajo. Además es un programa con licencia de distribución libre y ampliamente difundida en el ámbito académico. 3.3. Generalidades sobre el NS-2

NS-2 es un simulador de eventos discretos orientado a redes de comunicaciones. Este simulador se ha ido desarrollando estos últimos años desde que 1989 empezara como una variante del simulador REAL Network Simulator. En 1995, fue apoyado por el proyecto VINT (Virtual Internetwork Testbeb) que tenía como objetivo la creación de un simulador para el estudio de la escalabilidad y la interconexión entre protocolos de redes actuales y futuras. Dentro de este proyecto había colaboradores como USC/ISI (University of Southern California – Information Sciences Institute), Xerox PARC (Palo Alto Reserch Center), LBNL (Lawrence Berkeley National Laboratory) y UC Berkeley (Universidad de California de Berkeley). Actualmente NS-2 sigue desarrollándose a través de CONSER (Collaborative Simulation For Education and Reserch) que tiene como objetivo:

La investigación en el desarrollo y evaluación del protocolo de red.

Enseñanza de los protocolos de red nuevos como existentes.

30

Y SAMAN (Simulation Augmented by Measurement and Analysis for Networks), el cual se dedica a extender, detectar, y predecir fallos en el simulador. Además de los mencionados hay otros colaboradores como ACIRI. El simulador consta de un núcleo principal escrito en C++ que se puede ejecutar simplemente tecleando ns en la línea de comandos. Para actuar sobre el simulador se utiliza un interfaz específico. Este interfaz es OTcl que deriva del Tcl pero orientado a objetos. Los objetivos de NS-2 son los siguientes, por una parte debe manejar todos los protocolos de simulación manejando bytes y grandes volúmenes de datos en un tiempo de ejecución corto. El lenguaje C++ se encarga de manejar este volumen de datos de forma rápida a la hora de realizar simulaciones de protocolos de comunicación. Por otro lado, es necesario poder realizar una reconfiguración de los escenarios a simular. Para este fin se necesita otro lenguaje como OTcl que es de ejecución más lenta pero permite realizar los cambios de forma rápida e interactiva. Para poder separar la parte de datos de la parte de configuración, el NS-2 utiliza un mecanismo que concede el control de los objetos escritos en C++ a OTcl. Esto quiere decir que se pueden escribir códigos de programación de la simulación de una red sin tener que escribir nada en C++. Esto cambia cuando se quiere implementar cualquier clase o protocolo que estuviera previamente introducido en NS-2, de tal manera que se deberá escribir en C++ y posteriormente compilar el programa para que la modificación quede establecida, figura 3.1.

Figura 3.1. Jerarquía parcial de clases del NS-2.

31

Desde el punto de vista de los usuarios el simulador NS-2 interpreta el código escrito en OTcl, el cual tiene un planificador de eventos de simulación, librerías de objetos de componentes de red y librerías de módulos de instalación de red como muestra la figura 3.2.

Figura 3.2. Estructura de NS-2.

Es una herramienta muy potente y altamente configurable. Debido a esto se puede utilizar para realizar simulaciones de redes concretas así como herramienta académica. También hay que destacar que posee una licencia de distribución libre. 3.3.1. Instalación El simulador NS-2 se puede ejecutar en diferentes plataformas como Windows o Linux, pero la plataforma elegida ha sido la distribución de Linux (Ubuntu 10.04) disponible gratuitamente en la página oficial. Primero se ha realizado la partición en el disco duro para instalar el sistema operativo y posteriormente se ha instalado NS-2 disponible en la página oficial del simulador. La versión de NS-2 que se ha instalado es la 2.34 y se puede instalar de dos maneras; descargando paquete a paquete guardándolos en disco y posteriormente compilarlos o instalar un solo archivo comprimido (ns-allinone- 2.34) que contiene todos los paquetes como ha sido nuestro caso. Este archivo “todo en uno” contiene los paquetes básicos siguientes:

Tcl 31eléase 8.4.14 (componente necesario).

Tk 31eléase 8.4.14 (componente necesario).

Otcl 31eléase 1.13 (componente necesario).

TclC 31eléase 1.19 (componente necesario).

Ns 31eléase 2.31 (componente necesario).

Nam 31eléase 1.13 (componente opcional).

Xgraph versión 12 (componente opcional).

Cweb versión 3.4g (componente opcional).

SGB versión 1.0 (componente opcional).

Gt-im gt-itm y sgb2ns 1.1 (componente opcional).

Zlib versión 1.2.3 (componente opcional).

32

Para instalar el software se ha de seguir los siguientes pasos: El primer paso será la descarga del archivo ns-allinone-2.34.tar.gz, que puede descargarse de la siguiente fuente: http://sourceforge.net/projects/nsnam/files/allinone/ns-allinone-2.34/ns-allinone-2.34.tar.gz/download Mover el archivo al directorio donde vayamos a instalar ns-2, en nuestro caso al directorio del usuario, ejecutando el siguiente comando $cp ns-allinone-2.34.tar.gz /home/usuario/ Moverse al directorio usuario $cd /home/usuario Ejecutar el siguiente comando para descomprimir el archivo: $tar –xzvf ns-allinone-2.34.tar.gz ahora moverse al directorio creado con el comando $cd /home/usuario/ns-allinone-2.34 instalar las librerías necesarias para el correcto funcionamiento: sudo apt-get install build-essential autoconf automake libxmu-dev gcc-4.3

Debido a que Otcl no funciona con la versión de gcc instalado por omisión en Ubuntu

10.04, hay que ir al directorio ns-allinone-2.34/otcl-1.13, en Makefile.in buscar la línea que

dice:

CC= @CC@

y cambiar por la siguiente:

CC= gcc-4.3

Instalar, ejecutar el siguiente comando:

$./install

33

3.3.1.1. Configuración de las variables de entorno

Añadir las siguientes lineas al final dentro del archivo bashrc. Remplazar "home/usuario"

por el directorio donde tengan instalado ns-2.34

$ gedit ~/.bashrc # LD_LIBRARY_PATH OTCL_LIB=/home/usuario/ns-allinone-2.34/otcl-1.13 NS2_LIB=/home/usurio/ns-allinone-2.34/lib X11_LIB=/usr/X11R6/lib USR_LOCAL_LIB=/usr/local/lib export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$X11_LIB:$USR_LOCAL_LIB # TCL_LIBRARY TCL_LIB=/home/usuario/ns-allinone-2.34/tcl8.4.18/library USR_LIB=/usr/lib export TCL_LIBRARY=$TCL_LIB:$USR_LIB # PATH XGRAPH=/home/usuario/ns-allinone-2.34/bin:/home/usuario/ns-allinone-2.34/tcl8.4.18/unix:/home/usuario/ns-allinone-2.34/tk8.4.18/unix:/home/usuario/ns-allinone-2.34/xgraph-12.1/ NS=/home/usuario/ns-allinone-2.34/ns-2.34/ NAM=/home/usuario/ns-allinone-2.34/nam-1.13/ export PATH=$PATH:$XGRAPH:$NS:$NAM

Recargar el archivo bashrc, con el siguiente comando

$ source ~/.bashrc

Ejecutar ns

$ns

Figura 3.3. Ventana mostrada al ejecutar NS-2.

La figura 3.3 muestra que se ha configurado correctamente las variables de entorno para

ns, para salir se digita exit.

34

3.3.1.2. Validación de la instalación Dentro del directorio ns-allinone-2.34 digitar:

$ cd ns-2.34

$ ./validate

La validación puede tomar algún tiempo. Al final de la validación debe mostrarse

información como la de la imagen "all tests passed", figura 3.4.

Figura 3.4. Ventana desplegada al terminar la validación.

3.3.2. Funcionamiento de NS-2 Originariamente NS-2 fue ideado para redes fijas pero implementado más tarde para redes inalámbricas por el grupo Monarch de CMU. Mediante esta implementación aparecen las principales redes ad hoc y WLAN (Wireless Local Area Networks). En este trabajo se utilizara esta implementación para realizar simulaciones de nodos móviles en entornos WLAN. El NS- 2 se basa en dos lenguajes de programación. Por un lado, se utiliza el lenguaje OTcl para introducir las especificaciones del escenario que el usuario quiere simular. Por otro lado se utiliza C++ para la implementación de los protocolos. Para la implementación de un protocolo en NS-2 se deben seguir los siguientes pasos:

Implementación del protocolo a analizar mediante código en lenguaje

C++ en el caso que no esté previamente en NS-2.

Descripción de la simulación en OTcl. En este punto se debe describir todas las especificaciones del escenario que se desea simular.

35

Ejecución de la simulación. En este punto es necesario ejecutar el archivo donde previamente se han guardado las trazas de la simulación. La ejecución se realiza mediante el comando “ns” seguido del nombre del archivo.

Análisis de los resultados. El NS- 2 incluye una herramienta con la que se pueden visualizar las simulaciones, denominada NAM. Con esta herramienta se pueden visualizar desde la carga de tráfico entre dispositivos hasta la pérdida de paquetes como también movilidad de terminales. Además de esta herramienta para visualizar se pueden utilizar leguajes como PERL o AWK para filtrar los archivos que contiene las trazas y obtener los datos que se deseen evaluar. Los puntos arriba mencionados se pueden visualizar en la figura 3.5:

Figura 3.5. Jerarquía parcial de clases del NS-2.

Se puede observar cómo el núcleo de ns se basa en C++, mientras que la especificación de los escenarios en OTcl. Los escenarios por simular pueden utilizar tanto la herramienta para generar tráfico (cbrgen) como la herramienta (setdest) para simular el movimiento de terminales móviles mediante los diferentes modelos de movimiento. 3.3.3. Ventajas y desventajas del simulador NS-2 A la hora de elegir este simulador también se ha tenido en cuenta la gran cantidad de ventajas sobre desventajas que se exponen a continuación, tabla 3.1.

Ventajas Desventajas

Software muy versátil Configuración de la simulación a través de scripts

Herramienta extensamente conocida Necesidad de utilización de protocolos de capas superiores

Sistema multiplataforma

Contiene herramienta de animación grafica

Tabla 3.1. Ventajas y Desventajas del simulador NS-2.

36

3.3.3.1. Ventajas

Es un Software muy versátil porque abarca una gran variedad de aplicaciones como pueden ser la implementación de diferentes topologías de red tanto cableadas como inalámbricas, protocolos de ruteo, protocolos de transporte. Algunos de estos protocolos son http,TcpApp, telnet, CBR (Constant Bit Rate), TCP, RTP, algoritmos de ruteo, enrutamiento jerárquico, enrutamiento manual.

Herramienta extensamente conocida en el ámbito académico por ser un software con licencia de distribución libre y altamente configurable por ser de código libre.

Sistema multiplataforma, ya que puede ser ejecutado en diferente sistemas operativos como Windows desde la versión 95 o Unix (Free BSD, Ubuntu, SUSE, etc.)

Contiene herramienta de animación gráfica para hacer más fácil el aprendizaje y el entendimiento de las diferentes redes a implementar.

3.3.3.2. Desventajas

Las configuraciones de las simulaciones se deben realizar a través de código, por lo que requiere un mayor tiempo de desarrollo.

En NS-2 no es posible simular un escenario wireless sin especificar un protocolo. 3.3.4. Herramienta NAM de NS-2 NAM comenzó a desarrollarse en los noventa por Steven McCanne, miembro del “Network Research Group” del Lawrence Berkeley National Laboratory. Posteriormente fue mejorada por Marylou Orayami bajo la supervisión del proyecto VINT. Actualmente sigue desarrollándose en los proyectos SAMAN y CONSER en ISI. NAM, es una herramienta de simulación basada en el lenguaje Tcl/Tk encargada de mostrar de forma gráfica las simulaciones obtenidas mediante los archivos de trazas de salida del simulador NS-2. Para invocar estos archivos utilizaremos el comando: $nam archivo_traza.nam Una vez que se ejecute el archivo con la información de las trazas, la herramienta NAM mostrará en una ventana la topología de red indicada en la simulación. A continuación se muestra el aspecto general de la herramienta NAM, figura 3.6.

37

Figura 3.6. Herramienta NAM.

Las principales funciones de la herramienta NAM son:

Animation Area: en esta zona visualizaremos la topología de red que se ha especificado en la simulación.

Zoom In /Zoom Out: sirven para aumentar o disminuir el área de simulación.

Stop/Play Animation: sirven para poner en marcha o parar la simulación.

Current Animation Time: es el tiempo que ha transcurrido desde que hemos puesto en marcha la simulación. El tiempo máximo será el que hayamos especificado en dicha simulación.

Step: indica la velocidad con la que transcurre la simulación. Este valor esta en milisegundos y se puede variar mediante el slider que hay debajo del tiempo.

File: contiene diferentes opciones como grabar la simulación, imprimir el área de simulación, etc.

3.4. Ejemplos de script TCL Antes de realizar la simulación completa con diferentes modelos de movilidad implementaremos unas muy básicas para poder entender la estructura de un script TCL.

38

Para ello, seguiremos el manual Marc Greis's tutorial [6] en el que se detalla paso a paso como realizar un script. 3.4.1. Ejemplo de dos nodos Wireless comunicándose en modo ad-hoc A continuación programaremos un escenario con nodos inalámbricos. El escenario consta de 2 dos nodos móviles wireless, node_(0) y node_(1) que podrán estar estáticos o moverse en una área con una dimensión de 500m x 500m. Para realizar una simulación con nodos wireless primero hemos de definir los parámetros de dichos nodos como el tipo de propagación, el tipo de antena, el tipo de protocolo de enrutamiento que utilizaran, el número de nodos móviles, etc. #=========================================================== # Define options # ============================================================ set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(ant) Antenna/OmniAntenna ;# Antenna type set val(ll) LL ;# Link layer type set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type set val(ifqlen) 50 ;# max packet in ifq set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(rp) DSDV ;# ad-hoc routing protocol set val(nn) 2 ;# number of mobilenodes La estructura del script es la siguiente: En primer lugar, se debe crear el objeto del simulador mediante el comando: Set ns [new simulator] Ahora, abrimos los archivos de trazas donde se escribir toda la información obtenida por el simulador para posteriormente ser representados por NAM o XGRAPH . set nf [open out.nam w] $ns namtrace-all $nf Set tracefd [open simple.tr w] $ns trace-all $tracefd Creamos el objeto de la topología. set topo [new Topography] Asignamos las dimensiones del área de simulación. $topo load_flatgrid 500 500

39

Creamos el objeto GOD. create-god $val(nn) El objeto GOD (General Operations Director) almacena el número total de nodos móviles y el número de saltos necesarios para llegar de un nodo a otro. Para la configuración de los nodos móviles se tienen en cuenta una serie de componentes como, la capa de enlace (LL – Link Layer), interfaz de colas (IfQ), la capa MAC, el canal de envío y recepción, etc. # Configure nodes $ns_ node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -topoInstance $topo \ -channelType $val(chan) \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace OFF Después de configurar los nodos los creamos como se muestra a continuación: for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node ] $node_($i) random-motion 0 ;# disable random motion } La opción “random motion” la deshabilitamos ya que le proporcionaremos a los nodos móviles una posición de inicio: # # Provide initial (X,Y, for now Z=0) co-ordinates for node_(0) and node_(1) # $node_(0) set X_ 5.0 $node_(0) set Y_ 2.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 390.0 $node_(1) set Y_ 385.0 $node_(1) set Z_ 0.0 y un movimiento predeterminado: # # Node_(1) starts to move towards node_(0) #

40

$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0" $ns_ at 10.0 "$node_(0) setdest 20.0 18.0 1.0" # Node_(1) then starts to move away from node_(0) $ns_ at 100.0 "$node_(1) setdest 490.0 480.0 15.0" Mediante la línea ( $ns_ at 50.0 “$node_(1) setdest 25.0 20.0 15.0”) el node_(1) en el instante 50 s se moverá hacia las coordenadas x=25, y=20 con una velocidad de 15m/s. Creamos el tráfico entre los dos nodos. # TCP connections between node_(0) and node_(1) set tcp [new Agent/TCP] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns_ attach-agent $node_(0) $tcp $ns_ attach-agent $node_(1) $sink $ns_ connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns_ at 10.0 "$ftp start" Definimos el final de la simulación y reiniciamos los nodos móviles. # Tell nodes when the simulation ends # for {set i 0} {$i < $val(nn) } {incr i} { $ns_ at 150.0 "$node_($i) reset"; } $ns_ at 150.0001 "stop" $ns_ at 150.0002 "puts \"NS EXITING...\" ; $ns_ halt" proc stop {} { global ns_ tracefd close $tracefd } La simulación finalizará en el instante 150 s. Iniciar la simulación. puts "Starting Simulation..." $ns_ run Para ejecutar el modo gráfico mediante la herramienta NAM deberemos hacerlo con el comando nam seguido del archivo donde hemos guardado la simulación: nam archivo_traza.nam 3.5. Archivo de trazas El archivo traza se genera al ejecutar el script en oTCL, en el cual previamente se le indica que genere un archivo traza (.tr) que junto con el archivo nam (.nam) serán la herramienta de este proyecto. (Ver apartados). La tabla 3.2 resume los campos que se encuentran en un archivo traza (.tr).

41

Campo Marca Descripción

1 -

Indica el tipo de evento. Puede tener cinco valores distintos:

s send, indica que se trata de un paquete enviado

r receive, es un paquete recibido

f forward, es un paquete renviado por un nodo intermedio

d drop, se trata de un paquete perdido

2 -t Tiempo en qué ocurre el evento.

- -Hx Los campos que empiecen con esta marca se refieren a información acerca del siguiente salto.

3 -Hs Número de nodo dónde acontece el evento.

4 -Hd Número del siguiente nodo hacia el destino.

- -Nx Los campos que empiecen con esta marca se refieren a información acerca de las propiedades del nodo.

5 -Ni Identificador del nodo.

6 -Nx Coordenada x en la que se encuentra el nodo

7 -Ny Coordenada y en la que se encuentra el nodo.

8 -Nz Coordenada z en la que se encuentra el nodo

9 -Ne Nivel de energía del nodo.

10 -Nl

El valor de este campo depende de qué capa estamos teniendo en cuenta:

MAC paquete correspondiente a la capa MAC

AGT capa de transporte (tcp ó udp)

RTR paquete enrutado

IFQ referente a la cola salida del nodo PHY capa física

11 -Nw

Motivo por el cual se descarta el paquete:

--- el paquete no se descarta

END final de la simulación

COL colisión a nivel MAC Existen muchas más posibilidades, no hace falta enumerarlas todas.

- -Mx Los campos que empiecen con esta marca se refieren a información acerca de los paquetes a nivel de capa MAC.

12 -Ma Tiempo esperado en segundos para enviar el paquete a través del canal wireless

13 -Md Dirección MAC del nodo destino.

14 -Ms Dirección MAC del nodo fuente.

15 -Mt Tipo de capa MAC.

42

Tabla 3.2. Campos de los archivos de trazas.

El archivo traza es la base de la evaluación de los protocolos de enrutamiento. Mediante

el archivo traza, como se verá más adelante podemos obtener información detallada de lo

que ocurre en los distintos escenarios y con ello obtener así por ejemplo, el tiempo que le

tomo a cada paquete llegar del origen a su destino, el retardo que existe, el tiempo en el

que ocurren los eventos, etc. Como se verá más adelante, estos datos dan la pauta para

estimar mediante graficas una medida del desempeño dé los protocolos.

Como se ve en la tabla el archivo traza (.tr) contiene demasiada información lo que

conlleva de una exhausta selección de la información que solo se va a graficar

El archivo .nam que nos servirá para editarlo en el nam lo generara el ns-2 al ejecutar el archivo .tcl que hemos programado previamente, y normalmente le diremos que lo

- -Ix Los campos que empiecen con esta marca se refieren a información acerca de los paquetes a nivel de IP.

16 -Is Dirección IP del nodo fuente seguido de “.” Seguido de el número de puerto del nodo fuente.

17 -Id Dirección IP del nodo destino seguido de “.” Seguido del número de puerto del nodo destino.

18 -It Tipo de paquete. Puede ser: cbr, DSR, ack, udp, tcp, ARP…

19 -Il Tamaño del paquete en bytes.

20 -If Identificador flowstate.

21 -Ii Identificador de secuencia global del paquete. Identifica el paquete en el archivo de trazas.

22 -Iv Valor del TTL (Time To Live).

- -Px Los campos que empiecen con esta marca se refieren a información acerca de los paquetes a nivel de “aplicación”.

23 -P

En este campo se indica el tipo de “aplicación” que puede ser:

arp Address Resolution Protocol

dsr Dynamic Source Routing

cbr Constant Bit Rate

tcp Transport Control Protocol En función de este campo, el número y tipo de campos siguientes serán distintos. Este ejemplo está hecho a partir de un paquete cbr así que seguiremos con los campos de este tipo de paquete.

24 -Pi Número de secuencia cbr.

25 -Pf Número de veces que el paquete ha sido renviado.

26 -P Número óptimo de renvíos necesarios

43

guarde en el directorio donde tenemos todos los archivos ejecutables. También podremos indicar en el archivo que programamos .tcl que nos abra directamente el Network Animator.

Tabla 3.3. Archivo traza.

Formato de la estructura de un archivo .nam, figura 3.7:

Figura 3.7. Análisis de cada campo.

Las opciones de visualización del NAM son las siguientes:

Retroceso rápido: la simulación se va retrocediendo multiplicando su paso del tiempo por 25.

Retroceso normal: la simulación se retrocede según el paso del tiempo normal.

Stop: detiene la simulación.

Avance normal: se inicia la animación o la hace continuar si estaba pausada.

Avance rápido: la animación se va avanzando multiplicando el paso del tiempo por 25.

Tiempo: indica el instante en el que se encuentra la simulación.

Paso de tiempo: nos da una idea de la rapidez de la simulación.

Zoom: para aumentar o disminuir la simulación.

Tamaño de los nodos: permite variar el tamaño de los nodos, en caso de tener pocos nodos en la simulación podemos aumentarlos de tamaño para apreciar mejor el tránsito de los paquetes.

Indicador de tiempo: da idea del tiempo transcurrido en la simulación a través de una barra de tiempo, la cual visualmente nos da una imagen rápida del tiempo que queda y el tiempo transcurrido.

Flujo de enlace: si se pulsa en un enlace y se selecciona la opción “Graph” se puede visualizar el tiempo que le tomó a la información pasar por el enlace.

44

3.6. Programa Trace graph El NS-2 genera un archivo de tipo trace (.tr), este archivo nos servirá para ejecutar el trace graph el cual se podrá abrir desde el menú del trazador de graficas o podremos ordenar que se abra desde las líneas de código del archivo tcl que hemos programado previamente. El trace graph va acompañado del programa Matlab, que es un programa de tratamiento matemático al cual se le pueden introducir funciones matemáticas para que las represente gráficamente, una de las ventajas de guardar los archivos generados en un archivo matlab será que incrementaremos la velocidad a la hora de cargar de nuevo el archivo. 3.6.1. Gráficos en 3D

Numbers of generated packets at all the nodes: Nos dará una información

detallada de todos los paquetes de datos generados en todos los nodos de la red, que previamente hemos creado con el NS-2 indicándonos el nodo que genera esos paquetes y el nodo que recibirá esos mismos datos.

Numbers of sent packets at all the nodes: Esta opción nos informará acerca

de todos los paquetes enviados desde cualquier nodo de nuestra topología indicándonos en la gráfica el receptor de esos mismos paquetes enviados. En teoría la gráfica anterior debería ser igual a esta porque se supone que en la simulación todos los paquetes que son generados son destinados a ser enviados a un nodo receptor.

Numbers of received packets at all the nodes: Aquí podremos ver los nodos

receptores de los paquetes que será un gráfico inverso al anterior.

Numbers of forwarded packets at all the nodes: Nos mostrara el gráfico de

los paquetes expedidos en todos los nodos es decir aquí se cuentan todos los paquetes tanto los que son generados en el propio nodo como los que van de paso.

Numbers of dropped packets at all the nodes: Aquí podremos ver el numero

de paquetes dejados de caer o descartados en todos los nodos.

Number of lost packets at all the nodes: En este gráfico observaremos todos

los paquetes perdidos en todos y cada uno de los nodos, pudiendo ver el origen y destino de esos nodos con un simple golpe de vista gracias a la gran información que nos suministra el gráfico.

El resto de opciones en 3D son iguales que las anteriores pero en vez de basar las gráficas en función de los paquetes el resto se basan en función al número de bytes por lo que serán gráficas muy parecidas.

45

Capítulo 4 Evaluación de los protocolos AODV y DSDV 4.1. Configuración de los parámetros de los escenarios de simulación Para la evaluación de los protocolos AODV y DSDV se propusieron tres escenarios considerando los siguientes parámetros:

Protocolo de enrutamiento: Se define AODV o DSDV para nuestras

simulaciones, aunque también se pueden definir otros protocolos como por ejemplo TORA DSR PUMA.

Capa de enlace: Las opciones son LL o LL/Sat. La única diferencia de la capa de

enlace para redes móviles con respecto a las redes locales es que tiene un modulo ARP conectado a la misma que resuelve todas las direcciones IP a las conversiones de hardware (MAC). La clase LL se implementa en ~ns/ll.{cc,h}.

Capa Mac: En este proyecto se ha usado solo MAC/802.11, aunque existen otras

opciones como Mac/Csma/Ca, Mac/Sat, Mac/Sat/unslottedAloha, Mac/Tdma y SMAC. Historicamente, ns-2 ha utilizado la aplicación de la norma IEEE 802.11, debido a eso las implementaciones hechas en este proyecto se realizan con esa norma.

Tipo de cola: En los escenarios se utiliza Queue/DropTail también existe

Queue/DropTail/PriQueue y CMUPriQueue. Se eligió por su sencillez y porque además puede usarse con los protocolos AODV y DSDV, no así por ejemplo con el protocolo DSR que solo es válido con CMUPriQueue.

Capacidad de la cola: Número máximo de paquetes que puede almacenar un

nodo en su cola.

Tipo de antena: Antenna/OmniAntenna, antena omnidireccional, de esta forma

los nodos pueden radiar en cualquier dirección.

Tipo de propagación: Propagation/TwoRayGround (considera no solo el camino

directo de las ondas de antena a antena, sino que también considera el efecto de la reflexión de esas ondas en el suelo), Propagation/FreeSpace (considera tan solo el camino directo de las ondas, suponiendo que no hay ningún tipo de obstáculo), Propagation/Shadowing (considera el efecto de la propagación multicamino).

Capa física: Phy/WirelessPhy o Phy/Sat. Se escogió la primera opción debido a

que se trabajó en un entorno inalámbrico (Wireless).

Tipo de canal: Channel/WirelessChannel y Channel/Sat. Se escogió la primera

opción debido a que se trabajó en un entorno inalámbrico (Wireless).

Topología de red: Definida anteriormente.

46

Información de las trazas: Activación o no de distinta información que

aparecerá en los archivos de trazas acerca de la capa MAC, los agentes, el enrutamiento y los movimientos en los archivos de salida.

Todos estos parámetros se encuentran especificados en los programas que se encuentran en los anexos. 4.2. Medidas de desempeño Como se mencionó en el capítulo 1, la eficiencia del enrutamiento es evaluada por parámetros como throughput, delay, jitter, dropped packets, etc. A continuación se definirán los tres parámetros de desempeño que se utilizaran y analizaran para propósito de este trabajo. 4.2.1. Througput El Througput se define como la máxima tasa de transferencia que se puede alcanzar en una transmisión entre elementos terminales (end-to-end.). En otros palabras es la cantidad total de información que es recibida en los nodos receptores por unidad de tiempo se mide en bits por segundos (bps), ecuación 4.1.

(4.1)

4.2.2. Tasa promedio de entrega La tasa promedio de entrega es la fracción de paquetes que llegan a su destino por el número total de paquetes enviados en la red, regularmente se expresa en porcentaje, ecuación 4.2.

(4.2)

4.2.3. Retardo promedio de extremo a extremo El retardo promedio de extremo a extremo se expresa como el tiempo promedio que requieres todos los paquetes de datos que has sido entregado a su destino. Donde el retardo del paquete i-ésimo se expresa como Tri – Tsi. Asumiendo que j paquetes entregados a su destino, ecuación 4.3.

∑

(4.3)

47

4.3. Escenarios de simulación Se propusieron tres escenarios distintos en los cuales se evaluaron los comportamientos de los protocolos de enrutamiento, los escenarios se han elegido con base a evaluar características como:

Respuesta a diferentes cambios que pueden existir en redes ad hoc.

Tiempo de reacción de los nodos para el establecimiento de una conexión.

Tiempo de reacción de los nodos para el restablecimiento de una conexión previamente caída.

Retardo en la entrega de paquetes debido a la cantidad de saltos que realizan los paquetes.

Cantidad de paquetes perdidos durante la comunicación. 4.3.1. Escenario 1: Restablecimiento de la comunicación entre dos nodos En el primer escenario que hemos simulado se puede visualizar de una forma clara a través del nam, posteriormente se procede a evaluar el desempeño por medio de la traza generada ya que esto nos detalla lo que sucede cuando dos nodos pierden la comunicación que habían establecido previamente entre sí, siendo como primer criterio el tipo de reacción que presentan los protocolos proactivos frente a los reactivos, teniendo a un protocolo representando de cada uno de estos (proactivo y reactivo). En la tabla 1 se resumen los parámetros con los cuales se configuró este primer escenario: La figura 4.1 muestra el resultado que se obtiene al ejecutarse el archivo nam. Como se observa en una primera instancia existe una comunicación entre el nodo 0 y el nodo 1 en la cual se ha configurado un tráfico del tipo FTP sobre el protocolo de transporte TCP. Conforme el tiempo transcurre, se observa que ambos nodos se empiezan a alejar el uno del otro hasta perder la comunicación y por lo tanto el nodo 0 deja de enviar lo paquetes al nodo 1, esto se visualiza en la figura 4.2, donde los nodos han quedado totalmente desconectados.

Figura 4.1. Escenario 1: Conexión mediante el protocolo AODV y DSDV.

48

Figura 4.2. Escenario 1: Desconexión entre los nodos 0 y 1.

Una vez perdida la comunicación ambos nodos empiezan a regresar al lugar donde se encontraban al inicio, y es aquí donde se observa el comportamiento que tienen los protocolos AODV y DSDV para restablecer la comunicación que habían tenido. Para el primer caso, es decir el protocolo AODV. Se observa que la comunicación se empieza a establecer una vez que los nodos se encuentran dentro del rango de cobertura y mediante la utilización de sus mensajes HELLO para actualizar sus tablas tiene una reacción muy eficiente, la figura 4.3, visualiza lo que sucede al restablecer la comunicación.

Figura 4.3. Escenario 1: Restablecimiento de la conexión.

Un análisis más completo respecto al visor gráfico nam, se obtiene al analizar el throughput que como se mencionó antes es una medición de la cantidad de paquetes recibidos exitosamente entre el tiempo que les tomo a cada paquete en llegar de su origen a su destino. Para esto se extrajo la información generada por el archivo traza y con ello se graficó con base a lo obtenido. La figura 4.4, muestra el throughput usando el protocolo AODV mientras que la figura 4.5, muestra el throughput del protocolo DSDV. Al

49

comparar ambas graficas se observa cómo en ambas se tenía primero una comunicación entre el nodo 0 y el nodo 1, a los 20 segundos aproximadamente pierden la comunicación debido a que se alejan el uno del otro quedando fuera del rango de cobertura. En la gráfica observa cómo el protocolo AODV es más eficiente al restablecer la comunicación como se había visualizado en el nam, por una diferencia de unos cuantos segundos, el protocolo AODV tarda menos en restablecer la comunicación que el protocolo DSDV, esto debido a que el protocolo AODV a pesar de ser reactivo utiliza mensajes HELLO para actualizar sus tablas cuando ha perdido la comunicación.

.

Figura 4.4. Escenario 1: Throughput usando el protocolo AODV.

Figura 4.5. Escenario 1: Throughput usando el protocolo DSDV. Como se mostró anteriormente otra forma de medir el rendimiento de los protocolos es a través del Jitter. La figura 4.6 muestra el Jitter que se tiene usando el protocolo AODV, como se observa hay un retardo muy prolongado debido a la desconexión que se tuvo entre ambos nodos. En la figura 4.7, se ha graficado el Jitter en el mismo escenario pero usando el protocolo DSDV, también se observa un salto debido a la desconexión que se

50

tuvo pero al igual que el protocolo AODV, el protocolo DSDV mantiene las variaciones casi constantes cuando la comunicación existe.

Figura 4.6. Escenario 1: Jitter usando el protocolo AODV.

Figura 4.7. Escenario 1: Jitter usando el protocolo DSDV.

Como tercera comparación entre los protocolos se han graficado los resultados referente a los dropped packets (paquetes caídos) que resultan de los cambios repentinos en la red. Los paquetes perdidos también ocurren cuando el buffer de algún nodo se satura y en consecuencia los paquetes nuevos que llegan al nodo son descartados. También sucede cuando no encuentran un destino y en lugar de permanecer en el buffer son descartados. En las gráfica 4.8 se ha graficado el número de paquetes caídos o perdidos. Nótese que en la gráfica los ejes del plano inferior muestran los nodos en los que se envía, reciben y pierden los paquetes mientras que en el eje perpendicular al plano se muestra la el número de paquetes que pierde respectivo nodo.

51

Figura 4.8. Escenario 1: Paquetes perdidos usando el protocolo AODV.

4.3.2. Escenario 2: Establecimiento de la comunicación entre dos nodos a través de un nodo intermedio En el segundo escenario se plantea el caso contrario al escenario anterior, aquí se tratará de saber qué protocolo trabaja mejor para establecer una comunicación vía un nodo intermedio. En la figura 4.9 se observa que el nodo 0 intenta establecer comunicación con el nodo 1 utilizando el protocolo de transporte TCP sin tener éxito, poco después un tercer nodo (nodo 2) se moverá para ubicarse en una posición donde pueda tener comunicación con el nodo 0 y 1 sirviendo como medio para lograr la comunicación entre ellos. La figura 4.9 y 4.10, muestran los resultados obtenidos por el visor grafico nam. En una primera instancia los nodos 0 y 1 intentan establecer comunicación pero debido a la distancia que existe entre ellos no logran tener éxito, un segundo nodo empieza a desplazarse quedando dentro del rango del nodo 0 y también dentro del rango del nodo 1. Como se observará más adelante cada protocolo es responsable del manejo de la situación.

Figura 4.9. Escenario 1: Intento de conexión sin éxito de los nodos 0 y 1.

52

Figura 4.10. Escenario 2: Establecimiento de la conexión mediante un nodo intermedio.

Las gráficas del throughput muestran la efectividad que tiene el protocolo AODV que a pesar de no ser proactivo con el uso de sus mensajes HELLO tiene una rápida reacción de la existencia de un nodo intermedio (nodo 2) estableciendo la comunicación de manera más eficiente, por otro lado al protocolo DSDV a pesar de ser proactivo le toma más tiempo establecer comunicación con el nodo intermedio. Las figuras 4.11 y 4.12, muestran el throughput de los dos protocolos, como se puede observar, la eficiencia del protocolo AODV frente al DSDV en esta situación del establecimiento de la conexión. La figura 4.11, muestra que a los 20 segundos de iniciar la simulación el protocolo AODV ya está transmitiendo y enviando los paquetes al nodo 2 quien los encaminará al nodo 1. Por otro lado en la figura 4.12 se observa cómo el protocolo DSDV establece comunicación hasta los 55 segundos lo que denota una clara diferencia de 35 segundos entre ambos protocolos.

Figura 4.11. Escenario 2: Throughput usando el protocolo AODV.

53

Figura 4.12. Escenario 2: Throughput usando el protocolo DSDV.

Como es de esperarse, las figuras 4.13 y 4.14, los paquetes enviados presentan variaciones en el tiempo de entrega. En la figura 4.13, se observa que para el caso del protocolo AODV la variación que se tiene oscila entre 0 y 0.16 segundos mientras que para el caso del protocolo DSDV mostrado en la figura 4.14, se observa una variación que oscila de 0 a 0.14 segundos.

Figura 4.13. Escenario 2: Jitter usando el protocolo AODV.

54

Figura 4.14. Escenario 2: Jitter usando el protocolo DSDV.

Para el caso de los paquetes perdidos durante la comunicación figuras 4.15 y 4.16 se observa que ambos protocolos aparentemente pierden los mismo paquetes pero observando a mayor detalle, podemos notar que el protocolo AODV tiene un número de paquetes perdidos mayor al del protocolo DSDV. En la figura 4.15, se observa que la cantidad de paquetes perdidos alcanzan la cantidad de 8 en el nodo 1, mientras que para la figura 4.16, la cantidad de paquetes perdidos alcanza el valor de 6 en el mismo nodo. Se puede decir que el protocolo DSDV a pesar de tardarse más en establecer una comunicación es más eficaz en la entrega de los paquetes.

Figura 4.15. Escenario 2: Paquetes perdidos usando el protocolo AODV.

55

Figura 4.16. Escenario 2: Paquetes perdidos usando el protocolo DSDV.

4.3.3. Escenario 3: Comunicación entre dos nodos frente a cambios continuos en una red de 5 nodos Para el tercer escenario se propuso una red de 5 nodos de los cuales se establecerá una comunicación entre dos de ellos (nodo 0 y 1), en ocasiones se comunicaran de manera directa, en otras a través de nodos o intermedios, es decir la comunicación está sometida a diferentes cambios que pueden surgir en una red de este tipo. La figura 4.17 y 4.18 muestra lo que se visualiza en el nam al utilizar el protocolo AODV y DSDV respectivamente. En este escenario se observa claramente la naturaleza de los protocolos proactivos y reactivos en cuanto a la forma de manejar sus tablas de enrutamiento. Para el protocolo AODV (figura 4.17) se visualiza en el nam que la comunicación es manejada de manera reactiva, es decir, mientras exista comunicación no actualizará ni cambiara las rutas que tiene para el envío de paquetes, por otro lado el protocolo DSDV al ser proactivo actualiza sus tablas de enrutamiento y logra saber cuándo no es necesario enviar un paquete a un nodo intermedio si el nodo final se encuentra más cerca.

.

Figura 4.17. Escenario 3: Comunicación entre dos nodos usando el protocolo AODV.

56

Figura 4.18. Escenario 3: Comunicación entre dos nodos usando el protocolo DSDV.

En las gráficas del throughput para este escenario figuras 4.19 y 4.20, se observa lo que se había mencionado anteriormente de cada protocolo muestra tanto la reacción que tienen frente a los cambios previamente mencionados y también muestran cómo los protocolos proactivos al tener la información de sus tablas actualizada distinguen rápido la cercanía de los nodos que se comunican, es por eso que cuando dos nodos se encuentran lo suficientemente cerca el uno del otro la comunicación se establece de manera directa y no a través de nodos intermedios, mientras que en los reactivos hasta que no haya una desconexión cambian la ruta de enrutamiento. La figura 4.20, muestra que al actualizar sus tablas y cambiar la ruta de enrutamiento el throughput es más efectivo y eficiente mientras que en la figura 4.19, referente al protocolo AODV al seguir la misma ruta siempre el throughput es menos eficiente debido a los nodos intermedios que los paquetes atraviesan.

Figura 4.19. Escenario 3: Throughput usando el protocolo AODV.

57

Figura 4.20. Escenario 3: Throughput usando el protocolo DSDV.

Las figuras 4.21 y 4.22 muestran el Jitter de los paquetes enviados en cada uno de los protocolos utilizados en este escenario. Se observa que en la figura 4.21 el Jitter es muy variable tomando valores desde 0 a 0.25 segundos lo cual es justificado por la cantidad de nodos intermedios que utiliza el protocolo AODV, finalmente su naturaleza reactiva de no actualizar sus tablas termina por tener un Jitter más sensible y dependiente del número de nodos intermedios que atraviesan los paquetes. La figura 4.22, se observa el Jitter de los paquetes enviados pero usando el protocolo DSDV, la figura muestra una variación menor que va desde 0 a 0.1, claramente esto es mejor y eficiente si es que la información que se envía es sensible a los retardos como el caso de voz e imagen en tiempo real.

Figura 4.21. Escenario 3: Jitter usando el protocolo AODV.

58

Figura 4.22. Escenario 3: Jitter usando el protocolo DSDV.

En las figuras 4.23 y 4.24 se muestran los paquetes perdidos usando cada uno de los protocolos. La figura 4.23 muestra cómo al haber participado un mayor número de nodos intermedios, el número de paquetes perdidos aumenta en esos nodos. Por otro lado en la figura 4.24 no hubo tanta participación de nodos intermedios lo que resultó en un menor número de paquetes perdidos.

Figura 4.23. Escenario 3: Paquetes perdidos usando el protocolo AODV.

Figura 4.24. Escenario 3: Paquetes perdidos usando el protocolo DSDV.

59

CONCLUSIONES El presente trabajo muestra los resultados que se obtuvieron al evaluar el desempeño de los algoritmos de enrutamiento AODV y DSDV en un entorno de red inalámbrica ad hoc en donde se tomaron como criterios de desempeño el throughuput, jitter y la tasa de pérdidas de paquetes. Para lograr los objetivos planteados, se utilizó un simulador de eventos discretos con el fin de poder realizar el análisis de las métricas establecidas para los dos algoritmos. De esta manera, se puede concluir los siguientes aspectos que son esenciales al utilizar los algoritmos AODV y DSDV.

Rapidez para establecer y restablecer una comunicación: En el primer

escenario se simuló un restablecimiento de la comunicación y se observó el desempeño que presentaba cada uno de los dos protocolos (AODV y DSDV). Se observó que por ejemplo en cuanto al tiempo en restablecer una comunicación perdida el protocolo AODV resulta más eficiente debido al uso de los mensajes HELLO que funcionan para detectar la presencia de un nodo y a pesar de no ser un protocolo proactivo la implementación de estos mensajes lo hacen más eficaz que el protocolo DSDV. Por otro lado el protocolo DSDV a pesar de ser proactivo tarda más en establecer la comunicación debido a que no usa mensajes HELLO y por lo tanto es hasta cuando termina de actualizar sus tablas cuando puede establecer una comunicación. En el segundo escenario por ejemplo se destaca de nuevo el uso de los mensajes HELLO para establecer una comunicación esta vez vía un nodo intermedio. La mayor eficiencia la ofreció el protocolo AODV con respecto al protocolo DSDV con una diferencia de 25 segundos después, es decir, el protocolo DSDV tardo 25 segundos más que el AODV para empezar él envió de paquetes. En un tercer escenario se sometió a la red a muchos cambios por los cuales dos nodos que se comunicaban estarían en constante cambio debido a la dinámica que presentaban todos los nodos. Aquí la rapidez con la que se estableció la comunicación sólo varió al inicio precisamente cuando se estableció por primera vez la cual como se observa en la gráfica 4.18 y 4.19 existe una diferencia de 20 segundos.

Robustez para mantener la comunicación: Para referirnos a este punto se

resalta el tercer escenario donde la red se sometió a muchos cambios, en especial de movilidad, como lo reflejan las gráficas del throughput de la figura 4.18 y 4.19 el mejor resultado en cuanto a tiempo de conexión lo arrojó el protocolo AODV que inició la comunicación desde casi el primer segundo y la perdió hasta los 130 segundos en el tiempo de la simulación, mientras que el protocolo DSDV inició la comunicación a los 25 segundos y la perdió a los 118 segundos. Pero en cuanto a eficiencia en el tiempo de entrega los papeles se invierten ya que el protocolo DSDV es el que mejor respondió ya que entre los 40 y 118 segundos mantuvo un throughput de 80 packets/TIL mientras que el protocolo AODV mantuvo su throughput casi todo el tiempo a 30 packets/TIL.

60

Jitter: Para la parte del Jitter podemos destacar que en el primer escenario la

diferencia favoreció al protocolo DSDV sobre el protocolo AODV, aunque esta diferencia fue mínima, ambas Jitter estuvieron entre 0 y 0.03 segundos. En el segundo escenario ocurrió algo similar donde el Jitter para el protocolo AODV osciló entre 0 y 0.16 segundos mientras que para el DSDV entre 0 y 0.14 segundos lo que indica un mejor rendimiento para el protocolo DSDV por tener una menor variación. En el tercer escenario se notó más la diferencia ya que el protocolo DSDV por ser proactivo determino la mejor ruta en cada cambio que tenía la red mientras que el protocolo AODV hasta una desconexión mantuvo la misma ruta lo que le costó en un mayor retardo. El protocolo AODV tuvo un Jitter de entre 0 y 0.2 segundos mientras que el protocolo AODV entre 0 y 0.1, en esta ocasión la naturaleza de ser proactivo favorece al protocolo DSDV frente al AODV y lo refleja en el Jitter donde en los tres escenarios siempre se mantuvo en un intervalo menor.

Paquetes perdidos: El número de paquetes perdidos favoreció al protocolo

DSDV fue menor en el primer escenario con respecto al protocolo AODV por una mínima diferencia. En el segundo escenario donde ahora eran los nodos quienes intervenían en la comunicación, DSDV tuvo una menor pérdida de paquetes por parte del nodo 0 y el nodo 1 figuras 4.14 y 4.15. también es debido a que como el protocolo AODV es el primero en establecer la comunicación pues la probabilidad de un menor número de paquetes perdidos aumenta, por otra parte la actualización constante de las tablas de enrutamiento de un protocolo proactivo como en este caso lo fue el protocolo DSDV permiten buscar siempre el mejor camino y en una red tan fluctuante en cuanto a movilidad disminuyen los paquetes perdidos, es por eso que en el tercer escenario el mayor número de paquetes los ofreció el protocolo AODV.

Escalabilidad: Como quinto punto tomaremos en cuenta la escalabilidad que

presentan cada uno de los protocolos, es decir, que tan bien o que tan mal responden frente al incremento de nodos en la red, se puede hacer una comparativa entre los dos protocolos comparando los primeros dos escenarios contra el tercero donde el número de nodos fue mayor y se puede concluir que frente a un aumento de nodos el que más se adapta es el protocolo DSDV como vimos al ser proactivo mantiene y actualiza sus tablas lo que conlleva la elección de un mejor camino cada vez a diferencia del protocolo AODV. Es por eso que cuando se utilizaron dos o tres nodos el protocolo AODV ofreció mejores resultados mientras que cuando el número de nodos aumenta el protocolo DSDV es mejor.

61

GLOSARIO

Algoritmo: Secuencia lógica de pasos que permite resolver problemas. Los algoritmos de seguridad son de cifrado de datos o de autenticación. Ad-hoc: En redes de comunicación, una red ad hoc es aquella (especialmente inalámbrica) en la que no hay un nodo central, sino que todos los dispositivos están en igualdad de condiciones. Ad hoc es el modo más sencillo para el armado de una red. Sólo se necesita contar con 2 placas o tarjetas de red inalámbricas (de la misma tecnología). Una vez instaladas en los PC se utiliza el software de configuración del fabricante para configurarlas en el modo ad-hoc, definiendo el identificador común que utilizarán (SSID). Bluetooth: Especificación industrial para Redes Inalámbricas de Área Personal (WPAN) que posibilita la transmisión de voz y datos entre diferentes dispositivos mediante un enlace por radiofrecuencia en la banda ISM de los 2,4 GHz. Broadcast: Se trata del modo de operación básico en un canal inalámbrico, ya que cada mensaje emitido por un nodo en un canal inalámbrico es recibido por todos sus vecinos. Cifrado: Aplicación de un algoritmo específico a datos para modificar la apariencia de éstos y convertirlos en incomprensibles para aquellos que no estén autorizados a ver la información. Cluster: Se aplica a los conjuntos de computadoras construidos mediante la utilización de hardwares comunes y que se comportan como si fuesen una única computadora. Dirección IP: Las direcciones IP de versión 4 tienen una longitud de 32 bits o 4 bytes. Este "espacio" de red se utiliza para designar un número de red, un número de subred opcional y un número de host. Los 32 bits están agrupados en cuatro octetos (8 bits binarios), representados por cuatro números decimales separados por puntos. La parte de la dirección utilizada para especificar el número de red, el de la subred y el del host se especifica mediante la máscara de subred. Encaminamiento: Ó enrutamiento, es el proceso de selección de caminos desde un origen hasta un destino dentro de una red. Firewall: Un router o servidor de acceso, o varios de ellos, designados como búfer entre cualquier red pública conectada y una red privada. Un router que actúe como firewall utilizará listas de acceso así como otros métodos para asegurarse de la seguridad de la red privada. Host: Equipo, como un PC u otro dispositivo informático como un servidor, asociado a una dirección IP individual y, opcionalmente, a un nombre. Nombre de cualquier dispositivo en una red TCP/IP que tenga una dirección IP. Asimismo, cualquier dispositivo de una red al que se pueda asignar una dirección. El término nodo incluye dispositivos como routers e impresoras que, normalmente, no se denominan hosts. Jitter: Variación en cuanto a la cantidad de latencia entre paquetes de datos que se reciben en un nodo.

62

Latencia: En redes informáticas de datos se denomina latencia a la suma de retardos temporales dentro de una red. Un retardo es producido por la demora en la propagación y transmisión de paquetes dentro de la red. Multicast: Se refiere a la transmisión de información de un nodo emisor a varios nodos destinos. Network: De su traducción del Inglés “Red”. Una red es un grupo de dispositivos de computación que comparten parte de un espacio de la dirección IP y no un host único. Una red está formada por varios "nodos" o dispositivos con dirección IP, a los que es posible referirse como hosts. Ruta estática: Ruta configurada explícitamente e introducida en la tabla de enrutamiento. Las rutas estáticas tienen preferencia ante las rutas elegidas por los protocolos de enrutamiento dinámico. Trafico: Es la cantidad de información originalmente en paquetes y mensajes que circulan a través de una red de datos. Throughput: Se define como la máxima taza de transferencia que se puede alcanzar en una transmisión entre elementos terminales de una red. Unicast: Referente a la transmisión de información de un nodo emisor a un único nodo receptor.

63

ACRÓNIMOS

ADSL: Asymmetric Digital Subscriber Line (Línea de suscriptor digital asimétrica).

AODV: Ad hoc On-demand Distance Vector.

ARP: Address Resolution Protocol (Protocolo de resolución de direcciones). Protocolo

TCP/IP de bajo nivel que asigna la dirección de hardware de un nodo (llamada dirección

MAC) a la dirección IP.

CDMA: Code División Múltiple Access (Acceso Múltiple por División de Código).

CSMA/CA: Carrier SEnse Múltiple Access, Collision Avoidance (Acceso Múltiple por

Detección de Portadora con Evasión de Colisiones).

DHCP: Dynamic Host Configuration Protocol (Protocolo de configuración dinámica de

hosts). Proporciona un mecanismo para asignar dinámicamente direcciones IP a hosts, a

fin de que las direcciones se puedan volver a utilizar cuando los hosts ya no las necesiten.

DNS: Domain Name System (Sistema o servicio de nombres de dominio). Servicio de

Internet que traduce nombres de dominios compuestos por letras, en direcciones IP

compuestas por números.

DSR: Dynamic Source Routing (Fuente de Enrutamiento Dinámico).

DSDV: Destination-Sequenced Distance-Vector (Destino Secuencial de Vector Distancia).

EE: Estado de Enlaces.

FTP: (File Transfer Protocol), Protocolo de transferencia de Archivos.

HTTP, HTTPS: Hypertext Transfer Protocol (Protocolo de transferencia de hipertexto),

Hypertext Transfer Protocol, Secure (Protocolo de transferencia de hipertexto seguro).

Protocolo utilizado por los exploradores y servidores web para transferir archivos como

archivos de texto o de gráficos.

IEEE: Institute of Electrical and Electronics Engineers (Instituto de Ingenieros Eléctricos y

Electrónicos).

IP: Protocolo de Internet. Los protocolos de Internet son la familia de protocolos de

sistema abierto (no de propiedad) más conocida del mundo ya que pueden utilizarse para

establecer una comunicación entre cualquier conjunto de redes interconectadas y sirven

tanto para comunicaciones WAN como LAN.

LAN: Local Area Network (Red de área local). Red que reside en una ubicación o

pertenece a una organización y que normalmente, aunque no siempre, utiliza protocolos

IP u otros protocolos de Internet. No se trata de Internet global.

64

LSP: Link State Packet (Paquete de estado de Enlaces).

MANET: Mobile Ad hoc Networks (Redes Ad hoc Móviles).

NAM: The Network Animation (Simulador de Redes).

NS-2: Network Simulator 2 (Simulador de Redes 2).

PAN: Personal Area Network (Red de Area Personal).

QoS: Quality of Service (Calidad de Servicio). Método que permite garantizar el ancho de

banda para tipos de tráfico especificados.

PRnet: Packet Radio Network (Red de Paquetes de Radio).

RERR: Route ERRor (Error de Ruta).

RIP: Routing Information Protocol (Protocolo de información de enrutamiento). Protocolo

de enrutamiento que utiliza el número de routers que un paquete debe atravesar para

llegar a destino, como valor métrico de enrutamiento.

RREP: Route REPly (Respuesta de Ruta).

RREQ: Route REQuest (Petición de Ruta).

TCP: (Transmission Control Protocol). Protocolo de nivel de transporte orientado hacia la

conexión que proporciona una transmisión dúplex de datos fiable.

TDMA: Time División Múltiple Access (Acceso Múltiple por División de Tiempo).

TTL: Time To Live (Tiempo de Vida) es el tiempo de vida de un mensaje o paquete dentro

de una red.

VD: Vector de Distancias.

WAN: Wide Area Network (Red de área ancha). Red que proporciona servicio a usuarios

de una amplia área geográfica y que, a menudo, utiliza dispositivos proporcionados por

portadoras comunes.

65

Bibliografia:

[1] Basagni S., Conti M., Stojmenovic I. (2004). Mobile Ad hoc Networking, IEEE

PRESS Ed. Wiley Interscience.

[2] Stallings W. (1997). Comunicaciones y redes de computadoras, Ed. Prentice

Hall

[3] Tanenbaum A. (2003). Redes de Computadoras, Ed. Prentice Hall

[4] Perkins C., Belding-Royer E., RFC 3561 (2003), Ad hoc On-Demand Distance Vector (AODV) Routing, recuperado de: http://www.cs.huji.ac.il/labs/danss/sensor/adhoc/routing/perkins_1997AODV.pdf [5] Perkins C., Bhagwat P. (Oct. 1994). Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, recuperado de [6] The network simulator http://www.isi.edu/nsnam/ns/ [7] Altman E., Jimenez T. (2003-2004). NS Simulator for beginners, Ed. Universidad de los Andes, Mérida, Venezuela and ESSI, Sophia-Antipolis, France

66

ANEXO Código de las simulaciones

Primer escenario # wrls1.tcl # Restablecimiento de la comunicación entre dos nodos # Definición de las opciones set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(ifq) Queue/DropTail/PriQueue ;# interface queue type set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# antenna model set val(ifqlen) 50 ;# max packet in ifq set val(nn) 2 ;# number of mobilenodes set val(rp) DSDV ;# routing protocol set val(x) 500 ;# X dimension of topography set val(y) 400 ;# Y dimension of topography set val(stop) 150 ;# time of simulation end set ns [new Simulator] set tracefd [open simple.tr w] set windowVsTime2 [open win.tr w] set namtrace [open simwrls.nam w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $val(x) $val(y) # establecimiento de la topografía set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) # # Creación de nn nodos móviles [$val(nn)] and attach them to the channel. # # configuración de los nodos $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \

67

-propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace ON for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Localización inicial de los nodos $node_(0) set X_ 250.0 $node_(0) set Y_ 240.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 350.0 $node_(1) set Y_ 240.0 $node_(1) set Z_ 0.0 # Generación de los movimientos $ns at 10.0 "$node_(0) setdest 100.0 240.0 10.0" $ns at 10.0 "$node_(1) setdest 400.0 240.0 10.0" $ns at 35.0 "$node_(0) setdest 250.0 240.0 10.0" $ns at 35.0 "$node_(1) setdest 350.0 240.0 10.0" # Establecer una comunicación TCP entre el nodo_(0) y el nodo_(1) set tcp [new Agent/TCP/Newreno] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns attach-agent $node_(0) $tcp $ns attach-agent $node_(1) $sink $ns connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns at 10.0 "$ftp start" # Imprimir el tamaño de la pantalla proc plotWindow {tcpSource file} { global ns set time 0.01 set now [$ns now] set cwnd [$tcpSource set cwnd_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotWindow $tcpSource $file" } $ns at 10.1 "plotWindow $tcp $windowVsTime2" # Definición del nodo inicial en nam for {set i 0} {$i < $val(nn)} { incr i } {

68

# 30 define el tamaño de los nodos $ns initial_node_pos $node_($i) 30 } # Informar a los nodos cuando la simulación termina for {set i 0} {$i < $val(nn) } { incr i } { $ns at $val(stop) "$node_($i) reset"; } # terminación del nam y de la simulación $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.01 "puts \"end simulation\" ; $ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace close $tracefd close $namtrace #Execute nam on the trace file exec nam simwrls.nam & exit 0 } $ns run Segundo escenario # escen_2.tcl # A 3-node example for ad-hoc simulation with AODV # Define options set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(ifq) Queue/DropTail/PriQueue ;# interface queue type set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# antenna model set val(ifqlen) 50 ;# max packet in ifq set val(nn) 3 ;# number of mobilenodes set val(rp) AODV ;# routing protocol set val(x) 500 ;# X dimension of topography set val(y) 400 ;# Y dimension of topography set val(stop) 150 ;# time of simulation end set ns [new Simulator] set tracefd [open simple.tr w] set windowVsTime2 [open win.tr w] set namtrace [open simwrls.nam w]

69

$ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $val(x) $val(y) # set up topography object set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) # # Create nn mobilenodes [$val(nn)] and attach them to the channel. # # configure the nodes $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace ON for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Provide initial location of mobilenodes $node_(0) set X_ 100.0 $node_(0) set Y_ 240.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 500.0 $node_(1) set Y_ 240.0 $node_(1) set Z_ 0.0 $node_(2) set X_ 300.0 $node_(2) set Y_ 50.0 $node_(2) set Z_ 0.0 # Generation of movements $ns at 15.0 "$node_(2) setdest 300.0 285.0 10.0"

70

# Set a TCP connection between node_(0) and node_(1) set tcp [new Agent/TCP/Newreno] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns attach-agent $node_(0) $tcp $ns attach-agent $node_(1) $sink $ns connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns at 10.0 "$ftp start" # Printing the window size proc plotWindow {tcpSource file} { global ns set time 0.01 set now [$ns now] set cwnd [$tcpSource set cwnd_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotWindow $tcpSource $file" } $ns at 10.1 "plotWindow $tcp $windowVsTime2" # Define node initial position in nam for {set i 0} {$i < $val(nn)} { incr i } { # 30 defines the node size for nam $ns initial_node_pos $node_($i) 30 } # Telling nodes when the simulation ends for {set i 0} {$i < $val(nn) } { incr i } { $ns at $val(stop) "$node_($i) reset"; } # ending nam and the simulation $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.01 "puts \"end simulation\" ; $ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace close $tracefd close $namtrace #Execute nam on the trace file exec nam simwrls.nam & exit 0 } #Call the finish procedure after 5 seconds of simulation time $ns run

71

Tercer escenario

# escen3a.tcl # Definir las opciones set val(chan) Channel/WirelessChannel ;# tipo de canal set val(prop) Propagation/TwoRayGround ;# modelo de radio propagación set val(netif) Phy/WirelessPhy ;# tipo de interfaz de red set val(mac) Mac/802_11 ;# tipo de MAC set val(ifq) Queue/DropTail/PriQueue ;# tipo de cola set val(ll) LL ;# tipo de capa de enlace set val(ant) Antenna/OmniAntenna ;# modelo de antena set val(ifqlen) 50 ;# longitud máxima de paquetes set val(nn) 5 ;# número de nodos móviles set val(rp) DSDV ;# protocolo de encaminamiento Set val(x) 500 ; # X dimensión topográfica Set val (y) 400 ; # Y dimensión topográfica Set Val (stop) 150 ; # time of simulation end Set ns [new Simulator] Set tracefd [open simple.tr w] Set windowVsTime2 [open win.tr w] Set namtrace [open simwrls.nam w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $Val(x) $Val(y) # establecer el objeto topográfico set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) # # Crear nn nodos móviles [$val(nn)] y relacionarlos al canal. # # Configuration de los nodos $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \

72

-agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace ON for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Indicar la posición inicial de los nodos $node_(0) set X_ 5.0 $node_(0) set Y_ 5.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 490.0 $node_(1) set Y_ 285.0 $node_(1) set Z_ 0.0 $node_(2) set X_ 150.0 $node_(2) set Y_ 240.0 $node_(2) set Z_ 0.0 $node_(3) set X_ 250.0 $node_(3) set Y_ 240.0 $node_(3) set Z_ 0.0 $node_(4) set X_ 100.0 $node_(4) set Y_ 70.0 $node_(4) set Z_ 0.0 # Generación de los movimientos $ns at 10.0 "$node_(0) setdest 250.0 250.0 10.0" $ns at 15.0 "$node_(1) setdest 45.0 285.0 10.0" $ns at 110.0 "$node_(0) setdest 480.0 300.0 10.0" $ns at 70.0 "$node_(3) setdest 180.0 30.0 10.0" # Establecer una coneccion TCP entre el nodo 0 y 1 set tcp [new Agent/TCP/Newreno] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns attach-agent $node_(0) $tcp $ns attach-agent $node_(1) $sink $ns connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns at 10.0 "$ftp start" # Imprimir el tamaño de la ventana

73

proc plotWindow {tcpSource file} { global ns set time 0.01 set now [$ns now] set cwnd [$tcpSource set cwnd_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotWindow $tcpSource $file" } $ns at 10.1 "plotWindow $tcp $windowVsTime2" # Define la posición inicial en NAM for {set i 0} {$i < $val(nn)} { incr i } { # 30 define el tamaño de nodos para NAM $ns initial_node_pos $node_($i) 30 } # Informa a los nodos cuando la simulación ha terminado for {set i 0} {$i < $val(nn) } { incr i } { $ns at $val(stop) "$node_($i) reset"; } # Terminacion de NAM y de la simulacion $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.01 "puts \"end simulation\" ; $ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace close $tracefd close $namtrace #Ejecuta nam en el archive traza exec nam simwrls.nam & exit 0 } #Llamar a la terminación después de 5 segundos de tiempo de $ns run