Encaminamiento y Tunelización -Tunneling to the care-of address

Una vez completados los procesos de descubrimiento y registración en forma exitosa, los paquetes pueden ser encaminados desde su dirección IP origen a su dirección IP destino de varias maneras dependiendo de si el nodo móvil se encuentra en su red local o en una externa.

Encaminamiento

Si el nodo móvil se encuentra en su red local actúa como cualquier nodo fijo y los paquetes seguirán las reglas para el encaminamiento de paquetes IP hacia cualquier nodo o enrutador convencional.

Para el caso de que el nodo móvil se encuentre en una red foránea, el protocolo IP Móvil requiere que los paquetes enviados hacia el nodo móvil desde la red local sean encapsulados. El encapsulado altera el encaminamiento habitual de los paquetes ya que éstos deben pasar por un nodo intermedio, donde se los desencapsula y se envía el paquete original al destino final. En general las operaciones que comprende el envío de paquetes hacia un nodo móvil en una red foránea son:

• el agente local anuncia que existe conectividad hasta el prefijo de red de la dirección IP del nodo móvil. Por lo tanto, todo paquete destinado al nodo móvil es encaminado hacia su red local donde es recibido por su agente local.
• el agente local intercepta el paquete destinado al nodo móvil y consulta su entrada en su tabla de enlace de movilidad para conocer las direcciones de auxilio registradas.
• el agente local envía una copia del paquete hacia cada dirección de auxilio a través del túnel. En cada dirección de auxilio, se extrae el paquete original y es entregado al nodo móvil. Antes de enviar un paquete a través del túnel, el agente local realiza la operación de encapsulado dentro de un nuevo paquete cuya dirección de destino es la dirección de auxilio. Si se trata de una dirección de auxilio de un agente foráneo, éste deshace el encapsulamiento exterior del paquete para recuperar el paquete original. Luego consulta el campo de dirección IP de destino para comprobar si coincide con alguno de los nodos móviles a los que está prestando servicio. Si es este el caso, el agente foráneo envía el paquete al nodo móvil a través de la interfaz adecuada. Si el nodo móvil tiene una co-located care-of address, no recibe los servicios de ningún agente foráneo, por lo que el mismo, efectúa la tarea de desencapsulamiento.

Para enviar paquetes desde el nodo móvil a otros nodos, el nodo móvil debe encontrar la dirección de un enrutador que pueda dar salida a sus paquetes. Si el nodo móvil depende de un agente foráneo, el enrutador adecuado puede ser:

• el propio agente foráneo (campo dirección IP fuente de un mensaje avisos de agente)
• cualquier enrutador cuya dirección IP aparezca en los campos dirección enrutador del mensaje avisos de agente.

Si el nodo móvil no depende de un agente foráneo también cuenta con dos alternativas para seleccionar un enrutador:

• elegir algún enrutador que esté enviando mensajes de avisos de enrutador (no de agente) en la red en la que se encuentra.
• mediante el mismo mecanismo por el que obtuvo su co-located care-of address puede obtener la dirección de un enrutador adecuado. Por ejemplo, el protocolo DHCP ofrece información al nodo móvil, incluida la dirección de un enrutador.

Tunelización - Tunneling

El término encapsulado (o el proceso de encapsular y desencapsular paquetes) es un equivalente al de tunelización y consiste en la inserción de un paquete IP dentro de otro paquete. El paquete resultante es, posteriormente, enviado a un nodo intermedio entre el nodo origen y el nodo destino final.

El caso más general de tunelización es:

FUENTE → ENCAPSULADOR → - -------- - → DESENCAPSULADOR → DESTINO

Tomando fuente, encapsulador, desencapsulador y destino como nodos independientes. El nodo que encapsula paquetes (encapsulador) es considerado el punto de entrada al túnel y el nodo que los desencapsula el punto de salida del túnel. En general, pueden existir múltiples pares fuente-destino usando el mismo túnel entre encapsulador-desencapsulador.

“El mecanismo de encapsulamiento por defecto que debe ser soportado por todos los agentes de movilidad que usen IP Móvil, es IP-within-IP”.

Encapsulado IP-dentrode-IP - IP-within-IP-

El encapsulado IP-dentro de-IP (IP-within-IP) consiste en insertar una cabecera IP adicional antes de la cabecera propia del paquete inicial. También es posible insertar otras cabeceras entre las dos cabeceras anteriores. (Figura 5).

