Redes AD HOC

Proyecto final de Redes y Teleprocesamiento

28 de diciembre de 2010
Briane Julián - Fermani Mauro
 Índice
INTRODUCCIÓN............................................................................................................................... 2
REDES AD HOC ............................................................................................................................... 3
PRINCIPALES CARACTERÍSTICAS DE LAS REDES AD HOC ......................................................................... 4
COMUNICACIÓN ENTRE LOS NODOS ................................................................................................. 4
PROTOCOLOS REACTIVOS .......................................................................................................... 4
PROTOCOLOS PROACTIVOS ........................................................................................................ 5
VENTAJAS Y DESVENTAJAS DE LAS REDES AD HOC.............................................................................. 5
SEGURIDAD ................................................................................................................................ 6
PROTOCOLO DE ENCAMINAMIENTO AODV ........................................................................................... 7
TABLAS DE RUTEO........................................................................................................................ 7
DESCUBRIMIENTO DE CAMINOS ...................................................................................................... 8
FORMACIÓN DEL CAMINO DE VUELTA........................................................................................... 8
FORMACIÓN DEL CAMINO DE IDA .............................................................................................. 10
MANTENIMIENTO DE CAMINOS ................................................................................................ 11
FORMATO DE LOS MENSAJES ........................................................................................................ 12
ROUTE REQUEST (RREQ)........................................................................................................ 12
ROUTE REPLY (RREP) ............................................................................................................ 13
ROUTE ERROR (RERR) ........................................................................................................... 13
CASO DE ESTUDIO: PROTOCOLO AODV .............................................................................................. 15
ARCHIVO DE SIMULACIÓN............................................................................................................ 15
ANÁLISIS MEDIANTE NAM .......................................................................................................... 16
ANÁLISIS MEDIANTE AWK........................................................................................................... 19
CONCLUSIÓN................................................................................................................................ 20
REFERENCIAS ............................................................................................................................... 21
ANEXO - CÓDIGOS DE LA SIMULACIÓN ............................................................................................... 22
SIM.TCL ............................................................................................................................... 22
UBIC_NODOS.TCL .................................................................................................................. 23
MOV_NODOS.TCL .................................................................................................................. 23
TASAS.AWK .......................................................................................................................... 24

1
Introducción
Hoy día, mucha gente lleva numerosos dispositivos portátiles (ordenadores, teléfonos móviles, PDA,
etc.) para usarlos en sus vidas profesionales y privadas con el fin de compartir documentos, fotos o
diferentes archivos. Muchas veces no se cuenta con una estructura de red fija, es decir que no existe
un elemento físico encargado de la administración de la red que podría formarse con dichos
dispositivos.
Estos ejemplos de comunicación espontánea entre dispositivos podrían ser definidos de manera
informal como un esquema que a menudo se denomina red ad hoc, que permiten a los dispositivos
la comunicación, en cualquier momento y en cualquier lugar, sin la ayuda de una infraestructura
central.
En realidad, la formación de redes ad hoc como tal no es nueva, pero si la configuración, el uso y los
participantes. En el pasado, la noción de redes ad hoc se asociaba con frecuencia con la
comunicación en los campos de combate y en zonas desastrosas. Con la aparición de nuevas
tecnologías, es probable que cambie el escenario de la formación de redes ad hoc, así como su
importancia.
En este informe introduciremos el concepto de redes ad hoc, y luego se evaluará el funcionamiento
del protocolo AODV mediante el emulador NS-2 y NAM.

2
 Redes Ad Hoc
Las redes Ad Hoc consisten en un conjunto de nodos que se comunican mediante enlaces
(generalmente inalámbricos) y no tienen una infraestructura fija. Esto implica que no tienen ningún
tipo de control centralizado y que por lo tanto son flexibles y fácilmente desplegables.
Dentro de las redes Ad Hoc existen varios tipos:
redes de sensores;
redes mesh;
redes vehiculares (VANET, Vehicular Ad Hoc Network);
redes móviles Ad Hoc (MANET, Mobile Ad Hoc Network).
Para este proyecto daremos una mayor prioridad a las redes MANET, que hoy en día son las que
adquieren mayor utilidad.
Estas añaden la característica de movilidad de los nodos, eso con lleva que los enlaces entre nodos se
rompan y que haya enlaces que se incorporen o abandonen la red continuamente, por lo tanto la
topología de la red es altamente cambiante y aleatoria. Todos los nodos pueden actuar tanto como
emisores, receptores y routers (o encaminadores), esto es necesario ya que las rutas para llegar a un
destino pueden tener varios saltos. Los nodos pueden ser dispositivos tales como ordenadores
portátiles, PDAs, teléfonos móviles, etc.

Ejemplo gráfico Red Ad Hoc

