escuela superior de ingenierosbibing.us.es/proyectos/abreproy/12241/fichero/memoria.pdf · escuela...

Escuela Superior de Ingenieros

Ingeniería de Telecomunicación

Departamento de Ingeniería de Sistemas y

Automática

“Implementación del protocolo de encaminamiento AeroRP con

la herramienta Click Modular Router”

Proyecto Fin de Carrera

Autor: Lorena Otero Ramos Tutor: Dr. Anibal Ollero Baturone

Septiembre 2014

2

Implementación del protocolo de encaminamiento Lorena Otero Ramos AeroRP con la herramienta Click Modular Router

Acta Título: Implementación del protocolo de encaminamiento AeroRP con la herramienta Click Modular Router. Autor: Lorena Otero Ramos Tutor: Dr. Anibal Ollero Baturone El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Secretario: Vocal: Acuerdan otorgarle la calificacion de:

Sevilla, a de de 2014

3


Agradecimientos

Parece que fue ayer mi primer dia de clase en la ESI, y aquí estoy redactando mi Proyecto Fin de Carrera... ¿quién me lo iba a decir? Para mí este proyecto pone punto y final a una etapa de mi vida y abre la puerta de otra. El camino recorrido no ha sido fácil, he experimentado una mezcla de sentimientos, a veces de rabia e impotencia por no obtener los resultados esperados después de tanto esfuerzo y dedicación, en esos momentos me sentía como si pedaleara en una cuesta arriba llena de baches que no me dejaban avanzar, pero no todo ha sido malo, también he tenido sentimientos de alegría y satisfacción al ver como poco a poco iba llegando este ansiado momento. En el plano personal, agradecer a mis padres, Miguel Ángel y María Rosa, por todos los esfuerzos y sacrificios que han tenido que hacer para que pueda llegar a ser la persona que soy hoy en día, por su apoyo incondicional, su confianza en mí y su comprensión cuando más los he necesitado. Porque mis logros serán los vuestros, no hay palabras para agradecer todo lo que habéis y aún seguís haciendo por mí. También agradecer a Miguel Ángel y a Cristina, por la inmensa suerte que he tenido de que en esta gran rifa que es la vida me tocaran como hermanos. A mi familia en general, abuela, tios, primos... por estar siempre ahí. También agradecer especialmente a Fran, por ser tan comprensivo conmigo y ayudarme a no tirar la toalla en tantos momentos de agobio, por ser mi compañero de batalla y luchar siempre desde la primera línea a mi lado, y por entender de mí lo que otros no entienden y darme aliento cuando a veces me ahogaba. A mis amigas, por sacarme una sonrisa en los momentos tristes, por no haberme dejado que me rindiera nunca y por confiar en que sería capaz de llegar hasta aquí. En general a Chari, Nuria, Ana R., Ana C., Elvira, Tamara, María... pero en especial a Ángela por ser una amiga incondicional desde pequeña y estar siempre a mi lado cuando la he necesitado. A los amigos de la carrera, con los que he pasado tantas y tantas horas de estudio, en especial a Fernando, Antonio, Issam... gracias por hacer amenos los días intensivos de biblioteca y por siempre tener una palabra de ánimo. A mis amigos de Brasil, por acompañarme en la mejor experiencia tanto personal como profesional que he tenido, porque en un año habéis pasado a formar parte esencial de mi vida... Sandra, Raquel, Carlos, Carolina... Por último, agradecer a Catec por darme la oportunidad de realizar este proyecto con ellos, a Paco Alarcón por demostrarme ser mi amigo estando ahí en los buenos pero sobre todo en los malos momentos, y en especial a mi tutor, Paco Cuesta, por depositar su confianza en mí y siempre prestarme su ayuda cuando la he necesitado dedicándome así gran parte de su tiempo, ha sido un placer trabajar contigo. Sin todos vosotros nada de esto hubiera sido posible, simplemente gracias.

4


Índice

CAPÍTULO 1: Introducción ..................................................................................................... 11

1.1- Motivación del proyecto ............................................................................................. 11

1.2- Objetivos del proyecto ............................................................................................... 12

1.3- Contenido de la memoria ........................................................................................... 12

CAPÍTULO 2: Estado del arte ................................................................................................. 14

2.1- Definición redes MANET ............................................................................................. 14

2.1.1- Aplicaciones ......................................................................................................... 15

2.1.2- Ventajas y desventajas ......................................................................................... 16

2.2- Clasificación de los protocolos de enrutamiento en redes MANET ........................... 17

2.2.1- Según el mecanismo de descubrimiento de ruta ................................................. 18

2.2.2- Según la estrategia de encaminamiento .............................................................. 19

2.2.3- Según la estructura de la red ................................................................................ 20

2.2.3.1- Protocolos basados en la topología ............................................................... 20

2.2.3.2- Protocolos basados en la geografía ............................................................... 21

CAPÍTULO 3: Protocolo de enrutamiento AeroRP ................................................................. 23

3.1- Funcionamiento básico del protocolo AeroRP ............................................................ 24

3.1.1- Descubrimiento de vecinos .................................................................................. 24

3.1.2- El reenvío de los datos ......................................................................................... 25

3.1.2.1- El algoritmo de reenvio de datos ................................................................... 26

CAPÍTULO 4: Herramienta utilizada en el desarrollo del proyecto: Click Modular Router .... 30

4.1- Introducción a Click Modular Router .......................................................................... 30

4.2- Arquitectura ............................................................................................................... 31

4.2.1- Paquetes en Click Modular Router ....................................................................... 32

4.3- Entornos de ejecución ................................................................................................ 34

4.3.1- Nivel del kernel ..................................................................................................... 34

4.3.2- Nivel de usuario .................................................................................................... 35

4.3.3- Entorno de simulador ........................................................................................... 35

4.3.4- SMP Click .............................................................................................................. 36

5


4.4- Fichero de configuración ............................................................................................ 36

4.4.1- Ejemplo grafo archivo de configuración Click ....................................................... 37

4.5- Programación de elementos ....................................................................................... 38

CAPÍTULO 5: Implementación del protocolo AeroRP y su integración con Click Modular

Router ................................................................................................................................... 39

5.1- Configuración del entorno .......................................................................................... 39

5.2- División en elementos de Click Modular Router ......................................................... 39

5.2.1- Elemento AERORPGPSUDPTable .......................................................................... 40

5.2.2- Elemento AERORPCheckRange............................................................................. 41

5.2.3- Elemento AERORPRoutetable .............................................................................. 41

5.2.4- Elemento AERORPBeaconGenerator .................................................................... 43

5.2.5- Elemento AERORPNeighborsTable ....................................................................... 44

5.2.6- Elemento AERORPBuffer ...................................................................................... 45

5.3- Unión de los elementos de Click Modular Router ...................................................... 45

5.4- Fichero de cabecera .................................................................................................... 46

5.4.1- Cabecera AERORP y sus opciones......................................................................... 46

5.5- Fichero fuente ............................................................................................................ 48

5.5.1- Tabla de vecinos ................................................................................................... 48

5.5.2- Buffer de espera ................................................................................................... 49

CAPÍTULO 6: Evaluación de la implementación .................................................................... 51

6.1- Introducción al entorno de pruebas ........................................................................... 51

6.1.1- Descripción de las máquinas virtuales.................................................................. 51

6.1.2- Control en la realización de las pruebas ............................................................... 53

6.1.2.1- Sincronización temporal de las máquinas virtuales ....................................... 53

6.1.2.2- Generador de posiciones ............................................................................... 53

6.1.2.3- Recopilación de paquetes enviados y recibidos. ............................................ 54

6.2- Pruebas realizadas y resultados .................................................................................. 54

6.2.1- Primer experimento: medida del número de paquetes perdidos ........................ 55

6.2.1.1- Prueba 1: En función del rango de alcance entre nodos. ............................... 55

6.2.1.2 - Prueba 2: En función de la velocidad ............................................................ 63

6.2.1.3- Prueba 3: En función del número de nodos ................................................... 70

6.2.1.4- Prueba 4: En función del número de nodos y de la velocidad ....................... 86

6


CAPÍTULO 7: Conclusiones y líneas de trabajo futuras ........................................................ 102

7.1- Conclusiones ............................................................................................................. 102

7.2- Líneas de trabajo futuras .......................................................................................... 103

Referencias ......................................................................................................................... 104

Apéndices ............................................................................................................................ 105

APÉNDICE A: Manual de instalación ................................................................................ 105

APÉNDICE B: Ejecución de la implementación ................................................................. 108

APÉNDICE C: Elementos utilizados de la herramienta Click Modular Router y herramientas

utilizadas en la implementación ...................................................................................... 116

APÉNDICE D: Archivo de configuración y grafo de los elementos de la implementación 127

APÉNDICE E: Fichero de cabecera .................................................................................... 131

APÉNDICE F: Contenido del CDROM ................................................................................ 133

7


Índice de figuras

Figura 1. Ejemplo de una red móvil ad-hoc. .......................................................................... 15

Figura 2: Ejemplo de una red MANET en situaciones de emergencias y operaciones de

rescate. ................................................................................................................................. 15

Figura 3. Ejemplo de una red MANET en situaciones militares. ............................................ 16

Figura 4. Clasificación de protocolos de encaminamiento MANET según el mecanismo de

descubrimiento de ruta. ........................................................................................................ 19

Figura 5. Arquitectura plana. ................................................................................................ 20

Figura 6. Arquitectura jerárquica. ......................................................................................... 21

Figura 7. Variantes de reenvio geográfico. ............................................................................ 22

Figura 8. Clasificación de protocolos de encaminamiento MANET según la estructura de red.

.............................................................................................................................................. 22

Figura 9. Ejemplo del algoritmo de reenvío de datos. ........................................................... 27

Figura 10. Ejemplo TTI negativo. ........................................................................................... 28

Figura 11. Configuración Click Router. .................................................................................. 31

Figura 12. Funcionamiento de las conexiones push y pull. .................................................. 33

Figura 13. Puertos push, pull y agnostic. .............................................................................. 33

Figura 14. Ejemplo de la configuración de un router IP. ....................................................... 37

Figura 15. Elemento AERORPGPSUDPTable .......................................................................... 40

Figura 16. Elemento AERORPCheckRange ............................................................................. 41

Figura 17. Elemento AERORPRouteTable .............................................................................. 41

Figura 18. Elemento AERORPBeaconGenerator .................................................................... 43

Figura 19. Elemento AERORPNeighborsTable ....................................................................... 44

Figura 20. Elemento AERORPBuffer ...................................................................................... 45

Figura 21. Campos cabecera AeroRP ..................................................................................... 46

Figura 22. Campos cabecera AeroRP opción datos ............................................................... 47

Figura 23. Campos cabecera AeroRP opción baliza ............................................................... 47

Figura 24. Formato mensaje UDP que genera el nodo gestión. ............................................ 54

Figura 25. Formato mensaje UDP que genera la aplicación del nodo origen. ....................... 54

Figura 24. Elemento FromDevice ........................................................................................ 116

Figura 25. Elemento Classifier ............................................................................................. 116

8


Figura 26. Elemento CheckIPHeader ................................................................................... 117

Figura 27. Elemento MarkIPHeader .................................................................................... 118

Figura 28. Elemento Discard ............................................................................................... 118

Figura 29. Elemento IPClassifier .......................................................................................... 119

Figura 30. Elemento IPFilter ............................................................................................... 119

Figura 31. Elemento CheckUDPHeader ............................................................................... 120

Figura 32. Elemento EtherEncap ......................................................................................... 121

Figura 33. Elemento Queue ................................................................................................. 121

Figura 34. Elemento ToDevice ............................................................................................. 122

Figura 35. Elemento FromHost ........................................................................................... 122

Figura 36. Elemento ARPResponder .................................................................................... 123

Figura 37. Elemento ToHost ................................................................................................ 123

Figura 38. Elemento Strip .................................................................................................... 123

Figura 39. Diagrama del archivo de configuración .............................................................. 130

9


Índice de tablas

Tabla 1. Paquetes perdidos con 3 nodos intermedios moviéndose a velocidad constante de

0.1 m/s. ................................................................................................................................. 61


1 m/s. .................................................................................................................................... 69


0.1 m/s. ................................................................................................................................. 77


0.1 m/s. ................................................................................................................................. 85


1 m/s. .................................................................................................................................... 92


1 m/s. .................................................................................................................................. 100

10


Índice de gráficas

Gráfica 1. Paquetes perdidos por 3 nodos intermedios a una velocidad constante de 0.1 m/s

en función del rango de alcance ........................................................................................... 62

Gráfica 2. Paquetes enviados al destino por cada nodo intermedio en función de la distancia

AERORP_R. ............................................................................................................................ 63

Gráfica 3. Comparativa de paquetes perdidos de 3 nodos moviéndose a una velocidad de

0.1 m/s frente a 3 nodos moviéndose a una velocidad de 1m/s........................................... 69

Gráfica 4. Paquetes enviados al destino por cada nodo intermedio a v = 1m/s en función de

la distancia AERORP_R. ......................................................................................................... 70

Gráfica 5. Paquetes enviados al destino por cada nodo intermedio a v= 0.1m/s en función

de la distancia AERORP_R. .................................................................................................... 77

Gráfica 6. Comparativa de paquetes perdidos de varios nodos moviéndose a v=0.1m/s. .... 85

Gráfica 7. Paquetes enviados al destino por cada nodo intermedio a v= 0.1m/s en función

de la distancia AERORP_R. .................................................................................................... 86

Gráfica 8. Comparativa de paquetes perdidos de varios nodos moviéndose a v=1m/s. ..... 100

Gráfica 9. Paquetes enviados al destino por cada nodo intermedio a v= 1m/s en función de

la distancia AERORP_R. ....................................................................................................... 101

11


1.1- Motivación del proyecto

Internet se ha convertido en uno de los medios de difusión de información más importantes del mundo y las personas lo utilizan, en su vida cotidiana y profesional, como canal de comunicación, como sistema de colaboración masiva o simplemente como distracción. En los últimos años, la proliferación de dispositivos móviles cada vez más potentes (ordenadores portátiles, PDAs, smartphones, etc.) posibilita la integración de éstos con Internet. Sin embargo, la característica de movilidad que acompaña a este tipo de dispositivos provoca el nacimiento de nuevos retos tecnológicos.

Una red móvil ad-hoc ó MANET (Mobile Ad hoc NETwork) es un tipo de red inalámbrica, se trata de un conjunto de nodos móviles que se comunican entre sí a través de enlaces inalámbricos (wireless).Al contrario de las redes convencionales, una red MANET no necesita la existencia de una infraestructura previa ya que cada nodo se apoya en los demás para conseguir comunicarse con otro creando la llamada comunicación multi-salto.

Este tipo de redes tienen una larga lista de características que han despertado un importante interés en los investigadores durante los últimos años. Entre estas características se encuentra su bajo coste, la facilidad a la hora de crear una red puesto que no requieren infraestructuras, la flexibilidad y el soporte de movilidad. Sin embargo, algunas de las siguientes características que convierten a las MANETs en una solución interesante en determinados escenarios, imponen una serie de restricciones que dificultan su diseño e implementación.

Este tipo de redes tiene varios inconvenientes que una red convencional no presenta:

- La topología de este tipo de redes puede cambiar rápidamente y de una forma

impredecible, por lo que el período de validez de las rutas suele ser corto.

- Se deben tener en cuenta los recursos limitados de los nodos, ya que normalmente una red ad hoc estará formada por dispositivos alimentados por una batería como sensores, teléfonos móviles, PDAs, etc.

- La utilización de un medio compartido para la transmisión de los paquetes eleva el

índice de colisiones y limita el ancho de banda.

CAPÍTULO 1: Introducción

12


- Son más propensas a las amenazas de seguridad que las redes fijas cableadas. Posee una mayor posibilidad de espionaje, de falsificación y de ataques de negación de servicio.

1.2- Objetivos del proyecto

El proyecto tiene como objetivo principal la implementación de un protocolo de encaminamiento geográfico AeroRP(Aeronautical Routing Protocol)que permita el encaminamiento de paquetes basándose en la posición geográfica de los nodos que forman la red, esto permite dar solución a los problemas que se crean en una red MANET debido a su topología dinámica.

Con la implementación del protocolo de encaminamiento geográfico se pretende poder realizar el encaminamiento de paquetes dirigidos a un único nodo que se encuentra en una determinada posición geográfica. El encaminamiento del paquete se debe realizar en función de la posición geográfica de los nodos de la red. Vamos a realizar una serie de pruebas para comprobar el correcto funcionamiento de dicho protocolo.

Para facilitar la implementación de dicho protocolo haremos uso de la herramienta Click Modular Router [1], un software específico para la gestión y manipulación de paquetes en la red.

En el apéndice A, se incluyen los pasos a seguir para instalar esta herramienta.

1.3- Contenido de la memoria

La memoria se estructura en 7 capítulos y 6 anexos:

El capítulo1 sirve de introducción al proyecto. Se divide en tres apartados donde se

detallan las motivaciones que justifican la realización del proyecto, los objetivos

planteados que se pretenden cumplir y, el apartado actual, que presenta cómo se

estructura la memoria.

El capítulo 2 es el estado del arte, en este capítulo haremos una pequeña

introducción a las redes MANET y a los protocolos de encaminamiento más

utilizados en este tipo de redes.

13


El capítulo 3 describe el funcionamiento del protocolo AeroRP, en el que está

centrado nuestro proyecto.

En el capítulo 4 titulado “Herramienta utilizada en el desarrollo del proyecto: Click

Modular Router”, se presenta la herramienta básica que se ha utilizado para

realizar la implementación del protocolo de encaminamiento geográfico, donde se

describen los aspectos más importantes para entender el funcionamiento básico

de la herramienta.

En el capítulo 5 titulado “Implementación del protocolo AeroRP y su integración

con Click Modular Router”, se muestra cómo se ha dividido la implementación en

los diferentes elementos y se explica en detalle cada uno de ellos, y también se

explica brevemente el fichero fuente y de cabecera empleado en la programación

del código que desarrolla este protocolo.

El capítulo 6, “Evaluación de la implementación“, muestra las pruebas realizadas

sobre la implementación que permiten verificar el correcto funcionamiento del

nuevo modelo del protocolo de encaminamiento AeroRP y obtener las

conclusiones de la elaboración del proyecto.

El capítulo 7, “Conclusiones y trabajos futuros”, repasa los objetivos del proyecto y

analiza su cumplimiento. Es una valoración de los resultados obtenidos. Por otro

lado, también se deja una puerta abierta a posibles ampliaciones futuras del

proyecto.

En los apéndices, se muestra el manual de instalación de la implementación, un

pequeño manual de ejecución, una breve explicación de las herramientas y los

elementos empleados en la implementación del proyecto que ya estaban

implementados en la propia herramienta Click y las herramientas utilizadas en la

realización del proyecto, el archivo de configuración y el esquema de elementos de

la implementación, una descripción del contenido del CDROM con el código de la

implementación.

14


2.1- Definición redes MANET

Una red móvil ad-hoc o red MANET (Mobile Ad-hoc NETwork) [2][3] es una red

inalámbrica descentralizada formada por nodos móviles que se auto-organizan para poder

comunicarse entre ellos sin necesidad de que intervenga ningún tipo de infraestructura

previa desplegada (como pudiera ser una antena de una red de telefonía o un punto de

acceso de una WLAN) y que se interconectan entre sí a través de enlaces inalámbricos de

comunicación, los cuales pueden ser de uno o de múltiples saltos.

Cada nodo que forma una red MANET es simultáneamente un host y un router, ya

que puede tanto ejecutar aplicaciones que hacen uso de la red, como participar en el

encaminamiento de paquetes hacia otros nodos de la red. El mayor reto de este tipo de redes

es, por lo tanto, mantener la información acerca de la topología de la red correcta y

actualizada en todos los nodos a medida que éstos se van desplazando.

Considerando que los nodos móviles tienen un rango de transmisión limitado, los nodos puestos a grandes distancias se comunican a través de caminos a saltosmúltiples, es decir, a través de más nodos antes de alcanzar al destinatario.Por eso en las MANET los nodos colaboran para enviarse los paquetes de datos enrutándolos salto a salto.

La forma básica como opera una red móvil ad-hoc se ilustra mediante la Figura1,

donde el nodo A se puede comunicar directamente a través de un solo salto con el nodo B, el nodo C y el nodo D. Pero para que el nodo A pueda comunicarse con el nodo E, el nodo C debe actuar como intermediario entre A y E, transmitiendo la información entre ellos.

Por lo tanto la comunicación entre los nodos A y E se basa en una comunicación de

múltiples saltos:

CAPÍTULO 2: Estado del

arte

15


Figura 1. Ejemplo de una red móvil ad-hoc.

2.1.1- Aplicaciones

Entre los escenarios reales en los que éste tipo de redes son útiles destacan:

- En el caso de un accidente, catástrofe natural u otras situaciones de emergencia, en las que los canales normales de comunicación (redes cableadas, teléfonos móviles) no son viables. Las redes MANET permiten a los equipos médicos y de salvamento estar interconectados mientras se mueven por el escenario.

Figura 2: Ejemplo de una red MANET en situaciones de emergencias y operaciones de rescate.

