Análisis y Optimización del Handover en redes MobileIP

Transcripción

1 Análisis y Optimización del Handover en redes MobileIP UNIVERSIDAD DE EXTREMADURA GÍTACA Grupo de investigación de Ingeniería Telemática Aplicada y Comunicaciones Avanzadas Octubre de 2008 Autores: David Cortés Polo - Carlos Vecino de Casas Coordinador: José Luis González Sánchez

2 Análisis y Optimización del Handover en redes MobileIP 1 CONTENIDO ACRÓNIMOS UTILIZADOS...3 GLOSARIO TÉRMINOS UTILIZADOS SOBRE MOBILEIP...5 TÉRMINO DE MOBILE IP...5 TÉRMINOS ESPECÍFICOS DEL HANDOVER...5 FIGURAS INTRODUCCIÓN INTRODUCCIÓN A MOBILEIP FUNDAMENTOS DE MOBILE IP V FUNCIONAMIENTO DE MOBILE IP V DETECCIÓN DEL MOVIMIENTO EN UNA RED PROTOCOLO NEIGHBOR DISCOVERY DESCUBRIMIENTO DE OTROS HOME AGENTS ADQUISICIÓN DE UNA NUEVA COA DUPLICATE ADDRESS DETECTION (DAD) ACTUALIZACIÓN DE LOS VÍNCULOS USO DE LA CACHÉ DE VÍNCULOS RETURN ROUTABILITY ENRUTADO Y TUNNELING HANDOVER EN MOBILEIP V FAST HANDOVER EN MOBILE IP CUELLOS DE BOTELLA PRODUCIDOS POR LA LATENCIA DE CONECTIVIDAD REDUCCIÓN DE LOS CUELLOS DE BOTELLA DE LA CONECTIVIDAD CUELLOS DE BOTELLA PRODUCIDOS POR LA LATENCIA DE RECEPCIÓN DE PAQUETES REDUCCIÓN DE LOS CUELLOS DE BOTELLA DE LA RECEPCIÓN DE PAQUETES HIERARCHICAL MOBILE IP V PROYECTOS DE IMPLEMENTACIÓN DE MOBILEIPV PROYECTO MIPL CONFIGURACIÓN DE IPV6 MÓVIL EN LINUX CONFIGURACIÓN DE IPV6 MÓVIL EN LINUX PROYECTO SAM COMPARATIVAS LATENCIA DE HANDOVER EN DIFERENTES PROTOCOLOS HANDOVER EN SIGMA SOBRE STCP COMPARATIVA ENTRE SIGMA, FMIPV6, HMIPV6 Y FHMIPV CONCLUSIONES EVOLUCIÓN DE LOS PROTOCOLOS QUE REALIZAN HANDOVER (FHMIP, SIMP, FFHMIP) ALCANCE DE ESTE INFORME TÉCNICO FAST HANDOVER PARA HIERARCHICAL MOBILE IPV6 (F-HMIPV6)

3 8.2.1 VISIÓN GENERAL DE F-HMIPV FUNCIONAMIENTO DE F-HMIPV MOBILE IP SIN FISURAS (S-MIP) VISIÓN GENERAL DE S-MIP FUNCIONAMIENTO DE S-MIP FFHMIPV VISIÓN GENERAL DE FFHMIPV FUNCIONAMIENTO DE FFHMIPV ACTUALIDAD SOBRE LOS DISPOSITIVOS QUE INTEGRAN SOPORTE PARA MOBILEIPV DISPOSITIVOS HANDOVER SIN FISURAS ENTRE REDES HETEROGÉNEAS INTRODUCCIÓN DE LA INVESTIGACIÓN DEMOSTRACIÓN DEL HANDOVER "EL CUÁNDO Y POR QUÉ" DEL HANDOVER " HACIA DÓNDE?" SE REALIZA EL HANDOVER CÓMO SE REALIZA EL HANDOVER ESTANDARIZACIÓN Y SUPERVISIÓN DE PRODUCTOS PREPARADOS PARA MOBILEIPV OTRAS TECNOLOGÍAS QUE PODRÍAN COMPLEMENTAR A MOBILEIP RFID INTRODUCCIÓN FUNDAMENTOS DE RFID ESTADO ACTUAL SUITES DE SIMULACIÓN NETWORK SIMULATOR OMNET OPNET SIMULACIONES REALIZADAS ELECCIÓN DEL SIMULADOR INSTALACIÓN DEL SIMULADOR INTRODUCCIÓN A LAS SIMULACIONES ESCENARIO RESULTADOS SIMULACIÓN ANÁLISIS DE LOS RESULTADOS DE LA SIMULACIÓN ESCENARIO RESULTADOS SIMULACIÓN ANÁLISIS DE LOS RESULTADOS DE LA SIMULACIÓN ESCENARIO RESULTADOS SIMULACIÓN ANÁLISIS DE LOS RESULTADOS DE LA SIMULACIÓN CONCLUSIONES OBTENIDAS DE LAS SIMULACIONES CONCLUSIONES Y LÍNEAS DE INVESTIGACIÓN FUTURAS REFERENCIAS BIBLIOGRAFÍA

4 ACRÓ N I M O S U T I L I Z A D O S AN Access Network AP Access Point AR Access Router CoA Care-of-Address CN Correspondent Node DHCP Dynamic Host Configuration Protocol FA Foreign Agent FBACK Fast Binding Acknowledge FBU Fast Binding Update FMIP Fast Mobile IP HA Home Agent HACK Handover Acknowledge HI Handover Initiate HMIP Hierarchical Mobile IP IETF Internet Engineering Task Force LCOA On-Link Care-of-Address L2 Layer 2 L3 Layer 3 MAP Mobility Anchor Point MN Mobile Node NAR New Access Router NAT Network Address Translation NCoA Next Care-of-Address nfa New Foreign Agent 3

5 NLCoA Next Link Care-of-Address ofa Old Foreign Agent PAR Previous Access Router PCoA Previous Care-of-Address PLCoA Previous Link Care-of-Address PrRtAdv Proxy Router Advertisement RtSolPr Router Solicitation for Proxy Advertisement SCTP Stream Control Transmission Protocol SIP Session Initiation Protocol 4