3
Principales caracter ísticas d e las red es Ad Hoc
Terminales autónomos: Cada Terminal se comporta como un nodo autónomo que puede
funcionar como emisor, receptor o encaminador.
Soportan conexiones inalámbricas: No existe ningún tipo de infraestructura fija, los
terminales usan el aire como canal de comunicación.
Funcionamiento distribuido: No existe ningún elemento central que se encargue de la
gestión y el control de la red, todos los nodos son iguales y por lo tanto la gestión está
distribuida.
Topología dinámica: Como no es necesario ninguna infraestructura fija y además los nodos
pueden ser móviles, la topología de la red puede ser altamente cambiante. Las redes ad hoc
deben adaptarse rápidamente a los cambios de tráfico generado por los nodos, a los
distintos patrones de movimientos y a las condiciones de propagación.
Capacidad variable de los enlaces: Al tratarse de un medio de transmisión compartido el
canal de transmisión cambia constantemente los niveles de ruido, atenuación e
interferencias. Además, en una transmisión extremo a extremo pueden participar varios
enlaces distintos y la ruta puede cambiar varias veces en una misma transmisión.
Consumo de energía: Los nodos pueden ser móviles y por lo tanto es de suponer que
funcionaran con baterías de vida limitada, por esa razón es muy importante que el consumo
de energía se reduzca lo máximo posible.

Comunicación en tre los nodos

La arquitectura de redes ad hoc sigue el modelo OSI, por lo que se cuenta con las diferentes capas
del modelo: capa Física, capa de Enlace, capa de Red y capa de Transporte.
La capa de red es en dónde más se distinguen las redes MANET de las redes más conocidas. A este
nivel los protocolos de encaminamiento para las redes MANET es necesario que se adapten
rápidamente a los cambios constantes de la topología de la red para poder mantener una ruta para
la comunicación entre los nodos.
Existen una gran cantidad de protocolos de encaminamiento para las redes Ad Hoc, los cuales
pueden ser más o menos adecuados en cada escenario en concreto. Estos protocolos se pueden
dividir en dos grandes grupos en función del método que utilizan para determinar las rutas:
protocolos reactivos y proactivos.
Proto colos reac tivos
Son aquellos en los cuales se hallan las rutas entre un nodo origen y un nodo destino bajo demanda
de la fuente. Es decir, que sólo cuando sea necesario iniciar una transmisión se buscará una ruta para
realizarla. Una vez establecida la ruta, los nodos que participen en la transmisión se encargarán de su
mantenimiento. Las ventajas de este tipo de protocolos es que no necesitan demasiada señalización,
lo cual reduce el overhead y optimiza el uso de las baterías
Algunos de los protocolos reactivos más importantes son los siguientes:
Ad Hoc On Demand Distance Vector Routing (AODV), 2003
Cluster-Based Routing Protocol (CBRP), 1999
Dynamic MANET On demand (DYMO), 2005
Dynamic Source Routing (DSR), 2004

4
 Protocolos proact ivos
Intentan mantener tablas de las rutas actualizadas constantemente. Eso significa que cada nodo
debe mantener actualizada una tabla con todas las rutas hacia los otros nodos. La información que
contienen las tablas debe actualizarse periódicamente y ante cualquier cambio de la topología de
red. Esta actualización constante provoca que estos protocolos generen una gran cantidad de
paquetes de señalización (overhead) lo cual afecta a la utilización del ancho de banda, el throughput
y el consumo de energía entre otras cosas.
La ventaja principal que aportan estos protocolos es que el establecimiento de una nueva ruta para
iniciar una transmisión precisa de un tiempo muy pequeño al tener todos los nodos las tablas de
rutas actualizadas.
Algunos de los protocolos proactivos más destacables son los siguientes:
Adaptative Distance Vector (ADV), 2000
Cluster Gateway Switch Routing (CGSR), 1999
Destination-Sequenced Distance Vector (DSDV), 1994
Distance Routing Effect Algorithm for Mobility (DREAM), 1998

Ventajas y Desven tajas de las redes AD H OC

La principal ventaja de las redes ad hoc es que no necesitan una estructura fija ya todos sus nodos
son autónomos, funcionan como emisores, receptores y encaminadores. Esto da una gran flexibilidad
permitiendo la movilidad de los nodos.
Dichas ventajas se pueden ver reflejadas en aplicaciones como:
Entornos militares: En entornos militares las redes ad hoc permiten establecer comunicación
entre distintas unidades, vehículos o centros de mando, lo cual puede ser muy difícil o
imposible con una estructura fija.
Situaciones de emergencia: Nuevamente, desplegar una red sin necesidad de establecer una
estructura fija en escenarios provocados por desastres naturales cuando los equipos de
emergencia tienen que actuar rápidamente, es una solución rápida y eficaz.
Entornos civiles: Se pueden crear redes de sensores por ejemplo en entornos agrícolas, más
económico que instalar una infraestructura. También se pueden crear redes ad hoc para
compartir información entre los participantes en un congreso, una conferencia, una clase,
etc.
Redes de área personal: Se tratan de redes formadas por dispositivos de uso personal como
un ordenador portátil, un teléfono móvil, una PDA, etc. Usar una red ad hoc nos puede
permitir comunicar estos dispositivos entre ellos fácilmente.
La principal desventaja es que presenta un mayor overhead en el establecimiento de las rutas debido
a la ausencia de una estructura fija.
En el caso de las redes ad hoc inalámbricas, un factor que se tiene mucho en cuenta, es la cantidad
de mensajes enviados por el protocolo, ya que incide en el consumo de potencia del dispositivo.
Otra cuestión a tener en cuanta es la seguridad, ya que los datos enviados de un nodo a otro pasan
por nodos intermediarios que no se conocen.