- En situaciones de tráfico rodado urbano, en un escenario en el que los vehículos están equipados con sistemas de conexión inalámbrica que les permiten comunicarse entre ellos y con unidades estáticas que les ofrecen información sobre el estado del tráfico.

- En aplicaciones militares, donde una configuración de red descentralizada es una

ventaja operativa o incluso una necesidad.

16


Figura 3. Ejemplo de una red MANET en situaciones militares.

- Las redes MANET también pueden utilizarse para extender la cobertura de las redes inalámbricas actuales, por ejemplo en una reunión de trabajo para interconectarse vía bluetooth o por infrarrojos. - Redes en áreas remotas o muy escasamente pobladas, donde no salga a cuenta instalar redes con infraestructuras.

2.1.2- Ventajas y desventajas

A continuación se describen algunas características de una red MANET:

Topología dinámica. Los nodos se pueden mover arbitrariamente haciendo que algunos enlaces se destruyan y otros se creen cuando un nodo se acerque a otros que antes tenía fuera de su alcance, la topología de la red puede cambiar rápida y aleatoriamente en tiempos impredecibles. La rotura de enlaces debida a la movilidad de los nodos provoca que las rutas desde un origen hacía un destino puedan variar con mucha más frecuencia. Este aspecto es de gran influencia para el diseño de los protocolos de enrutamiento.

Instalación rápida. El nivel de la flexibilidad para la creación de las redes ad-hoc es alto, puesto que no requieren ninguna instalación o infraestructura previa y, así, pueden ser montadas y desmontadas en poco tiempo.

Coste. Pueden ser más económicas, debido a que se reducen los costes de la infraestructura fija.

Operación en forma distribuida. El término distribuido hace referencia a que en una red MANET, normalmente los nodos tienen un conocimiento local sobre su entorno. Es decir, cada nodo sólo conoce la información sobre los nodos vecinos que se encuentran dentro de su radio de transmisión y no tiene un conocimiento global de la red.

17


Ancho de banda limitado. El ancho de banda disponible en las redes MANET (redes inalámbricas) es menor comparado con el ancho de banda disponible en las redes de infraestructura cableada.

Seguridad física limitada. El efecto de una alta tasa de error de bits, es decir, la transmisión de información errada, es más significativo en una red móvil ad-hoc de múltiples saltos, ya que el agregado de todos los errores en los enlaces afecta significativamente la calidad de la información recibida.

Limitación de consumo energético. Los nodos en una MANET requieren de una batería para obtener la energía que asegure su funcionamiento. Por lo tanto la energía es uno de los recursos que se busca optimizar con el fin de limitar el consumo de la potencia.

2.2- Clasificación de los protocolos de enrutamiento en redes MANET

El encaminamiento es el mecanismo que usan los nodos de una red para reenviar los paquetes desde el origen hasta su destino usando la ruta más eficiente de forma que los paquetes sean entregados al destino de manera confiable.

El concepto de encaminamiento básicamente comprende dos actividades. En primer

lugar, determinar los caminos óptimos y, en segundo lugar, transferir los grupos de paquetes de información a través de la red. Los algoritmos utilizan varias métricas para calcular el mejor camino para que los paquetes lleguen a su destino. Estas métricas son medidas estándar como podría ser el número de saltos que son usados por el algoritmo para determinar el camino óptimo. El proceso para determinar el camino inicializa y mantiene tablas de encaminamiento que contienen la información total de cada ruta. La información que se almacena para cada ruta varía de un algoritmo a otro.

Los objetivos de los protocolos de encaminamiento son:

- Descubrir las mejores rutas en cada momento.

- Generar tablas de vecinos.

- Minimizar el número de entradas en la tabla.

- Responder rápidamente a los cambios de la topología.

- Utilizar enlaces tanto unidireccionales como bidireccionales.

18


- Presentar múltiples rutas para evitar la congestión, para ello hay que proveer una

forma de establecer y mantener las rutas a pesar de posibles caminos rotos donde tendrán

que encontrar una ruta alternativa.

La clasificación de los protocolos de encaminamiento de las redes MANET [4] [5] se

puede hacer según varios criterios, veremos los más importantes a continuación.

2.2.1- Según el mecanismo de descubrimiento de ruta

Protocolos Proactivos:

Cada nodo guarda información de cómo llegar a cualquier nodo de la red en una tabla de rutas y a su vez intercambia ésta información con sus nodos vecinos.

Se busca mantener actualizadas las tablas de encaminamiento, a través del envío de mensajes de forma periódica, debido a los continuos cambios en la red. Sin embargo, para mantener una actualización permanente de las rutas, se introduce una sobrecarga importante de la red con los mensajes de control que afectan a la utiización del ancho de banda y al uso de la energía. Dentro de ésta categoria se pueden incluir los siguientes protocolos: • Optimized Link State Routing Protocol (OLSR). • Distance-Sequenced Distance-Vector (DSDV).

• Aeronautical Routing Protocol (AeroRP).

Protocolos Reactivos:

No mantienen la información de encaminamiento o la actividad de encaminamiento en los nodos de la red si no hay comunicación. Calculan la ruta a un destino específico solamente bajo demanda, así que una tabla de encaminamiento que contiene todos los nodos como entradas no tiene que ser mantenida en cada nodo. Cuando una fuente desea enviar un mensaje a un destino, invoca un mecanismo del descubrimiento de ruta para encontrar la trayectoria al destino. El descubrimiento de ruta por lo general se produce inundando toda la red con paquetes de petición de ruta. Éstos protocolos no son adecuados debido al retardo empleado en la búsqueda de las rutas y porque éstas rutas pueden no ser válidas durante el tiempo suficiente en una red altamente dinámica. En cambio, tienen la ventaja de utilizar eficientemente el ancho de

19


banda de la red, debido a que busca las rutas exclusivamente cuando es necesario enviar algún paquete. Dentro de ésta categoria se encuentran los siguientes protocolos: • Ad-hoc On-Demand Distance-Vector (AODV). • Dynamic Source Routing (DSR).

Protocolos híbridos: Utilizan una combinación de los dos tipos anteriores. Se mantiene una filosofía

proactiva en un ámbito local y reactiva a nivel más global.

Dentro de ésta categoria se encuentra el siguiente protocolo:

Zone Routing Protocol (ZRP).

Figura 4. Clasificación de protocolos de encaminamiento MANET según el mecanismo de

descubrimiento de ruta.

2.2.2- Según la estrategia de encaminamiento

Los nodos manejan tablas de enrutamiento, en las que aparece la ruta que deben

seguir los paquetes que tienen como destino un nodo determinado de la red.

Encaminamiento salto a salto(hop by hop):

Se basa en que cada nodo no tiene que conocer la ruta completa hasta el destino, sino que sólo debe saber cuál es el siguiente nodo al que tiene que mandar el paquete. Por tanto, la información de ruta no va incluida en los paquetes de datos.

Protocolos de enrutamiento de redes MANET

Proactivo

OLSR DSDV AeroRP

Reactivo

AODV DSR

Híbrido

ZRP

20


Encaminamiento en origen(Source Routing):

La ruta se establece por el origen al enviar el paquete. Cada paquete lleva un campo que indica la ruta que debe seguir hasta llegar al destino, y los nodos sólo se dedican a reenviar los paquetes por esas rutas ya especificadas. Así pues, son los sistemas finales los que tienen las tablas de enrutamiento y no se hace necesaria la consulta o existencia de tablas de enrutamiento en los nodos intermedios.

2.2.3- Según la estructura de la red

2.2.3.1- Protocolos basados en la topología Los protocolos de encaminamiento basados en la topología tienen la desventaja de tener una sobrecarga alta debido a los mensajes de control entre los nodos.

La topología de una red móvil ad-hoc juega un papel muy importante en el desempeño de los algoritmos de control empleados en la red para los propósitos de sincronización de las transmisiones, el enrutamiento y para realizar broadcasting.

En las redes MANET se pueden distinguir dos tipos de topologías fundamentales:

Topología plana: Todos los nodos de la red envían y responden a los mensajes de control del mismo modo. Esta topología funciona adecuadamente cuando las redes son de un tamaño relativamente pequeño. En este caso el enrutamiento se puede llevar a cabo de una manera óptima y el consumo de potencia es bajo. Un ejemplo de protocolo que utiliza topología plana es: AODV, DSR y DSDV.

Figura 5. Arquitectura plana.

Topología jerárquica: Los nodos se organizan en grupos y en cada grupo existe un nodo de puerta de enlace que tiene la obligacion de comunicarse con el nodo de puerta de enlace de otro grupo distinto, el problema de esta topología es que la

21


arquitectura se rompe cuando falla el nodo de puerta de enlace. Por lo que estos nodos juegan un papel fundamental para el buen funcionamiento de la red. Un ejemplo de protocolo que utiliza la topología jerárquica es: HSR y LANMAR.

Figura 6. Arquitectura jerárquica.

2.2.3.2- Protocolos basados en la geografía En los protocolos de encaminamiento basados en la geografía todos los nodos conocen su posición geográfica con ayuda de algún sistema de posicionamiento, como por ejemplo el Sistema de Posicionamiento Global (GPS) por satélite, y utilizan éstas coordenadas GPS para determinar el siguiente salto. Estos protocolos tienen como ventaja que crean las decisiones de reenvío en función de algunos algoritmos para mover el paquete lo más cercano del destino posible basándose en la posición del destino y los nodos adyacentes. La desventaja es el coste adicional, la complejidad y la energía usada para que los nodos estén siempre localizados. Estos protocolos se descomponen en diferentes decisiones de reenvio geograficas: • MFR (Most Forward with Radius r): es el más intuitivo y reenvía el paquete hacia el nodo que hace que el avance hacia el destino sea mayor. • NFP (Nearest with Forward Progress): reenvía el paquete al nodo que está más cerca del nodo actual y del destino. NFP tiene como objetivo reducir la colisión de paquetes, haciendo saltos más cortos en las decisiones de encaminamiento. • CR (Compass Routing): elige el nodo que está más cerca de una línea imaginaria trazada entre el mismo y el destino y por tanto considerando más la trayectoria de los nodos que cualquier otro factor.

22


En la siguiente figura podemos ver un ejemplo gráfico:

Figura 7. Variantes de reenvio geográfico.

Entre todos los protocolos de encaminamiento pertenecientes a esta clasificación se pueden encontrar los siguientes protocolos: • Distance Routing Effect Algorithm for Mobility (DREAM) • Location-Aided Routing (LAR) • Greedy Perimeter Stateless Routing (GPSR) Además, dentro de esta clasificación se encuentra el protocolo de encaminamiento AeroRP, el cual va a ser objetivo de estudio en las siguientes secciones de éste proyecto. En la figura 8 se puede ver un resumen de la clasificación de los protocolos de encaminamiento en las redes MANET y algunos ejemplos de los protocolos que pertenecen a cada grupo.

Figura 8. Clasificación de protocolos de encaminamiento MANET según la estructura de red.

Protocolos de enrutamiento de redes MANET

Basados en topología

Topología plana

DSR OLSR DSDV

Topología jerárquica

HSR LANMAR

Basados en geografía

AeroRP GPSR LAR

23


En este capítulo nos centraremos en describir detalladamente el modo de funcionamiento del protocolo de enrutamiento AeroRP sobre el que se basa gran parte de éste proyecto, introducido en [6] y evaluado en [7], para posteriormente en el capítulo 5 describir la implementación de éste protocolo con la herramienta Click Modular Router. Se trata de un protocolo diseñado específicamente para abordar las cuestiones relacionadas con los entornos aeronáuticos de gran movilidad, donde los nodos se desplazan a una velocidad de hasta Mach 3.5, es decir, 3.5 veces la velocidad del sonido (~1234 km/h), lo que dá lugar a una topología altamente dinámica y una conectividad muy intermitente entre los nodos. Ésto conlleva a frecuentes cambios en la decisión de encaminamiento y a una sobrecarga en la red significativa y por tanto necesitamos un protocolo de múltiples saltos como el AeroRP que está diseñado específicamente para solucionar estos problemas relacionados con los entornos aeronáuticos altamente móviles. El protocolo de enrutamiento AeroRP es fundamentalmente un protocolo de encaminamiento basado en geografía y con decisión de reenvío MFR. Además es un protocolo de encaminamiento proactivo, es decir, mantiene la información de encaminamiento incluso antes de que se necesite. Éste protocolo realiza el encaminamiento salto a salto, es decir, decide hacia que nodo reenvía los datos en cada salto basándose en la información local y las rutas disponibles, por lo que es perfectamente adecuado para entornos altamente dinámicos. Aunque ésto puede conllevar al problema de que no siempre se seleccione la ruta óptima desde el origen hasta el destino, ya que no se compara en el origen todas las rutas disponibles hasta el destino, sino los distintos saltos posibles hasta el siguiente nodo. Por lo tanto, al final puede llegarse a elegir una ruta en la que se produzcan más saltos de los óptimos. Las aplicaciones militares presentan un alto nivel de variación en sus parámetros operacionales. Por ejemplo, basándose en los requisitos de seguridad de la aplicación de prueba, puede que no sea deseable que la geolocalización de los nodos esté disponible. A fin de apoyar esta dinámica en la operación, las politicas y las restricciones, AeroRP ofrece múltiples modos de funcionamiento.

CAPÍTULO 3: Protocolo de

enrutamiento AeroRP

24


3.1- Funcionamiento básico del protocolo AeroRP

El protocolo AeroRP se divide en dos fases [8]: la primera de ellas es el descubrimiento de los nodos vecinos, donde cada nodo construye una tabla con todos los nodos vecinos disponibles dentro de un rango fijado en el fichero de cabecera en un cierto instante de tiempo, para ello el nodo hace uso de varios mecanismos que explicaremos a continuación más detalladamente. La segunda fase es el reenvío de datos, donde cada nodo debe decidir el próximo salto para un paquete de datos, para ello la localización del destino es conocida por todos los nodos desde el principio, y una tabla de vecinos es mantenida en cada uno de los nodos y actualizada según el mecanismo utilizado en la primera fase con la posición y la velocidad exacta de cada nodo vecino. El nodo hace uso de esta información para elegir el siguiente salto del paquete de datos que queremos que llegue hasta su destino. El protocolo de enrutamiento AeroRP dispone de varios mecanismos para cada una de las fases, el modo de funcionamiento no está definido en el protocolo, sino que hay tantos modos de funcionamiento como mecanismos existen para cada fase. A continuación vamos a explicar detalladamente los mecanismos que podemos utilizar para cada una de las fases y los que finalmente hemos utilizado para el desarrollo e implementación de dicho protocolo con nuestra herramienta.

3.1.1- Descubrimiento de vecinos

El primer objetivo de un nodo es determinar cuales son sus nodos vecinos. Para realizar esta tarea, se utilizan varios mecanismos diferentes con el objetivo de minimizar la sobrecarga en la red. Podemos hacer uso de uno o varios mecanismos para completar la tabla de reenvío de datos.

1. El espionaje activo: es el principal mecanismo utilizado por el nodo para localizar e identificar a sus vecinos. En una red inalámbrica, cuando un nodo no está transmitiendo, escucha todas las transmisiones en el canal inalámbrico. Ésto implica que si un nodo puede escuchar transmisiones procedentes de otro nodo también puede comunicarse con ese nodo. Las entradas de la tabla de vecinos se eliminan si no se escuchan transmisiones desde un nodo durante un intervalo de tiempo predeterminado.

2. Las balizas “Hello”: son utilizadas por los nodos inactivos para anunciar su presencia. Cada nodo transmite una baliza indicando su posición y velocidad cada cierto intervalo de tiempo. Cuando un nodo recibe una baliza “Hello”, éste se encarga de mantener actualizada su tabla de vecinos. La frecuencia de envio de la baliza “Hello” es inversamente proporcional a la duración de contacto mínima calculada. Por ejemplo, si la duración de contacto mínimo es de 10 segundos, la baliza “Hello” se transmite cada segundo. AERORP_BEACON_INTERVAL es el intervalo de tiempo en el cual cada

25


nodo envía una baliza a sus nodos vecinos y está definido en nuestro fichero de cabecera.

3. La actualización desde la estación de tierra (Ground Station): puede utilizarse para aumentar o reemplazar el espionaje activo en algunos escenarios de las misiones, en los cuales la GS tiene un plan de la misión total o parcial. La GS envía, a todos los nodos, actualizaciones periódicas que contienen la ubicación y los vectores de trayectoria previstos en el plan de la misión de cada nodo.

Los requisitos de seguridad pueden imponer algunas restricciones en las redes aeronáuticas. En algunos casos en los cuales se considera sensible la ubicación o la trayectoria del nodo, los nodos individuales pueden no incluir esta información en la cabecera de los paquetes de datos o en las balizas “Hello”. En este caso, la GS es la encargada de enviar la actualización de la ubicación de todos los nodos a través de un canal cifrado. Dada la naturaleza dinámica de la red aeronáutica, el descubrimiento de vecinos no sólo consiste en la búsqueda de los nodos dentro del alcance de transmisión, sino también en determinar la duración en la que un nodo descubierto se mantendrá dentro de este alcance. Dependiendo de las restricciones operacionales, esta información se obtiene a través de mecanismos diferentes: la información sobre la ubicación y la trayectoria se incluye en la cabecera AeroRP o en las actualizaciones enviadas por la GS.

3.1.2- El reenvío de los datos

Después del descubrimiento de vecinos, la segunda fase del protocolo AeroRP es determinar, en cada nodo, el siguiente salto para una transmisión de datos en particular. Recordamos que a diferencia de los protocolos convencionales, AeroRP realiza un reenvio salto a salto. Cada nodo reenvía los paquetes de tal manera que terminen geográficamente más cerca del destino, esto es debido a que AeroRP tiene decisión de reenvío MFR. Cuando un nodo necesita transmitir un paquete de datos, y suponiendo que han sido descubiertos uno o más vecinos, los paquetes de datos se envian al nodo que está más cerca del destino, lo cual se calcula a partir de sus coordenadas actuales y trayectoria. La ubicación del destino es siempre conocida por el nodo que quiere enviar un paquetes de datos y además éste nodo incluye esta información en la cabecera AeroRP del paquete de datos para que sea usada en cada salto, y así poder determinar el mejor nodo al que reenviar el paquete de datos. El algoritmo para encontrar el mejor nodo al cual reenviar el paquete de datos se

explica a continuacion.

26


3.1.2.1- El algoritmo de reenvio de datos

La posición del i-esimo nodo, ni, se representa con el vector

Pi = (xi, yi, zi) y la trayectoria se define con el vector Ti = (si, i, i), donde x, y, z son las coordenadas del nodo, T es el vector de dirección esférica (velocidad, inclinación y acimut). Dado que la red es altamente dinámica, tanto la posición como la trayectoria de los nodos dependen del tiempo. Para un determinado par origen-destino, en un tiempo dado t, el nodo

de origen, ns, tiene la posición Pts = (xt

s, yts, zt

s) y la trayectoria Tts = (st

s, ts, t

s). Asimismo, el

nodo de destino, nd, está representado por Ptd = (xt

d, ytd, zt

d) y Ttd = (st

d, td, t

d). Si el destino es una GS estacionaria, entonces Pt

d=Pd. Paso 1: Cada nodo mantiene dos tablas: una tabla de vecinos que almacena la información acerca de los nodos que están actualmente en el rango de transmisión, y una tabla de datos de destino que almacena la información de todos los destinos, los cuales pueden o no estar actualmente dentro del rango de transmisión. Inicialmente, el número de vecinos dentro de la lista de vecinos N es cero. Paso 2: Cuando un nodo recibe un paquete, entonces se actualizan ambas tablas. Si el paquete capturado es una baliza “Hello” de un nodo ni, este nodo se supone que está dentro del rango de transmisión del nodo actual. Por lo que la lista de vecinos se actualiza con N= N ∪ {ni}. Además la dirección MAC, la posición y la trayectoria se derivan de su cabecera y se almacenan en la tabla de vecinos como la tupla {macIDi, Pt

i, Tti}. Si la transmisión recibida es

una actualización de la GS, se almacena en la tabla de datos de destino como la tupla {tiempo, macIDi, Pt

i, Tti}. La actualización de la GS puede contener información sobre las posiciones del

nodo en el futuro, por lo que las entradas de la tabla de datos de destino tienen una marca de tiempo. Por último, cuando se recibe una actualización de la GS, los campos de ubicación y trayectoria de las entradas de la tabla de vecinos se actualizan con los valores más recientes. Paso 3: Tras completar el paso 2 y añadir los datos de los vecinos a la tabla, se supone que un nodo dado n0 ha descubierto k vecinos. Cada nodo se añade a sí mismo como el primer vecino de la lista: N0 = {n0, n1,..., ni,…, nk}. Supongamos que el nodo n0 quiere enviar un paquete de datos a la GS nd con posicion Pd. Y que el alcance de transmisión de todos los nodos es R. A continuación, calculamos el Time To Intercept (TTI) para todos los vecinos de la tabla. El TTIi representa el tiempo que necesita el nodo ni, si continúa en su trayectoria actual, para conseguir encontrarse dentro del rango de transmisión del destino. El TTI es calculado como:

𝑇𝑇𝐼 = |𝑃𝑑

𝑡 − 𝑃𝑖𝑡| − 𝑅

𝑆𝑑