6 G L O S A R I O T É R M I N O S U T I L I Z A D O S S O B R E M O B I L E I P T é r m i n o d e M o b i l e I P Extracto de la terminología de MobileIP extraída del RFC 3775 [12]. -Mobile Node (MN) Nodo que puede cambiar su punto de acceso entre los diferentes puntos de acceso de diferentes redes, mientras permanece localizado con su home address. -Home address Dirección asignada a un MN, usada para comunicarse con el MN aunque éste no se encuentre en su red de origen. Correspondent Node (CN) Nodo con el que se está comunicando el MN, éste puede ser móvil o no. -Care-of-Address (CoA) Dirección asociada a un MN mientras está visitando una red que no es la de origen. -Home Agent (HA) -Binding Router de la red de origen del MN en la que está registrada la dirección actual de CoA. Asociación de una dirección dada por la red de origen del MN y la CoA, que permanece durante el tiempo de vida de la asociación. - Registration El proceso durante el que el MN envía un Binding Update a su HA o CN, para que se realice el binding y así se registre el nodo. T é r m i n o s e s p e c í f i c o s d e l h a n d o v e r Access Router (AR) Router por defecto de MN. Previous Access Router (PAR) Router por defecto del MN antes de que se realice el handover. -New Access Router (NAR) Router por defecto del MN al que se asociará cuando se termine el handover. -Previous Care-of-Address (PCoA) 5

7 CoA del MN válida en la subred del PAR. -Next Care-of-Address (NCoA) CoA del MN válida en la subred del NAR. -Router Solicitation for Proxy Advertisement (RtSolPr) Un mensaje del MN al PAR pidiendo información para un handover. -Proxy Router Advertisement (PrRtAdv) Un mensaje del PAR al MN que da información sobre sus vecinos facilitando la detección de movimientos. El mensaje también actúa como disparador para el inicio del handover por parte de la red. -Fast Binding Update (FBU) Mensaje del MN al PAR para redirigir el tráfico hacia el NAR. -Fast Binding Acknowledge (FBACK) Un mensaje del PAR en respuesta de un FBU. -Handover Initiate (HI) Un mensaje del PAR al NAR respect al handover del MN. -Handover Acknowledge (HACK) Un mensaje del NAR al PAR como respuesta al HI. 6

8 F I G U R A S Figura 1- esquema básico de MIPv Figura 2 - nivel óptimo de jerarquía en relación al número de AR...22 Figura 3 - escenario básico de movilidad en IPv Figura 4 - experimentos con protocolos de movilidad [17]...27 Figura 5 - comparación entre Real y UML. [17]...28 Figura 6 - diseño de la red con sigma y stcp [17]...29 Figura 7 - señales en el proceso de handover [17]...30 Figura 8 - topología de la red [17]...31 Figura 9 - comparativa latencia del handover en sigma [17]...32 Figura 10 - comparativa pedida de paquetes y throughput en sigma 1 [17]...33 Figura 11 - comparativa pedida de paquetes y throughput en sigma 2 [17]...33 Figura 12 - comparativa pedida de paquetes y throughput en sigma 3 [17]...33 Figura 13 - comparación de la calidad de la red con sigma y mip [17]...34 Figura 14 - fh-handover predictivo iniciado por la red [20]...35 Figura 15 - fh-handover predict. iniciado por la red [20]...37 Figura 16 - fh-handover predic. iniciado por MN [20]...38 Figura 17 - fh-handover predic. iniciado por mn [20]...39 Figura 18 - fh-handover reactivo [20]...40 Figura 19 - s-mip handover predictivo iniciado por el nodo móvil [20]...41 Figura 20 - fases de ffhmipv6 [28]...43 Figura 21 - proceso De FFHMIPv6 [28]...44 Figura 22 - manejo de hop-by-hop frame [28]...45 Figura 23 - hop-by-hop frame con la opción de ffhmipv6 [28]...46 Figura 24 - elementos que afectan al handover [28]...46 Figura 25 - dispositivo de nokia con mobileipv Figura 26 - realización de vídeo-llamada con handover...48 Figura 27 - vídeo de explicación del proceso de handover...49 Figura 28 - arquitectura del sistema [29]...50 Figura 29 - handover predictivo en redes heterogéneas [29]...51 Figura 30 - aplicaciones de rfid. IBM...53 Figura 31 - internet of things" nueva dimensión. ITU(Nomura Research Institute)...54 Figura 32 - crecimiento del mercado rfid. IDTechEX...54 Figura 33 - sistema rfid básico...55 Figura 34 - características de los tansponders en función de la frecuencia. Allied Business Intelligence Inc Figura 35 - aplicaciones de rfid según la frecuencia de trabajo...57 Figura 36 - clasificación de tags rfid...58 Figura 37 - diferentes tipos de tags rfid...58 Figura 38 - evolución de la tarjetas rfid [27]...60 Figura 39 - escenario Figura 40 - escenario 1 handover mipv Figura 41 - escenario 1 comparación rtt...70 Figura 42 - escenario 1 pings perdidos...70 Figura 43 - escenario

9 Figura 44 - escenario 2 handover mipv Figura 45 - escenario2 comparación rtt...75 Figura 46 - escenario 2 pings perdidos...75 Figura 47 - escenario Figura 48 - handover mipv6 escenario Figura 49 - escenario 3 comparación rtt...80 Figura 50 - escenario 3 pings perdidos...80 Figura 51 - binding update en hmip

10 2 I N T R O D U C C I Ó N El presente informe trata de exponer el proceso de investigación llevado a cabo desde la fecha de concesión de la beca de investigación sobre el Handover en MobileIP realizada con la colaboración de Cisco, UNEX y la Junta de Extremadura. Como podrá observarse a medida que se avanza en el documento, se ve que en un principio se optó por realizar una investigación general para conseguir y actualizar los conocimientos necesarios para poder adentrarnos con la suficiente claridad en el mundo de la movilidad IP. Los principales temas que se tratarán son: Introducción al mundo de la movilidad IP. Los principales fundamentos de Mobile IP. Principales problemas del Handover sobre Mobile IP básico. Realización del handover en MobileIP, introduciendo los dos tipos básicos de handover: Fast Handover y Hierachical Handover. Después de este tiempo adaptación y puesta al día en todo lo referente a nociones e ideas sobre Mobile IPv6 y el proceso del handover, se pasó a desarrollar una fase del presente informe con los puntos más importantes que podían complementar al proceso de investigación: Los puntos a tratar fueron los que siguen: Proyectos actuales sobre la implementación de MobileIPv6. Comparativas sobre la latencia de Handover en diferentes protocolos (Sigma, FMIPv6, HMIPv6 y FHMIPv6). Principales protocolos que son la evolución natural de los básicos MIPv6, FMIPv6 y HMIPv6. Actualidad de la investigación del Handover sin fisuras realizándose en redes heterogéneas (Wimax/Wifi). Dispositivos más importantes que integran la tecnología sobre los que se investiga. Otras tecnologías que podrían ser útiles para complementar a MobileIP. Suites de simulación de tecnología MobileIP. Simulaciones de MIPv6 frente HMIPv6. Líneas futuras de investigación. 3 I n t r o d u c c i ó n a m o b i l e I P Desde hace ya algunos años, las comunicaciones inalámbricas se han convertido en un referente en el mundo de las comunicaciones, debido sobre todo al auge de los dispositivos móviles como PDAs, móviles y ordenadores 9