5
Seguridad
Obviamente, la seguridad es un motivo de preocupación en una red ad hoc, en particular si se
emplean saltos múltiples. Desde un punto de vista puramente criptográfico, los servicios ad hoc no
implican muchos problemas nuevos. Los requisitos relativos a la autenticación, la confidencialidad y
la integridad o no repudio son los mismos que para otras redes de comunicaciones públicas. Sin
embargo, en una red inalámbrica ad hoc, la confianza es un problema fundamental. Ya que no
podemos confiar en el medio, la única elección que nos queda es usar la criptografía, lo que nos
fuerza a confiar en las claves criptográficas públicas. Por lo tanto, el reto básico es crear relaciones de
confianza entre claves sin la ayuda de una certificación de confianza de terceros.

6
 Protocolo de encaminamiento AODV
El protocolo AODV (Ad hoc On-demand Distance Vector) fue desarrollado en 1999 por Charles E. Per-
kins, del grupo de desarrollo avanzado de Sun Microsystems, y Elizabeth M. Royer, de la Universidad
de California, Santa Barbara . Su propósito fue diseñar un protocolo para redes ad-hoc formadas por
nodos móviles tomando como punto de partida el protocolo DSDV, con el fin de solventar sus
deficiencias: el alto número de envíos en modo broadcast y la latencia de transmisión. El protocolo
AODV se especifica en el RFC3561, publicada en julio del 2003.
El protocolo AODV es un protocolo reactivo, ya que el proceso de búsqueda de rutas se inicia sólo
cuando un nodo necesita enviar información a otro nodo y desconoce cómo acceder a él. Además,
está basado en la familia de algoritmos de vector de distancias y puede transmitir en modo unicast y
multicast.
El protocolo AODV combina técnicas extraídas de los protocolos DSDV y DSR, dando lugar a un
algoritmo que usa el ancho de banda de manera eficiente y que responde con rapidez a los cambios
en la red al tiempo que garantiza la ausencia de bucles. Con el fin de mantener sólo la información de
ruteo más reciente, el protocolo AODV toma de su predecesor, el protocolo DSDV, el concepto de
número de secuencia. Tanto en el protocolo AODV como en el protocolo DSDV, cada nodo se
encarga de mantener su propio contador o número de secuencia. Este número no es más que un
valor entero que cada nodo incrementa monótonamente antes de generar un mensaje de control
para copiarlo en éste antes de enviarlo. De manera complementaria al número de secuencia, cada
nodo se distingue por un identificador único dentro de la red. De este modo, con la pareja de valores
formada por el identificador del nodo y el número de secuencia, es posible distinguir la información
válida de la anticuada.
Si un nodo recibe dos paquetes con el mismo identificador de nodo pero con diferentes números de
secuencia, la información más reciente será la incluida en el paquete de mayor número de secuencia.
Puesto que cada nodo es responsable de su propio contador, no es necesario mantener un reloj
único y común a toda la red, lo cual simplifica enormemente la implementación del protocolo. El uso
de estos números de secuencia garantiza la ausencia de bucles en todo momento y evita problemas
como el de la “cuenta al infinito”.
El protocolo AODV emplea un mecanismo de descubrimiento de rutas en modo broadcast que
también emplea el protocolo DSR aunque con ciertas modificaciones. En el protocolo DSR, es el nodo
origen quien se encarga de calcular la ruta completa hasta el nodo destino. Esto puede degradar la
prestación de la red cuando ésta es muy extensa, ya que cada paquete incluye en su cabecera la
secuencia de nodos por los que debe pasar desde el origen hasta el destino. Por el contrario, en el
protocolo AODV, el camino se forma gracias a la información mantenida en las tablas de rutas de los
nodos intermedios.

Tablas de ru teo
Cada nodo debe mantener su propia tabla de ruteo. La tabla tendrá tantas entradas como destinos
conoce el nodo. Cada registro de la tabla tiene los siguientes campos:
Dirección IP del destino.
Número de secuencia del nodo destino: Número de secuencia asociado al nodo destino, cuyo
valor se obtiene de los mensajes de control.
Indicador de validez del número de secuencia del nodo destino: Si se pretende alcanzar un

7
 nodo destino y ha fallado uno de los enlaces implicados, o la ruta ha expirado, el número de
secuencia asociado a ese nodo destino se marca como inválido.
Otros indicadores sobre estado y rutas: Por ejemplo, indicadores sobre si la ruta es o no
válida, y en este último caso si es reparable, no es reparable y se debe buscar un camino
alternativo, o bien, si está siendo reparada.
Interfaz de red.
Número de saltos: Número de saltos necesarios para alcanzar el destino desde este nodo.
Siguiente salto. Nodo adyacente al que se debe enviar el paquete para llegar al destino
deseado.
Lista de precursores: Lista de nodos que forman el camino resultante del proceso de
descubrimiento de rutas.
Tiempo de vida de la ruta: Tiempo en el que la ruta caduca o debe ser borrada.

