Recepción de un MRA en un nodo

En la figura 6.1 se puede observar el comportamiento del nodo al recibir un MRA. Lo primero que hace un nodo al recibir un mensaje modificado de aviso de gateway es comprobar si él mismo es un gateway, porque si así fuese el paquete MRA sería descartado directamente saliendo de la rutina de recepción de mensajes MRA. Lo más probable es que no sea gateway. En este caso, se procede actualizar la entrada en la tabla de encaminamiento hacia el gateway originador del mensaje MRA. Hasta este preciso punto, las dos técnicas de DAD comentadas en este documento actúan de la misma manera, pero a

partir de aquí hay que diferenciar su comportamiento. Recepción MRA ¿El nodo es GW? Actualizar ruta hacia GW Descartar MRA ¿DAD anticipado? Llama a:Nuevo_GW

¿No hayruta hacia gw o es nuevo gw y con rut a más corta?

¿Ruta + act ual o + corta? Lanzar DAD convencional Actualizar ruta por defecto VOLVER Reenviar MRA Sí Sí Sí Sí No No No No

Figura 6.1 Recepción de MRA

En el caso de no realizar el DAD anticipado, el paso siguiente es comprobar si se desea escoger un nuevo gateway, bien porque no se haya seleccionado ninguno hasta el momento, o bien porque la ruta hacia éste sea más corta. Si el criterio de selección fuese minimizar el número de conmutaciones de gateways, la segunda comprobación no tendría lugar. Si, en cambio, se prefiere configurar un nuevo gateway se debe configurar la dirección asociada a este nuevo gateway e iniciar un procedimiento de DAD. Para ello, se lanza una petición de ruta hacia un hipotético nodo con la misma dirección recién configurada y activando el temporizador asociado a la detección de duplicidad de dirección.

Como se ha comentado en otras ocasiones, si no se recibe respuesta en un intervalo de tiempo determinado (TDAD) se entiende que la dirección es única. Al verificarse la unicidad de la dirección entonces se puede comenzar su utilización. Si se escoge el criterio de mantener el gateway que se venía empleando, bien porque para llegar al nuevo gateway hay que atravesar más nodos intermedios o porque se haya esté siguiendo el criterio de escoger el mejor gateway, entonces se realiza una segunda comprobación para ver si se trata de una ruta más corta o por el contrario es la misma que ya se estaba usando. Si se trata de una nueva ruta más corta hacia el mismo gateway o la misma ruta actualizada, entonces se actualiza la ruta por defecto en la tabla de encaminamiento. En caso contrario, es decir, de existir una ruta distinta, pero con más saltos o una versión anterior de la misma ruta no se hace nada. Una vez se ha actualizado la ruta por defecto en la tabla de encaminamiento, si correspondiese, se reenvía el mensaje de MRA. Aquí se presenta una diferencia entre la propuesta de [1] y la simplificación de [2] y es que en el segundo caso, únicamente se reenvía el mensaje MRA si el gateway asociado a él es el mismo que se está empleando en las comunicaciones con redes externas.

Si se ha optado por realizar el DAD anticipado, entonces en este punto del proceso se llama a una función que comprobará si se trata de un gateway detectado por primera vez, y por tanto ejecutar el DAD anticipado. Esta función se detallará un poco más adelante.

6.2.3.2. Recepción de un RREP

En la figura 6.2 se puede observar el comportamiento del nodo al recibir un RREP. Este tipo de mensaje fue explicado en el capítulo 2. Se trata de un paquete de respuesta de solicitud de ruta. También puede tratarse de un mensaje de respuesta de solicitud de ruta extendido o RREP_I, el cual contiene los mismos campos con las mismas funciones que un RREP normal, excepto por un flag. Si ésta se encuentra activa indica que el mensaje de respuesta fue generado por un gateway y que contiene la información necesaria para configurar una dirección IPv6 globalmente válida. Este mensaje se puede originar como respuesta a una solicitud RREQ_I, en la que un nodo busca de manera reactiva un gateway, o cuando el gateway, de oficio, responda a un nodo en particular cuando le llegue una solicitud de ruta de él.

El funcionamiento de los nodos móviles ante este evento es bastante similar al descrito en el apartado anterior, cuando se recibe un mensaje MRA. Si acaso la diferencia más importante es la comprobación que se realiza nada más identificar que tipo de mensaje se ha recibido. Esta verificación consiste en comprobar que el paquete recibido no es como

consecuencia del proceso de DAD, es decir, que no se trata de un conflicto de duplicidad de dirección. En caso de que el mensaje de respuesta contenga una ruta hacia un nodo con la misma dirección que se está configurando, el nodo deberá desechar tal dirección IPv6 y escoger una nueva, volviendo a iniciar un nuevo proceso de detección de duplicidad de dirección. Si el RREP recibido no tuviese relación alguna con la técnica de DAD, seguiría su tramitación habitual que consiste en actualizar la entrada correspondiente al origen del paquete en la tabla de encaminamiento.

Recepción Reply Comprobar que no es de DAD ¿Es RREP _I? Actualizar Ruta hacia origen ¿DAD anticipdo? Llama a: Nuevo GW

¿No hay rut a hacia gw o es nuevo gw y con rut a más corta?

Lanzar DAD convencional Actualizar ruta por defecto VOLVER Reenviar RREP ¿Rut a + actual o + corta? Sí Sí Sí Sí No No No No Sinmodificación

Hay que comentar que sólo se va a detallar el proceso para la recepción de un RREP_I, ya que el proceso de un RREP es el mismo que se propone en [1] y que se implementa en [27] en AODV. En este punto del procedimiento hay que preguntarse si se está trabajando con DAD anticipado o no. Si es así se actúa de la misma manera que al recibir un MRA, llamando a una función que chequeará si se trata de un gateway detectado por primera vez, y por tanto ejecutar el DAD anticipado. Esta función se detallará un poco más adelante.

Si no se está anticipando la ejecución de la técnica de DAD, los pasos a seguir también son similares a los que se dan cuando se recibe un mensaje de aviso de gateway. A saber, ver si se trata de un gateway nuevo y, en caso de seleccionarlo para encaminar los paquetes hacia el exterior a través de él, ejecutar el DAD convencional. Si el mensaje de respuesta extendido recibido se corresponde al gateway que se está empleando en las comunicaciones externas, entonces se mira si se trata de la misma ruta actualizada o una nueva, pero más corta y si es así se modifica la ruta por defecto en la tabla de encaminamiento, adecuándola a la nueva situación y pasando a reenviar la respuesta de RREP, si así fuera conveniente. Si el mensaje RREP_I correspondiese a una nueva ruta más larga o una versión obsoleta de la actual pasa directamente a reenviar el mensaje de respuesta.