11 portátiles, hacen que los estudios y las investigaciones que hasta ahora se estaban llevando en entornos alámbricos, no sean aplicables a los entornos inalámbricos. Este auge propicia además, el aumento de estos dispositivos conectados a la red y que las direcciones de IPv4 se acaben mucho más rápido de lo que estaba previsto. En este sentido, la unión de las comunicaciones móviles y de IPv6 es un hecho. Debido a la movilidad propiciada por estos elementos, el protocolo IPv6 no es suficiente para aportar a estos nuevos dispositivos de la movilidad que necesitan. De esta manera nace Mobile IP, una adaptación de los protocolos IPv4 e IPv6 para la movilidad (MIPv4 [1] y MIPv6 [2] respectivamente). Estos nuevos protocolos dotan de movilidad al protocolo IP para estar siempre conectado, esto es no perder la conexión si el dispositivo móvil pasa de una red a otra (este concepto usando los protocolos de red alámbrica no se podía conseguir ya que están orientados hacia redes fijas y no móviles). Debido a lo anteriormente descrito en la introducción, en este trabajo nos centraremos en la movilidad desde IPv6 ya que todos los trabajos relacionados con IPv4 están siendo abandonados ya que el despliegue de la movilidad en este protocolo es mucho más costoso así como el problema de la escasez de direcciones IP. Este documento se va a desglosar como sigue, en el capítulo 2 se muestra el funcionamiento básico de MIPv6, en el capítulo 3 se muestran los mecanismos que permiten el movimiento en el protocolo MIP y por último las propuestas dependiendo de la tecnología usada. 4 F u n d a m e n t o s d e M o b i l e I P v 6 Mobile IP es una modificación del protocolo IP que permite a los nodos continuar recibiendo datagramas independientemente de la red a la que estén conectados, esto conlleva mensajes de control adicionales que permiten manejar el encaminamiento de los datagramas. Este protocolo ha sido diseñado con la premisa de que debe ser escalable, porque se espera que en el futuro un gran porcentaje de los nodos conectados a Internet sea móvil. El protocolo IP asume que una dirección IP idéntica inequívocamente el punto de conexión a la red de un nodo. Antes de que un nodo pueda recibir datagramas, ese nodo debe ser identificado en la red en la que está conectado, sino el nodo será inalcanzable. 10 El protocolo IPv6 proporciona mecanismos de autoconfiguración que, de ser empleados, pueden proporcionar cierto grado de movilidad a nivel IP, es decir, la capacidad de conectarnos a diferentes redes (de acceso) y tener conectividad IP. Sin embargo, esto requiere la interrupción de todas las conexiones de niveles superiores y su posterior reinicio, una vez conectados al nuevo punto de acceso. Además, el resto de nodos no disponen de ningún mecanismo transparente para comunicarse de nuevo con el nodo móvil, al ignorar la nueva localización del mismo. Mobile IPv6 proporciona a un nodo movilidad a nivel 3 de forma transparente para los niveles superiores (por ejemplo TCP), siendo siempre alcanzable a través de su home address (HoA), sin importar si se encuentra conectado a su home network o está visitando otras redes. La transición, traspaso o handover entre redes es transparente para los niveles superiores y la pérdida de conectividad que se produce durante el mismo es el correspondiente al intercambio de los mensajes de señalización necesarios. Dado que Mobile Ip es una extensión de IP para redes móviles, aparecen nuevos conceptos que hay que tener en cuenta para comprender correctamente el protocolo: En primer lugar el nodo móvil (MN), este nodo está en movimiento y por lo tanto, va a cambiar de router de acceso debido a que deje de tener cobertura de un punto de acceso y comience a ganar cobertura de otro (procedimiento de Handover). Este nodo tiene además dos direcciones IP. La dirección de su red origen (HoA, Home of Address) y por otro lado la dirección IP de la red que visita (CoA, Care of Address).

12 El MN siempre hará el movimiento desde un punto de acceso (AR) de una red a otra, ya sea de su red de origen (HN, Home Network) o de otra red visitada (FN, Foreign Network) y viceversa. FIGURA 1- ESQUEMA BÁSICO DE MIPV6 Una vez vista los elementos básicos del protocolo, vamos a estudiar más a fondo el protocolo. 4.1 F u n c i o n a m i e n t o d e M o b i l e I P v 6 Mobile IP está orientado a dotar la movilidad a IPv6, la figura 1 muestra el funcionamiento básico de Mobile IP. El funcionamiento básico se puede dividir en varias etapas: Detección de movimiento en una red: Este proceso descubre el posible movimiento de un nodo móvil, de tal manera que permite comenzar el proceso de handover hacia otra red. Adquisición de una nueva CoA: Una vez que se ha descubierto una nueva red a la que saltar, se debe obtener una dirección válida para ser alcanzable en esa nueva red. Actualización de los vínculos: Con la nueva CoA obtenida se debe actualizar la información tanto en el HA como en los CN para que sepan como enviar la información al MN en su nueva red. Enrutado y Tunneling: Son los métodos usados para que que el MN sea alcanzable ya sea mediante un túnel HA-MN o mediante optimización de rutas entre el MN y el CN. En los siguientes puntos se va a detallar cada una de estas fases. 4.2 D e t e c c i ó n d e l m o v i m i e n t o e n u n a r e d Cuando un MN visita una nueva red, debe autoconfigurarse con los parámetros típicos necesarios para que sea un dispositivo direccionable en una red IPv6. En particular un MN necesita determinar el prefijo de la red en el momento en el que descubre un nuevo AR y se quiere conectar a el. Una vez que mediante los anuncios de router 11