Descubrimien to d e caminos
El proceso de descubrimiento de caminos se inicia cuando un nodo origen desea comunicarse con
otro nodo pero desconoce cómo acceder a él. Para ello, se intercambian principalmente dos tipos de
mensajes: mensajes de solicitud o petición de ruta (RREQ, Route REQuest) y mensajes de respuesta
de ruta (RREP, Route REPly). En esta operación de búsqueda de rutas se pueden distinguir a su vez
dos fases: la formación del camino de vuelta y la formación del camino de ida. La formación del
camino de vuelta establece todas las rutas posibles desde el origen hasta el destino, trazados por el
recorrido de los mensajes RREQ y la formación del camino de ida determina la ruta que finalmente
seguirán los paquetes desde el nodo origen hasta el nodo destino una vez finalizado el
descubrimiento de caminos.
Formación del camino de vuelta
Cuando un nodo origen desea alcanzar un nodo destino y desconoce cómo acceder a él, genera un
mensaje RREQ. En él se incluyen las direcciones IP y los números de secuencia de los nodos origen y
destino. Antes de enviar esta solicitud, el nodo origen incrementa su número de secuencia para
evitar conflictos con peticiones anteriores. En el campo correspondiente al número de secuencia de
destino, el nodo incluye el último valor aprendido, en caso de que ya hubiese solicitado esa ruta con
anterioridad, o bien indica que es desconocido. El mensaje RREQ se difunde por inundación.
La inundación es una técnica de envío de paquetes por la que cuando un nodo tiene información
dirigida a un destino concreto, la transmite a sus vecinos. Si el nodo que la recibe no es el
destinatario de esta información, la reenvía de nuevo. Este proceso continúa sucesivamente hasta
alcanzar el nodo destino. En complemento a la técnica de inundación y con el objetivo de evitar un
consumo excesivo del ancho de banda, el nodo origen emplea el algoritmo de búsqueda expansiva
en anillo. De acuerdo a este algoritmo, inicialmente el mensaje RREQ tiene asociado un valor
pequeño de su tiempo de vida TTL (Time-To-Live), de tal manera que el mensaje se descarta cuando
este tiempo expira. Si no se encuentra el destino antes de un plazo determinado, este valor se
incrementa progresivamente en el envío de las posteriores solicitudes de rutas. Con el fin de que un
nodo no permanezca eternamente intentando alcanzar un destino inaccesible, se tiene un número
máximo de intentos.
La imagen representa una red compuesta por diez nodos, en la que se indica mediante flechas el
recorrido de los mensajes RREQ. El nodo origen inicia el proceso de inundación con mensajes RREQ,
que llegan a sus tres vecinos, quienes a su vez reenvían sucesivamente la solicitud. En este caso, se

8
 considera que ninguno de los nodos intermedios conoce el camino, por lo que la inundación se
propaga hasta alcanzar el nodo destino.

Cada vez que un nodo recibe el mensaje RREQ, comprueba si es él el destino buscado o si al menos
conoce cómo acceder a él. Si no es así el nodo guarda un registro de la solicitud y vuelve a reenviar el
mensaje RREQ a sus vecinos, continuando con el proceso de inundación. Los nodos toman nota de
los mensajes RREQ recibidos para no reenviar la misma solicitud varias veces, ya que esto
sobrecargará la red de manera innecesaria.
La segunda imagen ilustra la fase de formación de los caminos de vuelta. Puesto que los nodos
intermedios anotan de dónde proviene la solicitud, se forman cuatro caminos de vuelta. Como se
puede apreciar, los caminos en color rojo no son factibles, sólo las dos rutas trazadas en color azul
comunican origen y destino. El proceso de inundación, y en consecuencia, la formación del camino
de vuelta, se detiene cuando el nodo que recibe la solicitud es el nodo destino o conoce cómo llegar
al mismo, dando lugar a la siguiente fase, la formación del camino de ida.

9
Formación del camino de ida
Si el nodo que recibe la solicitud es el propio nodo destino o es un nodo intermedio que tiene una
ruta activa hacia el destino, se genera un mensaje de respuesta de ruta. Se considera que un nodo
intermedio tiene una ruta activa hacia el destino cuando el número de secuencia del nodo destino
almacenado en la tabla de rutas es mayor o igual al número de secuencia del nodo destino de la
solicitud. Cuando es el nodo destino quien genera la respuesta, incluye en el mensaje RREP como
número de secuencia el valor máximo entre su propio número de secuencia y los números de
secuencia de destino incluidos en los mensajes de solicitud de rutas. A diferencia de la solicitud, el
mensaje RREP se reenvía de vuelta al origen de forma unicast. Un mensaje RREP siempre sigue el
camino inverso de su mensaje RREQ correspondiente, por lo que los nodos típicamente asumen que
los enlaces son bidireccionales. La siguiente imagen detalla la trayectoria de las respuestas para
completar la fase de formación del camino de ida, en la que se indica mediante flechas el recorrido
de los mensajes RREP.