|𝑃𝑑𝑡 − 𝑃𝑖

𝑡| = √(𝑥𝑑 − 𝑥𝑖)2 + (𝑦𝑑 − 𝑦𝑖)2 + (𝑧𝑑 − 𝑧𝑖)2

27


Donde |𝑃𝑑𝑡 − 𝑃𝑖

𝑡|es la distancia euclídea entre la ubicación actual del nodo ni y el nodo de destino nd, y sd es la componente de la velocidad real vi del nodo ni en la dirección del destino y se calcula como:

𝑠𝑑 = 𝑣𝑖 ∙ cos (𝛼 − 𝛽) Donde β es el ángulo del destino con respecto a la posición del nodo actual. Un sd alto y positivo indica que el vecino se está moviendo hacía el destino a una velocidad alta; un sd alta y negativo indica que el vecino se está alejando del destino.

𝑣𝑖 = √𝑣𝑥𝑖2 + 𝑣𝑦𝑖

2 𝛼 = 𝑎𝑟𝑐𝑡𝑔(𝑣𝑦𝑖

𝑣𝑥𝑖) 𝛽 = 𝑎𝑟𝑐𝑡𝑔(

𝑦𝑑−𝑦𝑖

𝑥𝑑−𝑥𝑖)

En la Figura 9 podemos ver un ejemplo de cómo calcular la velocidad real de un nodo ni que se mueve hacia el destino. En este ejemplo vxi es -14.15 m/s, vyi es 14.15 m/s, α es -135o y β es -111.8o, con lo cual sd dá como resultado 18.4 m/s.

Figura 9. Ejemplo del algoritmo de reenvío de datos.

Debemos contemplar un caso especial, en el que el nodo vecino se está alejando del destino, es decir, sd es negativo y además el destino no se encuentra dentro de su rango de

28


alcance R, en este caso el TTI es nulo, nunca debemos tomar estos nodos como próximo salto. La figura 10 ilustra el problema que puede ocurrir cuando se toma en cuenta este caso.

Figura 10. Ejemplo TTI negativo.

Si el TTI de los vecinos (n1 y n2) se calcula como |𝑃𝑑

𝑡− 𝑃𝑖𝑡|−𝑅

𝑆𝑑 , el nodo n1 será elegido

como el próximo salto por n0 porque tendrá un TTI negativo. Sin embargo, n2 es la mejor opción, ya que se está moviendo hacia el destino. Para fijar esto, la versión a trozos del cálculo TTI debe utilizarse de forma que el TTI de n1 se calcularía como 0 ya que este nodo está fuera del rango de transmisión del destino y se está alejando de él, por tanto AeroRP nunca elegirá este nodo como siguiente salto y así tendremos que la mejor elección para el siguiente salto será n2. Se permite un TTI negativo porque esta es una indicación de un nodo que está dentro del rango de transmisión del destino y por lo tanto deben ser considerados como un siguiente salto. Se eligen los nodos dentro de alcance de transmisión del destino sobre nodos que no lo están.

29


En definitiva, el TTI es calculado como sigue:

𝑇𝑇𝐼𝑖 = {

0 𝑠𝑑 < 0 𝑦 |𝑃𝑑𝑡 − 𝑃𝑖

𝑡| > 𝑅

|𝑃𝑑𝑡 − 𝑃𝑖

𝑡| − 𝑅

𝑆𝑑 𝑒𝑛 𝑜𝑡𝑟𝑜 𝑐𝑎𝑠𝑜

Paso 4: Finalmente, los datos se envían al nodo j-esimo, nj, que es el nodo dentro de la tabla de vecinos que está más cerca del rango de transmision del destino y por lo tanto tiene el valor de TTI mas bajo:

𝑇𝑇𝐼𝑗 = 𝑚𝑖𝑛{𝑇𝑇𝐼𝑖}

El proceso se repite en cada nodo intermedio, hasta que el paquete de datos llega al destino. En el caso en el que un nodo reciba un paquete para el cual el propio nodo tiene el mejor TTI pero no está dentro del alcance de transmisión del destino, el paquete de datos se puede insertar en una cola de tamaño configurable durante un periodo de tiempo ajustable. La cola se comprueba frecuentemente para ver si hay algun vecino con un menor TTI que el nodo local. Cuando se encuentra un vecino con un TTI menor, los paquetes de la cola se envian a una velocidad de datos configurable. Actualmente, existen tres modos diferentes de funcionamiento en AeroRP para cuando el nodo local tiene el mejor TTI: 1) Ferry: Encola los paquetes de forma indefinida hasta que se encuentra un nodo con un TTI menor y entonces se envían todos al nuevo nodo encontrado. 2) Buffer: Encola los paquetes en una cola de tamaño finito, con un tiempo de espera finito hasta que se encuentra un nodo con un TTI menor, los paquetes encolados son enviados al nodo con menor TTI y aquellos a los que se le agota el tiempo de espera son eliminados. 3) Drop: Rechaza el paquete.

30


4.1- Introducción a Click Modular Router

Click Modular Router [1] es un software que permite la creación de enrutadores (routers) flexibles y configurables, fue creado inicialmente por Eddie Kohler para su tesis doctoral en 1999 [9], y actualmente continúa desarrollándose por el mismo Eddie Kohler y otros voluntarios. En Click, un router sigue un modelo modular, está formado por el ensamblaje de diferentes módulos que procesan los paquetes. A estos módulos se les llama elementos. La idea es que cada elemento, de forma individual, realice una tarea simple, como puede ser la clasificación de paquetes en función de alguna característica, espera en cola de paquetes, etc. La forma de ensamblar los diferentes elementos es mediante un archivo de configuración que se traduce a un grafo dirigido en el que los vértices son los diferentes elementos que forman el router y las aristas indican las conexiones entre ellos. De esta forma, las aristas señalan la dirección en la que fluyen los paquetes de elemento en elemento. Para escribir este archivo de configuración se utiliza un lenguaje que se basa en declaraciones de elementos y conexiones entre ellos, que viene detallado en el apartado 4.4. Click Modular Router incluye una amplia biblioteca de elementos con funcionalidades variadas: buffers, IPv4, IPv6, Ethernet, 802.11, gestión de interfaces, ARP, NAT, etc. Pero una de las mejores características es que el desarrollador también tiene la posibilidad de implementar sus propios elementos programándolos en código C++, éste es el cometido de

CAPÍTULO 4: Herramienta

utilizada en el desarrollo del

proyecto: Click Modular

Router

31


nuestro proyecto, programar elementos que implementen el funcionamiento del protocolo AeroRP. Veamos en la siguiente figura un ejemplo de una configuración de un router click:

Figura 11. Configuración Click Router.

En esta configuración sencilla, todas las tramas generadas por el dispositivo eth0 son contadas por el elemento counter y posteriormente descartadas por el elemento discard.

4.2- Arquitectura El elemento es la abstracción visible al usuario más importante. Un elemento representa una unidad de proceso. Los elementos suelen realizar procesos sencillos, como por ejemplo modificar el valor de un campo o añadir una cabecera a la trama. El usuario decide que funcionalidad implementar escogiendo los elementos e interconectándolos entre sí. Cada elemento es, además, un objeto C++, las conexiones entre elementos se corresponden con punteros hacia los objetos C++ y el paso de la trama de un elemento a otro se realiza mediante llamadas a funciones virtuales. Las propiedades más importantes de un elemento son:

Clase del elemento: cada elemento pertenece a una clase determinada, esto específica el código que se ejecuta cuando la trama es procesada, y la configuración del elemento. Por ejemplo, indica cuántos puertos tiene, qué manejadores soporta, cómo procesa los paquetes, etc.

Puertos: cada elemento puede tener cualquier número de puertos de entrada o salida. Los puertos son los puntos finales de las conexiones entre elementos y cada uno de ellos tiene un rol diferente. Por ejemplo, los elementos con funcionalidad de clasificar tramas suele tener varios puertos de salida.

Cadena de configuración: algunos elementos soportan argumentos adicionales para configurar el elemento en su inicialización. La forma de hacer llegar al elemento estos parámetros es mediante la cadena de configuración. Los parámetros que se introducen en la cadena de configuración sirven para determinar el comportamiento del elemento, tal y como hacen los parámetros pasados a los constructores de objetos en los lenguajes de programación orientados a objetos.

32


Métodos de interfaz: cada elemento exporta métodos que otros elementos pueden llamar para interactuar entre ellos. Todos los elementos están obligados a exportar una serie de métodos que se utilizan, entre otras cosas, para transferir los paquetes entre unos elementos y otros. Además, un elemento puede exportar métodos que no sean obligatorios, como por ejemplo, el elemento Queue, que implementa una cola FIFO y que exporta un método que permite conocer su longitud actual.

Handlers: los elementos de Click Modular Router añaden la posibilidad de poder interactuar con ellos una vez que han sido inicializados y el router se encuentra en funcionamiento. Esto se puede hacer gracias a los manejadores. Con los manejadores, se puede por ejemplo, cambiar la configuración de un elemento o conocer sus valores. Por ello, existen manejadores de lectura y de escritura, que sirven para obtener información o cambiar la configuración de los elementos del router respectivamente. Además, el desarrollador también puede acceder a estos handlers y consultar o modificar valores mientras el router está en ejecución sin necesidad de para la ejecución del router para volver a inicializarlo.

4.2.1- Paquetes en Click Modular Router

Los paquetes en Click Modular Router son punteros que señalan a una estructura de cabecera que mantiene a su vez punteros a los datos actuales del paquete, es decir, el contenido del paquete, y a una serie de anotaciones que tienen los paquetes. Las anotaciones de los paquetes son información adicional adjunta al paquete y que no se encuentra dentro de los datos del paquete. Las anotaciones se utilizan para procesar de una manera más fácil los paquetes. Existen muchos tipos de anotaciones como por ejemplo, la anotación paint, que se utiliza para marcar a los paquetes con un cierto número por algún motivo, como puede ser el número del puerto de la interfaz de red de entrada. Otros tipos de anotaciones son por ejemplo las anotaciones de marcas de tiempo, que puede servir para anotar el tiempo de llegada de los paquetes. También, anotación de la dirección IP de destino, etc. Existen multitud de tipos de anotaciones de paquetes. Procesamiento de los paquetes Click Modular Router proporciona tres tipos de conexiones entre elementos. Las conexiones pueden ser push, pull o agnostic. Ésto se corresponde a la manera en que las tramas se procesan en un router real, dónde hay funciones que crean tramas, funciones que procesan tramas, y funciones que solicitan tramas cada cierto tiempo.

Conexión push, el elemento upstream le transfiere el paquete al elemento que se encuentra downstream (siguiente elemento). Son las apropiadas para procesar tramas que no han sido solicitadas.

33


Conexión pull, el elemento downstream pregunta al elemento upstream (elemento anterior) por la llegada de paquetes antes de que éste se los transfiera. Son las apropiadas cuando hay que controlar el instante en el que se procesa la trama.

Conexión agnostic, algunos elementos soportan tanto conexiones push como conexiones pull, y se pueden conectar a puertos push y pull sin generar conflictos en la configuración del router.

En la figura 12, se puede observar esquemáticamente el comportamiento de ambos tipos de conexión.

Figura 12. Funcionamiento de las conexiones push y pull.

De esta forma, los puertos que tienen comportamiento push sólo pueden ser

conectados a puertos con comportamiento push y los puertos con comportamiento pull

sólo pueden conectarse a otros puertos pull. Si en el archivo de configuración se conecta un

puerto push con otro pull, se producirá un error y el router no podrá ser inicializado.

Los elementos poseen puertos pull, push o agnósticos según su funcionalidad. Por ejemplo, el elemento FromDevice tiene un puerto de salida push, porque entrega las tramas generadas por un dispositivo cuando este se las da, en cambio, el elemento ToDevice tiene un puerto de entrada pull, porque solicita las tramas sólo cuando el dispositivo puede aceptarlas. Las conexiones entre puertos de un mismo tipo, o con un puerto agnóstico, están permitidas, pero las conexiones entre puertos de diferente tipo son incorrectas. Algunos elementos, como los Queue, permiten la transición entre diferentes tipos de puertos.

Figura 13. Puertos push, pull y agnostic.

34


En esta figura, hemos marcado los puertos de salida con cuadrados y los de entrada con triángulos, los puertos push están en negro y los puertos pull en blanco. En a) observamos una configuración incorrecta, el elemento FromDevice(eth0) tiene un puerto de salida push conectado al elemento counter, cuyos puertos son agnósticos, posteriormente se conecta al puerto de entrada pull del elemento ToDevice(eth1), al no realizarse ninguna transición de pull a push la configuración del router es incorrecta. En los casos b) y c) la configuración es correcta, porque el elemento Queue realiza la transición de push a pull, si observamos la figura, podemos comprobar que los colores de los puertos coinciden en estos últimos casos, pero no es así en el caso a). A los elementos que no intervienen en el procesamiento de paquetes y que simplemente almacenan y mantienen alguna información o dato, se les llama elementos de información.

4.3- Entornos de ejecución Una configuración de Click Modular Router puede correr como un módulo del kernel de Linux, como una aplicación a nivel de usuario o en el simulador ns-2. Estos entornos de configuración tienen una serie de ventajas e inconvenientes que hay que evaluar en cada caso concreto de uso para determinar cuál es la mejor opción. Los archivos de configuración varían en función del entorno de ejecución que queramos utilizar en el sentido de que, hay elementos que soportan ser utilizados en cualquier entorno de ejecución, pero hay otros que sólo están destinados a ser utilizados en el entorno a nivel de usuario o como módulo del kernel. Las principales diferencias se encuentran en los elementos que actúan como fuentes o sumideros de paquetes y los que interactúan con los dispositivos de red del ordenador.

4.3.1- Nivel del kernel

Para que una configuración de Click Modular Router pueda ser ejecutada a nivel del kernel de Linux, el kernel debe ser parcheado y compilado para permitir a los elementos de Click, codificados en lenguaje C++, ser compilados y ejecutados dentro de un módulo del kernel. De este modo, el módulo del kernel resultante puede ser instalado con la instrucción de Linux “insmod” (que sirve para instalar módulos en el kernel) o más fácilmente con el comando “click-install” que, además de instalar el módulo en el kernel, monta el sistema de ficheros del router Click. El sistema de ficheros del router Click es similar al sistema de ficheros /proc de Linux y sirve para comunicarse con el router que se está ejecutando como un módulo del kernel. En este sistema de ficheros es dónde se encuentran los ficheros manejadores que sirven para cambiar la configuración del router mientras que éste está en ejecución sin necesidad de volver a inicializarlo.

35


Para aquellos elementos que vayan a ejecutarse a nivel del kernel, hay que tener en cuenta todas las limitaciones propias de trabajar en este entorno, como puede ser, que no se permite operar con números en coma flotante o la utilización de librerías de nivel de usuario. La gran ventaja de trabajar a nivel del kernel es que la pila de red de Linux es sustituida por el módulo Click. De esta forma, los paquetes entrantes por las interfaces de red son procesados en primer lugar por Click Modular Router y Linux sólo podrá procesar aquellos paquetes que nuestro módulo del kernel le envíe. De este modo, tenemos la posibilidad de que haya paquetes que sólo sean vistos por Click Modular Router y Linux no sepa de su existencia. De la misma manera, todos los paquetes procedentes de la pila de red de Linux pueden ser capturados por Click Modular Router antes de que lleguen a las interfaces de red del ordenador. Esta forma de actuar es única para el entorno a nivel del kernel y no aplica al entorno de nivel de usuario. Recordemos que éstos eran los requisitos que pedíamos a la herramienta utilizada para desarrollar la implementación y que por ello se ha empleado Click Modular Router. Cabe señalar que únicamente es posible utilizar Click Modular Router a nivel del kernel para ciertas versiones del mismo. Esto se debe a que únicamente existen parches del kernel para las versiones 2.6.24.7, 2.6.19.2, 2.6.16.13, 2.4.32, 2.4.28, 2.4.27, 2.4.26, 2.4.26-Debian, 2.4.21, 2.4.20, 2.4.19 y 2.4.18.

4.3.2- Nivel de usuario

Si lo que se quiere es ejecutar Click Modular Router a nivel de usuario, se puede compilar y ejecutar el código de los elementos de forma sencilla sin necesidad de parchear el kernel. La diferencia más importante respecto a la ejecución de Click Modular Router como módulo del kernel es que, a nivel de usuario, Click obtiene los paquetes una vez que ya han sido procesados por la pila de red de Linux. De esta forma, otros programas como por ejemplo sniffers de paquetes, pueden ver los paquetes aunque estos sean descartados en el router Click. Por otro lado, la interacción con los manejadores se puede llevar a cabo a través de un elemento llamado ControlSocket que establece una comunicación con el manejador a través de un socket.

4.3.3- Entorno de simulador

Para poder ejecutar Click Modular Router sobre el simulador ns-2, además de la necesidad de tener instalado el simulador, se debe aplicar el parche nsclick. De esta manera, los elementos compilados para la simulación pueden ser utilizados en un archivo de configuración de Click y ser cargados en el script .tcl del simulador.

36


4.3.4- SMP Click

Normalmente Click Modular Router se ejecuta en sistemas de un único procesador y utilizando un entorno de un único hilo de ejecución. Sin embargo, es posible utilizar SMP Click para poder ejecutar Click Modular Router con múltiples hilos ejecutándose en paralelo sobre múltiples procesadores.

4.4- Fichero de configuración Para interconectar elementos e implementar nuestro router, es necesario escribir un fichero de configuración utilizando “lenguaje click”, este fichero define que elementos utilizará nuestro router (Declaraciones) y como estarán interconectados (conexión). Declaración: La declaración se especifica de la siguiente manera:

name :: class(config) Esto declararía un elemento name de la clase class y con los parámetros de configuración config. Conexión: Una conexión se especifica de la siguiente manera:

name1[port1] -> [port2]name2 Donde name1 y name2 son elementos declarados con anterioridad, y port1 y port2 especifican que puertos utilizar en la conexión de los elementos name1 y name2. También es posible declarar nuevos elementos durante la conexión, ahorrándonos su declaración anterior:

… -> name :: class(config) -> … Veamos un ejemplo sencillo de un fichero de configuración click:

Trafico_entrante::FromDevice(eth0); Clasificador::Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800); Trafico_entrante -> Clasificador; Clasificador[0] -> Print(“Trama ARP request”) -> d1::discard(); Clasificador[1] -> Print(“Trama ARP response”) -> d2::discard(); Clasificador[2] -> Print(“Trama datos”) -> d3::discard();

En este ejemplo, utilizamos el elemento Clasificador configurado para clasificar las tramas ethernet en tres categorias: ARP requests, ARP responses y tramas de datos. El

37


protocolo ARP (Address Resolution Protocol) se utiliza para descubrir direcciones MAC y relacionarlas con direcciones ethernet. El Clasificador es un elemento con un puerto de entrada y 3 puertos de salido, el resto de elementos posee sólo 1 puerto de entrada y 1 puerto de salida, nótese por tanto, como para cada uno de los puertos de salida del Clasificador definimos diferentes conexiones. Cuando los elemento sólo disponen de 1 puerto, no es necesario especificar [0].

4.4.1- Ejemplo grafo archivo de configuración Click

En esta figura se representa un router IP para paquetes unicast. En este ejemplo, se han tomado únicamente dos interfaces de red aunque el router se puede extender para trabajar con más interfaces:

Figura 14. Ejemplo de la configuración de un router IP.

38


4.5- Programación de elementos Aunque Click Router posee una amplia biblioteca de elementos, resulta muy útil saber cómo implementar nuestros propios elementos para conseguir funcionalidades que no obtendríamos utilizando los elementos básicos. Lo más aconsejable, es buscar un elemento con características similares a las que se desean implementar y programar un nuevo elemento a partir de este. Con el objetivo de mostrar los conceptos más básicos de programación de un elemento Click, detallamos a continuación el código del elemento MyNullElement, elemento muy sencillo, cuya funcionalidad consiste en no alterar la trama y poner en el puerto de salida la trama que se ha recibido en el puerto de entrada. #ifndef CLICK_MYNULLELEMENT_HH #define CLICK_MYNULLELEMENT_HH #include <click/element.hh> CLICK_DECLS class MyNullElement : public Element { public: MyNullElement() { } ~MyNullElement() { } const char *class_name() const { return "MyNullElement"; } const char *port_count() const { return PORTS_1_1; } const char *processing() const { return PUSH; } void push(int port, Packet *p) { output(0).push(p); } };

El elemento MyNullElement hereda la clase elemento, esta clase proporciona la funcionalidad básica, como los métodos input( ) y output( ).

El método port_count( ) indica a Click cuantos puertos tiene MyNullElement.

El método processing( ) indica que los puertos son de tipo push.

En MyNullElement no se definen los métodos configure( ) o initialize() por lo tanto el elemento no recibe datos para su configuración inicial.

En MyNullElement no se definen handlers.

La función push( ) se ejecuta cuando otro elemento envía una trama hacia MyNullElement. La trama se enviará al puerto de salida mediante la función output(0).push(p).

39


Una vez especificado y detallado el funcionamiento del protocolo, se describe en este capítulo los pasos necesarios para su implementación incluyendo las partes más importantes del código fuente, la configuración del entorno, las herramientas utilizadas para proyectarse el protocolo y la arquitectura utilizada. El objetivo final de la implementación es evaluar la

