Additional Revealed terms
2.5 Summary and Implications for Research
4.2.1. Números de secuencia
El objetivo de los números de secuencia es evitar bucles de encaminamiento
que pueden afectar a cualquier red pero afectan especialmente a las redes
inalámbricas dada su naturaleza de compartición del medio.
Cada nodo dispondrá de su propio número de secuencia, el cual aumentará a
cada nuevo paquete que sea recibido.
La utilización de números de secuencia nos permite tener siempre la
información de las rutas lo más actualizada posible ya que si nos llega
información desactualizada, sería descartada por el simple hecho de tener un
número de secuencia inferior.
4.2.2. Descubrimiento de rutas
Cuando queremos transmitir una información entre 2 nodos origen y destino, si
no tenemos ninguna ruta previamente establecida, pílale protocolo AODV
comienza un proceso de descubrimiento de ruta.
En este procedimiento enviamos un paquete RREQ (Route Request) en modo
Broadcast (Fig 4.1.) con el objetivo de solicitar una ruta indicando el
identificador del nodo que queremos alcanzar, el identificador de nodo origen,
el número de saltos inicializado a 0 y su número de secuencia.
Fig 4.1 Proceso completo de descubrimiento
Si cualquier nodo que no sea destino recibe este paquete, primero comprueba
si lo ha recibido previamente en un registro de RREQ recibidos (rreq_record) y
en caso de no estar registrado, lo vuelve a retransmitir, incrementamos el
número de saltos y creamos la ruta reversa (ruta al nodo por el que a llegado
este RREQ (fig 4.1.)). Gracias a esto vamos estableciendo nuestra tabla de
rutas hacia un destino o varios.
Un nodo tan sólo podrá responder con un paquete RREP (Route Reply) para
confirmar una ruta en 2 casos: si el nodo es ya el destino o también en el
momento en que el nodo que ha recibido un RREQ disponga de ruta hacia
destino.
En el momento de responder con un RREP, se envía en modo unicast hacia el
vecino que nos había mandado el RREQ de la ruta correspondiente, añadimos
la dirección de destino, el número de secuencia de destino así como la
dirección del nodo origen y el número de saltos entre origen y destino. Y así
sucesivamente hasta conseguir llegar a origen.
O
2
D
1
RREQ
RREQ
RREP
RREP
RREQ
O
2
D
1
RREP
O
2
D
1
DATOS
DATOS
Paquetes RREQ en
broadcast
Creacion de ruta
reversa
Paquetes RREP
en unicast
Paquetes de datos
por ruta establecida
Creación forward
Cuando los RREP llegan al siguiente nodo vecino, incrementamos el valor de
saltos hop-count del RREP y generamos una ruta de reenvío(fig 4.1.) (forward
route) hacia el destino del RREQ y hacia el nodo vecino por el que hemos
recibido el RREP. Así también actualizamos la ruta inversa antes establecida
mediante RREQ y todos los temporizadores asociados.
Una vez llega un RREP a origen se confirma la ruta. El nodo origen puede
recibir diversos RREP de diversos nodos como confirmación de posibles rutas
distintas a origen, en este caso el nodo origen tiene 2 criterios para escoger la
mejor ruta, por una parte la que tenga el menor número de saltos y por otro el
que tenga el número de secuencia más alto.
4.2.3. Mantenimiento y gestión de rutas
AODV se mueve en el medio radio que es un entorno bastante hostil por sus
continuas oscilaciones en la calidad del canal y sobretodo la movilidad de los
nodos que provoca la rotura de los enlaces. Es por ello que se establecen
distintos mecanismos para mantener o eliminar las rutas según su calidad y
fiabilidad.
4.2.3.1.
Conectividad local entre vecinos
En el estándar se definen 2 métodos:
El primer método consiste en dejar esta tarea a la capa MAC del estándar radio
utilizado en ese momento. Mediante confirmaciones (ACK) podemos saber el
estado del enlace, en caso de no recibir esta confirmación sabremos que
nuestro vecino o no está en condiciones de transmitir o el canal a perdido
mucha calidad.
Las confirmaciones se envían de forma automática cada vez que enviamos un
paquete de datos, podemos decir que es un método bastante rápido.
El segundo método es el más habitual y se basa en el envío de mensajes
HELLO. Estos mensajes son enviados por los nodos que forman parte de una
ruta activa para indicar al resto de nodos vecinos su existencia y así mantener
la conectividad con ellos.
Los paquetes HELLO son enviados en modo Broadcast, contienen la dirección
de su emisor, su número de secuencia, el tiempo de vida del enlace y un TTL
de 1. La cadencia de envío de estos paquetes funcional determina el parámetro
HELLO_INTERVAL.
La forma de actuar del resto de nodos que reciben estos paquetes HELLO, es
buscar en su tabla de rutas si alguna de estas tiene algún nodo vecino (next-
hop) necesario para alcanzar un destino, en caso afirmativo se actualizará el
temporizador asociado a esta ruta.
Un nodo invalidará un nodo vecino o la ruta/s activas en el momento que deje
de recibir paquetes HELLO en un tiempo superior al producto de las constantes
ALLOWED_HELLO_LOSS y HELLO_INTERVAL. ALLOWED HELLO LOSS es
el número máximo de paquetes HELLO que se pueden dejar de recibir antes
de descartar una ruta activa.
Existe un tercer método comentado en el RFC, el denominado passive ack, que
consiste en verificar el estado de las rutas escuchando todas las
confirmaciones que provienen de otros nodos a nivel de enlace, de esta forma
lograríamos un mayor control de las rutas invalidando de forma inmediata
aquellas que no han recibido el ack correspondiente.
4.2.3.2.
Paquetes RERR
Los paquetes Route Error forman parte de un mecanismo, que nos permite
detectar cuando un enlace radio está roto y por tanto cuando una ruta esta
caída en cierta sección.
Cuando esto sucede, el nodo que detecta la rotura invalida todos los destinos
que han pasado a ser inalcanzables por culpa de este error en el enlace y
seguidamente crea y envía el paquete RERR.
Dependiendo del enlace que se haya roto, puede significar que distintas rutas
hacia el nodo destino inalcanzable se hayan visto afectadas, así que según
esta naturaleza los paquetes RERR serán enviados en modo unicast o
multicast. Este paquete se utilizará para avisar del fallo del enlace y contendrá
una lista de los nodos que han pasado a ser inalcanzables.
Bajo el punto de vista del nodo que recibe el paquete RERR, primero mira si el
destino del paquete RERR es el next-hop de alguno de los destinos que vienen
en el paquete. En caso afirmativo y siempre que el número de secuencia sea
mayor al almacenado en tabla de rutas del nodo local, marca la ruta hacia
destino como inválida y le suma a su Tiempo de Vida la constante
DELETE_PERIOD restante para que expire. Una vez hecho esto vuelve a
propagar el paquete RERR repitiendo el proceso mencionado anteriormente
hasta llegar a origen.
Si un nodo recibe un RERR anunciando un destino que quiere a continuación
alcanzar, tiene que volver a empezar el mecanismo de descubrimiento de ruta
del que hemos hablado anteriormente.
4.2.4. Reinicio de un nodo
Cuando un nodo se desconecta y reconecta por el motivo que sea, perderá el
número de secuencia y los números de recuento de las rutas hacia sus
destinos, pudiendo provocar bucles en el enlace. Lo que hace el nodo al
reiniciar es vaciar la tabla de rutas y evita contestar los RREQ durante un
tiempo definido por DELETE_PERIOD, que es tiempo necesario para vaciar la
tabla de encaminamiento.