El encabezado IP exterior contiene información sobre los extremos del túnel, es decir, la dirección fuente y la dirección destino. El encabezado interior contiene información sobre la dirección fuente y la dirección destino de los nodos emisor y receptor respectivamente del paquete original y no puede ser modificado en ningún caso, salvo para decrementar el tiempo de vida – TTL (Time To Live) - del paquete.

Figura 5: Encapsulado IP-within-IP

Los campos en el encabezado IP exterior son establecidos por el encapsulador como sigue:

• Versión: 4
• Longitud del encabezado de Internet: longitud del encabezado IP exterior medido en palabras de 32-bits
• Tipo de servicio: es copiado del encabezado IP interior.
• Longitud total: mide la longitud total del paquete IP encapsulado, incluyendo los dos encabezados, interior y exterior, y la carga -payload-.
• Identificación, banderas y bit no-fragmentación: si el bit de “no fragmento” se encuentra seteado en el encabezado interior, también debe estar seteado en el encabezado exterior. Si el bit de “no fragmento” no está seteado en el encabezado interior, éste podría ser seteado en el encabezado exterior.
• Tiempo de vida (TTL): este campo es seteado con un valor apropiado en el encabezado exterior para entregar los paquetes encapsulados al punto de salida del túnel.
• Protocolo: 4
• Suma de comprobación del encabezado: suma de comprobación en el encabezado IP exterior.
• Dirección fuente: la dirección IP del encapsulador, es decir, el punto de entrada al túnel.
• Dirección destino: la dirección IP del desencapsulador, el punto de salida del túnel.
• Opciones: algunas de las opciones presentes en el encabezado IP interior no son copiadas en el encabezado IP exterior.

Durante el encapsulamiento del paquete, el TTL en el encabezado IP interior es decrementado en uno si se encuentra dentro del túnel como parte del reenvío del paquete; en otro caso el TTL no se modifica. Si el TTL resultante dentro del encabezado IP interior es igual a cero, el paquete es descartado y un mensaje ICMP de tiempo excedido podría ser enviado al emisor.

El TTL del encabezado IP interior no cambia durante el desencapsulamiento. Si después de este proceso el paquete interno tiene un TTL=0, el desencapsulador debe descartar al paquete. Si después del desencapsulamiento, el desencapsulador reenvía el paquete a una de sus interfaces, decrementa el TTL como en un reenvío normal.

El encapsulador generalmente usa las opciones IP permitidas para entregar la carga encapsulada al final del túnel, puede usar también la fragmentación, a menos que esté seteado el bit de no-fragmentación

Encapsulado mínimo

El encapsulado mínimo es un método por el cual un paquete puede ser encapsulado (conducido como carga) dentro de un paquete IP con menos gasto (overhead) que la encapsulación IP-dentrode-IP, que agrega un segundo encabezado IP a cada paquete encapsulado. Este método es levemente más complicado dado que la información de los encabezados, interior y exterior, es combinada para reconstruir el encabezado IP original y en consecuencia, reduce el gasto del encabezado.

Se define un encabezado de reenvío mínimo por paquetes no fragmentados antes de la encapsulación. El uso de este método es opcional. El encapsulado mínimo no debe usarse cuando un paquete original ya ha sido fragmentado, dado que no hay lugar en el encabezado de reenvío mínimo para almacenar información de la fragmentación. Para encapsular un paquete usando encapsulación mínima (Figura 6), se modifica el encabezado IP del paquete original y se inserta el encabezado de reenvío mínimo después del encabezado IP, seguido por la carga IP no modificada del paquete original (como por ejemplo encabezado y datos de transporte). No se requiere agregar al paquete un encabezado IP adicional.

Figura 6: Encapsulado Mínimo

En el encapsulamiento, el encabezado IP del paquete original es modificado:

• El campo protocolo en el encabezado IP es reemplazado por el número 55
• El campo dirección destino en el encabezado IP es reemplazado por la dirección IP del punto de salida del túnel.
• Si el encapsulador no es la fuente original del paquete, el campo dirección fuente en el encabezado IP es reemplazado por la dirección IP del encapsulador.
• El campo longitud total es incrementado por el tamaño del encabezado de reenvío mínimo.
• El campo suma de comprobación encabezado es recalculado en base a los cambios descriptos.