funcionalidad del protocolo en una red ad-hoc.

5.1- Configuración del entorno

Para llevar a cabo la implementación del protocolo hemos hecho uso de un sistema de virtualización. Hemos creado varias máquinas virtuales que emulan a una serie de nodos moviéndose libremente por un escenario de 10x10 metros. El nodo que envía mensajes (nodo origen) y el nodo que ha de recibir éstos mensajes (nodo destino) se encuentran en una posición fija del escenario.

El sistema operativo en todos los casos será la distribución de Linux Ubuntu 12.04.

El entorno está configurado para operar en modo Ad hoc, eso implica que la comunicación entre las máquinas es hecha de forma directa, no necesitando de ningún punto común para centralizar el tráfico y las informaciones.

5.2- División en elementos de Click Modular Router

Para realizar la implementación se ha utilizado la herramienta Click Modular Router. De los entornos de ejecución que se permiten se ha elegido la ejecución de Click como nivel de usuario ya que se puede ejecutar el código de los elementos de forma sencilla y sin necesidad de parchear el kernel. A continuación se exponen los diferentes elementos

CAPÍTULO 5:

Implementación del protocolo

AeroRP y su integración con

Click Modular Router

40


implementados en leguaje C++ que se han utilizado y se explica su función. Algunos de ellos ya estaban implementados en la propia herramienta y se explican detalladamente en el apédice E y otros han sido creados para realizar una tarea concreta que explicaremos a continuación, el código fuente de los elementos creados puede verse en el cd que ha sido adjuntado junto a la memoria del proyecto.

5.2.1- Elemento AERORPGPSUDPTable

Este elemento tiene un puerto de entrada y otro de salida. Ambos son tipo agnostic. Espera paquetes UDP ensu entrada generados por la aplicación generador_posiciones" que es

lanzada por el nodo gestión.

Este paquete consiste en una cabecera Ethernet seguida de una cabecera IP, una cabecera UDP, un conjunto de datos de tipo double (posición_nodo_ x, posición_nodo_y, posición_nodo_z) y un entero que es una marca de tiempo. Este elemento se encarga de leer estos paquetes y actualizar la posición de cada nodo, calculando su velocidad y actualizándola también. El cometido de este elemento es el de mantener siempre los nodos actualizados, para así que los nodos puedan mandar las balizas con las coordenadas correctas de su posición a través del elemento AERORPBeaconGenenator. La cadena de configuración dispone de varios argumentos: - ROUTETABLE: se trata de un puntero a la función AERORPRouteTable, para que ésta pueda acceder a la posición y velocidad actualizadas de cada nodo en cada momento, para poder comprobar si hay paquetes en el buffer esperando a ser enviados y para imprimir las estadísticas sobre los paquetes enviados/recibidos/almacenados. - NEIGHBORSTABLE: se trata de un puntero a la función AERORPNeighborsTable, para que ésta pueda actualizar la posición y velocidad actualizadas de cada nodo en cada momento. - BUFFER: se trata de un puntero a la función AERORPBuffer, para imprimir las estadísticas sobre los paquetes enviados/recibidos/almacenados. - NODE: es un entero, que almacena el número del nodo.

Figura 15. Elemento

AERORPGPSUDPTable

41


Este elemento cuenta con un temporizador que salta a los 5 segundos de recibir el último paquete por su entrada y llama a la función " printStats" de las funciones AERORPBuffer y AERORPRouteTable para imprimir las estadísticas sobre los paquetes que han pasado por el nodo. Los paquetes que son sacados por la salida de éste elemento son directamente descartados.

5.2.2- Elemento AERORPCheckRange

Este elemento se encarga de comprobar el rango de alcance para la transmisión de paquetes AERORP entre nodos (ya sean de datos o balizas). Tiene un puerto de entrada y dos de salida. Todos los puertos son de tipo push.

Analiza si el paquete que llega por el puerto de entrada es enviado por un nodo que está dentro de mi alcance de transmisión/recepción de paquetes definido por la constante AERORP_R en el fichero de cabecera click_aerorp.hh. La cadena de configuración acepta los siguientes argumentos: - GPSUDPTABLE: es un puntero a la función AERORPGPSUDPTable, para mantener actualizada la posición de cada nodo llamando a la funcion " getPosition".

5.2.3- Elemento AERORPRoutetable

Este elemento tiene 3 puertos de entrada y dos de salida. Todos ellos de tipo push. Se encarga de procesar los paquetes recibidos por alguno de sus tres puertos de entrada y encaminar el paquete hacía el siguiente salto que será el nodo con menor TTI o el destino si éste se encuentra dentro del alcance.

Es la función principal de nuestra implementación. Vamos a analizar los paquetes que pasan por cada uno de los puertos de ésta función: - Puerto 0 de entrada: espera paquetes IP que tienen como dirección destino la dirección final a la que debe llegar el paquete. Al entrar un paquete por el puerto 0, lo primero que haremos será buscar si hay un nodo con menor TTI que el mio, para ello llamaremos a la

Figura 16. Elemento

AERORPCheckRange

Figura 17. Elemento

AERORPRouteTable

42


función "LookForNextHop" definida en el elemento AERORPNeighborsTable, si lo encuentra comprobaremos si es el destino, en éste caso mandamos el paquete por la salida 0 directamente hacia el destino, si se trata de un nodo intermedio lo que haremos será llamar a la función "addAERORPHeader"(definida en ésta misma función) que incluirá en el paquete la cabecera AERORP con la opción de datos y baliza y lo mandará al siguiente salto por la salida 0 incluyendo el nodo en la traza que sigue el mensaje. Si no existe ningún nodo con menor TTI que el mio, ésto quiere decir que yo soy el mejor nodo, encolaremos el mensaje en el buffer a la espera de que llegue un nodo mejor y así poderle enviar todos los mensajes almacenados en el buffer para encaminarlos hacia el destino. - Puerto 1 de entrada: espera paquetes de datos AERORP. Al entrar un paquete por el puerto 1, llamaremos a la función "LookForNextHop" para buscar el mejor salto, si éste se encuentra y es el destino llamaremos a la función "deleteAERORPHeader"(definida en ésta misma función) para borrar la cabecera AERORP y así reenvíar el paquete al nodo destino por el puerto 0 de salida, si se trata de un nodo intermedio llamamos a la función "modifyAERORPHeader"(definida en ésta misma función) que modifica la cabecera con la posición del nodo y retransmite el paquete modificado por el puerto 0 al próximo salto incluyendolo en la traza que sigue el mensaje. Si no encontramos un nodo con menor TTI que el mio, entonces almacenaremos el mensaje en el buffer de espera. - Puerto 2 de entrada: espera paquetes baliza. Al entrar un paquete baliza, llamamos a la función “updateRoutetableEntry”, definida en la función AERORPNeighborsTable que extrae los datos del nodo vecino y actualiza la tabla de vecinos con el nuevo nodo y la posición actualizada de dicho nodo. Una vez actualizada la tabla de vecinos el paquete es descartado por la salida 1. -Puerto 0 de salida: envía los paquetes procesados por la función AERORPRoutetable al dispositivo DEVICE. - Puerto 1 de salida: descarta los paquetes baliza que entran por el puerto 2 de entrada una vez que han actualizado la tabla de vecinos. Ésta función también se encarga de imprimir las estadísticas de mensajes que han pasado por el nodo en cuestión. Y de imprimir la traza de los nodos que recorre cada mensaje identificándolo por su campo "ip_id" de la cabecera IP. También se encarga de comprobar si existe algún mensaje en el buffer cada vez que llega un nuevo nodo y actualiza la tabla de vecinos, para buscar el siguiente salto y si se encuentra, es decir, si el nodo del que hemos recibido la nueva baliza tiene un TTI menor, enviaremos todos los mensajes que haya en el buffer hacia el siguiente salto. Los argumentos que acepta la cadena de configuración son:

43


- NEIGHBORSTABLE: se trata de un puntero a la función AERORPNeighborsTable, para poder acceder a las funciones "LookForNextHop" y " updateRoutetableEntry" que se encargan de buscar el mejor salto (nodo con menor TTI) y de actualizar la tabla de vecinos respectivamente. - XDEST: define la posición x del nodo destino, en nuestro caso es 5 ya que el nodo destino es fijo en la posición (5, 10, 0). - YDEST: define la posición y del nodo destino, en nuestro caso es 10. - ZDEST: define la posición z del nodo destino, en nuestro caso es 0. - IPADDRESS: define mi dirección IP. - ETHERADDRESS: define mi dirección MAC. - DSTETHERADDRESS: define la dirección MAC del destino. - BUFFER: se trata de un puntero a la función AERORPBuffer, que me permite insertar los mensajes en el buffer cuando yo soy el nodo con menor TTI a la espera de un nodo mejor, y sacar los mensajes del buffer cuando encuentro un nodo con mejor TTI que el mío. - NODE: es un entero, que almacena el número del nodo.

5.2.4- Elemento AERORPBeaconGenerator

Este elemento posee un sólo puerto de salida de tipo push. Genera paquetes baliza periódicamente para anunciar la presencia de un nodo con su posición y velocidad actualizadas y los envía a la red. Éste paquete posee cabecera Ethernet, cabecera IP y cabecera AERORP con la opción de baliza.

Posee un temporizador que indica a la frecuencia a la que los paquetes baliza son enviados, se trata de la constante "AERORP_BEACON_INTERVAL" que se encuentra definida en el fichero de cabecera click_aerorp.hh, en nuestro caso cada 100 ms, aunque puede ser variable. Los argumentos que acepta la cadena de configuración son: - GPSUDPTABLE: puntero a la función AERORPGPSUDPTable, para mantener actualizada la posición y velocidad de cada nodo llamando a la funcion " getPosition" y "getVelocity" respectivamente.

Figura 18. Elemento

AERORPBeaconGenerator

44


- IPADDRESS: define mi dirección IP. - ETHERADDRESS: define mi dirección MAC. - DSTETHERADDRESS: define la dirección MAC del destino. - NODE: es un entero, que almacena el número del nodo.

5.2.5- Elemento AERORPNeighborsTable

AERORPNeighborsTable Ethernet Timer x y z vx vy

------ ----- -- -- -- -- --

Este elemento no cuenta con ningún puerto puesto que no procesa paquetes. En cada nodo va a existir una tabla donde se van a almacenar los datos de la posición geográfica de los nodos vecinos de los que se reciba alguna baliza, es decir, aquellos que se encuentran dentro del radio de cobertura. Los campos de dicha tabla son la dirección ethernet del nodo, timer (marca de tiempo), posición del nodo en el eje X, posición en el eje Y, posición en el eje Z, velocidad en el eje X, velocidad en el eje Y. Como se puede observar, son todos los campos de la cabecera común AERORP más la dirección Ethernet. Es necesario conocer la dirección Ethernet de los vecinos para poder retransmitir el paquete de nodo en nodo siguiendo un puente multisalto entre origen y destino. Este elemento va a tener todas las funciones necesarias para obtener los datos de cada vecino, así como para eliminar y añadir nuevas entradas en la tabla. El timer sirve para eliminar automáticamente la entrada de la tabla pasado un cierto tiempo de caducidad, definido por "AERORP_NEIGHBOR_CACHE_TIMEOUT" que es una constante, en nuestro caso cada 120 ms. Este elemento se encarga de insertar nuevos nodos en la tabla en el caso en el que aún ese nodo no exista o haya sido eliminada su entrada porque el tiempo ha expirado, o de actualizar el nodo, si ese nodo ya existe en la tabla, con la nueva posición cuando ha recibido una nueva baliza.

Figura 19. Elemento AERORPNeighborsTable

45


En este elemento es definida la función "LookForNextHop" que se encarga de calcular el TTI de cada nodo que hay en la tabla de vecinos y del propio nodo, llamando a la función "calculateTTI", para buscar el siguiente salto (nodo con menor TTI) y encaminar los mensajes hacía el. El argumento que acepta en la cadena de configuración es: - ETHERADDRESS: define mi dirección MAC.

5.2.6- Elemento AERORPBuffer

AERORPBuffer Index Timer Packet

-- -- --

Este elemento no cuenta con ningún puerto puesto que no procesa paquetes. En el caso de tener que enviar un mensaje y no tener ninguna entrada en la tabla de vecinos o ninguna de las que se tiene es un nodo mejor que yo, entonces hay que encolar el paquete en un buffer hasta que se encuentre un nodo vecino adecuado. El buffer se comporta como una cola FIFO (First In, First Out). Va a guardar una lista con todos los paquetes pendientes de envíar. Dispone de varias funciones para obtener, añadir y eliminar mensajes del buffer. Los campos de los que se compone son un índice que identifica el paquete dentro del buffer, una marca de tiempo (timer) que sirve para eliminar el paquete cuando el buffer se llena para ello llamaremos a la función "deleteBuf" definida en este mismo elemento (en nuestro caso ésto ocurre cuando pasa un tiempo definido por la constante definida en el fichero de cabecera click_aerorp.hh "AERO_RP_SEND_BUFFER_TIMEOUT " que la fijamos en 30 segundos), el orden de eliminación es el primero que se insertó en el buffer es el primero en ser borrado, y el paquete en sí que desea ser almacenado en el buffer. La cadena de configuración acepta sólo un argumento: - NODE: es un entero, que almacena el número del nodo.

5.3- Unión de los elementos de Click Modular Router La forma de ensamblar los diferentes elementos que se han descrito en el apartado 1.3 es mediante un archivo de configuración. Éste se puede entender como un grafo dirigido

Figura 20. Elemento AERORPBuffer

46


en el que los vértices son elementos y las aristas, indican las conexiones entre ellos. Por lo tanto, la forma de procesar los paquetes depende de cómo se conectan los elementos entre sí y del orden en el que son colocados. El archivo de configuración de la implementación y el esquema del grafo resultante se pueden consultar en el apéndice C.

5.4- Fichero de cabecera El fichero de cabecera está compuesto por las estructuras de datos y las definiciones de las constantes necesarias, e incluye las librerias de las que se hace uso. En el Apéndice D se puede observar el código completo de este fichero de cabecera.

5.4.1- Cabecera AERORP y sus opciones

Cuando se quiere enviar un mensaje desde un nodo origen a un nodo destino, al usar AeroRP como protocolo de enrutamiento es necesario añadir una nueva cabecera al mensaje. Esta cabecera se inserta entre la cabecera IP y el mensaje recibido de la Capa de Transporte. La cabecera AeroRP tiene una longitud variable, ya que se puede estar enviando un mensaje de baliza, en cuyo caso la cabecera incluiría la opción de BALIZA; o un mensaje de datos, en cuyo caso además de la opción de BALIZA se incluye una opción de DATOS. La cabecera AeroRP tendría los siguientes campos:

ETHERNET IP Próxima

cabecera

Longitud

opciones

Opción

datos

Opción

baliza

DATOS

14B 20B 1B 2B 26B 41B

• Proxima cabecera: Indica cuál es la primera cabecera que existe en el campo DATOS. • Longitud: Indica la longitud de las opciones. Para poder definir este estilo de cabecera, se crea la siguiente estructura:

struct click_aerorp {

unsigned char next_header;

unsigned short len;

};

Figura 21. Campos cabecera AeroRP

47


Cuando lo que se quiere enviar es un dato, hay que añadir la opción de DATOS. Esta opción consta de los siguientes campos.

Tipo Longitud Coordenada X Coordenada Y Coordenada Z

1B 1B 8B 8B 8B

• Tipo: Para diferenciar si se trata de una opción u otra (datos o baliza).

• Longitud: Indica la longitud de la Traza (nodos recorridos por un mensaje). • Coordenada X: Indica la posicion en el eje X del destino del mensaje. • Coordenada Y: Indica la posicion en el eje Y del destino del mensaje. • Coordenada Z: Indica la posicion en el eje Z del destino del mensaje. Para definir esta opcion de DATOS, se crea la siguiente estructura:

En cualquier caso, ya sea para enviar un mensaje de datos o enviar una baliza, hay que

incluir la opción de BALIZA. Esta opción consta de los siguientes campos:

Tipo Coordenada X Coordenada Y Coordenada Z Velocidad X Velocidad Y

1B 8B 8B 8B 8B 8B

• Tipo: Para diferenciar si se trata de una opción u otra. • Coordenada X: Indica la posición en el eje X del nodo que envía el mensaje. • Coordenada Y: Indica la posición en el eje Y del nodo que envía el mensaje. • Coordenada Z: Indica la posición en el eje Z del nodo que envía el mensaje. • Velocidad X: Indica la velocidad en el eje X del nodo que envía el mensaje. • Velocidad Y: Indica la velocidad en el eje Y del nodo que envía el mensaje.

struct click_aerorp_data{

unsigned char type;

unsigned char len_trace;

double x;

double y;

double z;

};

Figura 22. Campos cabecera AeroRP opción datos

Figura 23. Campos cabecera AeroRP opción baliza

48


Para definir esta opción de BALIZA, se crea la siguiente estructura:

Para poder diferenciar los dos tipos de opciones, se han definido las siguientes constantes:

Para saber la hora local de la máquina empleamos la función gettimeofday() ya definida en la biblioteca time de c++ y la convertimos en milisegundos para obtener una mayor precisión del tiempo:

5.5- Fichero fuente 5.5.1- Tabla de vecinos

En cada nodo se construye una tabla donde se van a ir guardando los nodos cercanos de los que se reciban alguna baliza. Para definir esta tabla, es necesario crear dos estructuras, una de ellas corresponde a la tabla en sí que para construirla usaremos "hashmap", esto es, una estructura que asocia una clave a un valor y la otra a las entradas de la tabla. La tabla de vecinos se define de la siguiente forma:

struct click_aerorp_beacon{

unsigned char type;

double x;

double y;

double z;

double vx;

double vy;

};

#define AERORP_TYPE_BEACON 0

#define AERORP_TYPE_DATA 1

typedef HashMap<EtherAddress, node_parameters>

NeighborMap;

static double getTimeMilliseconds() { struct timeval timestamp; gettimeofday(&timestamp, NULL); return (timestamp.tv_sec * 1000 + timestamp.tv_usec / 1000.0); }

49


En nuestra implementación la clave ("key") será la dirección ethernet del nodo correspondiente y el valor ("value") serán los campos de la estructura que define cada nodo de la tabla de vecinos. Para acceder a un nodo determinado de la tabla lo haremos a través de su dirección ethernet. Los tiempos de acceso y búsqueda al elemento son rápidos ya que no depende del número de elementos de la estructura. Cada una de las entradas de la tabla de vecinos se define con la siguiente estructura:

• timer: Indica el tiempo en el que se creó la entrada. • x: Indica la coordenada del eje X del nodo vecino. • y: Indica la coordenada del eje Y del nodo vecino. • z: Indica la coordenada del eje Z del nodo vecino. • vx: Indica la velocidad en el eje X del nodo vecino. • vy: Indica la velocidad en el eje Y del nodo vecino.

5.5.2- Buffer de espera

En el caso de tener que enviar un mensaje y no tener ninguna entrada en la tabla de vecino o ninguna de las que se tiene cumple con los requisitos necesarios, entonces hay que guardar el mensaje en un buffer hasta que se encuentre un nodo vecino adecuado al que enviar dicho mensaje. Al igual que con la tabla de vecino, es necesario crear dos estructuras. Una de ellas corresponde al buffer en sí y la otra a las entradas del buffer. El buffer de espera se define con la siguiente estructura:

En nuestra implementación la clave ("key") será un entero que corresponde el índice que identifica el paquete dentro del buffer y el valor ("value") serán los campos de la estructura que define cada entrada del buffer. Para acceder a un nodo determinado de la tabla lo haremos a través de su identificador. Los tiempos de acceso y búsqueda al elemento son rápidos ya que no depende del número de elementos de la estructura.

struct node_parameters{

Timer *timer;

double x;

double y;

double z;

double vx;

double vy;

};

typedef HashMap<int, WaitingPackets> Buffer;

50


Cada una de las entradas del buffer se define con la siguiente estructura:

• timer: Indica el tiempo en el que se creó la entrada. • packets: Es un puntero al paquete con el que desea trabajar el buffer.

struct WaitingPackets {

Timer *timer;

Packet *packets;

};

51


6.1- Introducción al entorno de pruebas

Para evaluar la implementación realizada se ha optado por la utilización de un software de virtualización. Un sistema virtual por software es un programa que simula un sistema físico (un ordenador o un dispositivo hardware) con unas características de hardware determinadas. A este sistema virtual se le llama máquina virtual. Cuando se ejecuta una máquina virtual, ésta proporciona un entorno de ejecución similar a un ordenador físico, con CPU, BIOS, tarjeta gráfica, memoria RAM, tarjeta de red, sistema de sonido, conexión USB, disco duro, etc. Se ha elegido el software de virtualización VirtualBox v.4.2.18 para virtualizar el entorno de pruebas, debido a que las máquinas virtuales soportan una gran variedad de sistemas operativos, incluido Linux con el kernel utilizado para ejecutar Click Modular Router. Además, hay que añadir la sencillez con la que se maneja, que es totalmente gratuito y la gran cantidad de documentación disponible. Por lo tanto, lo que conseguimos con VirtualBox v.4.2.18 es ejecutar varios ordenadores o máquinas virtuales (cada una de ellas independiente del resto) dentro de un mismo hardware de manera simultánea. De esta manera, podemos crear un entorno virtual de pruebas en un único ordenador. Por otro lado, VirtualBox v.4.2.18 permite crear redes virtuales a las que las máquinas virtuales se pueden conectar. Esto permite emular la interconexión de distintas máquinas virtuales en diferentes topologías de red. Estas redes pueden ser completamente virtuales o pueden estar conectadas a alguna de las interfaces de red del ordenador físico donde se