13 obtiene el prefijo de red, el MN tiene la información necesaria para poder autoconfigurarse o intentar pedir una dirección IP a un servidor DHCPv6. Sin esta nueva dirección IP, el nodo no puede llevar a cabo ciertas operaciones de un dispositivo direccionable en una red IPv6 como responder apropiadamente a varios mensajes multicast (o en caso de IPv4, broadcast). Este es el proceso básico de Mobile IP para detectar nuevos AR y así proporcionar la movilidad. Esta basado en el protocolo de anuncio de router y en el protocolo de descubrimiento de vecino. El procedimiento que sigue es el siguiente: Comunicación entre el nodo y el AR: El nodo para estar conectado debe de mantener siempre comunicación con un AR, ya sea de su red origen o de una red visitada. Para esto es necesario obtener la información que se le envía en los mensajes de router, en la cual se obtiene información precisa de la red a la que se conecta. Si esto no fuera posible, el MN puede enviar un mensaje para que el AR le envíe esta información. Obtención de los datos de la red: Como hemos dicho anteriormente con los anuncios de router el MN puede saber si se encuentra en la red origen o en la red visitada pero además puede obtener la información necesaria para poder autoconfigurarse [10] sin necesidad de un cliente de DHCP como era necesario en IPv4. Asignación de una nueva CoA: Si el MN se encuentra en una red visitada, para que sea accesible necesitará de una dirección de auxilio (CoA) para que pueda ser direccionado en esa red visitada. Para el intercambio de datos entre el AR y el MN existen dos métodos en forma de mensajes ICMP que se usan en el proceso de descubrimiento de routers (proceso que es heredado de IPv6). Estos dos mensajes son Router Advertisement, que permite a los Routers de Acceso darse a conocer y Router Solititation que permite al Nodo Móvil pedir un anuncio de router al Router de Acceso al que está conectado. Estos dos mensajes son una parte importante del proceso de Handover. Estos mensajes como se ha dicho anteriormente son heredados de IPv6 aunque dado la naturaleza de Mobile IP es necesario hacer modificaciones a estos mensajes para que proporcionen toda la información necesaria al MN. Por lo tanto los mensajes usados para el descubrimiento de agentes utilizarán los mensajes antes nombrados y se llamaran: 12 Router Advertisement: Este mensaje se transmite regularmente desde el router que está haciendo de agente Mobile IP. Router Solititation: Este mensaje es la petición del MN de que se retransmita un Router Advertisement. Normalmente los Router Advertisement tienen un tiempo de envío que varía en un intervalo mínimo de 0,3-0,7 segundos. Es decir este es el mínimo que impone Mobile IP para que se envíe un anuncio de agente P r o t o c o l o N e i g h b o r D i s c o v e r y Los nodos integrantes de una red (como puede ser Ethernet o token ring), deben conocer la dirección MAC de los otros nodos para comunicarse con ellos. Debido al principio de encapsulación de IP, todos los paquetes deben contener la dirección MAC del paquete al que se dirige para que pueda ser transportado por el medio físico. El proceso de resolución de una dirección IP a una dirección física es un paso necesario en las redes de datos. En IPv4 esta resolución la hacía el protocolo Address Resolution Protocol (ARP) [11]. En IPv6 la función la realiza el protocolo Neighbor Discovery (ND). El protocolo ND también permite a los nodos el descubrimiento de routers permitiendo el envío de paquetes hacia ellos. Este protocolo provee de métodos para asegurar la conectividad con un vecino cuya dirección haya

14 sido resuelta con anterioridad. Estas funciones son necesarias para la comunicación sobre un medio físico específico D e s c u b r i m i e n t o d e o t r o s H o m e A g e n t s Un router que actúa como HA aprende si existen otros HA en la red mediante los anuncios de router no solicitados que envían periódicamente. En el mensaje de Router Advertisement si se activa el bit H, quiere decir que el router está funcionando como HA y por lo tanto puede ser usado como tal. Es por esto que todos los HA de la red al recibir un mensaje de esta característica crea una lista de todos los routers actuando como HA en la red. Esta lista incluye tanto la dirección IP del HA como la preferencia (capacidad del mismo) y el tiempo de vida para que esa entrada expire de la lista. La dirección IP se obtiene de la cabecera del paquete y los otros dos parámetros son extraídos del Home Agent Information Option si el paquete lo contiene. Estos dos parámetros cuanto mayor sea el valor que contengan, querrán decir que tienen una mejor disposición para acoger nuevos nodos. Si en el anuncio de router no se incluye esta opción del mensaje, se deberá entonces poner los dos últimos valores a 0. El tiempo de vida, es el tiempo en segundos que va a mantenerse esa entrada en la lista de HA. Este tiempo es por defecto el mismo que el Router Lifetime en el mensaje Router Advertisement con un máximo de 18.2 horas. Si a un HA le llega un Router Advertisement con la cabecera de Home Agent Informtation Option y el valor del campo tiempo de vida de un HA es 0, debe eliminar la entrada de ese HA inmediatamente si lo tenía dado de alta en la lista de HA. Si el valor fuera diferente lo único que tendría que hacer es modificar ese valor en la lista y si no existiera la entrada de ese HA se deberá crear una nueva. Esta información es útil ya que permite el balanceo de carga entre los diferentes HA y así se intenta no saturar un único HA, sino que un MN que esté en su red origen, pueda tener la accesibilidad a otro HA que esté más descargado. Además con este método se pueden proponer otras variaciones como que un MN al estar requiriendo ciertos parámetros de QoS se le permita conectarse a otro HA de su misma red y que le proporcione esos parámetros. 4.3 A d q u i s i c i ó n d e u n a n u e v a C o A El mobile node tiene dos formas distintas de adquirir una CoA en función del tipo de Router Advertisement recibido. Según esta información se puede generar una NewCoA para los dos tipos de autoconfiguración de direcciones en IPv6: Stateful Address Autoconfiguration: El MN pregunta a un Servidor de direcciones con DHCPv6 o mediante el protocolo PPP a un servidor Radius para la obtención de su nueva CoA. O bien la dirección está configurada de manera manual en el equipo. Stateless Address Autoconfiguration: El MN genera la CoA concatenando el prefijo de red que envía el router en los Router Advertisement con la propia MAC del MN. El prefijo de subred elegido se convertirá en su router por defecto. Mediante el mecanismo de IPv6 llamado Duplicate Address Detection (DAD) se detecta si la CoA obtenida ya ha sido previamente asignada a otro nodo de la red. 13