A diferencia de la encapsulación IP-dentrode-IP, el campo TTL en el encabezado IP no es modificado durante la encapsulación, si el encapsulador está reenviando el paquete, éste podría decrementar el TTL como resultado de un ruteo IP normal. Dado que el TTL original permanece en el encabezado IP después de la encapsulación, los datos tomados por el paquete dentro del túnel son visibles, por ejemplo realizando un “tracerouter”.

El formato del encabezado de reenvío mínimo (Figura 7) presenta los siguientes campos:

• Protocolo: copiado del campo protocolo en el encabezado IP original
• Dirección fuente original presente (S): si es igual a cero indica que el campo dirección fuente original no está presente. Si es igual a uno indica que sí está presente.
• Reservado: seteado en cero, ignorado sobre recepción.
• Suma de comprobación encabezado: suma de comprobación.
• Dirección destino original: copiado del campo dirección destino del encabezado IP original.
• Dirección fuente original: copiado del campo dirección fuente del encabezado IP original.

Cuando un paquete es desencapsulado, los campos en el encabezado de reenvío son restaurados a los del encabezado IP y el encabezado de reenvío es removido del paquete. Además, al campo longitud total en el encabezado IP se le resta el tamaño del encabezado de reenvío mínimo removido y el campo suma de comprobación encabezado es recalculado en base a los cambios producidos en el encabezado IP a raíz de la desencapsulación.

Figura 7: Formato de encabezado de reenvío mínimo

Encapsulado GRE

El encapsulado GRE (Generic Record Encapsulation) es el más flexible ya que permite la encapsulación de cualquier tipo de paquete, incluidos los paquetes IP. El formato de un paquete GRE consta de una cabecera externa, seguida de la cabecera GRE, y de los datos IP. Contrariamente a los encapsulados IP-dentro de-IP y mínimo, el encapsulado GRE ha sido específicamente diseñado para prevenir encapsulamientos recursivos. Concretamente, el campo recur en la cabecera GRE es un contador que informa del número de encapsulados adicionales que son permitidos.

Problemas y posibles soluciones a cuestiones de IP Móvil

Algunos problemas con el protocolo IP Móvil se describen en esta sección, así como los últimos avances en materia de soluciones propuestas a estos problemas.

Enrutamiento ineficiente

Usando el Protocolo IP Móvil base, todos los paquetes destinados a un nodo móvil son enrutados a través del agente local del nodo móvil, el que mediante un túnel envía cada paquete a la ubicación actual del nodo móvil. Un nodo correspondiente envía paquetes a la dirección IP fija de un nodo móvil de la misma manera que a cualquier otro destino. Este esquema permite transparencia de interoperabilidad entre el nodo móvil y el nodo correspondiente, pero obliga a que todos los paquetes destinados al nodo móvil sean enrutados a través de su agente local. Este circuito es denominado “enrutamiento triangular” dado que un único trayecto del triángulo va desde el nodo móvil al nodo correspondiente y el agente local forma el tercer vértice controlando el camino que toman los datos desde el nodo correspondiente al nodo móvil. En muchos casos los paquetes direccionados al nodo móvil siguen caminos más largos que el óptimo, por ejemplo, si un nodo móvil está visitando una determinada subred, aún los paquetes enviados por los nodos correspondientes de ésta subred serán enrutados a través del agente local (en la red local) del nodo móvil. Este enrutamiento indirecto retarda la entrega de los paquetes al nodo móvil, y produce una carga innecesaria sobre las redes y enrutadores.

Para permitir un enrutamiento más eficiente podrían definirse extensiones de optimización de ruteo a las operaciones del protocolo IP Móvil base, de manera que los paquetes sean enrutados desde un nodo correspondiente a un nodo móvil evitando pasar por el agente local.

Las extensiones de optimización de ruteo pretenden lograr que los nodos mantengan una cache de enlaces -cache the binding- conteniendo la dirección de auxilio de uno o más nodos móviles. Cuando se envíe un paquete IP a un nodo móvil, si el emisor tiene una entrada en la caché de enlaces para el nodo móvil destino, podrá enviar mediante un túnel sus propios paquetes directamente a la dirección de auxilio indicada en el enlace de movilidad cacheado. En ausencia de una entrada en la caché de enlaces, los paquetes destinados al nodo móvil deberán volver a la red local del nodo móvil, para ser luego enviados mediante un túnel a la dirección de auxilio actual del nodo móvil a través de su agente local. Mediante la optimización de ruteo, el emisor original del paquete podría ser informado del enlace de movilidad actual del nodo móvil, teniendo así una oportunidad para cachear el enlace.