ejecuta el software de virtualización.

6.1.1- Descripción de las máquinas virtuales

Para realizar las pruebas se ha utilizado un tipo de máquina virtual con las siguientes características:

CAPÍTULO 6: Evaluación de

la implementación

52


Sistema operativo: Linux Ubuntu 12.04

Número de procesadores: 4

Versión de kernel de Linux: 3.8.0-37-generic

Memoria RAM: 4096 MB.

Disco duro de 15 GB. Disponemos de cuatro tipos de nodos diferentes: -Nodo Gestión. Lanza un script que fija la tabla ARP con todos los nodos que van a ser utilizados

en la implementación y su IP correspondiente. En el mismo script lanza una aplicación que genera envía paquetes UDP cada

100 ms a los nodos intermedios para fijar sus posiciones que van variando a lo largo del escenario y al nodo origen que mantiene fija su posición en la coordenada (5,0).

-Nodo Origen. Tiene una posición fija (5,0) fijada por la aplicación del nodo gestión.

Lanza un script con una aplicación que genera paquetes UDP que son los que

van a ser encaminados hasta un nodo destino con el protocolo de enrutamiento AERORP.

En el mismo script también ejecuta el código click de la implementación.

-Nodo Destino. Tiene una posición fija (5,10) fijada en el archivo de configuración click de cada

nodo intermedio y del nodo origen. Lanza un script con una aplicación que recibe los paquetes UDP enviados por el

nodo origen y contabiliza los paquetes recibidos y los paquetes perdidos para así poder realizar las estadísticas necesarias sobre paquetes perdidos.

-Nodos Intermedios. Tienen posiciones variables que van actualizándose por los paquetes UDP

recibidos del nodo gestión.

53


Lanzan un script que ejecuta el código click de la implementación.

Para la interconexión de las distintas máquinas virtuales se ha definido una red virtual: - La red 192.168.7.X con topología en bus. A esta red se encuentran conectadas todas las máquinas virtuales por una de sus interfaces. Esta red es la que se utiliza para llevar el control de las máquinas virtuales al realizar las pruebas y para la sincronización de éstas. Debido al bajo rendimiento que provoca en el equipo tener tantas máquinas virtuales ejecutándose al mismo tiempo, hemos decidido lanzar la ejecución de las máquinas virtuales sin un entorno gráfico. Para ello cuando estamos dentro de una máquina virtual presionamos: Ctrol + Alt + Fn, donde n es un entero entre 1 y 6. Si queremos volver al modo gráfico de la máquina virtual presionamos: Alt + F7. Todos estos scripts y la explicación de las aplicaciones programadas podemos encontrarlo en el apéndice B.

6.1.2- Control en la realización de las pruebas

Existen tres problemas a la hora de realizar las pruebas: la sincronización temporal entre diferentes máquinas virtuales para toma de medidas de tiempo, hacer saber a los nodos de la red MANET cuál es su posición inicial y saber el número de paquetes enviados por el nodo origen y los recibidos por el nodo destino.

6.1.2.1- Sincronización temporal de las máquinas virtuales