15 4.3.1 D u p l i c a t e A d d r e s s D e t e c t i o n ( D A D ) El protocolo DAD se realiza cada vez que una interfaz de red se conecta a una red IP. El propósito es obtener y asignar una única dirección IP a la interfaz sin requerir de servidores de autoconfiguración o la configuración manual de la dirección. El MN por lo tanto tendrá que mandar un DAD Neighbor Solicitation para ver si la dirección que ha calculado está duplicada o no. Normalmente a este método se le conoce como DAD probe, y sirve para probar direcciones. El nodo por tanto se conecta a la dirección multicast local de comunicación all devices (representado por FF02:: 1) Al conectarse a esta dirección multicast permite al nodo que reciba los Neigbor Advertisements de otros nodos y así detectar si hay algún nodo usando esa misma dirección. Además de suscribirse a este grupo, el MN se ha de suscribir al grupo multicast solicited-node en el cual puede detectar si hay algún otro nodo que esté itentando acceder con la misma dirección IP. Esto es posible ya que al unirse a un grupo multicast, se envía un mensaje Multicast Listener Discovery (MLD). El RFC 2462 (IPv6 Stateless Address Autoconfiguration) recomienda que el mensaje debe enviarse en un intervalo aleatorio de segundos para evitar congestiones al acceder varios nodos a la vez. El nodo que realiza DAD primero crea una dirección local para la que usará el prefijo de la red y su propia IID, esa será la dirección con la que se intentará conectarse a la red. El nodo por lo tanto envía un mensaje Neighbor Solicitation (DAD probe) al grupo multicast solicited-node. El nodo podrá enviar el mensaje probe múltiples veces, pero siempre cumpliendo la premisa de un tiempo entre los diferentes intentos. Sin embargo el número de probes por defecto que se envía es 1. Una vez que se han enviado los DAD probes, el MN debe esperar un tiempo (que normalmente es de un segundo) y cuando ha pasado ese tiempo el proceso de DAD termina. Cuando un Neighbor (otro nodo de la red) recibe el mensaje DAD probe, procesa el mensaje y si tiene la misma dirección que la especificada debe enviar un mensaje Neighbor Advertisement para que el MN cambie su dirección de pureba y vuelva a repetir el proceso. 4.4 A c t u a l i z a c i ó n d e l o s v í n c u l o s 14 Una vez que se ha completado el descubrimiento del agente el MN conoce perfectamente si se encuentra en su red origen o en una red visitada. Si se encuentra en una red origen, el MN se comporta como un dispositivo normal pero si se encuentra en una red visitada, entra en juego Mobile IP. En este caso se necesita comunicarse con el agente origen para intercambiar la información de la nueva conexión. A este proceso se le llama actualización de vínculos. La finalidad de este proceso es configurar el HA (agente origen) de manera que sepa que el MN está fuera de la red origen y así le pueda reenviar los datagramas que vayan dirigidos al MN. Para ello se debe registrar la dirección CoA a la que los paquetes serán reenviados desde el HA. En Mobile IPv6, todos los HA tienen una caché de vínculos (binding cache) que permite almacenar todos los vínculos con los MN a los que sirve de agente origen. De tal manera que sólo aquellos MN que tengan una entrada válida en la caché de vínculos serán los nodos que tengan conectividad. Para tener conectividad por lo tanto lo que se hace es que el nodo móvil envíe un binding update al HA en el momento que se mueva. Cuando el HA tenga una entrada en la Caché de Vínculos válida para esa comunicación, todos los paquetes que lleguen al HA con destino el MN serán reenviados hacia este último. En este modo de comunicación, los CN no intervienen en la comunicación móvil siendo el que controla toda la comunicación el HA y por lo tanto los CN pueden ser nodos IPv6 sin que acepten el protocolo Mobile IP. A este modo de comunicación se le llama tunneling bidireccional, refiriéndose a la técnica usada entre el MN y el HA para el envío de paquetes.

16 Mobile IPv6 también permite a los MN y los CN comunicarse directamente sin que haya ningún HA involucrado en el envío de paquetes. Para esto, el MN tiene que establecer los vínculos (bindings) con el CN directamente. El mensaje es mucho más complejo debido a los mensajes de seguridad que se deben mandar para demostrar que las dos direcciones (antigua y nueva) pertenecen al mismo nodo de la comunicación U s o d e l a c a c h é d e v í n c u l o s Mobile IPv6 puede ser visto como una manera de manejar entradas en una tabla de routing para nodos que necesitan mandar mensajes a un nodo móvil. Estas tablas de routing tienen la dirección HoA del nodo móvil como destino y proveen de información de cómo deben llegar los paquetes a esa dirección. Cuando el nodo móvil es localizado mediante su CoA, la tabla de routing debe contener información sobre ella y de cómo llegar hasta esa dirección. De esta manera se puede producir el efecto que se comentaba anteriormente y que una HoA pueda ser transformada por una dirección CoA gracias a la caché de vínculos. Estas caches deben mantener las entradas de manera segura ya que podría ser una gran baza para los ataques a redes inalámbricas la modificación de la caché de vínculos y es por esto que se han de poner grandes medidas de seguridad para que sólo quien demuestre que es quien dice ser pueda modificar la información de la caché de vínculos. Los mensajes que controlan la caché de vínculos son los siguientes: Binding Update (BU) Binding Acknowledgement (BAck) Binding Error (BERR) Binding Refresh Request (BRR) Binding Update es un elemento crucial en el protocolo ya que controla el núcleo de Mobile IPv6, la caché de vínculos. El resto de elementos y operaciones dentro de Mobile IPv6 deben ser entendidos siempre manteniendo la relación con Binding Update. Los mensajes de control de la caché de vínculos son estructurados como mensajes que se envían en la cabecera de movilidad (Mobility Header). Otras extensiones importantes a estos mensajes de control son los siguientes: Alternate Care-of Address Binding Authorization Data Binding Refresh Advice Si la cabecera de movilidad tiene alguna extensión, la cabecera y los datos de la extensión se introducen detrás de los datos del mensaje. Por último dentro de los mensajes de control de la caché, existe un campo que es HoA Destination Option, la cual permite mantener la HoA del nodo además de la CoA que contiene la cabecera de IPv R e t u r n R o u t a b i l i t y Dado que las comunicaciones móviles (y más aún estas que pueden tener varias direcciones IP) deben tener un sistema de seguridad avanzado para evitar ataques y usos indebidos de la red. Es por esto que desde el IETF se propuso el uso del método Return Routability no solo para comprobar el estado de las comunicaciones entre el 15