Algunos nodos podrían mantener una caché de enlaces para optimizar su propia comunicación con nodos móviles. Además podrían crear o actualizar sus entradas en la caché de enlaces cuando reciba un enlace de movilidad autenticado de un nodo móvil. Cada enlace en la caché de enlaces tiene asociado un tiempo de vida. Después de que ese período expira, el enlace es eliminado de la caché. Además, un nodo podría utilizar alguna estrategia para administrar su espacio en la caché de enlaces. Cuando necesite agregar una nueva entrada en la caché, podría elegir reemplazar una entrada ya existente.

Cuando un agente local de un nodo móvil intercepta un paquete desde la red local y mediante un túnel, lo envía al nodo móvil, el agente local podría deducir que la fuente original del paquete no tiene una entrada en la caché de enlaces del nodo móvil destino. Entonces, el agente local podría enviar un mensaje de actualización de enlace al nodo fuente original, informándole del actual enlace de movilidad del nodo móvil. No hace falta un acuse de dicho mensaje dado que en el futuro, paquetes desde el nodo fuente podrían causar la retransmisión de otra actualización de enlace de movilidad. Para que una actualización de enlace sea autenticada, el nodo fuente original, el nodo móvil y el agente local deben tener establecida una asociación de seguridad. De la misma manera, cuando algún nodo recibe un paquete a través del túnel, si tiene una entrada en la caché de enlace para el nodo destino, puede deducir que el nodo que lo envió tiene una entrada vencida en la caché de enlaces para su nodo móvil. En este caso el nodo que recibió el paquete, podría enviar un mensaje de advertencia al agente local del nodo móvil, para que éste le envíe un mensaje de actualización de enlace al nodo que envió el paquete a través del túnel. Al igual que en los mensajes de actualización de enlaces enviados por el agente local del nodo móvil, no es necesario un acuse de recibo de los mensaje de advertencia y, a diferencia, no se requiere de la autenticación de los mensajes de advertencia, dado que éstos no afectan directamente al enrutamiento de paquetes IP al nodo móvil.

Las extensiones de optimización de ruteo también permitirían a los paquetes en vuelo, cuando un móvil se mueva y a los paquetes enviados, en base a la fecha de vencimiento del enlace cacheado, ser reenviados directamente a la dirección de auxilio del nodo móvil.

Frecuencia insoportable de reportes destinados al agente local si el nodo móvil se traslada frecuentemente

Usando IP Móvil, un nodo móvil se registra con su agente local cada vez que cambia su dirección de auxilio. Si la distancia entre la red visitada y la red local es grande, puede existir una gran demora en los mensajes de señalización de la nueva registración y en consecuencia una baja performance.

Para este inconveniente se propone una registración local al dominio visitado, reduciendo así el número de mensajes de señalización a la red local y la demora en los mensajes de señalización cuando un nodo móvil se mueve desde un agente foráneo a otro dentro del mismo dominio visitado.

Cuando un nodo móvil arriba por primera vez en un dominio visitado, se registra con su agente local . En esa registración se asume que la red local genera una clave de registración para el nodo móvil, esa clave es distribuida al nodo móvil y al dominio visitado, y puede ser usada para autenticación de registraciones regionales.

Durante una registración local el agente local registra la dirección de auxilio del nodo móvil. Cuando el dominio visitado soporta administración de túnel regional, la dirección de auxilio registrada en el agente local es una dirección enrutable públicamente de un Gateway Foreign Agent (GFA). Esa dirección de auxilio no varía cuando el nodo móvil cambia de agente foráneo bajo el mismo GFA. Cuando varíe el GFA, el nodo móvil deberá realizar una registración local; cuando cambie el agente foráneo bajo el mismo GFA en lugar de una registración local, el nodo móvil podría realizar una registración regional dentro del dominio visitado. La propuesta del protocolo registración regional soporta un nivel de agente foráneo jerárquico debajo del GFA, pero el protocolo podría ser utilizado para soportar más niveles jerárquicos.

 

Figura 8: Dominio visitado con un GFA, y una red local con un agente local

Modelo único de agente local – modelo frágil

Si bien un modelo único de agente local es más simple y fácil de configurar, tiene la desventaja de la fragilidad. El nodo móvil será inalcanzable si el agente local falla.

Una posible solución es soportar múltiples agentes locales. Si un agente convencional falla, otro agente local podría enrutar los paquetes.