En este caso, puesto que se supone que ninguno de los nodos intermedios conoce la ruta, es el nodo
destino quien genera la respuesta, por lo que los dos mensajes RREP que llegan al nodo origen tienen
el mismo número de secuencia de destino. Para escoger una de las dos rutas posibles, se atiende al
menor número de saltos, y así se selecciona el camino de tres saltos, en lugar del que consta de
cuatro.
Cuando los nodos intermedios por los que pasó previamente la solicitud reciben la respuesta de
rutas, pueden verse en la necesidad de actualizar su tabla de rutas. En el diagrama de abajo se
muestra la lógica que siguen los nodos intermedios para decidir si actualizar o no la entrada en la
tabla correspondiente al nodo destino. Un nodo intermedio procede a la actualización de rutas en
dos casos. En primer lugar, refresca su ruta si el nuevo número de secuencia asociado al nodo
destino que se incluye en el mensaje RREP es mayor que el que figura en su tabla para ese destino.
En segundo lugar, cuando ambos números de secuencia coinciden, se procede a la actualización
cuando el número de saltos indicado en la respuesta es inferior al indicado en su tabla. Los mensajes
RREP redundantes o con un número de secuencia de destino menor se descartan automáticamente.
Cuando finalmente el nodo origen recibe el mensaje de respuesta, guarda la ruta hacia el destino y
puede comenzar a transmitir paquetes de datos.

10
 Nº de sec de
destinoen RREP >
Si
Nº de sec de
destino en tabla

Actualizar rutas
No

Nº de sec de Nº de saltos hacia el Si

destino en RREP
Si destino en RREP + 1
= Nº de sec de < Nº de saltos hacia
destino en tabla el destino en tabla

No No

No actualizar rutas

Mantenimiento de ca minos
El protocolo AODV, al igual que otros protocolos de encaminamiento, emplea mensajes hello para
que los nodos anuncien a sus vecinos su pertenencia a la red y, de esa manera, se pueda monitorizar
en una ruta activa el estado del enlace hacia el siguiente salto. Los mensajes hello se envían de
manera periódica, lo que permite detectar fallos de enlace. Cuando un nodo deja de recibir estos
mensajes por parte de alguno de sus vecinos, puede concluir que el enlace ha dejado de estar
operativo. En el momento en el que un nodo advierte un fallo en un enlace, difunde por broadcast un
mensaje de error de ruta (RERR, Route Error ) a sus vecinos, que a su vez lo propagan hacia nodos
cuyas rutas podrán verse afectadas por esta eventualidad. Puesto que el mensaje RERR se propaga
hacia el nodo origen, cada nodo intermedio marca como inválida la ruta cuando recibe el mensaje de
error. No obstante, el nodo origen perjudicado puede reiniciar su operación de descubrimiento de
rutas en caso de que aún necesite alcanzar ese nodo destino.

11
Formato de los mensajes
Route Request (RREQ)

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 1
J Join flag; reservado para multicast.
R Repair flag; reservado para multicast.
Gratuitous RREP flag; indica si RREP debe ser enviado directamente al
G
nodo especificado en el campo de la dirección IP destino.
Destination only flag; es seteado si se quiere que solo conteste al RREQ el
D
nodo destino.
Unknown sequence number; indica si el número de secuencia del nodo
U
destino es desconocido.
Número de saltos desde el nodo origen al nodo que le llega el mensaje de
Hop Count
requerimiento.
Un número de secuencia único identificando el RREQ particular cuando se
RREQ ID
toma junto con la dirección de IP del nodo origen.
Destination IP Address Dirección IP del nodo destino al que se desea llegar.
Destination Sequence
Último número de secuencia del destino obtenido por el emisor.
Number
Originator IP Address Dirección de IP del nodo que originó el RREQ.
Originator Sequence
Número de secuencia actual del emisor del mensaje RREQ.
Number

12
 Route Reply (RREP)

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|A| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 2
R Repair flag; usado para multicast.
A Acknowledgment required.
Si es distinto de cero, los 5 bits indican al siguiente salto que puede
Prefix Size usarse para cualquier nodo con el mismo prefijo que el origen que
solicita el destino.
Hop Count El número de saltos entre la IP origen y la IP destino.
Destination IP Address Dirección de IP del destino para el cual se suministra la ruta.
Destination Sequence
Número de secuencia asociada a la ruta establecida.
Number
Originator IP Address Dirección IP del nodo que originó el RREQ.
El tiempo en milisegundos para el cual el nodo recibe el RREP y
Lifetime
considera la ruta establecida como válida.