17 CN y el HA sino para el intercambio de claves entre los mismos y el MN. De tal manera que sin este intercambio de claves no es posible la comunicación. Como se comentó anteriormente, la finalidad de este método es comprobar el estado de los enlaces, es decir si el MN es alcanzable desde su HoA y su CoA. Los mensajes que implementa el protocolo Return Routability son: Home Test Init (HoTI) Care-of Test Init (CoTI) Home Test (HOT) Care-of Test (COT) Tanto HoTI como HOT permiten probar la dirección HoA del MN, mientras que CoTI y COT prueban la dirección CoA del mismo. 4.5 E n r u t a d o y T u n n e l i n g Una vez que el HA ha registrado en la caché de vínculos al MN, ya se pueden enviar paquetes a la CoA de este último. Sin embargo se necesita asegurar que el HA es capaz de capturar los paquetes enviados. Esto no parece un problema para los paquetes enviados de otros nodos que no pertenezcan a la red de origen. Todos esos paquetes se reciben en el HA (que es un router) y este mediante la caché de vínculos los reenvía hacia el nodo móvil. El tráfico que proviene de la HN, no tiene que atravesar ningún router, sino que los nodos se comunican directamente usando Address Resolution Protocol (ARP) o Neighbor Discovery (ND). De ahí que el HA deba anunciarse a todos los nodos de la red y publicando que deben usar su dirección de enlace si quieren mandar paquetes al MN. Por tanto el HA actúa de proxy para ARP o ND. Esto le permite interceptar los paquetes que provengan con la dirección de HA y reenviarlos a la dirección CoA. Todos estos mensajes que sean capturados por el HA y reenviados al MN deben preservarse los mensajes originales. Es por esto que el HA realiza una encapsulación IP sobre IP introduciendo el paquete original en otro paquete IP en el que la dirección destino sea la CoA (y la dirección fuente el HA). 16 De manera similar, el nodo móvil también encapsula el paquete destinado al CN en otro paquete IP cuyo destino es el HA y en cuya IP origen se introduce la CoA. Este tipo de enrutamiento es conocido como tunelling bidireccional entre el MN y el HA. Cuando la comunicación es directa entre un CN y un MN en una red visitada, el CN usa la cabecera de routing de IPv6 para enviar un paquete a la dirección Home Address (HoA). La dirección de destino es la CoA pero cuando llega el mensaje al MN se intercambia la información con la cabecera de routing de tal manera que la dirección que va a aparecer como destino es HoA. En el caso contrario, cuando se recibe un paquete del MN en el CN, se fuerza a este último a que cambie la dirección de origen CoA por la dirección HoA contenida en la cabecera de routing. Estos procesos únicamente se pueden llevar a cabo si existe la entrada correspondiente a la comunicación en la caché de vínculos para la HoA y esta es válida. 5 H a n d o v e r e n M o b i l e I P v 6 Una vez vistos los fundamentos principales de MIPv6, se ha de tener en cuenta el entorno en el que se usa este protocolo, los entornos móviles. De tal manera que uno de los puntos importantes de este protocolo es el paso de una red a otra. Existen muchos trabajos relacionados con la movilidad entre routers de acceso (AR), a estos movimientos a partir de ahora lo llamaremos handover.

18 Mientras que el tiempo de handover sea alto como lo es ahora, las aplicaciones con requerimientos altos, como son las de tiempo real, no se podrán usar con este protocolo y por lo tanto no se les podrá proveer de movilidad en los dispositivos de nueva generación hasta que se pueda proveer de mejores condiciones en cuanto se produzca un handover. La mayoría de las alternativas, requieren de modificaciones en el Router de Acceso (AR), en el Nodo Móvil (MN), o requiere tener en cuenta información de antemano para poder realizar el handover. Para esto se usan diferentes métodos como un Agente Origen (HA) local, routing Multicast, optimización de los protocolos de routing bi-casting, triggers de nivel 2, buffering y tunneling. De las múltiples opciones con las que se cuentan, destacan Hierarchical Mobile IPv6 (HMIPv6), creando un HA local dentro de una subred local. Las implementaciones basadas en multicast, proponen que el Correnspondent Node (CN) manden la información a un grupo multicast de manera que el MN se una a ese grupo multicast con la Care of Address (CoA) actual antes de dar el salto a la nueva red si es posible. Los protocolos de optimización de rutas, también han sido estudiado para reducir el tiempo de espera para la conexión con el nuevo (AR). Además se ha desarrollado un tipo nuevo de handover que se podría considerar un bi-casting, en el que se usa los triggers (o lanzadores) de nivel 2 unido a la cambios en el AR para detectar el movimiento de antemano y poder configurar así la CoA. Uno de los métodos más prometedores en este sentido es Fast Handover (FMIPv6) que mediante los disparadores de nivel 2 se detecta el movimiento y se prepara para el handover que se va a producir momentos después, encaminando la información que se envía a la antigua CoA desde el antiguo AR hacia el nuevo mediante un túnel, mientras se registra la nueva CoA. En los puntos sucesivos se irán describiendo uno a uno los métodos de nivel 3 de manera mas exhaustiva. Los métodos de nivel 2 muchas veces proveen mejores resultados que los de nivel 3 pero no deben ser utilizados ya que de esa forma la arquitectura del protocolo es dependiente de la tecnología, y esto no es aceptable en ningún caso. Es por esto que los métodos de nivel 2 sean explicados en un anexo de este documento. 5.1 F a s t H a n d o v e r e n M o b i l e I P 6 Normalmente un MN se conecta a su red de acceso, normalmente a través de un enlace wireless usando un punto de acceso o una estación base. El punto de acceso le provee de conectividad en el nivel de enlace y el router de acceso (AR) le provee de conectividad IP. Es por esto que el punto de acceso y el AR son dos entidades funcionales diferentes que pueden ser integrados en un único dispositivo físico. Ya que en este trabajo se está estudiando la capa IP que oferta movilidad a los nodos, el primer punto de estudio es el router de acceso. Un ejemplo de esto puede ser la Figura 1: Esquema básico de MIPv6. Las acciones que debe realizar un MN se pueden resumir en las siguientes: 1. Establecer conectividad de enlace 2. Establecer conectividad IP 3. Reservar recursos de red 4. Ejecutar las aplicaciones 5. Realizar Handover 6. Ir al paso 1 Una vez que el MN se activa, primero establece la conectividad a nivel de enlace. En este momento realiza el protocolo Neighbor Discovery para establecer la conectividad IP. En IPv6, estas operaciones necesitan configurar una dirección IP que permita la comunicación del MN dentro de la red usando un prefijo de red bien conocido (FE80::) y el identificador de interfaz del MN. Por tanto el MN debe asegurarse de que su nueva dirección local de enlace es única. Otro de los métodos que vimos para esto es usando el método de autoconfiguración del nodo 17

