Introduction 103

La versión original del NS-2.26 no cuenta con la instalación previa de ningún protocolo de multi-difusión para redes ad hoc y sólo cuenta con 3 protocolos de multi-difusión para redes cableadas, entonces se instaló una extensión del NS para la versión 2.26 del MAODV [Zhu y Kunz, 2004]. Partiendo de esta extensión se hicieron modificaciones para poder trabajar conjuntamente con la red cableada, también analizando otros trabajos como el de Ali Hamidian [2003] que integra el AODV7 con la red cableada.

Lo primero que se realizó fue la instalación del protocolo MAODV en la versión original del NS-2. El NS-2.26 ya tiene instalado el protocolo DVMRP, posteriormente se generaron escenarios con nodos cableados y con nodos inalámbricos, para instalar los dos protocolos primero de manera separada.

7 _{Ad Hoc On Demand Distance Vector}

78

Las primeras modificaciones que se hicieron fueron las de cambiar algunos de los parámetros del protocolo MAODV. Por ejemplo, el parámetro RREP_WAIT_TIME que se utiliza para indicar el tiempo que el nodo debe esperar por la respuesta de ruta RREP después de enviar un mensaje de petición RREQ; este parámetro se modificó debido a que no se tiene pensado crear escenarios con muchos saltos y no es necesario esperar tanto tiempo por la respuesta de ruta, por ello se cambió el valor de 0.5 a 0.25 segundos. Otro parámetro que se cambió fue el de RREQ_RETRIES, que se utiliza para indicarle al nodo cuantos intentos hará para obtener una respuesta de ruta; este parámetro se modificó con el fin de que solo se realicen dos reintentos de petición de ruta, pues en la arquitectura propuesta no es necesario realizar más intentos. También se eliminó el mensaje HELLO, del protocolo AODV, como se tiene pensado solo manejar tráfico de multi-difusión en la red, basta con los mensajes GRPH para avisar el estado de la red.

La arquitectura de red que se propone requiere de nodos con 2 interfaces: una cableada y una inalámbrica. El nodo con 2 interfaces se configura para que maneje multi-difusión con el protocolo DVMRP y también con el protocolo MAODV. Como tiene que manejar el mensaje prune y el mensaje graft además de los mensajes de control de MAODV, existe conflicto porque los mensajes de control de DVMRP no están registrados en el protocolo MAODV, por lo tanto, fue necesario modificar el archivo aodv.cc para registrar los mensajes de control de DVMP en las rutinas de MAODV.

Para lograr que el Enrutador de Frontera enviara el mensaje graft y se uniera al árbol de distribución de manera automática cuando exista un grupo de multi-difusión en la red ad

hoc, se tuvo que modificar el archivo aodv_mcast.cc en la función AODV::recvMGRPH. La figura 30 muestra lo que se evalúa en dicha función.

Figura 30. Proceso de unión del Enrutador de Frontera.

La figura 31 muestra la estructura interna de un nodo de multi-difusión. El tráfico entra y pasa por el agente llamado switch_, quien determina si los paquetes que se reciben son o no tráfico de multi-difusión. Cuando el tráfico entra al clasificador de multi-difusión, éste es direccionado a los replicadores de tráfico de multi-difusión y de los replicadores, el tráfico se envía a un agente que puede ser una aplicación en el nodo receptor. En este caso, el

Se recibe un mensaje GRPH El nodo que lo recibe ¿Es el Enrutador de Frontera? Se actualiza la tabla Líder de grupo Es parte del árbol de difusión en DVMRP

Se envía el mensaje graft por la

interfaz cableada para unirse al árbol de distribución en DVMRP

NO

SÍ

SÍ

80

tráfico se debe enviar al agente de enrutamiento AODV8, por lo que se requiere establecer una conexión entre el replicador de tráfico de multi-difusión y el agente de AODV.

Figura 31. Estructura interna de un nodo de multi-difusión.

Una vez establecida la conexión entre el replicador de tráfico de multi-difusión y el agente de AODV, es necesario hacer una nueva modificación; los paquetes que se direccionan del replicador de tráfico de multi-difusión al agente de AODV, tienen en el encabezado como dirección de la fuente la dirección del nodo que generó el tráfico en la red cableada, este nodo no es identificado por el agente de AODV, por tal motivo, es necesario cambiar la dirección del nodo fuente por la dirección del Enrutador de Frontera, de tal manera que el Enrutador de Frontera se convierte en la virtual fuente de tráfico de multi-difusión para la red ad hoc. Estas modificaciones son realizadas en la función AODV::recv en el archivo aodv.cc.

Para lograr que el enrutador de frontera se pode del árbol de difusión DVMRP, solo fue necesario modificar la función AODV::recvMACT, en el procedimiento recvMACT-P, que es donde se le indica que si el enrutador de frontera recibe al mensaje MACT-P, cambie su estado de miembro de grupo a no miembro de grupo y envíe el mensaje prune para liberarse del árbol de distribución de DVMRP.