Si se desean realizar medidas de tiempo que vinculen a más de un nodo de la red es necesario sincronizar sus relojes. Para ello, se ha utilizado el protocolo PTP (Precision Time Protocol. PTP es un protocolo parecido a NTP (Network Time Protocol) pero que sirve para sincronizar los relojes de diferentes máquinas entre sí a través de una red, pero obteniendo precisiones mayores. PTP permite alcanzar precisiones de sincronismo por debajo del orden de microsegundos. En la realización de las pruebas, se instaló el demonio PTPd (Precision Time Protocol daemon) en todas las máquinas para la sincronización con la máquina gestión. La guía de instalación podemos verla en el apéndice A.

6.1.2.2- Generador de posiciones

En el nodo gestión hemos creado dos aplicaciones la primera se encarga de leer de un fichero (IpNodes.dat) y asignar a cada nodo una dirección IP fija, y la segunda que se encarga de leer de un fichero (PositionsFile.dat) las posiciones actualizadas de los nodos y enviarlas cada 100 ms al nodo correspondiente (ésto es posible porque conocemos la dirección IP asociada a cada nodo) a través de un mensaje UDP que es recibido por la función

54


AERORPGPSUDPTable y ésta se encarga de extraer los datos de las coordenadas de posición del nodo en cada momento y actualizar la posición del nodo para transmitir el mensaje baliza correctamente. El formato del mensaje UDP que genera ésta aplicación es el siguiente:

DATA

ETHERNET IP UDP X Y Z Timestamp

14B 20B 8B 4B 4B 4B 4B Figura 24. Formato mensaje UDP que genera el nodo gestión.

El tamaño total del paquete es de 58 bytes.

6.1.2.3- Recopilación de paquetes enviados y recibidos.

En el nodo origen creamos una aplicación que se encarga de realizar unas estadísticas con el número de paquetes enviados por el nodo origen y que queremos hacer llegar hacia el nodo destino y el tiempo total que se tarda en realizar la simulación. En el nodo destino creamos una aplicación que realiza unas estadísticas sobre los paquetes que han llegado al destino y los que se han perdido, el tiempo total de la simulación y el índice del primer y último paquete recibido. El formato del mensaje enviado por la aplicación origen es:

ETHERNET IP UDP DATA

14B 20B 8B 112B

Figura 25. Formato mensaje UDP que genera la aplicación del nodo origen.

El tamaño total del paquete es de 154 bytes.

6.2- Pruebas realizadas y resultados

Para la realización de experimentos y comparativas se ha usado un entorno de pruebas controlado que abarca diferentes escenarios. A continuación se describen las pruebas realizadas y los resultados obtenidos.

55


6.2.1- Primer experimento: medida del número de paquetes

perdidos

Para este primer experimento hemos sacado unas estadísticas de los paquetes enviados, recibidos, guardados y perdidos por cada nodo. Donde: Packets Sent: número de paquetes enviados por la aplicación del nodo origen.

Sent Dest: número de paquetes reenviados al destino directamente. Observamos que

en el nodo origen los paquetes enviados al destino siempre son 0. Ésto se debe a que el nodo origen y el nodo destino están en una posición fija y el rango de alcance siempre es menor que la distancia entre dichos nodos.

Sent Inter: número de paquetes reenviados a un nodo intermedio para continuar con el enrutamiento.

Save Buffer: número de paquetes almacenados en el buffer a la espera de un nodo mejor al que enviar el mensaje.

Rcv Packets: número de paquetes recibidos en el nodo tanto IP como AERORP.

Del Buffer: número de paquetes sacados del buffer ya sea para reenviarlos a otro nodo o porque expira el timeout del paquete.

Exp Buffer: número de paquetes eliminados del buffer porque expira su timeout.

Out_Range: número de paquetes desechados debido a que si tenemos un un nodo X que recibe una baliza de un nodo Y con un TTI menor y el nodo X tiene mensajes pendientes de envío, al recibir la baliza los envía al nodo Y, el problema es que entre la transmisión y la recepción de un paquete existe un pequeño retardo y justo cuando el paquete llega al nodo Y la posición se ha actualizado y ahora la distancia entre los nodos es mayor que el rango de alcance AERORP_R y por tanto los paquetes se pierden. A mayor velocidad, mayor es el número de paquetes perdidos debido a que los nodos se mueven más rapidamente.

6.2.1.1- Prueba 1: En función del rango de alcance entre nodos.

Para realizar los experimentos vamos a variar el rango de alcance (AERORP_R) entre nodos para la retransmisión de los paquetes IP, y analizaremos los resultados, éste siempre debe ser menor de 10 ya que si no fuera así el nodo destino estaría dentro del alcance del nodo origen y por tanto no podríamos comprobar que el protocolo AeroRP funciona

56


correctamente ya que se mandarían directamente los mensajes desde el nodo origen al nodo destino sin pasar por ninguno de los nodos intermedios. - Descripción del escenario de emulación: Para realizar los experimentos necesarios hemos creado 6 máquinas virtuales cada una de ellas representa un nodo, dos de ellos son estacionarios (nodo origen y nodo destino) , tres nodos intermedios con movimiento aleatorio y con una velocidad constante de 0.1 m/s, que parten del punto de coordenada (5,5) y van a comportarse como aeronaves volando por el escenario el cual tiene unas dimensiones de 10x10 metros, y por último tenemos un nodo gestión que se encarga de enviar un mensaje UDP cada 100 ms a los nodos intermedios indicando la posición de cada uno de ellos, éstos al recibir dicho mensaje procedente del nodo gestión actualizan su posición. El nodo origen, fijado en la coordenada (5,0), va a estar enviando, de manera constante y con un intervalo de 500 ms, paquetes de datos IP al nodo destino que está fijado en la coordenada (5,10). Éstos paquetes IP tienen un tamaño fijo de 154 bytes. La emulación tiene una duración aproximada de 30 minutos. El envío de paquetes desde el nodo origen comienza a los 5 segundos de comenzar ésta.

- Análisis de resultados: 1. AERORP_R = 3 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3506 packets -> Sent Dest: 0 packets -> Sent Inter: 1576 packets -> Save Buffer: 3415 packets -> Rcv Packets: 3994 packets -> Del Buffer: 3415 packets -> Exp Buffer: 2418 packets -> Out Range: 0 packets *********************************** NODO INTERMEDIO 1 ********** AeroRP Statistics **********

-> Sent Dest: 9 packets -> Sent Inter: 736 packets -> Save Buffer: 955 packets -> Rcv Packets: 1082 packets -> Del Buffer: 955 packets -> Exp Buffer: 337 packets

57


-> Out Range: 0 packets *********************************** NODO INTERMEDIO 2 ********** AeroRP Statistics **********

-> Sent Dest: 0 packets -> Sent Inter: 381 packets -> Save Buffer: 766 packets -> Rcv Packets: 840 packets -> Del Buffer: 766 packets -> Exp Buffer: 459 packets -> Out Range: 0 packets *********************************** NODO INTERMEDIO 3 ********** AeroRP Statistics **********

-> Sent Dest: 79 packets -> Sent Inter: 382 packets -> Save Buffer: 575 packets -> Rcv Packets: 665 packets -> Del Buffer: 575 packets -> Exp Buffer: 204 packets -> Out Range: 0 packets *********************************** NODO DESTINO ********** AeroRP Statistics **********

-> Packets Received: 88 packets -> Packets Lost: 3418 packets -> First Index: 695 -> Last Index: 2345 -> Total Time: 1800000 ms ***************************************

Podemos observar que el nodo origen envía 3560 paquetes de los cuales tan sólo llegan al destino 88 paquetes y la gran mayoría se pierden por la red (97,49%). Esta emulación no es buena ya que la velocidad a la que se mueven los nodos es pequeña (0,1 m/s), el rango de alcance entre éstos es tan sólo de 3 metros, y sólo tenemos tres nodos intermedios para encaminar el paquete hacia el destino, todo ésto hace que lleguen muy pocos mensajes al nodo destino. 2. AERORP_R = 4 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3535 packets -> Sent Dest: 0 packets -> Sent Inter: 2731 packets -> Save Buffer: 2643 packets

58


-> Rcv Packets: 4131 packets -> Del Buffer: 2643 packets -> Exp Buffer: 1364 packets -> Out Range: 0 packets *********************************** NODO INTERMEDIO 1 ********** AeroRP Statistics **********




-> Packets Received: 915 packets -> Packets Lost: 2620 packets -> First Index: 429 -> Last Index: 3467 -> Total Time: 1800000 ms ************************************

59


Al aumentar el rango de alcance un metro, podemos observar que aumenta el número de paquetes recibidos por el destino, aunque aún se pierden bastantes paquetes por la red (75,12%). Por tanto, seguimos aumentando el rango un poco más para comprobar que a mayor rango de alcance, mejores son los resultados obtenidos. 3. AERORP_R = 5 metros NODO ORIGEN ********** AeroRP Statistics **********




-> Sent Dest: 792 packets -> Sent Inter: 1039 packets -> Save Buffer: 928 packets -> Rcv Packets: 1890 packets -> Del Buffer: 928 packets -> Exp Buffer: 59 packets

60


-> Out Range: 1 packets *********************************** NODO DESTINO ********** AeroRP Statistics **********


Al aumentar el rango de alcance un metro, podemos observar que aumenta considerablemente el número de paquetes recibidos por el destino, aunque aún se pierden bastantes paquetes por la red. Por tanto, seguimos aumentando el rango un poco más para comprobar que a mayor rango de alcance, mejores son los resultados obtenidos. 4. AERORP_R = 6 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3591 packets -> Sent Dest: 0 packets -> Sent Inter: 3502 packets -> Save Buffer: 677 packets -> Rcv Packets: 3627 packets -> Del Buffer: 677 packets -> Exp Buffer: 125 packets -> Out Range: 0 packets ***********************************

NODO INTERMEDIO 1 ********** AeroRP Statistics **********


-> Sent Dest: 932 packets -> Sent Inter: 706 packets -> Save Buffer: 645 packets -> Rcv Packets: 1641 packets -> Del Buffer: 645 packets

61


-> Exp Buffer: 3 packets -> Out Range: 0 packets *********************************** NODO INTERMEDIO 3 ********** AeroRP Statistics **********



Aumentamos el rango un metro más y comprobamos que en este caso llegan al destino más del 95% de los paquetes enviados por el origen, por lo que este resultado ya es bastante bueno para la baja velocidad a la que se mueven los nodos. En la siguiente tabla puede observarse el porcentaje de los paquetes enviados que no consiguen alcanzar el destino en cada una de las emulaciones realizadas en función del rango de alcance de transmisión y recepción de paquetes entre nodos empleando el protocolo de encaminamiento AeroRP a una velocidad de 0.1 m/s.

Paquetes Perdidos (3 nodos)

3 m 4 m 5 m 6 m

97.49 % 75.12% 47.69% 5.04%

Tabla 1. Paquetes perdidos con 3 nodos intermedios moviéndose a velocidad constante de 0.1 m/s.

En la siguiente gráfica representamos cómo varía el porcentaje de paquetes perdidos en función de la distancia AERORP_R, que es la distancia máxima a la que varios nodos pueden transmitir mensajes entre ellos:

62


Gráfica 1. Paquetes perdidos por 3 nodos intermedios a una velocidad constante de 0.1 m/s en función del rango de alcance

Podemos comprobar que a menor rango de alcance entre nodos se pierde un mayor número de paquetes entre origen y destino. Ésto es debido a que al disminuir la distancia máxima entre nodos para recibir balizas la tabla de vecinos se actualiza de una manera menos frecuente con lo que puede que la ruta por la que se decida enviar un paquete de datos en un instante determinado no sea la óptima, y es más probable que el paquete llegue a un nodo que no encuentre el siguiente salto para encaminar el paquete de datos hacia el destino, almacenará el paquete en el buffer, éste expirará al no encontrar un nodo mejor al que reenviar el paquete y finalmente el paquete se perderá en la red.

97,49%

75,12%

47,69%

5,04%

0

20

40

60

80

100

120

3 4 5 6

Paq

ue

tes

pe

rdid

os

[%]

Rango de alcance [m]

Paquetes perdidos en función de la distancia AERORP_R

3 nodos, v = 0,1 m/s

63


Gráfica 2. Paquetes enviados al destino por cada nodo intermedio en función de la distancia AERORP_R.

En la gráfica anterior hemos representado el número de paquetes enviados por cada

nodo intermedio hacia el destino, podemos observar que el nodo 3 es el que envía más

paquetes al destino en todas las emulaciones, ésto quiere decir que es el nodo que tiene

menor TTI durante la mayor parte del tiempo de emulación y que se encuentra más cerca del

destino.

6.2.1.2 - Prueba 2: En función de la velocidad

- Descripción del escenario de emulación: Para este segundo experimento tendremos exactamente el mismo escenario de emulación que en el caso anterior, la única diferencia es que ahora los nodos intermedios aumentan la velocidad con la que se mueven a través del escenario, sigue siendo constante pero en éste caso se mueven a 1 m/s en lugar de 0.1 m/s como en el caso anterior.

- Análisis de resultados: 1. AERORP_R = 3 metros

NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3535 packets -> Sent Dest: 0 packets -> Sent Inter: 5908 packets

9

193

728

1252

0

279

536

932

79

443

792

1226

0

200

400

600

800

1000

1200

1400

3 4 5 6

Nú

me

ro d

e p

aqu

ets

en

viad

os

al d

est

ino


PAQUETES ENVIADOS AL DESTINOEN FUNCIÓN DEL RANGO DE

ALCANCE

Nodo Intermedio 1 Nodo Intermedio 2 Nodo Intermedio 3

64


-> Save Buffer: 5506 packets -> Rcv Packets: 6199 packets -> Del Buffer: 5506 packets -> Exp Buffer: 291 packets -> Out Range: 0 packets *********************************** NODO INTERMEDIO 1 ********** AeroRP Statistics **********





65


Comparando con el resultado del primer experimento para el mismo rango de 3 metros, podemos observar que a mayor velocidad de los nodos intermedios, llegan al destino muchos más paquetes (83.08%), frente al (2.47%) que llegan si los nodos se mueven a menor velocidad. Podemos notar que mejora bastante nuestra emulación ya que los nodos al moverse a mayor velocidad recorren más espacio en menos tiempo. Con este resultado ya es bastante notable la diferencia al aumentar la velocidad pero vamos a variar el rango para comprobar que mejora bastante más. 2. AERORP_R = 4 metros NODO ORIGEN ********** AeroRP Statistics **********




-> Sent Dest: 1048 packets -> Sent Inter: 4109 packets

66


-> Save Buffer: 3586 packets -> Rcv Packets: 5157 packets -> Del Buffer: 3586 packets -> Exp Buffer: 0 packets -> Out Range: 104 packets *********************************** NODO DESTINO ********** AeroRP Statistics **********


Para un rango de 4 metros, podemos observar que a una mayor velocidad de los nodos intermedios, mejora bastante nuestra emulación ya que se pierden muchos menos paquetes a una velocidad mayor, en este caso se pierden el 9,61% de los paquetes frente al 75,45% que se perdieron en el caso de los nodos moviéndose a una velocidad de 0,1 m/s. Este resultado es bastante bueno ya que el porcentaje de paquetes perdidos por la red es bastante pequeño pero realizamos más experimentos con un rango de alcance mayor para afinar un poco más. 3. AERORP_R = 5 metros NODO ORIGEN ********** AeroRP Statistics **********


-> Sent Dest: 1033 packets -> Sent Inter: 2141 packets -> Save Buffer: 1587 packets -> Rcv Packets: 3174 packets -> Del Buffer: 1587 packets -> Exp Buffer: 0 packets -> Out Range: 14 packets ***********************************

67



-> Sent Dest: 1156 packets -> Sent Inter: 2208 packets

-> Save Buffer: 1740 packets -> Rcv Packets: 3364 packets -> Del Buffer: 1740 packets -> Exp Buffer: 0 packets -> Out Range: 28 packets *********************************** NODO INTERMEDIO 3 ********** AeroRP Statistics **********



Con un rango de alcance de 5 metros tenemos una ínfima pérdida de paquetes por la red del 2,87% que como podemos comprobar es bastante más pequeña que en el caso en el que los nodos se mueven a una velocidad constante de 0,1m/s. Este resultado ya es bastante bueno pues que llegan al destino casi todos los paquetes. 4. AERORP_R = 6 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3587 packets -> Sent Dest: 0 packets -> Sent Inter: 3734 packets -> Save Buffer: 738 packets -> Rcv Packets: 3734 packets -> Del Buffer: 738 packets -> Exp Buffer: 0 packets -> Out Range: 0 packets ***********************************

68







Observamos que para un rango de alcance de 6 metros llegan prácticamente todos los paquetes. Las pérdidas son mínimas. Podemos observar que mejora frente a los resultados del experimento anterior, pero la diferencia ya no es tan notable debido a que el rango de alcance entre nodos es grande.

69


En la siguiente tabla puede observarse el porcentaje de los paquetes enviados que no consiguen alcanzar el destino en cada una de las emulaciones realizadas en función del rango de alcance de transmisión y recepción de paquetes entre nodos empleando el protocolo de encaminamiento AeroRP a una velocidad de 1 m/s.


3 m 4 m 5 m 6 m

16.92% 9.61% 2.88 % 0.92 %

Tabla 2. Paquetes perdidos con 3 nodos intermedios moviéndose a velocidad constante de 1 m/s.

En la siguiente gráfica podemos visualizar cómo varia el número de paquetes perdidos por la red en función de la velocidad a la que se mueven los nodos por el escenario.

Gráfica 3. Comparativa de paquetes perdidos de 3 nodos moviéndose a una velocidad de 0.1 m/s frente a 3 nodos moviéndose a una velocidad de 1m/s.

Podemos observar que a mayor velocidad de movimiento de los nodos intermedios menor será el porcentaje de paquetes perdidos. Ésto es debido a que en el mismo tiempo el nodo recorre una distancia mayor y se puede aproximar al destino más rápidamente. Comprobamos entonces que es cierto que si los nodos se mueven a mayor velocidad por el escenario tenemos mejores resultados.

97,49%

75,12%

47,69%

5,04%16,92%

9,61% 2,88%0,92%0

20

40

60

80

100

120

3 4 5 6

Paq

ue

tes

pe

rdid

os

[%]


Paquetes perdidos en función de la velocidad

3 nodos, v = 0,1m/s

3nodos, v = 1m/s

70


Gráfica 4. Paquetes enviados al destino por cada nodo intermedio a v = 1m/s en función de la distancia AERORP_R.

En la gráfica anterior hemos representado el número de paquetes enviados por cada

nodo intermedio hacia el destino, podemos observar que los tres nodos envían

aproximadamente el mismo número de paquetes al destino en todas las emulaciones, salvo

el nodo intermedio 1 que siempre envía menos paquetes, ésto quiere decir que se mueve por

una zona más alejada del destino y que existen nodos con mejor TTI.

6.2.1.3- Prueba 3: En función del número de nodos

- Descripción del escenario de emulación: Para el tercer experimento creamos una nueva máquina virtual que corresponde a un cuarto nodo intermedio que se mueve a una velocidad constante de 0.1 m/s. Los demás nodos también se mueven a esa velocidad constante. La emulación va a tener los mismos parámetros que la prueba 1. Con esto queremos demostrar que cuantos más nodos intermedios tengamos para encaminar los paquetes mayor número de ellos llegarán al destino deseado. Repetimos el mismo proceso que anteriormente, variando el rango de alcance entre nodos y manteniendo la velocidad de los nodos constante a 0.1 m/s.

353

964 1033 10641231 1222 1156 1164

1353

1048

12801326

0

500

1000

1500

3 4 5 6

Nú

me

ro d

e p

aqu

ets

en

viad

os

al d

est

ino


PAQUETES ENVIADOS AL DESTINO DESDE LOS NODOS INTERMEDIOS


71



-> Packets Sent: 3474 packets -> Sent Dest: 0 packets -> Sent Inter: 2239 packets -> Save Buffer: 3305 packets -> Rcv Packets: 4189 packets -> Del Buffer: 3305 packets -> Exp Buffer: 1950 packets -> Out Range: 0 packets ************************************ NODO INTERMEDIO 1 ********** AeroRP Statistics **********




72





Comparando con el resultado del primer experimento para el mismo rango de 3 metros, podemos observar que a mayor número de nodos intermedios, llegan al destino algunos paquetes más (4.26%), frente al 2.51% que llegan si solo hay tres nodos intermedios. Este rango es bastante pequeño por lo que no se nota mucho la mejora. Vamos a variar el rango para comprobar que mejora bastante más. 2. AERORP_R = 4 metros NODO ORIGEN ********** AeroRP Statistics **********



73







Para un rango de 4 metros, podemos observar que a un mayor número de nodos intermedios, mejora bastante nuestra emulación ya que se pierden muchos menos paquete, en este caso se pierden el 57,46% de los paquetes frente al 75,12% que se perdieron en el caso de tres nodos intermedios. Podemos notar que mejora bastante nuestra emulación ya que al existir más nodos existen más posibilidades de reenvío de paquetes hacía el destino.

74


Con este resultado ya es notable la diferencia al aumentar un nodo más pero vamos a variar el rango para comprobar que mejora bastante más. 3. AERORP_R = 5 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3546 packets -> Sent Dest: 0 packets -> Sent Inter: 3499 packets -> Save Buffer: 1389 packets -> Rcv Packets: 3862 packets -> Del Buffer: 1389 packets -> Exp Buffer: 363 packets -> Out Range: 0 packets *************************************** NODO INTERMEDIO 1 ********** AeroRP Statistics **********




75





Con un rango de alcance de 5 metros tenemos una pequeña pérdida de paquetes por la red del 12,21% que como podemos comprobar es bastante más pequeña que en el caso de tres nodos 47,69%. Este resultado es bastante bueno ya que el porcentaje de paquetes perdidos por la red es bastante pequeño pero realizamos más experimentos con un rango de alcance mayor para afinar un poco más. 4. AERORP_R = 6 metros NODO ORIGEN ********** AeroRP Statistics **********



76







Observamos que para un rango de alcance de 6 metros llegan prácticamente todos los paquetes. Las pérdidas son mínimas. Podemos observar que mejora frente a los resultados del experimento anterior, pero la diferencia ya no es tan notable debido a que el rango de alcance entre nodos es grande. Este resultado ya es bastante bueno puesto que llegan al destino casi todos los paquetes.

77


En la siguiente tabla puede observarse el porcentaje de los paquetes enviados que no consiguen alcanzar el destino en cada una de las emulaciones realizadas en función del rango de alcance de transmisión y recepción de paquetes entre nodos empleando el protocolo de encaminamiento AeroRP con cuatro nodos intermedios a una velocidad de 0.1 m/s.


3 m 4 m 5 m 6 m

95.74% 57.46% 12.21% 0.45%


Gráfica 5. Paquetes enviados al destino por cada nodo intermedio a v= 0.1m/s en función de la distancia AERORP_R.

En la gráfica anterior hemos representado el número de paquetes enviados por cada nodo intermedio hacia el destino, podemos observar que en un rango pequeño (3 metros) llegan muy pocos paquetes al destino que son enviados prácticamente todos por el nodo 1 y el nodo 3, éstos durante la emulación son los nodos que han estado al alcance del destino con mejor TTI. Para 4 metros vemos que los cuatro nodos mandan aproximadamente el mismo número de paquetes al destino. Para 5 metros, el nodo 4 es el nodo que más paquetes reenvía porque posee mejor TTI y se encuentra en el rango del alcance del destino. Para 6 metros, el nodo que más paquetes envía es el 1. - Descripción del escenario de emulación: Para el cuarto experimento creamos una nueva máquina virtual que corresponde a un quinto nodo intermedio que se mueve a una velocidad constante de 0.1 m/s. Los demás

68

351

658

1130

2

321

578

749

78

479

837919

0

357

1040

775

0

200

400

600

800

1000

1200

3 4 5 6

Nú

me

ro d

e p

aqu

ete

s e

nvi

ado

s al

de

stin

o



Nodo Intermedio 1 Nodo Intermedio 2 Nodo Intermedio 3 Nodo Intermedio 4

78


nodos también se mueven a esa velocidad constante. La emulación va a tener los mismos parámetros que el primer experimento. Con esto queremos demostrar que cuantos más nodos intermedios tengamos para encaminar los paquetes mayor número de ellos llegarán al destino deseado. Repetimos el mismo proceso que anteriormente, variando el rango de alcance entre nodos y manteniendo la velocidad de los nodos constante a 0.1 m/s.



-> Sent Dest: 207 packets -> Sent Inter: 1606 packets -> Save Buffer: 1475 packets -> Rcv Packets: 2085 packets -> Del Buffer: 1475 packets -> Exp Buffer: 272 packets -> Out Range: 128 packets ******************************** NODO INTERMEDIO 2 ********** AeroRP Statistics **********


79






-> Packets Received: 725 packets -> Packets Lost: 2804 packets -> First Index: 315 -> Last Index: 3527 -> Total Time: 1800000 ms ***********************************

Comparando con el resultado del primer experimento para el mismo rango de 3 metros y con el experimento anterior podemos observar que a mayor número de nodos intermedios llegan al destino un mayor número de paquetes: con cinco nodos llega un 20.55%, frente al 4.26% que llegan si hay cuatro nodos intermedios o al 2.51% si hay solo tres nodos. Vemos que entre tres y cuatro nodos no hay mucha diferencia, pero ya con cinco nodos vemos que llegan bastante más paquetes. Vamos a variar el rango para comprobar que mejora bastante más.

80


2. AERORP_R = 4 metros NODO ORIGEN ********** AeroRP Statistics **********





81






Para un rango de 4 metros, podemos observar que a un mayor número de nodos intermedios, mejora bastante nuestra emulación ya que se pierden muchos menos paquetes, en este caso se pierden el 35.42% de los paquetes frente al 57.46% para cuatro nodos o al 75.12% que se perdieron en el caso de tres nodos intermedios. Podemos notar que mejora bastante nuestra emulación ya que al existir más nodos existen más posibilidades de reenvío de paquetes hacía el destino. Con este resultado ya es notable la diferencia al aumentar un nodo más pero vamos a variar el rango para comprobar que mejora bastante más. 3. AERORP_R = 5 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3548 packets -> Sent Dest: 0 packets -> Sent Inter: 3295 packets -> Save Buffer: 926 packets -> Rcv Packets: 3603 packets

82


-> Del Buffer: 926 packets -> Exp Buffer: 308 packets -> Out Range: 0 packets *************************************** NODO INTERMEDIO 1 ********** AeroRP Statistics **********





83





Con un rango de alcance de 5 metros tenemos una pequeña pérdida de paquetes por la red del 9.18% que como podemos comprobar es bastante más pequeña que en el caso de tres nodos 47,69%. Este resultado es bastante bueno ya que el porcentaje de paquetes perdidos por la red es bastante pequeño pero realizamos más experimentos con un rango de alcance mayor para afinar un poco más. 4. AERORP_R = 6 metros NODO ORIGEN ********** AeroRP Statistics **********



84







NODO DESTINO ********** AeroRP Statistics **********

-> Packets Received: 3582 packets -> Packets Lost: 2 packets

85


-> First Index: 0 -> Last Index: 3638 -> Total Time: 1800000 ms ************************************

Observamos que para un rango de alcance de 6 metros con cinco nodos intermedios se pierde una ínfima parte de paquetes. Podemos observar que mejora frente a los resultados del experimento anterior, pero la diferencia ya no es tan notable debido a que el rango de alcance entre nodos es grande. El resultado es casi perfecto pues sólo se pierde un 0.05% de los paquetes enviados por el nodo origen. En la siguiente tabla puede observarse el porcentaje de los paquetes enviados que no consiguen alcanzar el destino en cada una de las emulaciones realizadas en función del rango de alcance de transmisión y recepción de paquetes entre nodos empleando el protocolo de encaminamiento AeroRP con cinco nodos intermedios a una velocidad de 0.1 m/s.


3 m 4 m 5 m 6 m

79.45% 35.42% 9.18% 0.05%


Gráfica 6. Comparativa de paquetes perdidos de varios nodos moviéndose a v=0.1m/s.

Podemos observar gráficamente que a mayor número de nodos moviéndose por el escenario, mejor serán los resultados, es decir, llegarán al destino un mayor número de paquetes, ésto se debe a que al existir más nodos existen más posibilidades de reenvío de paquetes hacía el destino.

95,74%

57,46%

12,21%

0,45%

97,49%

75,12%

47,69%

5,04%

79,45%

35,42%

9,18%0,05%

0

20

40

60

80

100

120

3 4 5 6

Paq

ue

tes

pe

rdid

os

[%]


Paquetes perdidos en función del número de nodos

3 nodos, v=0.1m/s

4 nodos, v=0.1m/s

5 nodos, v=0.1 m/s

86


Gráfica 7. Paquetes enviados al destino por cada nodo intermedio a v= 0.1m/s en función de la distancia AERORP_R.

En la gráfica anterior hemos representado el número de paquetes enviados por cada nodo intermedio hacia el destino, podemos observar a grandes rasgos que el nodo que más paquetes envía es el nodo intermedio 3, ésto quiere decir que el nodo 3 es el que tiene un TTI menor durante la mayor parte del tiempo de la emulación. Y el nodo que menos paquetes envía hacia el destino es el nodo 2.

6.2.1.4- Prueba 4: En función del número de nodos y de la velocidad - Descripción del escenario de emulación: En el cuarto experimento tenemos exactamente el mismo escenario de emulación que

en el caso anterior, la única diferencia es que ahora los nodos intermedios aumentan su

velocidad, sigue siendo constante pero en este caso se mueven a 1 m/s en lugar de 0.1m/s

como en el caso anterior.

Con esta prueba combinamos ambos experimentos realizados anteriormente, queremos demostrar que cuantos más nodos intermedios tengamos para encaminar los paquetes mayor número de ellos llegarán al destino deseado y que a mayor velocidad también perderemos menos paquetes. Repetimos el mismo proceso que anteriormente, variando el rango de alcance entre nodos y manteniendo la velocidad de los nodos constante a 1 m/s.

207

473 525

804

242

643 690

838

140

537

748666

2

236

517604

134

399

742670

0

200

400

600

800

1000

3 4 5 6

Nú

me

ro d

e p

aqu

ete

s e

nvi

ado

s al

de

stin

o




Nodo Intermedio 4 Nodo Intermedio 5

87




-> Sent Dest: 333 packets -> Sent Inter: 4365 packets -> Save Buffer: 3919 packets -> Rcv Packets: 4698 packets -> Del Buffer: 3919 packets -> Exp Buffer: 0 packets -> Out Range: 111 packets ******************************** NODO INTERMEDIO 2 ********** AeroRP Statistics **********



88





Comparando con el resultado de la segunda prueba para el mismo rango de 3 metros, podemos observar que a mayor número de nodos intermedios, llegan al destino algunos paquetes más (4.26%), frente al 2.51% que llegan si solo hay tres nodos intermedios. Este rango es bastante pequeño por lo que no se nota mucho la mejora. Vamos a variar el rango para comprobar que mejora bastante más. 2. AERORP_R = 4 metros NODO ORIGEN ********** AeroRP Statistics **********


-> Sent Dest: 756 packets -> Sent Inter: 2887 packets -> Save Buffer: 2296 packets -> Rcv Packets: 3643 packets -> Del Buffer: 2296 packets -> Exp Buffer: 0 packets -> Out Range: 16 packets

89


*********************************** NODO INTERMEDIO 2 ********** AeroRP Statistics **********




-> Packets Received: 3412 packets -> Packets Lost: 157 packets -> First Index: 0 -> Last Index: 3568 -> Total Time: 1800000 ms ************************************ 3. AERORP_R = 5 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3577 packets -> Sent Dest: 0 packets

90


-> Sent Inter: 3901 packets -> Save Buffer: 1335 packets -> Rcv Packets: 3901 packets -> Del Buffer: 1335 packets -> Exp Buffer: 0 packets -> Out Range: 3 packets *************************************** NODO INTERMEDIO 1 ********** AeroRP Statistics **********




-> Sent Dest: 998 packets -> Sent Inter: 1326 packets -> Save Buffer: 806 packets -> Rcv Packets: 2324 packets -> Del Buffer: 806 packets

91


-> Exp Buffer: 0 packets -> Out Range: 32 packets *********************************** NODO DESTINO ********** AeroRP Statistics **********

-> Packets Received: 3447 packets -> Packets Lost: 130 packets -> First Index: 0 -> Last Index: 3576 -> Total Time: 1800000 ms ************************************ 4. AERORP_R = 6 metros NODO ORIGEN ********** AeroRP Statistics **********




92







3 m 4 m 5 m 6 m

16.86% 4.39% 3.63% 1.14%


- Descripción del escenario de emulación: Para el cuarto experimento creamos una nueva máquina virtual que corresponde a un quinto nodo intermedio que se mueve a una velocidad constante de 0.1 m/s. Los demás nodos también se mueven a esa velocidad constante. La emulación va a tener los mismos parámetros que el primer experimento. Con esto queremos demostrar que cuantos más nodos intermedios tengamos para encaminar los paquetes mayor número de ellos llegarán al destino deseado.

93


Repetimos el mismo proceso que anteriormente, variando el rango de alcance entre nodos y manteniendo la velocidad de los nodos constante a 0.1 m/s. - Análisis de resultados: 1. AERORP_R = 3 metros NODO ORIGEN ********** AeroRP Statistics **********


-> Sent Dest: 217 packets -> Sent Inter: 3451 packets -> Save Buffer: 2920 packets -> Rcv Packets: 3668 packets -> Del Buffer: 2920 packets -> Exp Buffer: 0 packets -> Out Range: 144 packets ************************************ NODO INTERMEDIO 2 ********** AeroRP Statistics **********


-> Sent Dest: 1079 packets -> Sent Inter: 3454 packets -> Save Buffer: 3088 packets -> Rcv Packets: 4533 packets

94


-> Del Buffer: 3088 packets -> Exp Buffer: 0 packets -> Out Range: 169 packets *********************************** NODO INTERMEDIO 4 ********** AeroRP Statistics **********




Comparando para el mismo rango de 3 metros podemos observar que a mayor número de nodos intermedios llegan al destino un mayor número de paquetes: con cinco nodos llega un 84.08%, frente al 83.14% que llegan si hay cuatro nodos intermedios o al 83.08% si hay solo tres nodos. Vemos que no hay mucha diferencia ya que a esa velocidad el número de paquetes que llegan al destino es bastante elevado. Vamos a variar el rango para comprobar que mejora más.

95


2. AERORP_R = 4 metros NODO ORIGEN ********** AeroRP Statistics **********





96






Para un rango de 4 metros, podemos observar que a un mayor número de nodos intermedios, mejora nuestra emulación, en este caso se pierden el 3.88% de los paquetes frente al 4.39% para cuatro nodos o al 9.61% que se perdieron en el caso de tres nodos intermedios. Podemos notar que mejora nuestra emulación ya que al existir más nodos existen más posibilidades de reenvío de paquetes hacía el destino, aunque en los tres casos al moverse los nodos a una velocidad de 1 m/s las pérdidas son mínimas. 3. AERORP_R = 5 metros NODO ORIGEN ********** AeroRP Statistics **********

-> Packets Sent: 3565 packets -> Sent Dest: 0 packets -> Sent Inter: 3709 packets -> Save Buffer: 915 packets -> Rcv Packets: 3709 packets

97


-> Del Buffer: 915 packets -> Exp Buffer: 0 packets -> Out Range: 3 packets *************************************** NODO INTERMEDIO 1 ********** AeroRP Statistics **********





98





Con un rango de alcance de 5 metros tenemos una pequeña pérdida de paquetes por la red del 2.97%. Este resultado es bastante bueno ya que el porcentaje de paquetes perdidos por la red es bastante pequeño pero realizamos más experimentos con un rango de alcance mayor para afinar un poco más. 4. AERORP_R = 6 metros NODO ORIGEN ********** AeroRP Statistics **********



99







-> Packets Received: 353 packets -> Packets Lost: 48 packets -> First Index: 0

100


-> Last Index: 3638 -> Total Time: 1800000 ms ************************************

Observamos que para un rango de alcance de 6 metros con cinco nodos intermedios se pierde una ínfima parte de paquetes. Podemos observar que la diferencia con respecto al experimento anterior ya no es tan notable debido a que el rango de alcance entre nodos es grande. El resultado es casi perfecto pues sólo se pierde un 1.34% de los paquetes enviados por el nodo origen. En la siguiente tabla puede observarse el porcentaje de los paquetes enviados que no consiguen alcanzar el destino en cada una de las emulaciones realizadas en función del rango de alcance de transmisión y recepción de paquetes entre nodos empleando el protocolo de encaminamiento AeroRP con cinco nodos intermedios a una velocidad de 1 m/s.


3 m 4 m 5 m 6 m

% 3.88% 2.97% 1.34%


Gráfica 8. Comparativa de paquetes perdidos de varios nodos moviéndose a v=1m/s.

16,92%

9,61%

2,88%0,92%

16,86%

4,39% 3,63%

1,14%

15,92%

3,88%2,97%

1,34%0

2

4

6

8

10

12

14

16

18

3 4 5 6

Paq

ue

tes

pe

rdid

os

[%]


Paquetes perdidos en función del número de nodos

3 nodos, v=1m/s

4 nodos, v=1m/s

5 nodos, v=1 m/s

101


Gráfica 9. Paquetes enviados al destino por cada nodo intermedio a v= 1m/s en función de la distancia AERORP_R.

Hemos realizado 4 experimentos, en ellos además de variar el rango también variamos la velocidad a la que se mueven los nodos y el número de nodos intermedios y realizamos estadísticas sobre los diferentes casos para comprobar que cuanto mayor rango de alcance, mayor velocidad de los nodos y mayor número de ellos, mejores son los resultados obtenidos, esto quiere decir que se pierden un menor número de mensajes en la red y por tanto el protocolo AeroRP cumple su cometido.

648 607728

826

497

726794 769

1079

699 705 739

517

665 664 666

217

723

568 535

0

200

400

600

800

1000

1200

3 4 5 6

Nú

me

ro d

e p

aqu

ete

s e

nvi

ado

s al

de

stin

o



Nodo Intermedio 1 Nodo Intermedio 2 Nodo Intermedio 3 Nodo Intermedio 4 Nodo Intermedio 5

102


7.1- Conclusiones Para solucionar el problema de topología dinámica de las redes MANET hemos concluido que hay que desarrollar nuevos protocolos de encaminamiento, como por ejemplo el AeroRP. Las conclusiones que podemos obtener de la evaluación de la implementación son:

Se ha conseguido el objetivo principal del proyecto: la implementación de un protocolo de encaminamiento geográfico AeroRP que permita el encaminamiento de paquetes basándose en la posición geográfica de los nodos que forman la red.

Click Modular Router nos ha permitido desarrollar una implementación divida en módulos y flexible en la que es sencillo introducir nuevas funcionalidades con nuevos elementos.

Tras realizar varias pruebas sobre distintos escenarios variando algunos parámetros podemos corroborar que:

- A mayor número de nódos móviles desplazándose por el escenario y a mayor velocidad de éstos se obtienen mejores resultados, es decir, el destino recibe un mayor número de paquetes de datos.

- Al ampliar el rango de alcance entre los nodos definido en el fichero de cabecera, mejor será el funcionamiento de nuestro protocolo, y menos paquetes se perderán en el camino hasta el destino.

CAPÍTULO 7: Conclusiones

y líneas de trabajo futuras

103


7.2- Líneas de trabajo futuras

El trabajo realizado ha sido la implementación de este protocolo de enrutamiento a nivel geográfico en una red emulada de máquinas virtuales, por tanto, una línea de trabajo futura podría ser la implementación de este protocolo en un sistema embebido. De entre los entornos de ejecución que se permiten se ha elegido la ejecución de Click como un módulo a nivel de usuario, una ampliación futura de este proyecto seria la utilización a nivel del kernel, donde la pila de red de Linux es sustituida por el módulo Click de forma que, los paquetes entrantes por las interfaces de red son procesados en primer lugar por Click Modular Router y Linux sólo podrá procesar aquellos paquetes que nuestro módulo del kernel le envíe. De esta manera, tenemos la posibilidad de que haya paquetes que sólo sean vistos por Click Modular Router y Linux no sepa de su existencia. Del mismo modo, todos los paquetes procedentes de la pila de red de Linux pueden ser capturados por Click Modular Router antes de que lleguen a las interfaces de red del ordenador. Por último, señalar que el servicio de localización y de generación de posición actual de los nodos se encuentra sin completar en la implementación. Por ello, se plantea que en un futuro, se adapte la implementación a la utilización de un servicio de localización y un sistema GPS reales.

104


[1] Official Website: http://www.read.cs.ucla.edu/click/click [2] “Red Ad hoc”, http://es.wikipedia.org/wiki/Red_Ad_hoc [3] Sarkar, Basavaraju, Puttamadappa: “Aurbach - Ad-hoc mobile wireless networks- Principles, protocols and applications”. Auerbach Publications (2008). [4] Mohapatra, Prasant, “Ad Hoc Networks Technologies and Protocols”, Springer Science, Boston 2005 [5] S. Corson and J. Macker. Mobile Ad hoc Networking (MANET): Routing Protocol Performance. Issues and Evaluation Considerations. RFC 2501, Junio 1999. [6] A. Jabbar, E. Perrins, and J. P. Sterbenz. A Cross-Layered Protocol Architecture for Highly-Dynamic Multihop Airborne Telemetry Networks. In Proceedings of the International Telemetering Conference (ITC), San Diego, CA, Oct. 27-30 2008. [7] Abdul Jabbar and James P.G. Sterbenz. AeroRP: A Geolocation Assisted Aeronautical Routing Protocol for Highly Dynamic Telemetry Environments. In Proceedings of the International Telemetering Conference, Las Vegas, NV, October 2009. [8] Justin P. Rohrer, Abdul Jabbar, Egemen K. Çentinkaya, Erik Perrins, and James P.G. Sterbenz. Highly-Dinamic Cross-Layered Aeronautical Network Architecture. In Proc. IEEE Transactions on aerospace and electronic systems, U, NThe university of Kansas, October 2011. [9] Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti, and M. Frans Kaashoek, “The Click Modular Router”, Laboratory for Computer Science, MIT, Vol. 18, No. 3, August 2000.

Referencias

http://www.read.cs.ucla.edu/click/click

http://es.wikipedia.org/wiki/Red_Ad_hoc

105


APÉNDICE A: Manual de instalación A.1 - Instalación de Click Modular Router y de la implementación A continuación se detallan los pasos de la instalación de Click Modular Router y de nuestra implementación en una máquina con sistema operativo Linux Ubuntu 12.04. Paso 1. En primer lugar hay que obtener la versión de Click Modular Router más reciente de la página web: [1]. El fichero con la versión más reciente se llama click-2.0.1.tar.gz. Paso 2. Descomprimimos el archivo: bash:$ sudo tar -xvf click-2.0.1.tar.gz

Paso 3. Antes de compilar Click Modular Router, es necesario:

Crear una carpeta aerorp dentro del directorio elements donde guardaremos todos los elementos que hemos implementado (aerorp).

Copiar los elementos de nuestra implementación en el directorio /click/elements/aerorp/.

Esto sirve para que Click Modular Router tenga en cuenta los nuevos elementos que hemos implementado. Paso 4. Para que la carpeta creada aerorp pueda ser compilada debemos incluir algunas líneas en el archivo configure, para ello: Nos movemos dónde está el archivo configure y lo abrimos con un editor de texto: bash: $ cd ~/Escritorio/click-2.0.1/

bash: $ sudo gedit configure

Apéndices

106


Incluimos las siguientes líneas: - En el trozo de código donde habilitamos las carpetas que vamos a utilizar incluimos:

enable_aerorp

- En el trozo de código donde incluimos las opciones que usamos por línea de comandos para incluir una carpeta en nuestra compilación incluimos:

--enable-aerorp include aerorp elements

- Para habilitar la carpeta y que el proyecto incluya los elementos creados y que hemos colocado en dicha carpeta, incluimos:

fi

# Check whether --enable-aerorp was given.

if test "${enable_aerorp+set}" = set; then :

enableval=$enable_aerorp;

else

enable_aerorp=NO

fi

test "x$enable_all_elements" = xyes -a \

( "x$enable_aerorp" = xNO -o "x$enable_aerorp" = x \) &&

enable_aerorp=yes

if test "x$enable_aerorp" = xyes; then

:

Paso 5. Cambio de directorio: bash:$ cd /click-2.0.1/

Paso 6. Ejecutar los siguientes comandos para preparar Click Modular Router para la compilación: bash:/click-2.0.1/$ sudo ./configure -–enable-aerorp --

enable-userlevel --disable-linuxmodule.

Con la opción --enable-aerorp conseguimos que se compilen los elementos que se encuentran en ese directorio.

Con la opción --enable-userlevel y --disable-linuxmodule compilamos los elementos de Click Modular Router para ejecutarlo en modo usuario y no como un módulo del kernel.

107


Paso 7. Cambiamos el directorio y compilamos: bash:/click-2.0.1/$ cd userlevel

bash:/userlevel/$ make

A.2 - Instalación de Precision Time Protocolo daemon (PTPd)

A la hora de evaluar la implementación, si se desean realizar medidas de tiempo que vinculen a más de un nodo de la red es necesario sincronizar sus relojes. Para ello, se ha utilizado el demonio PTPd. La instalación es muy sencilla, basta con teclear los siguientes comandos en la consola:

bash:$ sudo apt-get update

bash:$ sudo apt-get install ptpd

Una vez instalado el programa hay que iniciar su ejecución como maestro en el nodo gestión con los comandos: bash:$ sudo ptpd -b interfaz_nodo_gestion

Y como esclavo en las demás máquinas que deseamos sincronizar con el nodo gestión, para ello usamos los siguientes comandos: bash:$sudo ptpd -c -b interfaz_nodo -u ip_nodo_gestion -d -g

Donde interfaz_nodo_gestion es el dispositivo de red que se va a utilizar para sincronizarse con el resto de máquinas, en nuestro caso es el nodo gestión (eth2). Interfaz_nodo es el dispositivo de red correspondiente a cada nodo que queremos sincronizar. El demonio ptpd debe encontrarse en ejecución en todas aquellas máquinas que se deseen sincronizar.

108


APÉNDICE B: Ejecución de la implementación B.1- Funcionamiento de la aplicación generador de paquetes El nodo origen se encarga de lanzar la aplicación que genera paquetes UDP de tamaño 154 bytes y que pretenden alcanzar el nodo destino. Para lanzar ésta aplicación tenemos que seguir los siguientes pasos: Paso 1. Nos desplazamos hasta la carpeta donde se encuentra la aplicación: bash:$ cd Escritorio/AppAeroRP/build_debug

Paso 2. Ejecutamos la aplicación: bash: :/build_debug/$ utils/aerorp-src -i ip_destino

B.2 - Funcionamiento de la aplicación recepción de paquetes

El nodo destino se encarga de contabilizar los paquetes recibidos que son enviados por el nodo origen y los paquetes perdidos en el camino. Para así poder sacar las estadísticas correspondientes a los paquetes perdidos según el rango de alcance de los nodos. Para lanzar ésta aplicación tenemos que seguir los siguientes pasos: Paso 1. Nos desplazamos hasta la carpeta donde se encuentra la aplicación: bash:$ cd Escritorio/AppAeroRP/build_debug

Paso 2. Ejecutamos la aplicación: bash:/build_debug/$ utils/aerorp-dst -i ip_destino

B.3 - Funcionamiento de la aplicación del nodo gestión

El nodo gestión lanza dos aplicaciones, una se encarga de asociar cada nodo con su dirección IP para el posterior envío de los mensajes que se encargan de mantener la posición de cada nodo actualizada y la otra se encarga de leer de un fichero todas las posiciones de cada nodo que se está moviendo por el escenario de prueba y manda a cada nodo correspondiente un mensaje UDP con la posición y el tiempo en el que varía ésta para que

109


todos los nodos puedan actualizar sus posiciones y mandar las balizas a los nodos vecinos indicando su posición actual. Paso 1. Nos desplazamos hasta la carpeta donde se encuentra la aplicación: bash:$ cd Escritorio/AppAeroRP/build_debug

Paso 2. Ejecutamos la primera aplicación en una terminal: bash:$ /build_debug/$ utils/ aerorp_pos –f

../../data/IpNodes.dat -a port

Donde la opción -f nos indica el archivo para la asignación de la IP a cada nodo y la opción -a nos dice qué puerto usaremos para la transmisión UDP. Paso 3. Ejecutamos la segunda aplicación en otra terminal diferente: bash:/build_debug/$ utils/aerorp_pos_vicon_file –f

../../data/PositionsFile.dat -x pos_x_origen -y pos_y_origen -

n num_nodos

Donde la opción -f nos indica el fichero que tenemos que leer con la posición de cada nodo y el tiempo en el que varía ésta, la opción -x y -y nos indica la posición fija del nodo origen y la opción -n nos indica el número de nodos intermedios que intervienen en el escenario de prueba.

B.4 - Cómo ejecutar la implementación en un nodo intermedio o en el nodo origen Paso 1. Nos movemos hasta la carpeta donde vamos a compilar el código implementado: bash:$ cd Escritorio/click-2.0.1/userlevel

Paso 2. Compilamos el código: bash:$ make

Paso 3. Ejecutamos la implementación: bash:$ sudo ./click ../conf/archivo_configuración.click

110


B.5 - Script nodo origen #! /bin/bash

# Lanza CLICK

~/Escritorio/click-master/userlevel/click ~/Escritorio/click-

master/conf/aerorp.click &

sleep 5

# Lanza APP Origen

~/Escritorio/AppAeroRP/build_debug/utils/aerorp_src -i

192.168.7.126 &

B.6 - Script nodo destino #! /bin/bash

# Lanza APP Destino

~/Escritorio/AppAeroRP/build_debug/utils/aerorp_dst -i

192.168.7.126 &

B.7 - Script nodo gestión #! /bin/bash

# Configurar tabla ARP

arp -i interfaz -s ip_origen mac_origen #NODO_ORIGEN

arp -i interfaz -s ip_nodo_intermedio1 mac_nodo_intermedio1

#NODO_1

.

.

arp -i interfaz -s ip_nodo_intermedioN mac_nodo_intermedioN

#NODO_N

#Lanza APPs Gestión

sudo ~/Escritorio/AppAeroRP/build_debug/utils/aerorp_pos -f

~/Escritorio/AppAeroRP/data/IpNodes.dat -a 1235 &

sudo ~/Escritorio/AppAeroRP/build_debug/utils/aerorp_pos_vicon_file

-f ~/Escritorio/AppAeroRP/data/PositionsFile.dat -x 5 -y 0 &

sleep 1800

#Mata los procesos

111


pkill aerorp_pos_vicon_file

pkill aerorp_pos

Con el comando arp configuramos la tabla ARP asociando la dirección IP con su correspondiente dirección MAC. Con el comando sleep 1800 dejemos que la aplicación se ejecute durante media hora o lo que es lo mismo 1800 segundos y posteriormente con el comando pkill matamos los procesos de las aplicaciones que están en ejecución.

B.8 - Script nodos intermedios #! /bin/bash

# Lanza CLICK

~/Escritorio/click-2.0.1/userlevel/click ~/Escritorio/click-

2.0.1/conf/aerorp.click &

B.9 - Ejecución en modo root sin pedir contraseña Todos los scripts necesitamos ejecutarlos en modo root, para no tener que introducir la contraseña cada vez que lanzamos la aplicación y así ahorrar tiempo debemos modificar el archivo "sudoers":

bash:$ sudo gedit /etc/sudoers

O también podemos modificarlo escribiendo en la línea de comandos de la consola:

bash:$ sudo visudo

Añadimos la siguiente línea detrás de la línea %sudo ALL=(ALL:ALL) ALL:

nombre_usuario ALL=NOPASSWD:/ruta_script

B.10 - Creación del disector protocolo AERORP en Wireshark

Paso 1. Crear un fichero aerorp.lua para definir el protocolo:

bash:$ sudo gedit /usr/share/wireshark/aerorp.lua

Añadir el siguiente código al fichero:

112


---------------------------------------------------------

--

--DECLARACION DE PROTOCOLOS Y CAMPOS DEL PROTOCOLO

---------------------------------------------------------

--

AERO_RP = Proto ("AERO_RP", "Protocolo AERO_RP");

local f = AERO_RP.fields

f.nextHeader=ProtoField.int8("AERO_RP.nextHeader",

"Next header")

f.payloadLength=ProtoField.uint16("AERO_RP.payloadLength"

, "Size of options")

f.optionB = ProtoField.int8("AERO_RP.optionB",

"Baliza option")

f.posx = ProtoField.double("AERO_RP.posx", "X

position")

f.posy = ProtoField.double("AERO_RP.posy", "Y

position")

f.posz = ProtoField.double("AERO_RP.posz", "Z

position")

f.velx = ProtoField.double("AERO_RP.velx", "X

velocity")

f.vely = ProtoField.double("AERO_RP.vely", "Y

velocity")

f.optionData = ProtoField.int8("AERO_RP.optionData",

"Data option")

f.lengthtrace =

ProtoField.int8("AERO_RP.lengthtrace", "Trace

length")

f.destx = ProtoField.double("AERO_RP.destx", "X

position of destiny")

f.desty = ProtoField.double("AERO_RP.desty", "Y


f.destz = ProtoField.double("AERO_RP.destz", "Z


local data_dis = Dissector.get("data")

local packet_counter

function AERO_RP.init ()

packet_counter = 0

end

---------------------------------------------------------

113


--DECLARACION DE FUNCION DISSECTOR

---------------------------------------------------------

function AERO_RP.dissector(buf, pkt, tree)

-- Adding fields to the tree

local subtree = tree:add(AERO_RP, buf())

local offset = 0

--nextHeader + payloadLength

local nextHeader = buf(offset,1)

subtree:add_le (f.nextHeader, nextHeader)

offset = 1

local payloadLength = buf(offset, 2)

subtree:add_le (f.payloadLength, payloadLength)

offset = 3

--Data option

local optionData = buf(offset, 1)

subtree:add (f.optionData, optionData)

offset = 4

p = optionData:uint()

if p == 1 then

local lengthtrace = buf(offset, 1)

subtree:add_le (f.lengthtrace, lengthtrace)

offset = 5

local destx = buf(offset, 8)

subtree:add_le (f.destx, destx)

offset = offset + 8

local desty = buf(offset, 8)

subtree:add_le (f.desty, desty)

offset = offset + 8

local destz = buf(offset, 8)

subtree:add_le(f.destz, destz)

offset = offset + 8

end

--Baliza Option

if p == 1 then

local optionB = buf(offset, 1)

114


subtree:add_le (f.optionB, optionB)

offset = offset + 1

end

local posx = buf(offset, 8)

subtree:add_le (f.posx, posx)

offset = offset + 8

local posy = buf(offset, 8)

subtree:add_le (f.posy, posy)

offset = offset + 8

local posz = buf(offset, 8)

subtree:add_le (f.posz, posz)

offset = offset + 8

local velx = buf(offset, 8)

subtree:add_le (f.velx, velx)

offset = offset + 8

local vely = buf(offset, 8)

subtree:add_le (f.vely, vely)

offset = offset + 8

data_dis:call(buf(offset):tvb(),pkt,tree)

end

---------------------------------------------------------

--

--INCLUSION DE PROTOCOLO EN DISSECTOR_TABLE

---------------------------------------------------------

--

aero = DissectorTable.get("ip.proto")

aero:add(220, AERO_RP)

Paso 2. Comprobar que la variable disable_lua se encuentra con valor "false", en caso contrario, hacer que esto ocurra: bash:$ sudo gedit /usr/share/wireshark/init.lua

...

--Set disable_lua to true to disable Lua support.

disable_lua = false

...

Paso 3.

115


Incluir al final del fichero "init.lua" la ruta donde se encuentra el fichero que hemos creado con el disector ("aerorp.lua"):

...

dofile("console.lua")

--dofile(DATA_DIR.."dtd_gen.lua")

dofile([[/usr/share/wireshark/aerorp.lua]])

Paso 4. Guardar el fichero y ejecutar Wireshark. bash:$ wireshark &

Paso 5. Para comprobar si el resultado es el esperado realizamos las siguientes comprobaciones:

1. El protocolo es reconocido por wireshark en la lista: Internals -> Supported Protocols -> Protocols

2. Los campos del protocolo son los mostrados en la lista: Internals -> Supported Protocols -> display Filter Fields

3. El protocolo está incluido en el DissectorTable correspondiente:

Internals -> Dissector Tables -> Integer Tables

4. Comprobar que la captura de un mensaje AERORP reconoce los campos del nuevo protocolo.

116


APÉNDICE C: Elementos utilizados de la herramienta Click Modular Router y herramientas utilizadas en la implementación

C.1- Elementos Click Modular Router

1. Elemento FromDevice

El elemento intercepta todos los paquetes recibidos por la interfaz de red DEVICE (que es uno de los argumentos válido en su cadena de configuración) y los dirige a su único puerto de salida que es de tipo push. Éste elemento no posee ningún puerto de entrada. Los paquetes incluyen la cabecera del nivel de enlace.

Los argumentos más importantes que acepta este elemento en la cadena de configuración son: - DEVNAME: es el nombre de la interfaz de red desde donde se quieren recibir los paquetes. - SNIFFER: es un booleano. Especifica si FromDevice debe ejecutarse en modo sniffer. Si el modo sniffer está desactivado, como es nuestro caso, se aplican reglas de filtrado para bloquear que el kernel pueda manejar todos los paquetes que llegan al dispositivo DEVICE. El valor por defecto es verdadero.

2. Elemento Classifier Este elemento clasifica los paquetes según una serie de reglas. Tiene un único puerto de entrada y N puertos de salida, tantos como reglas de clasificación. Todos los puertos son de tipo push.

Figura 25. Elemento

Classifier

Figura 24. Elemento

FromDevice

...

117


Una regla es un patrón que se pasa en la cadena de configuración del elemento y que tiene la sintaxis "offset/valor" o “offset/valor%máscara" donde el parámetro máscara es opcional. Una regla se cumple si los bytes del paquete a partir del offset coinciden con el valor. El desplazamiento debe ser un número decimal y el valor y la máscara deben ser hexadecimales. El dígito "?" está permitido como hexadecimal y significa que ese byte puede tomar cualquier valor. La regla "-" significa que esa es la salida por defecto. Las reglas se comprueban en orden por lo que aquellas que sean más específicas deben ir primero. Este elemento se utiliza en cuatro ocasiones en la implementación como podemos observar en el diagrama de flujos en el apéndice D:

- Clasificador 0: para clasificar los paquetes que llegan por la interfaz de red en IP (offset = 12 corresponde al bit "type" de la cabecera Ethernet, y valor = 0800 corresponde a un paquete IP) o en otros (es la salida por defecto "-").

- Clasificador 1: clasifica si el paquete que llega a la entrada de éste elemento tiene

la cabecera AERORP incorporada (offset = 23 corresponde al bit "ip_p" de la cabecera IP, y valor = DC corresponde al protocolo AERORP ya que lo hemos asociado al número 220 que en hexadecimal se corresponde con DC) o en otro tipo de paquetes (salida por defecto "-")

- Clasificador 2: clasifica el tipo de paquete AERORP que llega por el puerto de

entrada que puede ser de datos o baliza (offset = 37 corresponde al bit "type" de la cabecera AERORP, y valor = 00 corresponde a un paquete baliza o valor = 01 corresponde a un paquete de datos).

- Clasificador 3: clasifica los paquetes que llegan del host en ARP o IP (desplazamiento = 12 corresponde al bit "type" de la cabecera Ethernet, y valor = 0806 corresponde al protocolo ARP o valor = 0800 corresponde al protocolo IP).

3. Elemento CheckIPHeader Comprueba que los paquetes que llegan por su puerto de entrada tienen cabecera IP a partir de un offset que es pasado como parámetro en su cadena de configuración. Tiene un puerto de entrada y uno de salida. La entrada es de tipo agnostic, pero la salida es push.

Figura 26. Elemento

CheckIPHeader

118


Comprueba que el tamaño del paquete es razonable, y que los campos de la versión, el tamaño de la cabecera y checksum son validos. Comprueba que las direcciones IP origen e IP destino son correctas. Los argumentos más importantes que acepta en la cadena de configuración son: - OFFSET: es un entero sin signo. Indica a partir de que byte del paquete comienza la cabecera IP. Su valor por defecto es 0. - CHECKSUM: es un booleano. Si tiene valor true entonces comprueba que el checksum de cada paquete sea correcto, en caso contrario no lo hace. Por defecto es true. - BADSRC: lista de direcciones IP separada por espacios. Descartará paquetes cuya dirección origen esté en esta lista. Por defecto esta vacía. Se utiliza en la implementación para asegurar que los paquetes que salen del clasificador 0 por la salida 0 y llegan por el puerto de entrada del elemento ChekIPHeader son paquetes IP.

4. Elemento MarkIPHeader

Marca los paquetes como paquetes IP estableciendo las anotaciones de la cabecera IP. Se trata de un elemento con un puerto de entrada y uno de salida de tipo agnostic. Con el argumento OFFSET, que se le pasa como parámetro a la cadena de configuración, se le indica en que byte empieza la cabecera IP. Por defecto el valor del offset es 0.

Se utiliza en la implementación para configurar las anotaciones de los paquetes IP para posteriormente meterlos en el clasificador de IP.

5. Elemento Discard Este elemento se encarga de descartar los paquetes que recibe. Tiene un único puerto de entrada de tipo agnostic. Se utiliza en la implementación cuando es necesario tirar algún paquete.

Figura 27. Elemento

MarkIPHeader

Figura 28. Elemento

Discard

119


6. Elemento IPClassifier

Este elemento clasifica los paquetes IP según una serie de reglas. Tiene un único puerto de entrada y N puertos de salida, tantos como reglas de clasificación. Todos los puertos son de tipo pushLos paquetes IP que entran en este elemento deben

tener anotaciones.

Los argumentos más importantes que acepta en la cadena de configuración son: - ip proto PROTO: donde PROTO es el nombre de un protocolo o un número de protocolo valido. - [SRCORDST] host IPADDR: donde IPADDR es una dirección IP y SRCORDST es 'src', 'dst', 'src or dst' o 'src and dst'. Si la dirección IP coincide enviamos el paquete por la salida correspondiente. - [SRCORDST] net NETADDR: donde NETADDR es una dirección de red con el formato "IPADDR/bits" o "IPADDR/ MASK" y SRCORDST es 'src', 'dst', 'src or dst' o 'src and dst'. Si la dirección de red coincide enviamos el paquete por la salida correspondiente. En nuestra implementación empleamos este elemento para mandar los paquetes si el destino es mi red, sino serán descartados (SRCORDST será dst, y NETADDR es el número de nuestra dirección IP de red 192.168.7.0 seguido de la máscara 24 y separado de ésta por una barra inclinada).

7. Elemento IPFilter Filtra paquetes IP por contenidos. Tiene un solo puerto de entrada y N puertos de salida tanto como reglas de clasificación. Todos los puertos son tipo push.

Se filtra con la pareja acción-condición. La acción describe qué hacer con el paquete si se cumple la condición correspondiente, por ejemplo, "allow" permite enviar el paquete si la condición se cumple o "drop" que descarta el paquete si la condición se cumple. La condición puede ser la comparación de cualquiera de los campos de la cabecera IP, por ejemplo, "proto" filtra por número de protocolo, "port" filtra por número de puerto, "src" o "dst" filtra por

Figura 29. Elemento

IPClassifier

Figura 30. Elemento

IPFilter

...

...

120


dirección IP origen o destino. Si tenemos que cumplir más de una regla, separamos éstas con "&&". En nuestra implementación utilizamos dos veces este elemento: - Para filtrar el paquete IP si la dirección IP destino es la del nodo destino (conocida por todos los nodos), y el paquete es UDP, éste filtro se emplea para recoger sólo los paquetes que genera la aplicación del nodo origen que tienen como dirección final la del nodo destino y así asegurarse de que los paquetes entren correctamente en la función routetable para encaminarlos hacía el destino (la acción es "allow" y las condiciones son "proto == 17" correspondiente al protocolo UDP, "dst == DST_IP" que es la dirección del nodo destino al que queremos enviar los mensajes, "src == MY_IP" es mi máquina la que va a enviar los mensajes). - Para filtrar los paquetes UDP generados por la aplicación del nodo gestión y que sirven para actualizar la posición de cada nodo, éstos paquetes son filtrados por la dirección destino que tiene que coincidir con la del nodo que quiere actualizar su posición (la acción es "allow" y las condiciones son "proto == 17" correspondiente al protocolo UDP, "dst==MY_IP " donde MY_IP es la dirección del nodo que va a actualizar su posición y "port==1235" es el número de puerto). Si todas estas condiciones se cumplen el paquete es enviado a la función AERORPGPSUDPTable que es la encargada de actualizar la posición del nodo correspondiente.

8. Elemento CheckUDPHeader

Este elemento espera paquetes UDP/IP como entrada. Comprueba que el tamaño de la cabecera UDP es el correcto y que el campo checksum de dicha cabecera es válido. Tiene un puerto de entrada y un puerto de salida. El puerto de entrada

es agnostic, pero el puerto de salida es push.

En nuestra implementación lo utilizamos para asegurarnos de que el paquete que entra a la función AERORPGPSUDPTable para actualizar la posición de los nodos es verdaderamente un paquete UDP.

Figura 31. Elemento

CheckUDPHeader

121


9. Elemento EtherEncap

Se trata de un elemento con un puerto de entrada y otro de salida de tipo agnostic. Encapsula los paquetes que le llegan por el puerto de entrada en una cabecera Ethernet con tipo TYPE, dirección origen SRC y dirección destino DST.

Los argumentos de la cadena de configuración son: - ETHERTYPE: es el tipo de protocolo que se encuentra encima de Ethernet. En nuestro caso, el tipo del protocolo es IP tiene el valor 0x0800. - SRC: es la dirección MAC origen. - DST: es la dirección MAC destino. En nuestra implementación se utiliza en dos ocasiones: - Para encapsular los paquetes baliza en una cabecera Ethernet. La dirección origen es la MAC del nodo que envía el paquete, la dirección destino es broadcast (FF:FF:FF:FF:FF:FF) para que llegue a todos los nodos dentro del rango de cobertura y el tipo de protocolo, el del protocolo IP (0x0800). - Para encapsular los paquetes IP que llegan desde el host con la dirección origen la dirección MAC del nodo origen que envía el paquete, la dirección destino es la dirección MAC del nodo destino conocido por todos los nodos para el encaminamiento de los paquetes y el tipo de protocolo es IP (0x0800).

10. Elemento Queue

Se trata de un elemento con un único puerto de entrada y 1 de salida. Sigue la estrategia FIFO (First In- First Out). Si el número de paquetes en la cola llega a CAPACITY se tiran los paquetes entrantes.

Figura 32. Elemento

EtherEncap

Figura 33. Elemento

Queue

122


La cadena de configuración sólo acepta un argumento: - CAPACITY: es el número máximo de paquetes que puede almacenar la cola. Por defecto toma el valor 1000. Este elemento se utiliza en la implementación para almacenar y planificar los paquetes antes de ser enviados al dispositivo de red.

11. Elemento ToDevice

Este elemento tiene un único puerto de entrada de tipo pull. Envía los paquetes que recibe por el puerto de entrada a la interfaz de red DEVNAME.

Los argumentos más importantes que acepta en la cadena de configuración son: - DEVNAME: es el nombre de la interfaz de red desde donde se quieren recibir los paquetes. - DEBUG: es un booleano. Si es true, imprime mensajes de depuración en la salida. Por defecto es false.

12. Elemento FromHost

Este elemento tiene un único puerto de salida de tipo push y ningún puerto de entrada. Captura los paquetes que provienen del kernel de Linux antes de que lleguen a la interfaz de red. Para ello, crea una interfaz ficticia llamada DEVNAME.

Los argumentos que acepta la cadena de configuración son: - DEVNAME: es de tipo String. Es el nombre de la interfaz ficticia que se crea. - NETADDR: es una dirección de red con el formato "IPADDR/ MASK". En nuestro caso es la dirección de red de nuestro nodo para recibir los paquetes que llegan desde el host.

Figura 34. Elemento

ToDevice

Figura 35. Elemento

FromHost

123


Figura 37. Elemento

ToHost

Linux enviará peticiones ARP a la interfaz ficticia. Debemos responder a estas

peticiones en el orden en el que se reciben los paquetes.

13. Elemento ARPResponder

Este elemento recibe en su único puerto de entrada mensajes ARP Request, incluyendo la cabecera Ethernet. Y envia un mensaje ARP Reply por su puerto de salida si conoce la

respuesta.

14. Elemento ToHost

Este elemento tiene un único puerto de entrada de tipo push. Su función es la de mandar los paquetes que recibe al kernel de Linux. Si se indica un nombre de interfaz mediante el parámetro DEVNAME, los paquetes son entregados al kernel de Linux como si provinieran de la interfaz de red con ese nombre.

Por defecto, y así es como se utiliza en la implementación, se esperan paquetes encapsulados en una cabecera Ethernet, aunque es posible modificar el funcionamiento para que espere paquetes con cabeceras IP.

15. Elemento Strip

Este elemento tiene un puerto de entrada y uno de salida. Ambos puertos son de tipo agnostic. Borra los primeros LENGTH bytes de cada paquete que se le pasa como parámetro a la cadena de configuración.

La cadena de configuración acepta como argumento: - LENGTH: es un entero. Indica el número de bytes que se tiene que borrar desde el byte 0 del paquete.

Figura 36. Elemento

ARPResponder

Figura 38. Elemento Strip

124


En nuestra implementación lo utilizamos para borrar la cabecera Ethernet del paquete (LENGTH = 14).

C.2. Herramientas utilizadas La implementación del entorno en cuestión fue realizada con herramientas de código abierto, o de uso libre, que son distribuidas gratuitamente en Internet, además del uso del sistema operativo Linux. El uso de esas herramientas permitió la modificación y adaptación del código necesario para crear el protocolo de enrutamiento. Los siguientes puntos hablan de las herramientas utilizadas durante la implementación.

Lenguaje de programación C++

Hemos realizado la implementación de los elementos de nuestro protocolo en lenguaje C++, ya que éste es un lenguaje orientado a objetos y posee las siguientes ventajas: - Soporte: actualmente, puede compilar y ejecutar código de C, ya que viene con librerías para realizar esta labor. - Difusión: al ser uno de los lenguajes más empleados en la actualidad, posee un gran

número de usuarios y existe una gran cantidad de libros, cursos, páginas web... dedicados a

él.

- Versatilidad: C++ es un lenguaje de propósito general, por lo que se puede emplear para resolver cualquier tipo de problema. - Portabilidad: el lenguaje está estandarizado y un mismo código fuente se puede compilar en diversas plataformas. - Eficiencia: C++ es uno de los lenguajes más rápidos en cuanto ejecución. - Herramientas: existe una gran cantidad de compiladores, depuradores, librerías...

Entorno Integrado de Desarrollo Qt Creator Para el desarrollo de las diferentes aplicaciones y de los elementos del proyecto hemos usado Qt Creator con sus bibliotecas Qt ya que éste hace que el código en C++ sea más legible puesto que posee un avanzado editor de código, ayuda sensible al contexto integrada, resaltado y auto-completado de código y un depurador visual, entre otras muchas cosas.

125


Linux

La parte principal del sistema operativo Linux es el Kernel que va evolucionando constantemente a través de iniciativas de OpenSource respaldadas por todo el mundo. En este trabajo fue utilizada la versión 8.0.35-generic, concretamente en Linux Ubuntu, una distribución de Linux basada en Debian. El kernel del Linux no fue modificado en ningún nodo, facilitando así la implantación del protocolo en cualquier nodo que tenga instalado éste sistema operativo.

VirtualBox v 4.2.18

Para virtualizar el entorno de pruebas hemos utilizado el software de virtualización VirtualBox v 4.2.18 de Oracle. Por medio de esta aplicación nos ha sido posible instalar un sistema operativo adicional (Linux Ubuntu 12.04) como "sistema invitado" dentro de otro sistema operativo "anfitrión" (Windows 7 Professional). Con este software podemos crear tantas máquinas virtuales como nodos necesitemos para realizar las pruebas y comprobar que nuestro protocolo de enrutamiento funciona correctamente.

Wireshark

Es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones. Posee una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver todo el tráfico que pasa a través de una red estableciendo la configuración en modo promiscuo. Es un software libre y lo hemos utilizado en nuestro proyecto para examinar los paquetes que atraviesan los nodos y comprobar que los nodos envían y reciben los paquetes perfectamente. El problema es que el protocolo AERORP no es reconocido por wireshark. Para que Wireshark pueda representar la información y especificaciones del protocolo, es necesario crear un disector. El disector puede ser creado con el lenguaje de programación C++ o con el lenguaje de programación LUA. En nuestro caso, empleamos el lenguaje LUA y en el apéndice B explicamos paso a paso cómo crear el disector correspondiente para que wireshark analice nuestro protocolo.

http://es.wikipedia.org/wiki/Modo_promiscuo

126


Click Modular Router

Para el desarrollo de la implementación del protocolo de encaminamiento AERORP hemos utilizado Click Modular Router que como hemos explicado en el capítulo anterior se trata de una herramienta software que permite la creación de routers flexibles y configurables, éstos están formados por el ensamblaje de diferentes elementos (éstos a su vez pueden estar definidos ya en la propia herramienta o podemos crearlo nosotros mismos) cada uno de los cuales realiza alguna tarea. Para ensamblar los diferentes elementos y que nuestra herramienta lleve a cabo el funcionamiento de nuestro protocolo AERORP necesitamos un archivo de configuración (ver apéndice C).

La instalación de esta herramienta es descrita en el apéndice A.

127


APÉNDICE D: Archivo de configuración y grafo de los elementos de la implementación

El archivo de configuración de la implementación correspondiente es:

define($DEVICE interfaz_nodo, $ETHERTYPE 0x0800, $MYMAC

MAC_del_nodo, $MYIP IP_del_nodo, $DSTMAC MAC_destino, $NODE

numero_nodo, $DSTIP IP_destino)

// Elementos AeroRP

gps_udp_table::AERORPGPSUDPTable(ROUTETABLE routetable,

NEIGHBORSTABLE neighbors_table, BUFFER buffer_table, NODE $NODE);

check_range::AERORPCheckRange(GPSUDPTABLE gps_udp_table, NODE

$NODE);

gen_beacon::AERORPBeaconGenerator(GPSUDPTABLE gps_udp_table,

IPADDRESS $MYIP, ETHERADDRESS $MYMAC, DSTETHERADDRESS $DSTMAC, NODE

$NODE);

neighbors_table::AERORPNeighborsTable(ETHERADDRESS $MYMAC);

buffer_table::AERORPBuffer(NODE $NODE);

routetable::AERORPRouteTable(NEIGHBORSTABLE neighbors_table, XDEST

5, YDEST 10, ZDEST 0, IPADDRESS $MYIP, ETHERADDRESS $MYMAC,

DSTETHERADDRESS $DSTMAC, BUFFER buffer_table, NODE $NODE);

// Salida a la Red

output::Queue(2000)->ToDevice($DEVICE);

// Clasificadores

aerorp_class0::Classifier(12/0800, -); // 0:IP,

1:NO_IP

aerorp_class1::IPClassifier(dst net 192.168.7.0/24, -);//0: MI_RED,

1: OTRA_RED

aerorp_class2::Classifier(23/DC, -); // 0: AERORP,

1: NO_AERORP

aerorp_class3::Classifier(37/01, 37/00); // 0:AERORP_DATA,

1: AERORP_BEACON

fh_cl::Classifier(12/0806, 12/0800) // 0: ARP,

1: IP

128


// Sección que genera los paquetes balizas

gen_beacon

->EtherEncap($ETHERTYPE, $MYMAC, FF:FF:FF:FF:FF:FF)

->output;

//Sección que procesa los paquetes procedentes del host

FromHost(aerorp, $MY_IP/24)

->fh_cl;

// Paquetes dirigidos al host

fh_cl[0]

->ARPResponder(0.0.0.0/0 1:1:1:1:1:1)

->ToHost(aerorp);

// Si es un paquete IP entra por el puerto 0 de la función

routetable

fh_cl[1]

->IPFilter(allow proto==17 && dst == $DSTIP && src == $MYIP)

->Strip(14)

->EtherEncap($ETHERTYPE, $MYMAC, $DSTMAC)

->[0]routetable;

FromDevice($DEVICE, SNIFFER false)

->aerorp_class0;

aerorp_class0[0]

->CheckIPHeader(OFFSET 14)

->MarkIPHeader(14)

->aerorp_class1;

aerorp_class0[1] -> Discard;

aerorp_class1[0] -> aerorp_class2;

aerorp_class1[1] -> Discard;

aerorp_class2[0] -> check_range;

// Sección que procesa los paquetes UDP para actualizar las

posiciones de los nodos

aerorp_class2[1]

->IPFilter(allow proto == 17 && dst == $MYIP && port == 1235)

->CheckUDPHeader

->gps_udp_table

->Discard;

// Analiza si los paquetes son procedentes de nodos dentro del

rango de cobertura

129


check_range[0] -> aerorp_class3;

check_range[1] -> Discard;

// Si es un paquete de datos entra por el puerto 1 de la función

routetable

aerorp_class3[0] -> [1]routetable;

// Si es un paquete baliza con cabecera AERORP entra por el puerto

2 de la función routetable

aerorp_class3[1] -> [2]routetable;

// Paquetes dirigidos a la red

routetable[0] -> output;

//Paquetes baliza descartados

routetable[1] -> Discard

130


El grafo que representa el anterior esquema de configuración queda como sigue:

Figura 39. Diagrama del archivo de configuración

131


APÉNDICE E: Fichero de cabecera #ifndef CLICK_AERORP_HH

#define CLICK_AERORP_HH

#include <ctime>

#include <sys/timeb.h>

CLICK_DECLS

//Intervals in ms

#define AERORP_BEACON_INTERVAL 100

#define AERORP_NEIGHBOR_CACHE_TIMEOUT 120

#define AERO_RP_SEND_BUFFER_TIMEOUT 30000

#define AERO_RP_INFINITO 999999999

#define AERORP_R 3

#define PI 3.1416

#pragma pack(push)

#pragma pack(1)

// AERORP Header

struct click_aerorp {

unsigned char next_header;

unsigned short len;

};

#define AERO_RP_SIZE_OF_HEADER 3

// Beacon Option

struct click_aerorp_beacon {

unsigned char type; // Bit 23

double x;

double y;

double z;

double vx;

double vy;

};

#define AERO_RP_SIZE_OF_BEACON_OPT 41

// Data Option

struct click_aerorp_data{

unsigned char type; // Bit 23

unsigned char len_trace;

double x;

double y;

double z;

};

#define AERO_RP_SIZE_OF_DATA_OPT 26

132


#pragma pack(pop)

// Defines the packet type

#define AERORP_TYPE_BEACON 0

#define AERORP_TYPE_DATA 1

#define IP_PROTO_AERORP 220 // hexadecimal: DC

#define AERORP_OFFSET sizeof(click_ether) + sizeof(click_ip)

#define AERORP_OFFSET_DATA AERORP_OFFSET + sizeof(click_aerorp)

#define AERORP_OFFSET_BEACON AERORP_OFFSET_DATA + sizeof(click_aerorp_data)

static double getTimeMilliseconds()

{

struct timeval timestamp;

gettimeofday(&timestamp, NULL);

return (timestamp.tv_sec * 1000 + timestamp.tv_usec / 1000.0);

}

CLICK_ENDDECLS

#endif

133


APÉNDICE F: Contenido del CDROM

Con la memoria se adjunta un CDROM que contiene, además de la memoria en formato PDF, el código de la implementación y de las pruebas realizadas en el proyecto fin de carrera. En la raíz del CDROM tenemos el directorio llamado “PFC Lorena Otero Ramos”. Dentro de este directorio podemos encontrar: Subdirectorio “Código_implementación”: este subdirectorio se divide a su vez en otros

dos subdirectorios:

“aerorp.click”: donde podemos encontrar el archivo de la configuración de la implementación.

"elementos_aerorp_click”: aquí podemos encontrar el código de los elementos de Click Modular Router implementados.

Subdirectorio “Código_pruebas”: aquí se encuentra el código de los programas

generador_paquetes, receptor_paquetes y generador_posiciones que se han utilizado en la evaluación de la implementación.

Fichero PDF “Memoria”: es la memoria del proyecto en formato PDF.

escuela superior de ingenierosbibing.us.es/proyectos/abreproy/12241/fichero/memoria.pdf · escuela...

Documents