19 que permite obtener una dirección IP sin necesidad de que entre en juego alguna entidad de la red. Este proceso simplifica la asignación de las direcciones pero requiere que se haga una comprobación adicional realizando el Duplicate Address Detection (DAD). Una vez que se ha configurado la dirección IP del nodo, el MN realiza el descubrimiento de routers, permitiendo identificar cual es su router por defecto y crear una dirección IP global que pueda ser direccionada fuera de su red origen. Durante el proceso, la red requiere que el MN presente sus credenciales para la autenticación y la autorización de acceso a la red. Si la autenticación es satisfactoria se establece la conexión con el AR y es en ese momento cuando el nodo móvil puede enviar y recibir paquetes IP usando su nueva dirección IP. Una vez que el nodo establece conectividad IP, comienza la ejecución de varios procesos que necesitan acceso a Internet como por ejemplo una aplicación de VoIP con un CN. Una aplicación como es VoIP necesita normalmente de ciertos parámetros de QoS de la red. Con estos parámetros la red intenta dar ciertos privilegios a los flujos que provenga de este tipo de aplicaciones. En este contexto, por ejemplo, se puede incluir un clasificador, un medidor y un marcado de paquetes. Además de esto si el enlace inalámbrico que no tenga mucha velocidad, es conveniente que se implemente las funciones de compresión en la cabecera IP y de transporte para poder aprovechar mejor los recursos de ancho de banda que se poseen. Estos ejemplos muestran lo importante de la comunicación entre el AR y el MN para configurar los parámetros de la comunicación de manera eficiente. Ahora, vamos a suponer que el MN se está moviendo y se produce un handover entre su AR actual y un nuevo AR. Es importante separar el algoritmo de selección del nuevo router a conectarse del mecanismo de handover en sí. Por ahora vamos a asumir que el MN como su actual router saben a qué router se va a producir el handover. Durante este proceso, el MN debe abandonar su actual conexión en el nivel de enlace y establecer uno nuevo. Por lo tanto el proceso que se está describiendo se debe repetir completamente. Dado que el trafico multimedia tiene unos requerimientos especiales (que además se han ratificado en las negociaciones de acceso a la red origen), se plantean ciertos problemas a la hora de que se produzca un handover con flujos de tiempo real. 1. Como permitir al MN que envíe y reciba paquetes inmediatamente después de que obtenga la conectividad a nivel de enlace. A esto lo llamaremos el problema del fast handover. 2. Como mantener ininterrumpido el acceso a los recursos de la red para que el corte causado por el handover en la capa de transporte sea minimizado. A esto se le llamará el problema del smooth handover o handover suave. 18 Hay dos puntos importante dentro del diseño de Fast Handover. El primero es que las latencias debidas a la detección del movimiento, la adquisición de la dirección IP y la configuración a consecuencia del handover deben ser reducidas. El segundo es que la latencia para que los paquetes IP lleguen al destino con la nueva dirección IP (nueva CoA) también debe ser reducida. Se debe tener en cuenta que los paquetes siguen llegando a su destino con la dirección IP antigua hasta que al CN se le notifique lo contrario, normalmente con el procedimiento de Return Routability (que se produce después de un Binding Update). Estos paquetes deben ser reenrutados hacia la nueva dirección del nodo móvil hasta que la actualización de la localización sea efectiva A esto se le puede llamar mejora de la latencia del punto de recepción de los paquetes. Tanto la latencia de conectividad como de la recepción de los paquetes pueden intentar ser minimizadas. La latencia introducida por el cambio entre un enlace y otro no está relacionada con el nivel IP sino con el físico y esta latencia no puede ser modificada por los protocolos C u e l l o s d e b o t e l l a p r o d u c i d o s p o r l a l a t e n c i a d e c o n e c t i v i d a d Un MN necesita saber el prefijo de red para poder configurar su dirección IP. Con el método de IPv6 stateless address autoconfiguration, el MN también necesita realizar el protocolo de DAD para asegurarse que su dirección es única. Ambas operaciones contribuyen a la latencia de conectividad. Algunos trabajos [prob_dad] hablan de