Route Er ror (RERR )

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |N| Reserved | DestCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination Sequence Number (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Additional Unreachable Destination IP Addresses (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Additional Unreachable Destination Sequence Numbers (if needed)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

13
 Type 3
No delete flag; si el flag esta seteado, se esta ejecutando una reparación
N
local del link y entrada en la tabla de ruteo no debe ser borrada.
DestCount Número de destinos inalcanzables incluidos en el mensaje.
Unreachable
Dirección IP del destino que se ha vuelto inalcanzable.
Destination IP Address
Unreachable
Número de secuencia en la tabla de ruteo correspondiente al nodo
Destination Sequence
destino inalcanzable.
Number

14
 Caso de estudio: protocolo AODV
Con el objetivo de realizar una simulación de una red ad hoc MANET utilizando el protocolo AODV se
usó el simulador NS-2 (network simulator), el cual es un simulador de redes basado en la
planificación de eventos.
NS-2 está encapsulado dentro del lenguaje TCL (Tool Command Language). Las simulaciones se
realizan mediante un programa Tcl. Pero en la versión 2 en lugar de encontrarse encapsulado en el
lenguaje Tcl, se sustituye por el Object Tool Command Language de MIT (Massachusetts Institute of
Technology), OTCL (una versión de Tcl orientada a objetos). Utilizando las instrucciones de NS-2 se
define la topología de la red, se configuran las fuentes de tráfico, se guardan los resultados en un
fichero de salida y se invoca el simulador. Las instrucciones de NS-2 permiten invocar los
procedimientos Tcl desde puntos arbitrarios de la simulación, ofreciendo un mecanismo flexible que
permite modificar desde la topología de la simulación, hasta registrar acontecimientos que de forma
normal no se registran o se hacen en formatos diferentes. Una topología de red se define mediante
tres primitivas que construyen los bloques: nodos (nodes), enlaces (links) y agentes (agents).
Para visualizar los resultados obtenidos de la simulación, se utilizó la herramienta NAM (Network
AniMator). La misma da soporte para poder interpretar y entender las simulaciones de un modo
visual. Si bien no es imprescindible, es de mucha ayuda para poder visualizar como es el
comportamiento de la red y así saber como tratar los resultados obtenidos.
Por último se utilizó el lenguaje AWK el cual sirve para procesar datos basados en texto. Este
lenguaje es ideal para trabajar con nuestros archivos de trazas que contienen información
estructurada en campos, ya que sus características permiten descomponer líneas de entradas en
campos y comparar los mismos con patrones específicos. Para ello se creó un filtro, el cual nos
permite ver las tasas de paquetes y bytes entregados en la red simulada.

Archivo d e s imulación
En primer lugar realizamos el archivo tcl cuya estructura consta de las siguientes partes:
1. Parámetros de la simulación
# Se especifican los parámetros que se utilizaran en la simulación.
…
set val(pr) AODV;# Protocolo de ruteo
…
2. Inicializando variables globales
set ns [new Simulator]
3. Creación de los archivos de traza.
set traza [open traza.tr w]
$ns use-newtrace; # usamos el nuevo formato de traza
$ns trace-all $traza
set namtraza [open traza.nam w]
$ns namtrace-all-wireless $namtraza $val(x) $val(y)
4. Creación la topografía inicial.
#Se especifica el área donde se situara la red.
5. Se crea el canal de comunicación.
#En nuestro caso se crea un canal de aire.

15
 6. Seteo de la configuración que tendrán los nodos.
#Se asocia a la configuración del nodo los parámetros establecidos
anteriormente
7. Creación de los nodos con la configuración establecida.
for {set i 0} {$i < $val(n)} {incr i} {
set node_($i) [$ns node]
}
8. Ubicación inicial y movimientos de los nodos.
#Se carga la ubicación inicial de cada nodo en el área antes
especificada y se dan los eventos que moverán los nodos.
9. Creamos tráfico.
# Se crea la conexión TCP entre los nodos que se comunicaran durante
la simulación.
10. Tiempo de duración de la simulación.
11. Procedimiento de finalización.
#Se da por finalizada la traza y se ejecutan los programas de
visualización o análisis deseados.
12. Sentencia de corrida.
$ns run

Anális is med iante NAM

Para visualizar lo sucedido en la simulación hecha mediante ns utilizamos la herramienta NAM junto
al archivo traza.nam obtenido en la corrida. A partir de esto pudimos corroborar el correcto
funcionamiento del protocolo en estudio. A continuación se muestran algunas capturas de pantallas
y se explica brevemente lo que sucede.

El programa cuenta con controles para

detener y avanzar el tiempo de
simulación a diferentes velocidades. En
la parte inferior se visualiza la línea de
tiempo.
Aquí se muestra la posición inicial de
una red ad hoc con 5 nodos, en donde
se creará tráfico entre el número 0 y el
número 1.

16
 Para iniciar la transferencia de datos, el
nodo 0 crea un mensaje RREQ y lo
envía a sus vecinos, en este escenario
solo le llega al nodo 3. Como el nodo 3
no es el destino y tampoco conoce
como llegar al nodo 1, lo pasa al nodo
2. El mensaje llega al nodo 1 pasando
por 3, por 2 y por 4, concluyendo el
camino de vuelta. Al llegar al nodo 1,
éste responde con un RREP
formándose el camino de ida. Luego el
nodo 0 empieza a trasmitir datos
pasando por todos los nodos.

Podemos ver que el nodo 4 se aleja

provocando una ruptura en el camino
inicial. El nodo 2 se encarga de buscar
el camino alternativo hacia el nodo 1.
De esta manera, el emisor (nodo 1)
sigue su transmisión sin requerir un
nuevo camino.

Luego el nodo 0 se aleja del nodo 3,

provocando la ruptura de camino
anterior, y creando uno nuevo
(mediante mensajes RREQ y RREP) que
solo tiene como intermediario al nodo
2.

17
 Aquí se ve que el nodo 2 se empieza a
alejar de su posición original.
Se puede apreciar que aunque el nodo
0 esté más próximo al 1, éstos se
siguen comunicando a través del 2 ya
que AODV es un protocolo reactivo y
mientras la ruta actual no se rompa, no
realiza la petición de otra.

Como podemos observar el nodo 2

desaparece de la red dejando así la
ruta anterior rota, en consecuencia el
nodo 0 realiza nuevamente una
petición (RREQ) encontrando esta vez
un link directo al nodo 1.

Por último vemos que el nodo 1 se

vuelve a alejar de su emisor,
provocando la ruptura nuevamente de
la ruta. No obstante el nodo 1 realiza
inmediatamente una nueva petición
(RREQ) encontrando esta vez como
intermediario al nodo 3.

Vale aclarar que en los instantes donde se produce la ruptura de las rutas, hay un tiempo donde no
existe transmisión de datos y en algunos casos cierta cantidad de paquetes se pierden.

18
 Anális is med iante AWK
Mediante este lenguaje se analiza el archivo de traza traza.tr. El mismo interpreta cada fila por
separado, hasta que aparece un salto de línea, y cada fila la interpreta como una serie de campos
separados por espacios, es decir, exactamente como se componen los archivos de trazas.
Para obtener los datos deseados, creamos un filtro el cual tiene la siguiente estructura:
BEGIN {
#instrucciones que sólo se ejecutaran una vez
# Se inicializan las variables globales
}
{
#instrucciones que se ejecutaran para cada evento
}
END {
#instrucciones que sólo se ejecutaran una vez
}
Por cada fila:
Si el registro es un evento send realizado por el emisor y el paquete es de tipo tcp,
entonces se incrementa en uno la cantidad de paquetes enviados y se suma el tamaño
del paquete a la cantidad de bytes enviados.
Si el registro es un evento recibe realizado por el receptor siendo el paquete también de
tipo tcp, se incrementa en uno los paquetes recibidos y se suma los bytes del paquete a
la cantidad total de bytes recibidos.
Para el manejo de los bytes por paquetes, se descuenta en este último caso los bytes de las
cabeceras IP.
Con estos datos se realiza el cálculo para obtener la tasa de paquetes entregados, como así también
la tasa de bytes entregados. Este desarrollo se realiza en la parte END.
Los datos arrojados son los siguientes:
Paquetes recibidos 1499
Paquetes enviados 1540
Tasa de paquetes entregados 0.973377
----------------------------
Bytes recibidos 1527980
Bytes enviados 1600600
Tasa de paquetes recibidos 0.954630

19
Conclusión
Las redes ad hoc permiten que el tráfico pase por múltiples nodos sin necesidad de una estructura
fija, lo cual brinda la posibilidad de movilidad de sus nodos. Esta propiedad influye de manera directa
para que los enlaces sean mayormente de tipo wireless, ya que estos la aprovechan en su totalidad.
Por el mismo motivo, es poco factible realizar una red cableada ad hoc, ya que su principal ventaja se
ve reducida por la inmovilidad de los nodos. Igualmente esto no es excluyente, en caso de no contar
con un dispositivo encaminador y poseer múltiples placas de red por nodo, se podría llevar a cabo
dicha red. Esto se ve reflejado en el protocolo estudiado (AODV) ya que en su RFC (RFC3561) no
limita que el tipo de conexión de los enlaces sean wireless.
A partir de la simulación realizada, se observa que la cantidad de paquetes perdidos es relativamente
baja teniendo en cuenta la cantidad de cambios en la topología de la red, deducido a partir de los
altos valores obtenidos en las tasas calculadas, lo que verifica que el protocolo AODV cumple con las
propiedades de las redes ad hoc.

20
 Referencias
Wikipedia - http://es.wikipedia.org/wiki/Red_Ad_hoc
RFC 3561 - Ad hoc On-Demand Distance Vector (AODV) Routing -
http://www.faqs.org/rfcs/rfc3561.html.
“Estudio de la eficiencia de encaminamiento del protocolo AODV en redes ad hoc
inalámbricas de gran escala” - María Elena Gil Jiménez.
Paper: “Formación de redes inalámbricas ad hoc—El arte de la formación de redes sin red” -
Magnus Frodigh, Per Johansson y Peter Larsson.
“Estudio y análisis de prestaciones de redes móviles Ad Hoc mediante simulaciones NS-2 para
validar modelos analíticos” - Jordi Chalmeta Ugas.
Network Simulator (NS-2) - http://www.isi.edu/nsnam/ns/.
NAM (Network AniMator) - http://www.isi.edu/nsnam/nam/.
Formato trazas NS-2 - http://nsnam.isi.edu/nsnam/index.php/NS-2_Trace_Formats.

21
Anexo - Códigos de la simulación
sim.tc l
#***** Simulación protocolo AODV *****#

# Parámetros de la simulación
set val(canal) Channel/WirelessChannel ;# Tipo de canal
set val(prop) Propagation/TwoRayGround ;# Modelo de radio de propagación
set val(i_red) Phy/WirelessPhy ;# Tipo de interfaces de red
set val(mac) Mac/802_11 ;# Tipo de MAC
set val(i_cola) Queue/DropTail/PriQueue ;# Tipo de cola de la interfaz
set val(ll) LL ;# Tipo de capa de enlace
set val(ant) Antenna/OmniAntenna ;# Modelo de antena
set val(i_max) 50 ;# Cantidad máxima de paquetes en la cola
set val(n) 5 ;# Número de nodos
set val(pr) AODV ;# Protocolo de ruteo
set val(x) 1000
set val(y) 1000

# Inicializando variables globales

set ns [new Simulator]
set traza [open traza.tr w]
$ns use-newtrace ;# usamos el nuevo formato de traza
$ns trace-all $traza
set namtraza [open traza.nam w]
$ns namtrace-all-wireless $namtraza $val(x) $val(y)

source "ini_antena.tcl"

#Participantes
set Alice 0
set Bob 1
set Carol 2
set Dan 3
set Eva 4

# Crea la topografía
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)

# Indica la cantidad de nodos

create-god $val(n)

# Crea el canal de comunicación

set canal [new $val(canal)]

# Configuración del nodo

$ns node-config -adhocRouting $val(pr) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(i_cola) \
-ifqLen $val(i_max) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(i_red) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace OFF \
-channel $canal

# Crea los nodos con la configuración establecida

for {set i 0} {$i < $val(n)} {incr i} {
set node_($i) [$ns node]
}

22
 # Ubicación inicial y movimientos de los nodos.
source "ubic_nodos.tcl"
source "mov_nodos.tcl"

# Creamos tráfico TCP entre Alice y Bob

set tcp [new Agent/TCP]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns attach-agent $node_($Alice) $tcp
$ns attach-agent $node_($Bob) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 1.0 "$ftp start"

$ns at 30.0 "stop"

$ns at 30.01 "puts \"NS Terminando...\" ; $ns halt"
proc stop {} {
global ns traza
$ns flush-trace
close $traza
exec nam traza.nam &
exit 0
}

puts "Comenzando simulación..."

$ns run

ubic_nodos.tcl
$node_($Alice) set X_ 100.0
$node_($Alice) set Y_ 500.0
$node_($Alice) set Z_ 0.0

$node_($Bob) set X_ 900.0

$node_($Bob) set Y_ 500.0
$node_($Bob) set Z_ 0.0

$node_($Carol) set X_ 500.0

$node_($Carol) set Y_ 600.0
$node_($Carol) set Z_ 0.0

$node_($Dan) set X_ 300.0

$node_($Dan) set Y_ 700.0
$node_($Dan) set Z_ 0.0

$node_($Eva) set X_ 700.0

$node_($Eva) set Y_ 700.0
$node_($Eva) set Z_ 0.0

for {set i 0} {$i < $val(n)} {incr i} {

$ns initial_node_pos $node_($i) 20
}

mov_nodos.tcl
#Movimientos de Alice
$ns at 1.0 "$node_($Alice) setdest 400.0 450.0 50.0"

#Movimientos de Bob
$ns at 1.0 "$node_($Bob) setdest 600.0 650.0 100.0"
$ns at 15.0 "$node_($Bob) setdest 400.0 800.0 30.0"

#Movimientos de Carol
$ns at 12.2 "$node_($Carol) setdest 600.0 999.0 300.0"

23
#Movimientos de Dan
$ns at 14.0 "$node_($Dan) setdest 500.0 600.0 30.0"

#Movimientos de Eva
$ns at 2.0 "$node_($Eva) setdest 700.0 780.0 400.0"
$ns at 4.0 "$node_($Eva) setdest 700.0 700.0 300.0"

tasas.awk
BEGIN {
# Las instrucciones contenidas dentro de BEGIN sólo se ejecutan una vez
# Se abre el fichero de salida
salida2="Tasas.txt"
# Se inicializan las variables globales
mayor_id=-1
bytes_env_0=0
rec_1=0
env_0=0
bytes_rec_11=0
}

{
# Las instrucciones contenidas dentro de este apartado principal se ejecutan una vez
# para cada fila del fichero
# Se asignan variables a las columnas o campos a utilizar del fichero de trazas
accion=$1
nodo_actual=$9
bytes_paquete=$37
id_paquete=$41
nodo_destino=$7
prot_mes=$35
trace_level=$19
if(accion!="SFESTs" && accion!="SFs" && trace_level=="AGT"){
# Se analizan los paquetes enviados
if ( accion == "s"){
# Se miran los paquetes no analizados previamente
if (id_paquete > mayor_id){
mayor_id=id_paquete
if ( prot_mes == "tcp"){ # Sólo interesan los paquetes tcp
# Se comprueba si el paquete lo envía el nodo fuente
if ( nodo_actual == 0){
bytes_env_0 = bytes_env_0 + bytes_paquete
# Se suman los bytes tcp enviados por el nodo 0
# o fuente
env_0++
# Se incrementa el número de paquetes tcp
# enviados por el nodo 0
}
}
}
}
# Se analizan los paquetes recibidos
if ( accion == "r"){
if (nodo_actual == nodo_destino){
if (nodo_actual == 1){
bytes_rec_1 = bytes_rec_1 + bytes_paquete - 20
# Se suman los bytes tcp recibidos por el nodo 1
# o destino, se descuenta la cabecera IP de 20 bytes
rec_1++
# Se incrementa el número de paquetes tcp recibidos
# por el nodo 1
}
}
}
}
}

24
 END{
# Las instrucciones contenidas dentro de END sólo se ejecutan una vez
# Se guardan los resultados obtenidos en el fichero de salida
printf("Paquetes recibidos %i \n", rec_1) > salida2
printf("Paquetes enviados %i \n", env_0) > salida2
printf("Tasa de paquetes entregados %f \n", rec_1/env_0) > salida2
printf("---------------------------- \n") > salida2
printf("Bytes recibidos %i \n", bytes_rec_1) > salida2
printf("Bytes enviados %i \n", bytes_env_0) > salida2
printf("Tasa de paquetes recibidos %f \n", bytes_rec_1/bytes_env_0) > salida2
# Se cierra el fichero de salida
close(salida2)
}

25