20 eliminar el proceso de DAD para disminuir la latencia introduciendo métodos para ver si la dirección está duplicada una vez que se ha comenzado a usar. Además calculan la probabilidad de que se produzca una colisión entre dos direcciones IP iguales dentro de una red. El protocolo Mobile IP especifica mecanismos para la detección de movimiento. Estos son dependientes de que los anuncios de routers no solicitados sean frecuentes, pero al menos se pierden 30 ms (que es el tiempo mínimo entre anuncios de router) además del proceso de obtención de información de las capas inferiores y de Neighbor Discovery para que se detecte el cambio de la red. Incluso con anuncios de router más frecuentes, es muy difícil detectar el movimiento de una red a otra. Si se utiliza una aproximación híbrida basada en usar Neighbor Unreachability Detection (NUD), puede llevar a un retardo variable en la detección del movimiento, que puede ser mayor a cien milisegundos. Con el handover ya confirmado a una nueva red y una única dirección IP, el MN ya podría enviar paquetes. En este caso la latencia introducida por DAD domina la configuración de la dirección IP, normalmente por encima de un segundo. Hasta que el proceso de DAD no se complete cualquier aplicación como la de VoIP va a seguir generando paquetes que serán desechados por el sistema operativo debido a que el interfaz de red no está configurado correctamente todavía. Incluso cuando el MN tenga configurada la dirección IP, no puede usar esa dirección con el CN sin realizar primero el procedimiento de Return Routability. Esto es debido a que el CN descartará los paquetes que contengan una dirección de origen que no esté reflejada en su caché de vínculos. Por lo tanto la realización de este procedimiento llevará consigo un retraso de 1,5 por el tiempo de Round-Trip Time (RTT) al nodo CN R e d u c c i ó n d e l o s c u e l l o s d e b o t e l l a d e l a c o n e c t i v i d a d La clave para reducir la latencia es permitir al MN que detecte cuales son sus AR adyacentes antes de que se produzca el handover. Si el MN puede estar en contacto con las redes cercanas, puede obtener la información de configuración IP (mediante los anuncios de router del AR adyacente de otra red) antes de que se conecte a ese AR. Por tanto esta información de configuración permite al MN detectar rápidamente el movimiento a la nueva red y obtener la conectividad IP más rápidamente. Esto implica que el MN conozca de antemano el nuevo router y la futura dirección IP antes de dejar el AR al que está conectado. El método para conocer todos los AR que tiene alrededor es mediante Neighbour Discovery, y el hecho de conocer a todos los AR adyacentes es que el nodo móvil tiene un mapa de todos futuros AR a los que se puede conectar y la información IP correspondiente para que el nodo se pueda conectar a cualquiera de ellos. El problema que introduce este método es que al estar una interfaz de red buscando posibles routers adyacentes, es que dado que muchas interfaces wireless generan handovers de enlace en el momento de la búsqueda, con lo que se produce un retardo en el salto al buscar nodos adyacentes con lo que se puede obtener unos resultados muy pobres en las aplicaciones de tiempo real. Una mejora sobre este método es que los AR tengan el mapa completo de los routers adyacentes y sus características. Mediante un nuevo protocolo Candidate Access Router Discovery (CARD), se puede obtener las capacidades y características de los AR de manera que el nodo puede tomar su decisión y elegir el que más le convenga C u e l l o s d e b o t e l l a p r o d u c i d o s p o r l a l a t e n c i a d e rec e p c i ó n d e p a q u e t e s La latencia producida por la recepción de paquetes después de un handover es debida a que el CN necesita actualizar su caché de vínculos con la nueva dirección IP del MN. La configuración depende de la latencia de conectividad. Una vez que el MN detecta el movimiento y configura su nueva CoA, debe enviar un mensaje 19

21 Binding Update a su HA para que cualquier paquete que llegue a su HN sea reenviado inmediatamente. Simultáneamente a esto se envía un mensaje HoTI al CN mediante el túnel creado entre el HA y el MN y el mensaje CoTI directamente al CN sin usar el túnel. Cuando los mensajes HOT y COT lleguen, el nodo móvil estará seguro de que tiene conectividad con el CN y enviará el mensaje Binding Update. El MN puede comenzar a transmitir paquetes de manera optimista (sin esperar el Binding Ack). Pero aun usando esto último el tiempo de espera es de 1,5 RTT. Este delay en Internet puede ser superior a 100 ms y al que hay que sumarle la latencia del nivel de enlace. Además todos los paquetes que se han enviado siguen llegando a la anterior CoA del nodo móvil. Hay que tener en cuenta que el Binding Update es por cada CN con el que el nodo se esté comunicando, con lo que la latencia se incrementa cuando hay varios CN involucrados. La latencia de recepción refleja el retardo de señalización de Mobile IPv6. A esto hay que añadir la latencia de conectividad que refleja el retardo del proceso total de handover R e d u c c i ó n d e l o s c u e l l o s d e b o t e l l a d e l a r e c e p c i ó n d e p a q u e t e s Una aproximación para reducir este tipo de latencia es que de forma temporal el envío de los datos se haga desde el anterior AR hasta la nueva CoA (una vez hecho el handover). Este tipo de reenvío debe ser cuidadoso con el tiempo del movimiento del nodo. Por tanto este método debe ser iniciado antes de que el MN deje su anterior AR o únicamente después de que el MN establezca ya la comunicación con el nuevo AR. Estableciendo la comunicación antes del handover: Normalmente, el handover se produce cuando se pierde la potencia o la calidad de la señal de un enlace wireless. Esto pude pasar debido al movimiento del usuario. Sin embargo, en sistemas como WLAN, esto también puede ocurrir debido a congestión del punto de acceso debido a que no hay control de admisión. También puede ser producido por interferencias de otros dispositivos o nodos que están en la misma frecuencia pero con unos niveles de potencia mucho mayores (como microondas, cámaras de video-vigilancia, etc). Estas son consideraciones básicas por las que la calidad de una señal puede disminuir y por lo tanto el handover sea necesario. 20 Existen otras razones, por ejemplo, un nodo móvil descubre que un AR diferente le puede dar mejor servicio de acceso (mejor QoS). La red existente también puede decidir si fuerza al MN a saltar a un AR particular para balancear la carga. En estos casos, el MN decide si se produce el handover si la calidad y la fuerza de la señal son aceptables. Por tanto hay un considerable interés en estandarizar un conjunto de triggers de nivel 2 que permitan el inicio de handovers. Presumiblemente, estos triggers deberán notificar al software de movilidad en la pila IP cuando se producen ciertos eventos de interés. Como complemento decir que el working group del IEEE de la especificación están definiendo un conjunto de servicios que un MN puede usar de modo que pueda descubrir los servicios de red disponibles, mediante pares de pregunta-respuesta. Existen ya muchas propuestas ante esta problemática como puede ser esta última o los objetivos del protocolo CARD. Por tanto el modo de funcionamiento del establecimiento de la comunicación antes del handover es simple, se calcula una nueva CoA que puede ser usada si se produce el salto a la nueva red. Se construye esta dirección teniendo en cuenta la información que está siendo recibida usando neighborhood discovery. El nodo móvil entonces manda un mensaje Fast Binding Update (FBU) al AR al que está dejando de manera que le pide la retransmisión de los paquetes que le llegue a la nueva dirección CoA que tenía previamente calculada. En ese momento cierra la comunicación con el antiguo AR y se conecta al nuevo AR. Cuando el AR anterior procesa el mensaje FBU, inmediatamente activa la entrada de reenvío en su tabla de encaminamiento, de tal manera que cualquier paquete que llegue a la antigua CoA será tunelizada a la nueva dirección CoA que es valida en el nuevo AR. Cuando el paquete llegue al nuevo AR, este va a realizar un Neighbor Solicitation para la nueva CoA. Si el nodo móvil está presente en esta red responderá a la llamada