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

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
www.gitaca.es
Octubre de 2008
Autores: David Cortés Polo - Carlos Vecino de Casas
Coordinador: José Luis González Sánchez
Análisis y Optimización del Handover en
redes MobileIP
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........................................................................................................................7
2
INTRODUCCIÓN .......................................................................................................9
3
INTRODUCCIÓN A MOBILEIP ............................................................................................9
4
FUNDAMENTOS DE MOBILE IP V6 .................................................................................... 10
4.1
FUNCIONAMIENTO DE MOBILE IP V6 .......................................................................... 11
4.2
DETECCIÓN DEL MOVIMIENTO EN UNA RED .................................................................. 11
4.2.1
PROTOCOLO NEIGHBOR DISCOVERY .................................................................... 12
4.2.2
DESCUBRIMIENTO DE OTROS HOME AGENTS........................................................... 13
4.3
ADQUISICIÓN DE UNA NUEVA COA ............................................................................ 13
4.3.1
DUPLICATE ADDRESS DETECTION (DAD) .............................................................. 14
4.4
ACTUALIZACIÓN DE LOS VÍNCULOS ............................................................................ 14
4.4.1
USO DE LA CACHÉ DE VÍNCULOS .......................................................................... 15
4.4.2
RETURN ROUTABILITY ..................................................................................... 15
4.5
ENRUTADO Y TUNNELING ....................................................................................... 16
5
HANDOVER EN MOBILEIP V6.......................................................................................... 16
5.1
FAST HANDOVER EN MOBILE IP6 ............................................................................... 17
5.1.1
CUELLOS DE BOTELLA PRODUCIDOS POR LA LATENCIA DE CONECTIVIDAD ....................... 18
5.1.2
REDUCCIÓN DE LOS CUELLOS DE BOTELLA DE LA CONECTIVIDAD .................................. 19
5.1.3
CUELLOS DE BOTELLA PRODUCIDOS POR LA LATENCIA DE RECEPCIÓN DE PAQUETES ........... 19
5.1.4
REDUCCIÓN DE LOS CUELLOS DE BOTELLA DE LA RECEPCIÓN DE PAQUETES ...................... 20
5.2
HIERARCHICAL MOBILE IP V6 ................................................................................... 21
6
PROYECTOS DE IMPLEMENTACIÓN DE MOBILEIPV6 ................................................... 23
6.1
PROYECTO MIPL.................................................................................................. 23
6.1.1
CONFIGURACIÓN DE IPV6 MÓVIL EN LINUX .................................................. 24
6.1.2
CONFIGURACIÓN DE IPV6 MÓVIL EN LINUX ............................................................ 24
6.2
PROYECTO SAM .................................................................................................. 27
7
COMPARATIVAS LATENCIA DE HANDOVER EN DIFERENTES PROTOCOLOS .................. 28
7.1
HANDOVER EN SIGMA SOBRE STCP .......................................................................... 29
7.2
COMPARATIVA ENTRE SIGMA, FMIPV6, HMIPV6 Y FHMIPV6 .......................................... 31
7.3
CONCLUSIONES.................................................................................................... 34
8
EVOLUCIÓN DE LOS PROTOCOLOS QUE REALIZAN HANDOVER (FHMIP, SIMP, FFHMIP) 34
8.1
ALCANCE DE ESTE INFORME TÉCNICO ......................................................................... 34
8.2
FAST HANDOVER PARA HIERARCHICAL MOBILE IPV6 (F-HMIPV6)....................................... 35
Análisis y Optimización del Handover en redes MobileIP
1
1
Análisis y Optimización del Handover en redes MobileIP
2
8.2.1
VISIÓN GENERAL DE F-HMIPV6 .......................................................................... 35
8.2.2
FUNCIONAMIENTO DE F-HMIPV6........................................................................ 36
8.3
MOBILE IP SIN FISURAS (S-MIP) ................................................................................. 40
8.3.1
VISIÓN GENERAL DE S-MIP ................................................................................ 40
8.3.2
FUNCIONAMIENTO DE S-MIP ............................................................................. 41
8.4
FFHMIPV6 ......................................................................................................... 42
8.4.1
VISIÓN GENERAL DE FFHMIPV6 .......................................................................... 42
8.4.2
FUNCIONAMIENTO DE FFHMIPV6 ....................................................................... 42
9
ACTUALIDAD SOBRE LOS DISPOSITIVOS QUE INTEGRAN SOPORTE PARA MOBILEIPV6........................ 47
9.1
DISPOSITIVOS ...................................................................................................... 47
9.2
HANDOVER SIN FISURAS ENTRE REDES HETEROGÉNEAS ..................................................... 48
9.2.1
INTRODUCCIÓN DE LA INVESTIGACIÓN .................................................................. 48
9.2.2
DEMOSTRACIÓN DEL HANDOVER ........................................................................ 48
9.2.3
"EL CUÁNDO Y POR QUÉ" DEL HANDOVER............................................................. 49
9.2.4
"¿HACIA DÓNDE?" SE REALIZA EL HANDOVER ......................................................... 50
9.2.5
“CÓMO” SE REALIZA EL HANDOVER ...................................................................... 50
9.3
ESTANDARIZACIÓN Y SUPERVISIÓN DE PRODUCTOS PREPARADOS PARA MOBILEIPV6 ................. 51
10
OTRAS TECNOLOGÍAS QUE PODRÍAN COMPLEMENTAR A MOBILEIP .......................... 52
10.1
RFID............................................................................................................... 52
10.1.1
INTRODUCCIÓN ........................................................................................... 52
10.1.2
FUNDAMENTOS DE RFID ................................................................................. 55
10.1.3
ESTADO ACTUAL ........................................................................................... 58
11
SUITES DE SIMULACIÓN ............................................................................................... 61
11.1
NETWORK SIMULATOR ......................................................................................... 61
11.2
OMNET++...................................................................................................... 62
11.3
OPNET ........................................................................................................... 62
12
SIMULACIONES REALIZADAS ......................................................................................... 63
12.1
ELECCIÓN DEL SIMULADOR .................................................................................... 63
12.2
INSTALACIÓN DEL SIMULADOR ................................................................................ 64
12.3
INTRODUCCIÓN A LAS SIMULACIONES ........................................................................ 66
12.4
ESCENARIO 1 ..................................................................................................... 66
12.4.1
RESULTADOS SIMULACIÓN 1 ............................................................................. 68
12.4.2
ANÁLISIS DE LOS RESULTADOS DE LA SIMULACIÓN 1 ................................................. 71
12.5
ESCENARIO 2 ..................................................................................................... 72
12.5.1
RESULTADOS SIMULACIÓN 2 ............................................................................. 73
12.5.2
ANÁLISIS DE LOS RESULTADOS DE LA SIMULACIÓN 2 ................................................. 76
12.6
ESCENARIO 3 ..................................................................................................... 77
12.6.1
RESULTADOS SIMULACIÓN 3 ............................................................................. 78
12.6.2
ANÁLISIS DE LOS RESULTADOS DE LA SIMULACIÓN 3 ................................................. 81
12.7
CONCLUSIONES OBTENIDAS DE LAS SIMULACIONES ........................................................ 82
13
CONCLUSIONES Y LÍNEAS DE INVESTIGACIÓN FUTURAS ......................................................... 83
14
REFERENCIAS ........................................................................................................... 85
15
BIBLIOGRAFÍA ....................................................................................................... 86
ACRÓNIMOS UTILIZADOS
• 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
• 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
Análisis y Optimización del Handover en redes MobileIP
• HI
Handover Initiate
3
• 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
Análisis y Optimización del Handover en redes MobileIP
• SIP
Session Initiation Protocol
4
GLOSARIO–TÉRMINOS UTILIZADOS SOBRE MOBILEIP
Término de Mobile IP
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)
Router de la red de origen del MN en la que está registrada la dirección actual de CoA.
-Binding
- 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érminos específicos del handover
­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)
Análisis y Optimización del Handover en redes MobileIP
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.
5
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)
Análisis y Optimización del Handover en redes MobileIP
Un mensaje del NAR al PAR como respuesta al HI.
6
Figura 1- esquema básico de MIPv6..............................................................................................11
Figura 2 - nivel óptimo de jerarquía en relación al número de AR .........................................................22
Figura 3 - escenario básico de movilidad en IPv6 ..............................................................................24
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 mobileipv6...............................................................................47
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. .......56
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 1 .............................................................................................................67
Figura 40 - escenario 1 handover mipv6 ........................................................................................68
Figura 41 - escenario 1 comparación rtt ........................................................................................70
Figura 42 - escenario 1 pings perdidos ..........................................................................................70
Figura 43 - escenario 2 .............................................................................................................72
Análisis y Optimización del Handover en redes MobileIP
FIGURAS
7
Análisis y Optimización del Handover en redes MobileIP
Figura 44 - escenario 2 handover mipv6 ........................................................................................73
Figura 45 - escenario2 comparación rtt .........................................................................................75
Figura 46 - escenario 2 pings perdidos ..........................................................................................75
Figura 47 - escenario 3 .............................................................................................................77
Figura 48 - handover mipv6 escenario 3 ........................................................................................78
Figura 49 - escenario 3 comparación rtt ........................................................................................80
Figura 50 - escenario 3 pings perdidos ..........................................................................................80
Figura 51 - binding update en hmip..............................................................................................82
8
2
INTRODUCCIÓ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.
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
Introducción a mobileIP
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
Análisis y Optimización del Handover en redes MobileIP
Comparativas sobre la latencia de Handover en diferentes protocolos (Sigma, FMIPv6, HMIPv6
y FHMIPv6).
9
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
Fundamentos de Mobile IP v6
Análisis y Optimización del Handover en redes MobileIP
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).
•
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.
F IGURA 1-
ESQUEMA BÁSICO DE
MIP V 6
Una vez vista los elementos básicos del protocolo, vamos a estudiar más a fondo el protocolo.
4.1
Funcionamiento de Mobile IP v6
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
Detección del movimiento en una red
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
Análisis y Optimización del Handover en redes MobileIP
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:
11
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.
Análisis y Optimización del Handover en redes MobileIP
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.
4.2.1
Protocolo Neighbor Discovery
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
sido resuelta con anterioridad. Estas funciones son necesarias para la comunicación sobre un medio físico
específico.
4.2.2
Descubrimiento de otros Home Agents
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.
4.3
Adquisición de una nueva CoA
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.
Análisis y Optimización del Handover en redes MobileIP
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.
13
4.3.1
Duplicate Address Detection (DAD)
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 0 – 500 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.
Análisis y Optimización del Handover en redes MobileIP
4.4
14
Actualización de los vínculos
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.
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.
4.4.1
Uso de la caché de vínculos
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)
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
IPv6.
4.4.2
Return Routability
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
Análisis y Optimización del Handover en redes MobileIP
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.
15
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
Enrutado y Tunneling
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.
Análisis y Optimización del Handover en redes MobileIP
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
Handover en MobileIP v6
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.
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.
Fast Handover en Mobile IP6
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
Análisis y Optimización del Handover en redes MobileIP
5.1
17
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.
Análisis y Optimización del Handover en redes MobileIP
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.
5.1.1
Cuellos de botella producidos por la latencia de
conectividad
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
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.
5.1.2
Reducción de los cuellos de botella de la conectividad
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.
5.1.3
Cuellos de botella producidos por la latencia de
recepción de paquetes
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
Análisis y Optimización del Handover en redes MobileIP
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.
19
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.
5.1.4
Reducción de los cuellos de botella de la recepción de
paquetes
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:
Análisis y Optimización del Handover en redes MobileIP
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 802.21 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
Neighbor Solicitation. Si no está en esa red, el paquete que está en el buffer del router, se descarta. Los nuevos
routers intentan realizar un Neighbor Discovery después de 1 segundo. Por otro lado, el nodo móvil debe enviar
un mensaje de anuncio de router no solicitado para establecerse en la red. Esto fuerza al nuevo AR a realizar un
Neighbor Discovery otra vez tan pronto como el nuevo paquete llegue y pueda entregar el paquete al MN.
Estableciendo el reenvío una vez hecho el handover
En algunas ocasiones no es posible establecer el plano de reenvío antes de que el nodo abandone el AR incluso
aunque tenga el mapa de routers adyacentes. El MN se ve forzado a conectarse a un nuevo AR, que pertenece a
otra red o subconjunto, o el mensaje FBU se pierde antes de que llegue al router. Por estas razones la
actualización de la tabla de enrutamiento sólo se puede efectuar una vez que el MN obtenga conectividad en la
nueva red. Hasta que se produzca la actualización se van a estar perdiendo los paquetes que se envíen al MN.
Incluso sin la actualización de las tablas de routing en el AR que se abandona, el nodo móvil se sigue
beneficiándose de la reducción de la latencia en la detección del movimiento y en la configuración de la nueva
dirección IP. Desde que el MN tiene conocimiento de los routers adyacentes, puede detectar el movimiento a una
nueva red y determinar la dirección del nuevo AR y la respectiva IP que ha de usar. Además la probabilidad de
colisión entre dos IP's iguales es muy pequeña, se puede enviar un mensaje FBU inmediatamente al AR anterior
para actualizar la tabla de routing y de esta manera minimizar la pérdida de paquetes. Pero debido a cuestiones de
seguridad muchos de los administradores de red no van a permitir el envío de datos a través de sus redes con una
dirección CoA que no ha sido verificada anteriormente. Por tanto este método sólo será válido en los casos en los
que la red permita enviar un mensaje sin que haya sido verificado con anterioridad una dirección CoA.
El nodo móvil puede enviar más de un FBI siempre que no tenga la certeza de que un FBU previo haya sido
procesado con éxito. Por ejemplo, cuando un MN decide dejar una red tras enviar un FBU para que la pérdida de
paquetes sea mínima, si este no recibe un FBack antes de que abandone el AR anterior, reenviará un FBU cuando
le sea posible desde su nueva ubicación en el nuevo AR. De esta manera hace notar que se ha producido un
handover y que quiere que los paquetes se le retransmitan a esa nueva CoA. Sin ese paquete FBack no es posible
determinar si se ha aceptado esa petición o no. Por otro lado, si un FBU se ha procesado (aunque el MN no tenga
conocimiento de ello) y se comienza a recibir paquetes, se puede considerar como un FBack recibido
(dependiendo de la implementación del protocolo).
Una vez vistas las herramientas para minimizar la pérdida de paquetes con el AR anterior, también hay que
intentar minimizar la pérdida de paquetes con el nuevo AR (que podría descartarlos al no tener constancia de esa
dirección CoA). Es por esto que se necesita mandar un mensaje al nuevo AR que le indique de que se va a
producir un handover hacia su red y que va a estar enlazado con ese AR. Este anuncio se hace usando el mensaje
Fast Neighbor Advertisement (FNA) que incluye la nueva dirección CoA del nodo.
El mensaje FNA tiene dos aproximaciones. El primero informa al nuevo AR de que un nodo se va a conectar con
el. Cuando se comienzan a reenviar los paquetes que llegan al anterior AR, el nodo móvil todavía no se ha
enlazado con el nuevo AR, por lo tanto los paquetes están siendo enviados a la nueva CoA, el nuevo AR deberá
almacenar los paquetes en el buffer para su posterior entrega al nodo móvil. La llegada de paquetes se hace de la
misma manera que se ha visto anteriormente, es decir usando el protocolo Neighbor Discovery.
5.2
Hierarchical Mobile IP v6
Aunque el protocolo Fast Handover se centra principalmente en reducir la latencia y la pérdida de paquetes
durante los handovers, en esencia es un protocolo independiente del protocolo actual de movilidad usado en
Internet. El protocolo no afecta a Mobile IP como tal, toma como inamovibles las latencias que introduce Mobile
IP. En otras palabras, un nodo móvil va a seguir realizando todas las operaciones como son especificadas en el
estándar. Estas operaciones van a introducir un overhead adicional de señalización en diversos escenarios. Por esta
Análisis y Optimización del Handover en redes MobileIP
Anuncio de un nuevo enlace con otro AR
21
razón nace Hierarchical Mobile IPv6 (HMIPv6), que fue diseñado para evitar este overhead. Además el protocolo
puede ser útil en cuestiones de privacidad en términos de direcciones IP ya que con este método la dirección CoA
no es mostrada al CN.
Por lo tanto, Mobile IP jerárquico es una extensión que se propone sobre MIPv6 para mejorar los handover
dentro de un dominio (micro-movilidad). Para esto lo que se propone es la introducción de un nuevo elemento
denominado Mobility Anchor Point (MAP).
MAP realiza las mismas funciones que un HA dentro de un dominio de tal manera que disminuye la señalización
que transmite el MN cuando se produce un handover. Es por esto que desaparece el concepto de CoA como la
dirección IP que mantiene el MN en la red visitada para que cada MN mantenga dos direcciones IP, una para los
movimientos locales dentro de un mismo MAP, Local CoA (LCoA), y otra para movimientos que requieran
también cambio de MAP se utilizarán Regional CoA (RcoA).
La dirección LCoA es calculada cuando se produce un cambio en el router de acceso mientras que la dirección
RCoA es calculada cuando hay un cambio de MAP. Por tanto para publicar la nueva dirección LCoA únicamente
se ha de mandar un mensaje Local Binding Update (LBU) al MAP (este mensaje relaciona LCoA y RCoA en la
tabla de encaminamiento del MAP), mientras que para RCoA se han de mandar dos MAP, uno para el HA y otro
para el MAP. De tal manera que se ahorra señalización en muchos casos debido a que el mayor número de saltos
que se van a producir en una red es dentro del mismo dominio.
Análisis y Optimización del Handover en redes MobileIP
En [7] se estudia el nivel máximo que debe tener la jerarquía para que la red no se vea sobrecargada por los
mensajes de control. En este trabajo se desarrolla un modelo analítico para la jerarquía multinivel de HMIPv6 y se
llega a la conclusión de que en pequeñas redes de hasta 128 AR aproximadamente, no es necesaria ninguna
jerarquía para el óptimo funcionamiento de la red. En cuanto la red tiene un mayor número de AR, el nivel de
jerarquía óptimo aumenta pasando a 2. El máximo de jerarquía que se recomienda en este trabajo es e 7 en el caso
de que la red tenga más de 248 AR.
22
F IGURA 2 - NIVEL ÓPTIMO DE JERARQUÍA EN RELACIÓN AL NÚMERO DE AR
El fundamento de este estudio es la cantidad de información de control que se pasan los nodos de la jerarquía.
Llegando a ser en algunos momentos un problema al inundar la red de mensajes. Este es uno de los mayores
problemas de HMIPv6.
Otras investigaciones permiten el desarrollo de un algoritmo para que se produzcan handovers rápidos usando
HMIPv6 basados en multicast [8]. En este trabajo, se muestra la necesidad de mejorar el tiempo de handover de
nivel 3 usando HMIPv6 usando técnicas de multicasting para la continuidad de la conexión entre el MN y la red
durante el salto.
6
PROYECTOS DE IMPLEMENTACIÓN DE MOBILEIPV6
En este apartado se van a exponer las principales vías encontradas, en lo que se refiere a investigación sobre la
implementación real de los protocolos móviles basados en IPv6, es decir MobileIPv6, FMIPv6, HMIPv6 y
FHMIPv6.
Por el momento el más desarrollado es MobileIPv6, esto es lógico ya que es el protocolo más antiguo de los
mencionados, además de ser la base de todos los demás.
Sobre las implementaciones de HMIPv6 y FHMIPv6 no se han encontrado proyectos significativos aún, sino que
todo lo realizado está basado en simulaciones con determinados programas como OMNET, OPNET y NS-2(con la
ayuda de determinados módulos externos).
6.1
Proyecto MIPL
La implementación más conocida para uso sobre Linux de MobileIPv6 es la realizada en la Universidad de
Helsinki. MIPL Mobile IPv6 para Linux [12] empezó en el año 1999 como un proyecto de estudiantes. Después el
desarrollo fue tomado por GO-Core un proyecto ubicado en el laboratorio de Software de Telecomunicación de
HUT (Universidad de Helsinki).
El código fue desarrollándose a medida que aparecieron nuevos proyectos, y también nuevas versiones del núcleo
de Linux. Al principio todo se desarrollo sobre la versión del kernel 2.3.59 y se llegó hasta la versión 8 del
proyecto de MIPL. Después de algunos cambios importantes en la especificación de Mobile IPv6, se decidió que
MIPL se dividiría en un núcleo y una serie de módulos que lo complementarían para hacer más fácil el desarrollo
del proyecto.
Actualmente MIPL es desarrollado en el tiempo libre de sus investigadores, y como parte de proyectos de
estudiantes de la universidad de Helsinki. Los desarrolladores tienen otras tareas que hacer, pero tratan de dedicar
el mayor tiempo posible para asegurar que el software funcione.
Con respecto a MIPL para linux hay que decir que ha sido liberado bajo licencia GPL y está disponible para
cualquier persona de forma gratuita [14].
Pese a lo interesante de este tema, la información sobre el proyecto es bastante escasa ya que el proyecto de de
MIPL ha quedado en estado de letargo y su desarrollo no es continuado, aunque se mantendrá la línea de
investigación abierta por si en futuros informes el proyecto se reactiva y aporta nuevos datos.
Análisis y Optimización del Handover en redes MobileIP
A finales de 2003, se inició el desarrollo MIPL 2. El nuevo número de versión se implanta para hacer hincapié en
que es un proyecto totalmente diferente de las anteriores versiones. Básicamente, la versión 2.0 es una reescritura
completa de todo el software, con la mayor parte de la funcionalidad en un “user daemon”. Al mismo tiempo, se
inició la colaboración con el proyecto HUT USAGI [13], con el principal cometido de poder obtener soporte IPv6
móvil en el principal núcleo de Linux.
23
6.1.1
CONFIGURACIÓN DE IPv6 MÓVIL EN LINUX
F IGURA 3 -
ESCENARIO BÁSICO DE MOVILIDAD EN
IP V 6
En IPv6 desaparecen tanto los Foreign Agents como la obtención de direcciones provisionales en las subredes
visitadas por el nodo móvil a través de DHCP. Estos procedimientos son sustituidos por la autoconfiguración a
través de la recepción de Router Advertisements. Por lo tanto, los elementos que intervienen en la movilidad en
IPv6 son los Home Agent y los Mobile Nodes.
Para los nodos que mantienen comunicaciones con éstos últimos, los Correspondent Nodes, este proceso puede
ser teóricamente transparente. Existe la posibilidad de utilizar actualización de rutas si éstos tienen instalado el
software de movilidad, evitando el enrutamiento triangular. Sin embargo, esta transparencia no es posible para
versiones del kernel inferiores a la 2.4.16, por lo que será necesaria la instalación del mismo software que en el
Home Agent y Nodo Móvil.
Análisis y Optimización del Handover en redes MobileIP
6.1.2
24
Configuración de IPv6 móvil en Linux
6.1.2.1
Sistema operativo y kernel (para todos los equipos:
Home Agent, Mobile Node y Correspondent Node.)
•
Cualquier distribución de Linux. Las pruebas se han hecho con SuSE 7.3.
Implementación de MIPv6: MIPL Mobile IPv6 for Linux, de la Universidad de Helsinki. Esta
aplicación es válida para RedHat 6.1, 6.2, 7.0, Suse, Debian con kernel 2.4.x. Para su instalación son
necesarios conocimientos de IPv6, y configuración, parcheado y compilación del kernel.
•
KERNEL: es posible utilizar USAGI http://www.linux-ipv6.org/ (es una implementación del
kernel de linux con énfasis en el soporte IPv6). Esta implementación tiene la ventaja de que no es
necesaria la aplicación de ningún parche, ya que está sincronizada con la implementación de HUT.
Además, este kernel posee buen soporte IPv6, por lo que existen diversas aplicaciones para IPv6 que sólo
funcionan con este kernel. La versión que se ha usado contiene el kernel 2.4.17.
•
Sin embargo, también es posible utilizar cualquier kernel 2.4.x de linux, con la ventaja de que es
más estable. Sin embargo, en este caso hay que aplicar un parche al kernel de linux. Este parche se
obtiene en la distribución de MIPL. Para ello, hay que entrar en el directorio donde está el kernel
(generalemente /usr/src/linux), y ejecutar: % patch -p1 < $MIPL/mipv6-0.9.1-v2.4.16/mipv6-0.9.1v2.4.16.patch ; siendo $MIPL el path en el que se ha descomprimido el .tar.gz de mipl.
•
•
Además, al compilar el kernel habrá que incluir las opciones que se recomiendan en (*).
6.1.2.2
Instalación de USAGI
Después de descomprimir las fuentes de USAGI, que se pueden bajar de http://www.linux-ipv6.org/, entrar en
el directorio */usagi/ y ejecutar:
•
% make prepare TARGET=linux24
•
Compilar el kernel de linux, haciendo:
•
% cd kernel/linux24
•
% make mrproper
•
% make dep
•
% make bzImage
•
% make modules
•
% make modules_install
•
% cp arch/i386/bzImage /boot/...
•
% cp System.map /boot
•
% vi /etc/lilo.conf
•
% lilo
(*) Respecto a las opciones del kernel, deben incluirse al
menos las siguientes:
CONFIG_EXPERIMENTAL=y
CONFIG_SYSCTL=y
CONFIG_PROC_FS=y
CONFIG_MODULES=y
CONFIG_NET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETFILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=m
CONFIG_IPV6_IPV6_TUNNEL=m
CONFIG_IPV6_MOBILITY=m
(**)Por ser USAGI una implementación experimental, se
recomienda que ciertas opciones se seleccionen a NO durante la
configuración:
CONFIG_IPV6_DEBUG=n
CONFIG_IPV6_6TO4_NEXTHOP=n
CONFIG_IPV6_NDISC_DEBUG=n
Análisis y Optimización del Handover en redes MobileIP
• % make menuconfig (o "make config" o "make xconfig")
(*)
25
CONFIG_IPV6_ACONF_DEBUG=n
CONFIG_IPV6_RT6_DEBUG=n
CONFIG_IPV6_MLD6_DEBUG=n
CONFIG_IPV6_MLD6_NO_SUPPRESS_DONE=n
CONFIG_IPV6_NODEINFO=n
CONFIG_IPV6_NODEINFO_DEBUG=n
CONFIG_IPV6_NODEINFO_USE_UTS_DOMAIN=n
CONFIG_IPV6_MOBILITY=n
CONFIG_ATM_IPV6
Después, se deben instalar las aplicaciones de USAGI haciendo:
•
6.1.2.3
•
% cd usagi/usagi
•
% ./configure
•
% make
•
% make install
Instalación de MIPL Mobile IPv6
Análisis y Optimización del Handover en redes MobileIP
Después de descargar y descomprimir las fuentes de MIPL, entrar dentro del directorio mipv6-0.9.1-v2.4.16 y
seguir los siguientes pasos:
26
•
% ./configure
•
% make
•
% make install
6.1.2.3.1
Configuración
La configuración se realiza a través de los ficheros de configuración de Home Agent, Mobile Node y
Correspondent Node. Aquí hay unos ejemplos comentados de los tres ficheros de configuración:
• Home Agent
• Mobile Node
• Correspondent Node
6.1.2.3.2
Uso de MIPv6
Existe un script automático de arranque del servicio MIPv6, llamado mobile-ip6, con las siguientes opciones:
{start|stop|status|restart}. Otra posibilidad es cargar el módulo a mano ejecutando insmod.
6.2
Proyecto SAM
Como introducción a este proyecto se tiene que decir que su principal propósito fue la implementación del
FMIPv6, una evolución de MobileIPv6, que reducía el tiempo de handover de unos 2 segundos a unos
milisegundos.
Dentro del proyecto SAM [15] se decidió implementar el protocolo FMIPv6 en el Kernel de Linux usando la
implementación de Mobile IPv6 MIPL.
Particularmente, FMIPv6 debe correr en varias entidades diferentes, es decir, su implementación estará dividida
en varias máquinas diferentes: en los dispositivos móviles y en los puntos de acceso. De esta manera,
implementarlo implica tener que hacerlo en diversas máquinas diferentes, complicando el proceso.
Con el objetivo de evaluar y medir diferentes protocolos de movilidad (entre ellos FMIPv6), en el proyecto SAM
se desarrolló un escenario de pruebas basado en máquinas Linux, enrutadores Cisco y tarjetas IEEE 802.11
funcionando en modo infraestructura (figura 1). Por las razones antes expuestas, desarrollar el nuevo protocolo en
el Kernel de Linux en dicho escenario es inviable. Es por ello que se optó por desarrollar el protocolo en otro
entorno de mayor productividad. Linux ofrece la posibilidad de construir sobre el sistema (que interactúa
directamente con el hardware) una o varias máquinas virtuales usando User Mode Linux (UML) [16].
F IGURA 4 -
EXPERIMENTOS CON PROTOCOLOS DE MOVILIDAD
[17]
Para desarrollar el nuevo protocolo, se replicó el escenario en un entorno UML, creando una máquina virtual por
cada máquina física. El escenario virtual UML es idéntico al real, se utilizan las mismas versiones de software y del
Kernel de Linux. Se emuló una Ethernet en la máquina física que comunicaba las máquinas virtuales, dicha
Ethernet servía de red troncal para comunicar las diferentes entidades del escenario de pruebas. Para emular la
interfaz IEEE 802.11 que comunica el dispositivo móvil con los enrutadores de acceso, se usó también una
Ethernet, es decir, no se emuló el medio físico ni MAC de la red inalámbrica. Dicha emulación no es necesaria
para una correcta evaluación del protocolo. FMIPv6 extiende las funcionalidades de MIPv6, y es independiente de
la tecnología de nivel 2 utilizada. El handover en UML se emula desconectando la interfaz del enrutador de acceso
y conectándola al siguiente.
Usando este sistema se pueden evaluar diferentes aspectos de la implementación. Se pueden realizar pruebas de
carga del protocolo, es decir, estudiar cómo responde la implementación usando varios dispositivos móviles.
También permite estudiar la cantidad de señalización que incorpora FMIPv6 respecto a MIPv6.
Análisis y Optimización del Handover en redes MobileIP
Para finalizar con esta introducción se tiene que hacer una mención especial a la fuente de la que se ha sacado la
mayor parte de la información sobre el proyecto: el boletín de rediris nº 74 y 75 [17].
27
Una vez que se tenía la topología e implementación anteriormente expuesta, se migró todo a un escenario real
para realizar las pruebas pertinentes. Hay que destacar que el código de UML se puede ejecutar en un entorno
real.
Como resultados de la implementación del FMIPv6 tenemos los siguientes:
Los paquetes fluyen hacia el dispositivo móvil con un retardo constante (inicio de la gráfica), cuando se inicia el
handover (pico de retardo) los paquetes son guardados por uno de los enrutadores de acceso, justo en el momento
en que el dispositivo móvil se reconecta al nuevo punto de acceso, el enrutador envía estos paquetes al dispositivo.
Es por ello que los paquetes que se envían al dispositivo móvil mientras éste está desconectado (cambiando de un
punto de acceso a otro) se retardan. Una vez que el dispositivo es conectado al nuevo punto de acceso, los
paquetes fluyen con un retardo constante (final de la gráfica).
F IGURA 5 - COMPARACIÓN ENTRE R EAL Y UML. [17]
Análisis y Optimización del Handover en redes MobileIP
7
COMPARATIVAS LATENCIA DE HANDOVER EN
DIFERENTES PROTOCOLOS
28
MobileIP es un estándar propuesto por IETF para manejar la movilidad de los hosts de internet en los que se
requieren comunicaciones con dispositivos móviles. Por ejemplo, se establece una conexión TCP que permanece
viva y recibe los paquetes cuando el host móvil se mueve entre los diferentes puntos de acceso de las redes. Sin
embargo, hay varios inconvenientes cuando se usa MobileIP en un entorno real de computación móvil, los más
importantes son: la alta latencia del Handover y la pérdida de paquetes durante esta fase. Para conseguir
solucionar estos problemas se han propuesto mejoras al protocolo original apareciendo así: MobileIPv6, FMIPv6
(Fast Handover for Mobile IPv6), HMIPv6 (Hierarchical MIPv6) y una combinación de los dos últimos protocolos
que es FHMIPv6 (esta combinación la trataremos más en profundidad en los siguientes informes, puesto que es la
más reciente y aún está en desarrollo).
Como se ha visto en el anterior párrafo, MobileIPv6 está en constante desarrollo, pero ninguno de los protocolos
evolucionados ha conseguido solventar completamente el problema de la alta latencia del handover y la alta tasa de
pérdida de paquetes. Como objetivo del informe se quiere presentar otro protocolo que consiga reducir los
aspectos negativos comentados, para ello introduciremos al lector un nuevo esquema llamó SIGMA ( Seamless IP
diversity based Generalized Mobility Architecture). Después compararemos a SIGMA con todas las mejoras de
MIPv6.
La principal idea de SIGMA es dejar operativo el antiguo camino entre los nodos, mientras se realiza la nueva
conexión entre el nodo móvil y su nueva red, y así tener un handover sin fisuras.
En lo que se refiere a la comparativa que se va a realizar hay que resaltar que se usará SIGMA sobre STCP (Stream
Control Transmission Protocol) que es un protocolo desarrollado por la IETF que ha recibido recientemente
mucha atención por parte de la comunidad de investigación de comunicaciones. El Multihoming es una
característica que incorpora SCTP, la cual es conveniente para introducir la diversidad de IP en los entornos de
computación móviles. Hay que decir que aunque la comparativa estará hecha sobre STCP, SIGMA también puede
utilizarse normalmente en infraestructuras basadas en IPv4 o IPv6 sin el soporte de MobileIP.
7.1
Handover en SIGMA sobre STCP
Para mostrar cómo se realizaría un handover básico en SIGMA nos fijaremos en la Figura 6. En la ilustración los
nodos móviles serán MH y es multi-homed, o lo que es lo mismo, estará conectado a través de los dos puntos de
accesos de cada una de las redes. El nodo corresponsal (CN) es single-homed (solo conectado a una red) y estará
enviando información al nodo MH.
F IGURA 6 - DISEÑO DE LA RED CON SIGMA Y STCP [17]
Primero se obtine la nueva dirección IP: en la figura 6 el handover comienza cuando MH
se mueve en la zona en la que las dos redes se solapan (en lo que se refiere a cobertura wireless). Una vez
que el MH recibe el router advertisement del nuevo router de acceso (AR2), éste debería obtener la
nueva dirección IP (IP2). La dirección puede obtenerse mediante DHCP, DHCPv6 o mediante Stateless
Address Autoconfiguration.
Se añade la dirección IP a la asociación: Ahora MH tiene que informar a CN de su nueva
dirección IP. Esto lo hará a mediante la opción de SCTP Addres Dynamic Reconfiguration. Esta opción
define dos nuevos tipos de fragmento (ASCONF y ASCONF-ACK) y diversos tipos de parámetros
(añadir una dirección IP, Eliminar una dirección IP, establecer el conjunto primario de direcciones…).
Se redireccionan los paquetes de datos a la nueva dirección IP: Cuando MH se
mueve más hacia el área de cobertura, el punto de acceso2, CN tiene que redireccionar el tráfico a la
nueva dirección IP (IP2) para así incrementar las posibilidades de que los datos lleguen correctamente a
MH. Esta tarea puede ser realizada enviando un ASCONF de MH a CN, con el que CN cambiará su
dirección primaria de destino a IP2.
Análisis y Optimización del Handover en redes MobileIP
Después de haber explicado la estructura de la red sobre la que se trabajará y como se conecta el nodo móvil con
el emisor se pasará a explicar detalladamente cómo se realiza la operación de handover que dividiremos en 5
pasos:
29
Actualización del administrador de ubicación (LM): SIGMA soporta el administrador
de ubicación, que mantiene una base de datos con todas las correspondencias entre las identificaciones de
MH y sus actuales IP primarias. MH sólo puede usar una única identificación. Aquí se puede observar una
diferencia entre SIGMA y MIP: el administrador de ubicación y las funciones de transmisión de datos
están ligadas en MIP, mientras que en SIGMA están separadas para agilizar el handover y hacer la puesta
en funcionamiento del MH en la otra red más flexible.
Desactivación de la IP antigua: esto se produce cuando MH sale del alcance de la red1 y ya
no se debe de transmitir nada a la IP1. En SIGMA MH tiene que notificar a CN que la IP1 está
totalmente fuera de servicio enviando un ASCONF a CN para eliminarla de la lista de direcciones IP de
destino disponibles. Otra opción sería que MH pusiese a 0 la ventana de recepción de información (la que
corresponde a los datos que puede enviar CN a MN). SIGMA puede adaptarse más fácilmente a
movimientos en zig-zag de MH, con respeto a su posición entre las dos redes, ya que mantiene la
dirección antigua por más tiempo y la puede reutilizar (puesto que la dirección IP1 no se extrae de la
lista, sino que se desactiva como válida y no se elimina hasta que el tiempo de vida de la IP1 expira). Esto
reduce considerablemente la latencia y la señalización de tráfico causada durante la obtención de la nueva
dirección IP.
Análisis y Optimización del Handover en redes MobileIP
El proceso comentado anteriormente es el equivalente al siguiente diagrama:
30
F IGURA 7 -
SEÑALES EN EL PROCESO DE HANDOVER
[17]
7.2
Comparativa entre SIGMA, FMIPv6, HMIPv6 y FHMIPv6
Los datos que se expondrán a continuación han sido tomados utilizando la herramienta de simulación NS-2
simulator y expresarán la latencia del Handover, la pérdida de paquetes y el Throughtput y la calidad de la red o
(network friendliness).
TOPOLOGÍA DE LA RED
[17]
Para que los datos sean coherentes la topología de la red a simular debe de ser igual para todos los protocolos
utilizados (SIGMA con STCP, FMIPv6, HMIPv6 y FHMIPv6). Hay que indicar que los protocolos basados en
MIP utilizan la optimización de ruta y que SIGMA ha sido implementado sobre NS-2 simulator por los
investigadores que realizaron el estudio [18]. La topología será la que se muestra en la Figura 5 y que ha sido
utilizada por numerosos estudios sombre MIP [19]. En la figura MIPv6 usa al HA de forma convencional, mientras
que SIGMA usa a éste como el administrador de ubicación. El Router2 actuará como un punto MAP para HMIPv6
y FHMIPv6, mientras que únicamente será router para SIGMA y FMIPv6. Todas las demás características de la
red como ancho de banda, delay de propagación, etc. se muestran en la propia figura de la red.
Para finalizar con los parámetros de simulación tendremos:
Dos agentes FTP uno en MN(sumidero) y otro en CN (fuente) para transmitir datos entre ellos
dos.
Cada AR tiene un área de cobertura de 40 metros de radio y la región de solapamiento es de 10
metros. El periodo de anuncio de router de HA AR1 y AR2 es de 1 segundo, y los anuncios no están
sincronizados.
Para hacer una comparativa clara se ha usado el protocolo SCTP, como protocolo de la capa de
transporte para las mejoras de MIPv6.
Análisis y Optimización del Handover en redes MobileIP
F IGURA 8 -
31
Resultados obtenidos:
 Latencia del Handover:
Análisis y Optimización del Handover en redes MobileIP
F IGURA 9 -
32
COMPARATIVA LATENCIA DEL HANDOVER EN SIGMA
[17]
En las anteriores gráficas se puede ver cómo el tiempo de latencia del handover, tanto en el nodo router HA como
en CN, es mucho más bajo para SIGMA que para las evoluciones de MIPv6.
 Pérdida de Paquetes y Throughput:
COMPARATIVA PEDIDA DE PAQUETES Y THROUGHPUT EN SIGMA
1 [17]
F IGURA 11 -
COMPARATIVA PEDIDA DE PAQUETES Y THROUGHPUT EN SIGMA
2 [17]
F IGURA 12 -
COMPARATIVA PEDIDA DE PAQUETES Y THROUGHPUT EN SIGMA
3 [17]
En esta parte de la comparativa hay más similitud entre los resultados de SIGMA y MIPv6, aunque en el thoughput
la superioridad de SIGMA es bastante clara.
 Calidad de la red o (network friendliness):
Análisis y Optimización del Handover en redes MobileIP
F IGURA 10 -
33
F IGURA 13 -
7.3
COMPARACIÓN DE LA CALIDAD DE LA RED CON SIGMA Y MIP
[17]
Conclusiones
Los resultados indican que para unos parámetros y configuración de red típicos, SIGMA tiene una latencia de
handover más pequeña, tiene menor tasa de pérdida de paquetes y una mayor productividad (Throughput).
Por último, se ha demostrado que SIGMA es mejor (más amigable) para la red que MIP.
Análisis y Optimización del Handover en redes MobileIP
8
EVOLUCIÓN DE LOS PROTOCOLOS QUE REALIZAN
HANDOVER (FHMIP, SIMP, FFHMIP)
34
En este apartado, se presenta un estudio de los enfoques de movilidad existentes, para la capa 3, que intentan que
el tiempo de desconexión durante el handover sea mínimo. El punto de inicio es el bien conocido protocolo de
Mobile IP especificado por la IETF. Aunque el protocolo es soportado par computadoras y dispositivos móviles
en internet, deja mucho que desear cuando se produce un handover mientras está activa una sesión de
comunicación. Mejoras como FMIP y HMIP han sido propuestas para manejar los inconvenientes de MobileIP
[20]. A parte de los esquemas que han sido estandarizados ya por la IETF, existen otros muchos esquemas
desarrollados por diversos grupos de investigación. Se expondrán a continuación una selección de los nuevos
enfoques que se destinan a que el tiempo de desconexión, en la capa 3, mientras se está realizando un handover, y
hay una sesión activa, se reduzca al mínimo.
8.1
Alcance de este informe técnico
Este documento se centra en las variantes existentes del protocolo MobileIP. El interés especial que se tiene es el
delay del handover, cómo de rápido podremos obtener la nueva dirección IP y actualizar la comunicación con los
demás equipos cuando cambiamos de punto de acceso a internet (capa 3 de movilidad).
El estudio se centrará en los protocolos de handover entre diferentes tipos de redes y se estudiará su latencia.
Los protocolos de capa superior, como el Protocolo de Inicio de Sesión (SIP) y el Protocolo de Transmisión de
Control de flujo (SCTP) se centran principalmente en la gestión de la movilidad en conexiones de extremo a
extremo y no tienen la posibilidad de lograr handover con delays cortos. La comunicación y manejo de sesiones en
estos protocolos son iniciadas y mantenidas a través de servidores. El comportamiento de estos protocolos durante
el handover es similar al de MobileIP y lo realiza sin buenos resultados cuando una sesión de comunicación está
activa durante el handover. Por el contrario, algunos esquemas de MobileIP parecen ser capaces de reducir el
delay de los handovers entre redes. Por lo tanto, este trabajo se centra en las extensiones de Mobile IP,
extensiones bajo el enfoque de conseguir retardos bajos para el handover.
8.2
Fast handover para Hierarchical Mobile IPv6 (F-HMIPV6)
En un borrador de la IETF, que espiró en Abril de 2006, Jung et al. propuso una combinación de Fast Handover
con Hierarchical Mobile IPv6 como extensión a MobileIPv6 (más tarde otros autores han propuesto una evolución
de esta revisión con FF-HMIP, que será comentado más adelante). Por una parte, como combinación tiene el
potencial de reducir los gastos generales de sobrecarga de señalización y delay relacionadas con el Binding
Update, después de que se realice el handover en la capa 3(dirigido por HMIPv6). Por otro lado, también puede
reducir las latencias relacionadas con la detección de movimiento y configuración de nuevas CoA durante el
handover en la capa 3 (dirigido por FMIPv6).
8.2.1
Visión general de F-HMIPv6
Análisis y Optimización del Handover en redes MobileIP
Los autores proponen el siguiente proceso de operación para F-HMIPv6: Cuando un MN entra en el dominio de
un nuevo MAP, primero realiza el proceso de registro, de acuerdo con HMIPv6, con el HA y MAP. Después,
cuando el MN se mueve desde un PAR (antiguo router de acceso) a un NAR (nuevo router de acceso) dentro del
dominio del MAP, seguirá el proceso de Binding Update (actualización de vínculos) de F-HMIPv6.
F IGURA 14 -
FH - HANDOVER PREDICTIVO INICIADO POR LA RED
[20]
35
Durante la realización del handover, los paquetes de datos enviados por los CNs serán tunelizados por el MAP
hacia el nuevo router de acceso (NAR) por un túnel bidireccional, es similar al proceso que se utiliza en FMIPv6.
Opcionalmente, el MAP debería empezar a redireccionar los paquetes al PAR y al NAR simultáneamente. Hay
que destacar que no se crea un túnel bidireccional entre el PAR y el NAR.
8.2.2
Funcionamiento de F-HMIPv6
Como FMIPv6, F-HMIPv6 puede soportar handovers iniciados por la propia red y por el dispositivo móvil. Es
más, los handovers pueden ser predictivos y reactivos, pero en el caso de la opción reactiva es sólo razonable
parcialmente como se podrá ver más adelante.
8.2.2.1
Handover F-HMIP predictivo iniciado por la red
En el caso del handover predictivo iniciado por la red, ya sea PAR (fuente de activación) o NAR (objetivo) recibe
una L2-trigger que les informa de que el movimiento de un MN del PAR al NAR es inminente. El procedimiento
consta de los siguientes pasos (Figura 15):
a)
El AR que recibió la señal de handover se lo indica al MAP. El mensaje de indicación incluye
PLCoA (Dirección anterior CoA) del MN y un identificador del NAR(capa de enlace o dirección IP).
Análisis y Optimización del Handover en redes MobileIP
b)
El MAP envía un mensaje de PrRtAvd al nodo móvil (MN), que contiene un anuncio de router
del NAR. Los autores establecen que el mensaje debería llevar información acerca de la próxima
dirección CoA (NLCoA) del MN, para ser usada en la región del NAR (prefijo de red para stateless autoconfiguration o NLCoA para stateful configuration). Igual que el handover predictivo en la extensión
HMIPv6, este esquema es más restrictivo desde el punto de vista de handover entre dominios diferentes,
se asume que el MAP tiene suficiente conocimiento sobre los NAR asociados con el fin de asignar la
dirección NLCoA del MN o incluso dejarla a la elección del MN. Como en el caso HMIPv6, parece que
dejar esta decisión a la NAR es lo más adecuado.
36
F IGURA 15 -
FH - HANDOVER PREDICT . INICIADO POR LA RED
[20]
d)
MAP y NAR hacen un HI-HACK (intercambio de mensajes de Handover Initiate Handover
Acknowledge) para establecer un túnel bidireccional entre ellos.
e)
MAP envía un mensaje FBACK hacia MN con la PLCoA y la NLCoA, y comienza el envío de
paquetes a PLCoA dirigidos al NAR, por el túnel establecido anteriormente. El NAR almacena los
mensajes de FBACK así como los mensajes remitidos, con el fin de entregarlos cuando el MN complete
el handover de la segunda capa (L2). El motivo de enviar el mensaje FBACK de vuelta al MN a través de
las dos direcciones NLCoA y PLCoA es porque el MN podría haber completado el handover L2 al NAR
antes de que el mensaje FBACK haya sido recibido a través del PAR (Figura 15).
Análisis y Optimización del Handover en redes MobileIP
c)
El nodo móvil NM envía un mensaje de FBU (fast binding update) al MAP. El mensaje contiene
la PLCoA y la dirección IP del nuevo router de acceso (IP NAR).
37
F IGURA 16 -
FH - HANDOVER PREDIC . INICIADO POR
MN [20]
Análisis y Optimización del Handover en redes MobileIP
f)
Cuando el MN detecta por un trigger en la capa de enlace que se ha movido al NAR, este envía
un mensaje de FNA al NAR.
38
g)
NAR envía los mensajes almacenados de FBACK al MN para el caso en el que el MN ha
permanecido sin recibirlos. NAR también comienza la transmisión de paquetes almacenados y la entrega
de los paquetes nuevos al MN.
h)
El MN envía un Local Binding Update (LBU) al MAP y recibe un Local Binding ACK (LBACK)
para informar al MAP de que ya está en el NAR.
F IGURA 17 -
[20]
Handover F-HMIP predictivo iniciado por el nodo móvil
La forma de operación para el handover predictivo iniciado por el nodo móvil, es la misma que la que se utiliza si
lo hace la red, con la única diferencia que es el MN el que recibe la información del disparador de la capa de
enlace (L2 trigger) sobre el movimiento inminente hacia el nuevo router de Acceso (NAR). Una vez que el trigger
ha saltado el MN envía un mensaje de RtSolPr al MAP para pedir información sobre el NAR. El resto de mensajes
de comunicación para la realización del handover son los mismos que los que se explicaron en el apartado
anterior.
8.2.2.3
Handover F-HMIP reactivo
La figura 18 muestra porqué el handover reactivo F-HMIPv6 (reactive F-HMIPv6) no tiene sentido. Desde que
MN se salta el envío de un mensaje de FBU mientras está todavía conectado a PAR, la creación de un túnel
bidireccional entre el MAP y el NAR no está hecha cuando el MN llega a NAR. Por lo tanto, es el mensaje Local
Binding Update el que informa al MAP de la nueva vinculación. Un túnel de establecimiento en este momento no
es necesario, ya que el MAP puede reenviar los paquetes a NCoA directamente.
Análisis y Optimización del Handover en redes MobileIP
8.2.2.2
FH - HANDOVER PREDIC . INICIADO POR MN
39
F IGURA 18 -
Análisis y Optimización del Handover en redes MobileIP
8.3
40
FH - HANDOVER REACTIVO
[20]
Mobile IP sin fisuras (S-MIP)
La opción de handover que se va a presentar en este apartado es bastante interesante, pero no ha sido
estandarizada por la IETF. En la referencia bibligráfica nº 4 podemos ver cómo Hsieh propuso un protocolo
handover sin fisuras para H-MIP (este protocolo se llamó S-MIP), que era capaz de minimizar el tiempo en el que
el MN no podía enviar ni recibir paquetes IP. S-MIP ofrece la posibilidad de reducir aún más la perturbación
durante un handover en la capa 3( L3 ), la entrega de paquetes al MN mientras todavía está conectado al PAR se
combina con un pre-registro simultaneo al NAR. El “paper” sólo sugiere el uso de un nuevo nodo llamado
“Decision Engine”, cuyo objetivo es controlar el movimiento de los nodos móviles (MN) y tomar decisiones
sobre los handovers. Sin embargo, con el fin de ser coherente con las descripciones del protocolo en las secciones
anteriores, mantenemos el estilo de utilizar los disparadores L2 para iniciar los handovers. Esto no cambia nada
sobre la especificación del handover S-MIP que se describirá a continuación.
8.3.1
Visión general de S-MIP
S_MIP puede ser considerado básicamente como una evolución de F-HMIP. Después de que se ha tomado la
decisión de realizar el handover, cada paquete que llega de un CN al MAP, se duplicará y enviará al PAR y al NAR
simultáneamente. Estos paquetes serán marcados con el bit Simulcast (S bit), como un parámetro opcional en la
cabecera IP. Mientras tanto, se crea un túnel bidireccional entre el PAR y el NAR (como se propone en FHMIPv6 entre MAP y NAR). El NAR mantiene un buffer (f-buffer), que contendrá todos los paquetes enviados
por el PAR (f-packets) y un buffer-simulcast (s-buffer) , que contendrá todos los paquetes marcados con el bit S
(s-packets). El PAR debería transmitir únicamente los paquetes al NAR, que no tienen activo el bit S. Además,
todos los paquetes (s / f packets) serán enviados en el canal inalámbrico por el PAR. Esto ofrece la posibilidad de
que el MN pueda continuar recibiendo paquetes hasta que pierda la conexión con el PAR definitivamente.
8.3.2
S - MIP HANDOVER PREDICTIVO INICIADO POR EL NODO MÓVIL
[20]
Funcionamiento de S-MIP
Como en F-HMIPv6, la señal del disparador de L2 para iniciar el handover en la capa tres puede ser recibo en el
MN o en la red. Como es habitual, la diferencia es sólo en los mensajes iniciales y en este caso sólo mostraremos
como se produce el handover cuando salta el disparador del nodo móvil.
8.3.2.1
Handover S-MIP predictivo iniciado por el nodo móvil
a)
El proceso comienza con el recibimiento en el nodo móvil (MN) de una señal disparada por la
capa 2 (L2 trigger) que indica un handover inminente hacia el nuevo router de acceso (NAR). EL MN
envía un mensaje de RtSolPr al PAR, que contiene la información de identificación del NAR.
b)
Acto seguido el PAR y el NAR hacen un HI-HACK (intercambio de mensajes de Handover
Initiate Handover Acknowledge) para establecer un túnel bidireccional entre ellos y averiguar la NLCoA
del MN.
Análisis y Optimización del Handover en redes MobileIP
F IGURA 19 -
41
c)
Luego PAR responde al MN con un mensaje de PrRtAdv informando sobre su NLCoA.
d)
Llegados a este punto el MN inicia el handover a nivel de capa de transporte (L3) enviando un
mensaje de FBU al PAR. PAR envía un mensaje “Simulcast” (Scast) al MAP, con el que indica al MAP
que active el bit S en los paquetes que tienen como destino al MN y los envíe al PAR y NAR.
e)
PAR envía un mensaje de FBACK al NLCoA y PLCoA y continúa emitiendo todos los mensajes
que provienen del MAP. Únicamente enviará los mensajes pendientes que no tienen el bit S activado, al
NAR. Estos podrían ser mensajes almacenados, o los últimos mensajes procedentes del MAP antes de
que se empezara a usar el bit S.
f)
Una vez que llega el MN al NAR envía un mensaje FNA al NAR. NAR empieza a transmitir los
f- packet del f-buffer. Cuando el buffer está vacío, el NAR envía un mensaje de “Simulcat Off” (Soff) al
MAP para que deje de enviar paquetes repetidos al NAR y al PAR a la vez. Luego NAR envía los spackets del s-buffer al MN. Mientras tanto, MAP para de poner el bit S en los paquetes que van
destinados al MN y retoma el envío normal de paquetes al router de acceso del MN.
8.4
FFHMIPv6
En esta sección vamos a presentar otro método para realizar el fast handover en redes MobileIPv6, el método se
llama Flow based Fast Handover for MIPv6, como puede extraerse de su nombre es una evolución del FMIPv6.
8.4.1
Visión general de FFHMIPv6
Análisis y Optimización del Handover en redes MobileIP
FFHMIPv6 usa las características del protocolo IPv6 y los beneficios que da este protocolo al control de tráfico.
Al utilizar el IPv6 Flow Label cada flujo de tráfico puede ser identificado y redireccionado a una nueva
localización. Esto hace posible la recepción de paquetes simultáneamente con el proceso de registro de
actualización de vínculos (Binding Update), minimizando así la demora experimentada en el handover. El método
solamente requiere algunas modificaciones en el protocolo MIPv6 existente y unos requerimientos
computacionales y de memoria menores para los puntos de acceso.
42
El método FFHMIPv6 requiere que la mayor parte de los routers que componen una red con IPv6 rellenen la
propiedad de flujo de tráfico (traffic flow property) y mantengan información de estado de los flujos de tráfico.
Un flujo de tráfico es identificado por la etiqueta de IPv6 Flow Label y las direcciones de fuente y destino. El nodo
móvil (MN), agente origen (HA) y el nodo corresponsal (CN) usan la etiqueta de Flujo, así las conexiones MNHA y MN-CN son identificadas como flujos de tráfico. Esta información de flujo es usada para controlar el tráfico
cuando un MN se mueve entre dos redes.
8.4.2
Funcionamiento de FFHMIPv6
La figura 20 es un ejemplo de los pasos que sigue FFHMIP. Cuando un MN se mueve a una nueva subred, este
recibe una nueva dirección CoA y lo registra en el HA (Paso 2 de la figura 20). Este mensaje de registro incluye
también una etiqueta de flujo (Flow label) de la conexión móvil. Usando esta etiqueta de flujo el router que se
encuentra en el punto de cruce (AR2 de la figura 20) redirección el flujo a la nueva localización del nodo móvil.
Ahora se explicarán con más precisión las funciones que tienen que realizar los nodos móviles y los routers en el
método de FFHMIPv6
F IGURA 20 -
8.4.2.1
FASES DE FFHMIPV 6
[28]
Funciones de un Nodo Móvil (MN)
El MN recibe y desensambla los paquetes encapsulados a paquetes IPv6. Las direcciones de fuente y destino del
túnel son verificadas; la dirección fuente debe ser la de HA o la de MN y la dirección del MN la dirección antigua
de CoA. De esta forma podemos tener la certeza de que los paquetes pertenecen al método FFHMIPv6.
El tunelizado del flujo de tráfico es siempre temporal y de duración constante (algunos segundos) así es que
durante esta redirección el MN ha tenido el tiempo suficiente para registrar la nueva dirección de CoA en el HA y
CNs. Por otra parte, el nodo móvil tiene la posibilidad de deshacer el túnel IPv6 creado antes y liberar la antigua
dirección CoA. Cuando el MN vuelve a ir a su red antigua, FFHMIPv6 se deshabilita para evitar los posibles bucles
de enrutamiento.
Análisis y Optimización del Handover en redes MobileIP
El método de FFHMIPv6 es usado sólo cuando la dirección CoA cambia ( figura 20, paso 1). La estructura Hopby-Hop (opción que usa IPv6), incluyendo las direcciones del HA y de los CNs y la etiqueta de Flujo, es añadida al
mensaje de Binding Update (figura 20, paso 2). El Hop-by-Hop Frame (figura 23) incluye un nuevo tipo
identificador de FFHMIPv6, donde los parámetros usados por FFHMIPv6 son determinados por los routers.
Sobre la base de esta información, el flujo de tráfico de HA a CN (figura 20, *a) es redirigido a la nueva
localización (Tunelizado) (figura 20, paso 4).
43
F IGURA 21 - PROCESO D E FFHMIP V 6 [28]
8.4.2.2
Funciones de los Routers en FFHMIPv6
Análisis y Optimización del Handover en redes MobileIP
Los flujos de tráfico pasivos tienen un tiempo de vida definido en las redes. Cuando pasa ese tiempo la
información de estado almacenada desaparece. Como puede verse en la referencia bibliográfica nº 5 el tiempo de
vida de los flujos de tráfico es de 120 segundos y después se convierten en pasivos. La información de estado del
flujo identifica el viejo CoA, y el flujo de tráfico puede ser redirigido a la nueva CoA.
44
La identificación usa el mensaje de Binding Update del Hop-by-Hop frame. Todos los routers deben ir a través de
este frame(hop-by-hop). Si el router identifica la definición de FFHMIPv6, éste maneja el frame como se indica en
la ilustración 9. Si el Flow Path (Figura 23) está definido (Flow Path = 1), FFHMIPv6 se ha hecho en la red.
Utilizando la información del Hop-Hop frame, por el flujo de tráfico, es buscado desde la información de estado
de flujos del router. Si el flujo de tráfico es encontrado, se envía un mensaje ICMP a la nueva dirección CoA del
MN, y así se conoce el otro del extremo del túnel IPv6 (esto se realiza por el roturer del punto de cruce
Ilustración 7 AR2). Después de esto, el túnel IPv6 se forma entre el router AR2 y el MN, y el flujo de tráfico es
redirigido por túnel. A continuación, el bit de Flow Path en el hop-by-hop frame se fija como activo, con lo que el
proceso de FFHMIPv6 no se tiene que realizar de nuevo. Por último, el mensaje BU es transmitido al HA y el
proceso de registro de MIPv6 continúa.
MANEJO DE HOP - BY - HOP FRAME
[28]
Los paquetes de partida para la antigua dirección CoA son encapsulados en un nuevo paquete IPv6 para la nueva
dirección de CoA. En otro caso, el tráfico debería ser redirigido a la nueva ubicación sólo después de que el
proceso de registro ha sido realizado en HA y CNs. La conexión del tunel IPv6 permanece hasta que la dirección
primaria CoA se ha registrado en HA y CNs. Después el tráfico se dirige directamente a la nueva dirección CoA
sin necesidad del tunnelling.
En la figura 21 se describe el proceso completo de FFHMIP cronológicamente.
a)
El mensaje de BU es procesado en el router AR2 (router del cruce) y el túnel IPv6 es
establecido.
b)
Luego se procede al proceso de registro en el HA con el mensaje de BU.
c)
Después de que se ha hecho el registro en los CNs. Como se puede observar (figura 18), el flujo
de tráfico es redireccionado a la nueva dirección CoA antes de que el proceso de registro se haya
terminado por completo.
8.4.2.3
Requerimientos específicos de FFHMIPv6
FFHMIPv6 requiere pocas extensiones sobre el protocolo MIPv6. Hop-by-Hop frame incluye el campo Option
Type, que es de 8 bits para identificar las propiedades que deben manejar los routers. Además el método de
Análisis y Optimización del Handover en redes MobileIP
F IGURA 22 -
45
FFHMIPv6 requiere un nuevo tipo identificador de FFHMIPv6, que se utiliza para definir los parámetros
FFHMIPv6 a los enrutadores (figura 23). Los bits definidos son los siguientes:
•
Bits 6-7: - si el router no reconoce el Hop-by-Hop- Hop type, éste procede normalmente.
•
Bit 5: 1 – el campo opción de Hop-by-Hop puede cambiar en la ruta.
•
Bit 0-4 – identificador de la función.
Análisis y Optimización del Handover en redes MobileIP
El que identifica al campo opción (Option) de Hop-by-Hop fue escogido para ser el próximo disponible en la
IANA (Internet Assigned Numbers Authority) (01011). Opción Longitud de datos (Option Data Length) se
determina por el número de conexiones móviles y de los flujos del MN. Después de la Longitud de los datos (Data
Length) FFHMIPv6 define una serie de opciones:
•
Bit 3: 1- Flow Path si está ya establecido en la red IPv6.
•
Bit 2: 1- si una alternativa CoA sigue Flow Label.
•
Bit 0-1: reservado.
F IGURA 23 -
HOP - BY - HOP FRAME CON LA OPCIÓN DE FFHMIPV 6
El HA, MN y el CN deben enviar paquetes IPv6 utilizando el mismo Flow Label, por eso el flujo de tráfico debe
ser identificado correctamente. MN debe mantener la CoA antigua después del handover, porque esta es usada
dentro del tunal IPv6. Los routers deben ser capaces de realizar un túnel IPv6 y mantener la información de
estado de los flujos de tráfico.
F IGURA 24 -
46
[28]
ELEMENTOS QUE AFECTAN AL HANDOVER
[28]
9
Actualidad sobre los dispositivos que integran
soporte para MobileIPv6
En este apartado se tratará de ir introduciendo todos los dispositivos innovadores que van saliendo al mercado y
que incorporan movilidad con MobileIPv6, así como las empresas y asociaciones que están implantando y
testeando los equipos para realizar un estándar entre ellos.
9.1
Dispositivos
IPv6 terminal prototype de Nokia
Nokia [21] y NTT Communications han desarrollado un prototipo de terminal inalámbrico que permite movilidad
olvidándose de las contraseñas de acceso a las redes. Esto se consigue usando una clave externa basada en
tecnología de identificación por radio frecuencia (RFID), y es el primer prototipo del mundo que se realizará con
Mobile IPv6, IPsec y protocolos RFID.
F IGURA 25 -
DISPOSITIVO DE NOKIA CON MOBILEIPV 6
La clave de seguridad externa se introduce mediante una etiqueta con tecnología RFID, y da un acceso fácil a la
red, simplemente tocando el terminal con la etiqueta. La clave de seguridad también tiene una clave IPsec, que
cifra el acceso a diferentes tipos de redes.
Por otra parte el uso de MobileIPv6 y Wireless Lan a la vez, permite que una llamada sea realizada en el
transcurso en el que el terminal está pasando entre diferentes redes inalámbricas, de manera que cuando el
terminal está pasando de un punto de acceso a otro la conexión puede mantenerse.
Análisis y Optimización del Handover en redes MobileIP
En el siguiente enlace podemos ver una demostración ilustrativa del uso del dispositivo:
http://www.nokia.com/NOKIA_COM_1/About_Nokia/Research/Demos/IPv6_terminal_prototype/ipv6_te
rminal3.avi.
47
9.2
9.2.1
Handover sin fisuras entre redes heterogéneas
Introducción de la investigación
En el Congreso Mundial de móviles que se realizó el mes de Febrero en Barcelona, Intel mostró su investigación
(demo) sobre la realización de un handover sin fisuras entre redes WiFi y WiMAX. Otras empresas colaboradoras
en el proyecto de investigación de Intel en lo que se refiere al handover son: Nokia I + D de Nokia y Nokia
Siemens Redes I + D.
En este esfuerzo Nokia Siemens Networks se centró en el suministro de la infraestructura de red y Servicio de
Información de la comandancia de servicios, mientras que Intel y Nokia se centró en los clientes de telefonía
móvil. Intel proporcionó de funcionalidad a la Capa 2,5, incluido los eventos de la capa de enlace, la información
del cliente y el manejo del servicio, y Nokia proporcionó la gestión de Mobilidad.
9.2.2
Demostración del handover
A continuación se mostrará una demo que ofrece un primer vistazo a una posible solución, aunque se va a
continuar con los experimentos y mejoras de la tecnología.
Análisis y Optimización del Handover en redes MobileIP
En el siguiente enlace http://www.youtube.com/watch?v=hYtGG2bTEpg podemos ver al investigador Vijay
Kesavan realizando una demo de cómo se realiza un handover entre WiFi / WiMAX . Si observamos el vídeo se
ve cómo se está realizando una video-llamada entre el investigador y otra persona.
48
F IGURA 26 -
REALIZACIÓN DE VÍDEO - LLAMADA CON HANDOVER
Las innovaciones que abarcan este pequeño grupo de dispositivos orientados al consumidor (smartphones,
dispositivos móviles, Internet, UMPCs, etc.) están permitiendo que los usuarios quieran conectarse a internet e
interactuar entre ellos en cualquier lugar. Un studio de ABI estima que el tamaño del mercado para dispositivos
móviles multimedia (con WiFi y WiMAX/3G) aumentarán de 3,4 millones de unidades en 2008 a más de 89
millones de unidades en 2012. La demanda de la ubicuidad de múltiples servicios a través de las nuevas redes de
acceso inalámbrico se puede abordar a través del handover sin fisuras, para que los consumidores no sufran
interrupciones del servicio y funcionamiento de sus aplicaciones multimedia durante sus desplazamientos.
Los pasos que tiene que seguir el dispositivo móvil para la realización del handover horizontal (dentro de un
mismo tipo de red) o vertical (a través de la red heterogénea) se pueden clasificar en tres tareas lógicas como se
muestra en la figura 26, que en orden cronológico son:
1. "cuándo y por qué" El dispositivo realiza la transición a una nueva red.
2. "donde", o a que red debería trasladarse el dispositivo.
3. "cómo" el dispositivo debería realizar el handover para trasladarse de una red a otra
manteniendo la conectividad y sin perder la sesión.
El "cuándo y por qué", se activa cuando el dispositivo móvil recibe una indicación de que un handover debería
tener lugar. El handover puede ser provocado por condiciones externas, como la degradación de la señal o la
congestión de la red, el descubrimiento de una red más adecuada, red de menor costo, mayor ancho de banda o
una mejor eficiencia energética, o ser usuario de la red a la que se va a pasar. El "dónde" pasará el dispositivo
móvil, seleccionará la nueva red para conectarse, y el "cómo" se define como la forma en que el dispositivo realiza
la transición, por ejemplo, ya sea haciendo un traspaso horizontal o vertical.
La red puede facilitar la selección de red del dispositivo móvil, proporcionando un mapa de redes que describe la
presencia y características de las redes disponibles en los alrededores del dispositivo móvil. Además la propia red
puede iniciar una petición de handover por ejemplo cuando se detecta que la carga en una de las redes de acceso
está al límite de su capacidad.
Ahora podemos visualizar el video [http://www.youtube.com/watch?v=e8gNGCGI-EI] en el que el investigador
debate sobre el proceso que lleva debajo el handover.
F IGURA 27 -
"El Cuándo y por qué" del handover.
El objetivo es proporcionar una información exacta y predictiva de la situación de las redes para que la capa de
enlace pueda tener constancia de cuando hay que hacer un handover por la inminente degradación o pérdida de la
señal inalámbrica. Un proceso de tres etapas predice con un alto nivel de precisión la calidad de la señal dónde se
realizará el traspaso. Se pueden:
1. Suavizar las características de la señal.
2. Predecir el nivel de la señal en el futuro cercano.
3. Realizar un análisis de las tendencias, centrándose en los métodos que proporcionan precisión con
cálculos generales básicos.
Para los anteriores cometidos se usa la media exponencial para suavizado de la señal, "Línea Recta" para la
predicción y la Transformada Rápida de Fourier, para el análisis de las tendencias de la ventana tanto a corto como
a largo plazo. Los resultados muestran que se predecir la degradación de la capa de enlace en Wi-Fi y WiMAX con
alrededor del 90% de precisión y proporcionar esta indicación alrededor de 800 mseg a 1 segundo antes de que la
pérdida ocurra, con lo cual se tiene un importante margen de tiempo para adoptar medidas.
Análisis y Optimización del Handover en redes MobileIP
9.2.3
VÍDEO DE EXPLICACIÓN DEL PROCESO DE HANDOVER
49
F IGURA 28 -
9.2.4
ARQUITECTURA DEL SISTEMA
[29]
"¿Hacia Dónde?" se realiza el handover
Una vez que la indicación de una inminente desconexión es recibida, la siguiente decisión será la selección de una
nueva red a la que conectarse. En el entorno inalámbrico la capacidad de descubrir las redes depende de la
proximidad de la fuente de la señal y el medio ambiente, por ejemplo, interferencias, obstáculos, etc. Los
dispositivos móviles tienden a escanear periódicamente el espacio para la "búsqueda" de redes inalámbricas, con lo
que consumen energía. Aquí es donde la información adquirida desde la red a la que se está conectado ( por
ejemplo, red información de ruta que describe y la presencia y las características de las otras redes) ayuda a
mejorar la eficiencia energética mediante el escaneo sólo sobre los interfaces en áreas geográficas específicas.
Para evaluar la mejor red de destino, hay que considerar:
• El ámbito de la red (por ejemplo, ancho de banda, el retraso, seguridad, etc.), a nivel de
plataforma (por ejemplo, carga de batería, térmica, etc.).
Análisis y Optimización del Handover en redes MobileIP
• Las preferencias del usuario (por ejemplo, costo monetario , Operador, etc.)
50
• Preferencias definidas por el operador de red / operador de red virtual que da servicio al
dispositivo móvil.
9.2.5
“Cómo” se realiza el Handover
Esta sección ya es parte de la ejecución del handover. Hay muchos métodos disponibles para la manipulación se
sesiones del handover, por ejemplo, Mobile IP (MIP), Proxy Mobile IP, el Protocolo de Inicio de Sesión (SIP),
Voice Call Continuity (VCC 3GPP). En este caso se han utilizado aplicaciones basadas en SIP A/V.
F IGURA 29 -
HANDOVER PREDICTIVO EN REDES HETEROGÉNEAS
[29]
Usando la optimización que se mencionó anteriormente, podemos ver en la figura 27 que podemos iniciar la
ruptura antes de que los dos señales inalámbricas se solapen completamente, con suficiente margen de tiempo
para que se realice el handover sin fisuras de sesiones multimedia (hay que señalar que la autenticación no se ha
tenido en cuenta aquí).
Esta implementación de Intel está basada en la especificación del borrador de IEEE 802,21 para el cliente y los
componentes de la red (Información del servidor y manejo del servidor) pero esto es sólo una opción de lograr el
objetivo del handover sin fisuras entre redes heterogéneas.
9.3 Estandarización y supervisión de productos preparados
para MobileIpv6
Una vez que realizan los tests de los productos, este grupo otorga un logo que indica que el dispositivo está
preparado para soportar ipv6. Hay que destacar que existen dos tipos de logo uno básico y otro más avanzando,
que sería el que nos interesaría en este caso, que asegura su compatibilidad con mobileIpv6.
Fase1:
Fase2:
Para ver los requerimientos necesarios en cada fase remito al lector a la siguiente dirección:
http://cf.v6pc.jp/frames.html
Análisis y Optimización del Handover en redes MobileIP
En lo que se refiere a estandarización de los dispositivos en Japón [22] hay un grupo que se dedica a ver si los
terminales que salen al mercado pasan una serie de pruebas y están preparados para soportar Ipv6. La institución
que se encarga de esto es “IPv6 Promotion Council”.
51
Una vez que los dispositivos han pasado los test se almacenan en una base de datos que puede consultarse mediante
la
siguiente
dirección:
http://cf.v6pc.jp/logo_db/approved_list.php
(fase1)
y
http://cf.v6pc.jp/logo_db/approved_list_p2.php (fase2).
Por último adjunto en la referencia bibliográfica nº 8 el whitepaper que contiene toda la información necesaria
sobre los tests realizados y la instituación.
10 OTRAS TECNOLOGÍAS QUE PODRÍAN COMPLEMENTAR
A MOBILEIP
Esta sección es creada para ir considerando diversas tecnologías que puedan complementar y facilitar el proceso en
el que MobileIP realice el handover. Básicamente iremos observando tecnologías que puedan facilitar la
autenticación en las redes, o mejorer la calidad de las mismas.
Como primer paso se va a comentar la tecnología RFID de forma básica y general, aunque en otros informes
posteriores se intentará enfocar más hacia la autenticación sobre redes wireless.
10.1 RFID
Análisis y Optimización del Handover en redes MobileIP
10.1.1
52
Introducción
En términos generales, la tecnología RFID (“Radio Frequency IDentification”) permite la identificación de objetos
de forma inalámbrica, sin necesidad de que exista entre el lector y el objeto contacto o línea de visión directa,
requisito indispensable para otras tecnologías como la lectura láser de códigos de barras. Esta identificación se
realiza mediante la incorporación o fijación de un transpondedor al objeto (“tag”), el cual transmite los datos que
contiene cuando detecta que está siendo interrogado por un lector RFID. Aunque la tecnología no es nueva, los
avances técnicos en aspectos tales como alcance, seguridad, almacenamiento o velocidad de lectura entre otros,
han suscitado el interés de la industria por ella, considerándola como el sustituto natural del código de barras dada
la importante oportunidad que RFID ofrece para conseguir una importante reducción de costes en las cadenas de
producción y logística. Grande empresas internacionales con una importante carga logística o de producción han
comenzado a implantar la tecnología o han exigido a sus proveedores que la incorporen, motivadas por las
notables mejoras que supone su introducción para sus procesos productivos. Algunos casos ampliamente
documentados son los de las empresas Wal-Mart, Metro Group, Tesco, Mark&Spencer, Departamento de
Defensa de Estados Unidos, Michelin, BMW, Volvo, Hewlett-Packard, Best-Buy o Nokia.
Sin embargo, aunque la aplicación natural de esta tecnología sea dentro de la cadena de producción y distribución,
diariamente aparecen nuevas aplicaciones y oportunidades de negocio alrededor de las distintas variantes de esta
tecnología de identificación y su combinación con otras tecnologías. Aplicaciones sobre las que se puede encontrar
una amplia bibliografía e implantaciones en distintos sectores de actividad son:
Control de acceso: peajes de carreteras, aparcamientos, acceso a edificios, acceso a
zonas restringidas.
Prepago: peajes de carreteras, transportes (autobús, metro), pago con teléfono móvil.
Identificación, localización y monitorización de personas, animales o materiales: en
combinación con sensores (temperatura, humedad), tecnología inalámbrica (wlan) o tecnología
de localización (GPS).
Autenticidad de productos (“anticounterfeiting”) o documentos.
Autenticación en Redes Wireless.
APLICACIONES DE RFID .
IBM
Son tantas las posibilidades de utilización de la tecnología RFID en todos los sectores de actividad, hoy día, que se
la considera uno de los pilares básicos de la siguiente evolución de las redes de comunicación, la cual ha recibido
varias denominaciones (“Internet of things”, “Ambient Intelligence”, “Ubiquitous Computing”) aunque todas ellas
se refieren al mismo concepto: la interacción automática e inteligente entre dispositivos en cualquier circunstancia
o ubicación, y su comunicación con sistemas remotos de datos a través de las redes de telecomunicación.
Análisis y Optimización del Handover en redes MobileIP
F IGURA 30 -
53
F IGURA 31 -
INTERNET OF THINGS " NUEVA DIMENSIÓN .
ITU(N OMURA R ESEARCH I NSTITUTE )
Análisis y Optimización del Handover en redes MobileIP
Aunque aún es necesario investigar y combinar distintas tecnologías para llegar a este nivel de conectividad
(sensores, inteligencia artificial, nanotecnología, movilidad, baterías), la aportación de la tecnología RFID es clara
y fundamental en esta visión del futuro de las comunicaciones: la introducción a bajo coste de un código
identificativo único y universal en los objetos, el cual les permita autentificarse e interactuar con otro sistemas,
tanto locales como remotos. Esta es la visión que los organismos responsables de la normalización y
estandarización de RFID a nivel mundial (EPCGlobal, Auto-ID Labs, ISO) están desarrollando e intentando
implantar en coordinación con todos los agentes involucrados (fabricantes, desarrolladores de software,
reguladores de telecomunicaciones nacionales e internacionales).
54
Todas estas expectativas han contribuido a que, inicialmente, la industria estimara un enorme y rápido
crecimiento del mercado y de la implantación de la tecnología RFID a nivel mundial. El volumen de negocio total
derivado de la introducción de RFID, incluyendo tecnologías relacionadas, desarrollo de software y servicios
especializados (consultoría, integración) es difícil de calcular, por lo que la mayoría de los análisis incluyen sólo el
derivado directamente de la introducción de las etiquetas y equipos lectores RFID en las cadenas de producción y
suministro de forma equivalente al código de barras.
F IGURA 32 -
CRECIMIENTO DEL MERCADO RFID .
IDT ECH EX
Sin embargo, a día de hoy, aunque los analistas siguen coincidiendo en mantener las previsiones de negocio de la
tecnología, los datos de actividad que muestra el mercado inducen a revisar las previsiones en el tiempo,
ampliando el periodo de implantación de la tecnología a nivel mundial, dadas las barreras intrínsecas que supone
no sólo en cuanto a precio (el código de barras no tiene coste y ya se encuentra implantado en todas las cadenas de
producción), sino también a nivel de complejidad técnica (software y hardware) y a nivel normativo y regulatorio.
10.1.2
Fundamentos de RFID
En un primer acercamiento, un sistema RFID básico se puede definir en los siguientes puntos:
•
El objetivo de la tecnología es la identificación de objetos a distancia, vía radio, sin necesidad de
contacto ni línea de visión directa.
•
Una solución básica basada en RFID se compone de un lector con una o más antenas, etiquetas
de identificación (“tags”) y un software que realice el tratamiento de la información recogida por los
lectores.
SISTEMA RFID BÁSICO
Hay que tener en cuenta que la potencia de la tecnología RFID reside tanto en su bajo coste como en la
universalidad (“serialization”) y unicidad del código identificador del tag (EPC, “Electronic Product Code”),
fundamentales para las aplicaciones de la cadena de suministro. Por tanto, la estandarización a nivel mundial tanto
del código EPC (concebido como evolución del código UPC, “Universal Product Code” de los códigos de barras)
como de los mecanismos para su asignación y para garantizar la interoperabilidad de los distintos sistemas es vital
cuando se habla de RFID. Dada su importancia, en este documento se considerarán también como partes de un
sistema RFID los elementos que componen lo que se ha denominado “EPCGlobal Network”:
•
Código EPC (EPC)
•
Middleware EPC (“Savant”)
•
ONS (“Object Name Service”)
•
EPCIS (“EPC Information Services”) En los siguientes apartados se revisarán las características
principales de la tecnología y de cada uno de estos componentes.
Análisis y Optimización del Handover en redes MobileIP
F IGURA 33 -
55
F IGURA 34 - CARACTERÍSTICAS DE LOS TANSPONDERS EN FUNCIÓN DE LA FRECUENCIA . A LLIED B USINESS I NTELLIGENCE I NC .
10.1.2.1
Frecuencias de funcionamiento
Han pasado más de cincuenta años desde el nacimiento de la tecnología RFID, pero es en estos últimos años, con
la intervención de grandes “retailers” multinacionales, fabricantes y operadores logísticos, y la consolidación de
EPCGlobal como organismo internacional de estandarización, cuando se ha producido un aumento del número de
aplicaciones que hacen uso de ella.
Análisis y Optimización del Handover en redes MobileIP
El desarrollo progresivo de las tecnologías de fabricación de circuitos integrados ha posibilitado el abaratamiento
de los costes de producción y la evolución de la tecnología hacia frecuencias de transmisión más elevadas, lo que
supone reducción de tamaño y mayor velocidad de transferencia de datos. La frecuencia de trabajo de la etiqueta y
de los lectores condiciona las características físicas de propagación del campo electromagnético y, por tanto, las de
la transmisión de los datos: tipo de acoplamiento, distancia máxima de lectura, velocidad de transmisión,
sensibilidad a los materiales. Estas características condicionan también las aplicaciones comerciales para las que se
puede utilizar la tecnología RFID, como se puede apreciar en la siguiente ilustración:
56
F IGURA 35 -
APLICACIONES DE RFID SEGÚN LA FRECUENCIA DE TRABAJO
10.1.2.2
Tipos de etiquetas
Una etiqueta o “tag” consta básicamente de un inductor (LF, HF) o antena (UHF, µW) y de un circuito integrado
de distintas características según el fabricante.
Atendiendo a las distintas características de los tags, se pueden realizar las siguientes clasificaciones:
Análisis y Optimización del Handover en redes MobileIP
La regulación internacional especifica que los equipos RFID utilicen la banda de frecuencias de uso libre ISM
(“Industrial, Scientific and Medical”) para UHF, como ocurre con otras tecnologías (WiFi, Bluetooth). Sin
embargo, éste es uno de los problemas de compatibilidad a nivel mundial de la tecnología, ya que dentro de esta
banda, para la frecuencia UHF existen distintos rangos permitidos por las diferentes entidades nacionales
reguladoras, tal y como se muestra en la imagen anterior. La unificación internacional de las frecuencias a utilizar
o el desarrollo de lectores y etiquetas “multibanda” será necesario para que la tecnología se pueda utilizar en todo
el mundo sin problemas de compatibilidad.
57
F IGURA 36 -
CLASIFICACIÓN DE TAGS RFID
En la siguiente imagen se pueden apreciar distintos diseños de tags en función de su alimentación:
Análisis y Optimización del Handover en redes MobileIP
F IGURA 37 -
58
10.1.3
10.1.3.1
DIFERENTES TIPOS DE TAGS RFID
Estado actual
Tecnología
Actualmente, el mayor desarrollo de la tecnología RFID se está llevando a cabo en UHF debido, sobre todo, a las
grandes expectativas derivadas de la trazabilidad e identificación de productos en la cadena de producción, y a que
el mercado de productos para las aplicaciones en otras bandas de frecuencia se encuentra consolidado. Los nuevos
desarrollos que se están realizando en la industria (estándares, técnicos) están encaminados a eliminar las
limitaciones de la tecnología y mejorar su uso dentro de la trazabilidad de productos:
•
El rango de lectura de una etiqueta es esencialmente dependiente del tipo de etiqueta usada. Un
diseño preciso de la antena (tamaño y forma) logrará una mayor eficiencia en la recepción, al igual que la
adecuada elección del integrado con mejor sensibilidad. En las etiquetas pasivas, los rangos de lectura son
muy amplios; las pruebas realizadas por Libera Networks con etiquetas de distintos fabricantes indican
que estos pueden variar entre 30cm y 5m. Para lograr mayores alcances será necesaria la utilización de
etiquetas activas, que poseen una alimentación propia.
•
Los alcances que se suelen indicar en las especificaciones de las etiquetas RFID son para los casos
de “tag in isolation”, en que una sola etiqueta es leída por un solo lector. Sin embargo, las situaciones
normales serán aquellas en las que múltiples etiquetas se sitúan dentro del área de interrogación de un
mismo lector, o “tag in population”. Tanto para este caso como para el caso de que varios lectores
coincidan en leer una misma etiqueta simultáneamente, los rangos de lectura de las etiquetas se ven
claramente reducidos debido a las interferencias en la transmisión. Los avances de la industria en este
aspecto se centran en el desarrollo de los mecanismos de anticolisión, como se observa en la mejora
introducida al pasar del modelo de árbol binario determinista del estándar ISO180006B al protocolo de
anticolisión probabilística Aloha ranurado que sigue el estándar EPC Class1 Gen2. Por otro lado para el
caso de múltiples lectores interfiriéndose entre sí, es suficiente con implementar una multiplexación en
frecuencia (FDMA) como la del estándar EPC Gen2, donde el lector salta entre sus posibles canales de
frecuencia de funcionamiento cada cierto tiempo o hacer uso del protocolo Listen Before to Talk (LBT)
que se implementó a partir de la norma ETSI 302-208.
•
Otro aspecto a tener muy en cuenta es la composición del objeto a etiquetar, prestando especial
atención a los de metal,donde las etiquetas se vuelven “invisibles” o en el agua, donde se ve reducido su
alcance de lectura. Para los objetos de metal, se pueden encontrar en el mercado tags donde la superficie
metálica hace de plano de masa de la antena de la etiqueta, de forma que al etiquetar el objeto aumenta el
rango de lectura. Para el resto de materiales, el uso de un envoltorio que permita la separación entre el
tag y el objeto es, en la mayoría de los casos, suficiente para recuperar gran parte del alcance y evitar la
completa desintonización de la antena, aunque implica mayor coste de producción.
•
En cuanto al mapa de memoria, hay que resaltar que aparte del identificador (“tag ID”), se están
desarrollando tags con memoria de usuario (“User Memory”), que hace posible el almacenamiento de
información adicional referente al producto dentro de la etiqueta, lo que permite la modificación de
ciertas variables relacionadas con sus características en tiempo real.
Finalmente, otras líneas de desarrollo actuales dentro de la industria buscan la integración de la tecnología con
otras tecnologías o equipos de transmisión radio, de forma que la identificación única de los ítems que ofrece
RFID permita la autentificación e interacción automática de los equipos. Así, la tecnología NFC (“Near Field
Communication”), encaminada a las transacciones de pago y al establecimiento de conexión de forma intuitiva por
parte del usuario, se basa en la tecnología RFID de HF y en los estándares de las tarjetas prepago. Por otro lado, la
integración de RFID con equipos de redes malladas (“Mesh”) y sensores permitirá la identificación unívoca
automática de cada nodo y su interacción dinámica con el resto de nodos que compongan la red.
Análisis y Optimización del Handover en redes MobileIP
•
Paralelamente, se han ido introduciendo medidas de seguridad, tanto desde el punto de vista del
empresario como del usuario final, mediante campos de passwords reservados en memoria. Los tags
UHF Gen2 incluyen los comandos LOCK, que evita la modificación del contenido de la etiqueta a partir
de su aplicación, y KILL, que deshabilita los tags volviéndolos a un estado inactivo permanente, evitando
que puedan volver a ser detectados una vez que los objetos a los que acompañan hayan sido adquiridos
por el consumidor.
59
Análisis y Optimización del Handover en redes MobileIP
F IGURA 38 -
60
EVOLUCIÓN DE LA TARJETAS RFID
[27]
11
Suites de simulación
Una vez llegados al punto del proceso de investigación en el que se ha conseguido una familiarización con la
tecnología y protocolos de MobileIPv6, se está en el punto que es necesario poner en práctica los conocimientos
mediante la simulación de posibles escenarios y variaciones de los protocolos originales.
En esta sección se pasará a ver cuáles son las ventajas e inconvenientes de los principales programas de simulación
que se han encontrado en el mercado como son: Network Simulator, OMNET y OPNET.
11.1 Network Simulator
Sin ninguna duda la principal ventaja que se puede encontrar en este simulador es que es de libre distribución y
que ya se está familiarizado con su programación de escenarios en fichero tcl ( fue usado en la asignatura de
Redes). En su contra se puede destacar la falta de soporte técnico, y que no soporta ningún protocolo de
movilidad en su versión base, si se quiere utilizar para este cometido es necesario instalar nuevos módulos al
programa base.
En el siguiente esquema se puede ver las principales extensiones de ns-2 referentes a tecnología MobileIP:
CMU Monarch Group’s extensions de
mobilidad y Wireless para NS
Mobiwan
Noah routing agent y mejora de HO, es
implementado por Joerg Widmer
Extensión de
FHMIP
realizada por
Hsieh.
CIMS
Ahora se pasará a explicar en qué consisten cada una de las extensiones:
Análisis y Optimización del Handover en redes MobileIP
Sun Microsystems => Mobins2,
extensión que implementa MIP
61
•
CMU Monarch's \Wireless and Mobility Extensions to ns2: fue la primera extensión
realizada para ns-2 en lo concerniente a movilidad wireless, se desarrolló en 1998, daba funcionalidad a
los nodos para moverse por el escenario con una velocidad y posición determinadas, era muy básico.
Actualmente está obsoleto.
•
SUN Microsystems con Mobins2: esta es la primera extensión de ns-2 que soporta el
protocolo de Mobile IP (MIP), sólo implementa el handover básico.
•
NOAH: es un agente de ruta wireless que únicamente soporta comunicación directa entre BSs y
los nodos móviles. Por otra parte mejora la implementación básica de MobileIP proporcionada por SUN.
Este módulo será de gran utilidad a los siguientes que se comentarán, y que ya realizan la implementación
de protocolos MobileIP más evolucionados.
•
Extensión que implementa FMIP: esta extensión soporta los protocolos MIP, HMIP y la
combinación de MIP+FMIP y HMIP+FMIP. Esta extensión está basada en la implementación
proporcionada por el proyecto de NOAH.
•
Mobiwan: este fue un proyecto que quería estudiar la movilidad de nodos en redes de área
extensa y sobre IPv6. Los resultados del proyecto fueron la implementación de los protocolos MIPv6 y
HMIPv6.
•
CIMS: esta extensión realiza la implementación de la micromovilidad en el protocolo HMIP. Se
necesita el módulo MIP (de SUN) y la implementación del agente de ruta de NOAH.
Por la gran cantidad de módulos y por la falta de robustez del sistema de simulación que conseguiríamos, esta
opción se desechará en un principio si no se encuentra nada con mejores garantías.
Análisis y Optimización del Handover en redes MobileIP
11.2 OMNET++
62
OMNET++ es un entorno de simulación de eventos discretos, modular, orientado a objetos y de código abierto.
Los módulos son programados en C++, y se ensamblan en componentes más grandes y modelos, usando un
lenguaje de alto nivel (NED), lo que permite la reusabilidad de dichos módulos. Cuenta con una interfaz gráfica de
usuario muy potente y su principal área de aplicación es la simulación de redes de comunicaciones, aunque
también es usado para otro tipo de simulaciones de sistemas de IP, arquitecturas hardware y procesos de negocio.
Omnet++ se ha convertido en una herramienta muy popular entre la comunidad científica y también en la
industria, y han sido publicados modelos de simulación en el ámbito de internet como IP, IPv6, MPLS, protocolos
de movilidad …
OMNET++ es gratis para uso académico y sin ánimo de lucro, pero para su uso comercial es necesario obtener
una licencia.
Para las necesidades de simulación de este proyecto, OMNET++ dispone del modelo de simulación IPv6Suite,
que permite simular los protocolos y redes IPv6. Como punto negativo hay que destacar que únicamente
implementa, en lo que se refiere a protocolos MobileIP, HMIP y se quedaría algo corto para las pretensiones de
simulación de nuestro proyecto. También hay que decir que este proyecto ha quedado parado y se ha pasado a
desarrollar INETFrameWork que sólo incluye MobileIPv6.
11.3 OPNET
OPNET [23] es quizás algo más que un lenguaje de programación orientado a las comunicaciones. Proporciona
acceso directo al código fuente siendo esto una gran ventaja para los nuevos programadores que se aventuren a
programar con OPNET. Actualmente es utilizado por grandes empresas de telecomunicaciones.
OPNET dispone de un modelo de IPv6 [24] que incluye muchas características importantes para nuestras
investigaciones como:
• Direccionamiento expandido.
• Implementaciónde doble pila, IPv4 e IPv6.
• Protocolos de routing IPv6: RIPng, OSFv3, y enrutamiento estático.
• Mobile IPv6.
• Túneles IPv6.
• ICMPv6.
• Neighbour discovery.
• Autoconfiguración de direcciones IP stateless.
Además de lo comentado anteriormente dispone de una suite (Modeler Wireless) dedicada expresamente a la
simulación en escenarios con movilidad, y entre otros protocolos da soporte a tecnologías tan punteras como el
WIMAX.
El único gran inconveniente de esta aplicación es que es de pago y sólo se podría conseguir mediante la realización
de un convenio de investigación entre la UNEX y OPNET.
Simulaciones Realizadas
12.1 Elección del simulador
Después de valorar las opciones de más peso que hay en el mercado, en lo referente a simuladores con soporte de
MobileIPv6, se llegó a la conclusión de que el más idóneo era OPNET por ser el que más garantías y funcionalidad
podía ofrecernos. El problema que se tenía para usar OPNET era su licencia de pago, por lo que se intentó la
realización de un convenio entre la Universidad de Extremadura y OPNET para la adquisición de licencias para
usos académicos y de investigación. Para llevar a cabo el convenio se siguió un proceso de varias semanas de
contactos con la empresa para proporcionarles la información y datos del proyecto de investigación que haría uso
de las aplicaciones de la compañía, en concreto:
•
•
•
•
Modeler Wireless Suite 14.5 for Windows.
Modeler 14.5 for Windows.
IPv6 module for Windows.
3D Network Visualizer 2.1.0
Desafortunadamente no fue posible la concesión de licencias puesto que OPNET pensó que su uso para el apoyo
de becas de CISCO Systems podría tener un uso comercial, en vez de méramente académico y de investigación.
Debido a los sucesos anteriormente expuestos se optó por el uso del software de OMNET++, con el módulo de
ampliación IPv6SuiteWithINET. Más concretamente hemos utilizado la versión 3.3 de OMNeT++ y el CVS
20060809 de la IPv6SuiteWithINET, las últimas disponibles, para la realización de todas las pruebas y
Análisis y Optimización del Handover en redes MobileIP
12
63
simulaciones. La elección de OMNeT++ se ha llevado a cabo por tratarse de un simulador de código abierto y
gratuito, que en principio da soporte a MobileIPv6 y a HMIPv6.
Una vez decidido el simulador a utilizar el siguiente paso será el proceso de instalación, que vamos a explicar en el
siguiente apartado, después tendremos que hacer un proceso de investigación y aprendizaje del software para
comprender su funcionamiento y conseguir las estadísticas necesarias para la comparación de las diferentes
simulaciones.
12.2 Instalación del simulador
A Priori el proceso de instalación parece sencillo como podemos ver a continuación en las indicaciones básicas
ofrecidas por el proveedor:
En primer lugar instalamos OMNeT++ 3.3 siguiendo las instrucciones que encontramos en el fichero
doc/readme.unix dentro de la distribución omnetpp-3.3-src.gz que podemos descargar del sitio Web de
OMNeT++ [25]. Los pasos a seguir son los siguientes:
1. Copiamos el archivo al directorio donde queremos instalarlo y lo extraemos mediante el siguiente comando:
tar zxvf omnetpp.tgz
2. Con el comando anterior se habrá creado un directorio llamado omnetpp-3.3 Añadimos al fichero .bashrc las
siguientes líneas:
export PATH=$PATH:~/omnetpp-3.3/bin
export LD_LIBRARY_PATH=~/omnetpp-3.3/lib
Reiniciamos la consola para que se realicen las órdenes anteriores.
Análisis y Optimización del Handover en redes MobileIP
3. Chequeamos el fichero configure.user para asegurarnos que contiene la configuración que queremos.
4. Por último seguimos el método habitual de compilación en Linux:
./configure
Revisamos que la salida del configure sea correcta, si no lo es posiblemente sea porque falta alguna librería que
deberemos instalar y si lo es:
Make
5. Para chequear la instalación ejecutamos los siguientes comandos:
cd ~/omnetpp/samples/dyna
./dyna
Una vez hayamos comprobado que OMNeT++ está correctamente instalado procederemos a la instalación de la
IPv6SuiteWithINET-20060809. Para ello seguimos los siguientes pasos:
1. Descargamos el fichero IPv6SuiteWithINET-20060809.tar.bz2 de la Web de descarga del sitio Web de la
IPv6Suite [26].
2. Descomprimimos el fichero anterior en el directorio que queramos con los siguientes comandos:
64
bzip2 IPv6SuiteWithINET-20060809.tar.bz2
tar –xvf IPv6SuiteWithINET-20060809.tar
3. Nos aseguramos de tener instaladas las siguientes librerías y programas, sino los tenemos los instalamos:
• cmake
• ruby
• libboost-dev
• libboost-signals-dev
4. Ejecutamos los siguientes comandos para regenerar el fichero CMakeLists.txt dentro del directorio
IPv6SuiteWithINET-20060809:
cd /[directorio_instalación]/IPv6SuiteWithINET-20060809
ruby Etc/scripts/CMakeListGen.rb . INET
5. Sin salirnos de este directorio ejecutamos cmake de la siguiente forma:
cmake .
6. Finalmente compilamos la instalación con el siguiente comando:
make
7. Para comprobar que se ha instalado correctamente seguimos los siguientes pasos:
• Se crea un script ejecutable con el nombre MIPv6Network ensiguiente carpeta:
IPv6SuiteWithINET-20060809/Examples/IPv6/MIPv6Network
../../../tkINET $*
• Lanzar el script que hemos creado, de esta forma se iniciará la simulación del ejemplo MIPv6Network. Si la
simulación arranca y se ejecuta correctamente es porque la instalación fue correcta.
En el equipo elegido para la simulación, que constaba de un ordenador portátil Macbook, con sistema operativo
Ubuntu 8.04, ha sido imposible instalar la extensión IPv6Suite, por problemas con la versión que llevaba Ubuntu
del compilador gcc 4.2.3 y g++ 4.2.3. Parece ser que la implementación en C++ de IPv6Suite no seguía los
estándares ISO actuales de C++ y no se podía llevar a cabo la compilación del programa en el proceso de
instalación.
Como solución se optó por virtualizar el sistema operativo Debían (kernel 2.4.27) con el programa VirtualBox,
de esta manera teníamos una versión antigua de gcc, en concreto la versión 3.3.5 y se pudo llevar a cabo la
instalación con éxito.
Análisis y Optimización del Handover en redes MobileIP
El contenido del script será el siguiente:
65
12.3 Introducción a las simulaciones
Como IPv6Suite da soporte a MobileIPv6 y a HMIPv6, el objetivo que tendrán nuestras simulaciones es comparar
ambos protocolos y buscar lo que hace a HMIPv6 mejor que el simple MobileIPv6.
Como podemos ver en los estudios realizados sobre HMIPv6, el protocolo no afecta a Mobile IP como tal, toma
como inamovibles las latencias que introduce Mobile IP. En otras palabras, un nodo móvil va a seguir realizando
todas las operaciones como son especificadas en el estándar. Estas operaciones van a introducir un overhead
adicional de señalización en diversos escenarios. Por esta razón nace Hierarchical Mobile IPv6 (HMIPv6), que fue
diseñado para evitar este overhead. Además el protocolo puede ser útil en cuestiones de privacidad en términos de
direcciones IP ya que con este método la dirección CoA no es mostrada al CN. Por lo tanto, Mobile IP jerárquico
es una extensión que se propone sobre MIPv6 para mejorar los handover dentro de un dominio (micromovilidad). Para esto lo que se propone es la introducción de un nuevo elemento denominado Mobility Anchor
Point (MAP).
Si queremos comprender porque se escogen los siguientes puntos como aspectos centrales en las comparativas de
las simulaciones sería conveniente releer el punto 5.2 Hierarchical Mobile IP v6 del presente documento.
Por lo tanto en las simulaciones nos tendremos que fijar en los siguientes aspectos:
Tiempo de handover para los diferentes protocolos y redes.
Número de mensajes emitidos en el escenario, para ver si es realmente una ventaja de HMIPv6
sobre MIPv6.
Y aspectos básicos sobre los paquetes perdidos y RRT de éstos.
Análisis y Optimización del Handover en redes MobileIP
12.4 Escenario 1
66
Como puede verse en la figura 38, este escenario está formado por 3 routers, uno de ellos funcionando como
agente origen (ha), otro como Map (en la versión de MIPv6 será un router), cinco puntos de acceso inalámbricos,
un nodo móvil representado por un portátil (client1) y un nodo corresponsal (server). Los routers están
conectados todos entre sí mediante un “internetCable” que representa a una conexión a través de Internet. Los
puntos de acceso inalámbricos (ap1...ap4) y el nodo corresponsal (server) están conectados a los routers a través
de un “intranetCable” que representa una conexión a través de una red local.
F IGURA 39 -
ESCENARIO
1
La simulación consiste en lo siguiente:
A partir del tiempo configurado en Hmipv6Network.client1.pingApp.startTime desde el comienzo de la
simulación, el nodo móvil comienza a enviar pings al nodo corresponsal con la cadencia configurada en la variable
Hmipv6Network.client1.pingApp.interval
y
no
parará
hasta
el
tiempo
indicado
en
Hmipv6Network.client1.pingApp.stopTime, que siempre será mayor que el tiempo de simulación. Conforme el
nodo móvil se va alejando del ap1 y acercándose al ap2, la potencia de la señal que recibe del ap1 va disminuyendo
y aumentando la que recibe del ap2. Cuando la señal que recibe de su actual punto de acceso (ap1) es de menor
potencia que el umbral configurado en networkInterface.hoThresholdPower el nodo móvil busca un nuevo punto
de acceso al que conectarse. Y de entre todos los disponibles se conecta al que reciba su señal con mayor potencia,
configura su dirección de auxilio y registra esta nueva ligadura con su agente origen. Si la opción
routeOptimisation está activada en el fichero de configuración XML el nodo móvil también registra su ligadura
con su nodo corresponsal (sólo se ha usado la optimización de ruta para la simulación MIPv6). De esta forma
podemos ver que el nodo móvil realizará 4 handovers a lo largo de su recorrido por el escenario.
Para concluir con esta introducción al escenario, diremos que únicamente se cuenta con un MAP de un nivel, esto
a priori no mostrará mucha mejora de HMIPv6 frente MIPv6.
La simulación de MIPv6 será idéntica al escenario anterior sólo que el router MAP no tendrá función de MAP ,
sino que será un router corriente.
Análisis y Optimización del Handover en redes MobileIP
Al comenzar la simulación el nodo móvil se conecta al punto de acceso que tiene más cerca, el Hap, y a través de
él al router que actúa como su agente origen. Registra con éste su dirección origen (HoA), pero aún no configura
una dirección de auxilio (CoA), pues no la necesita dentro de su red origen. El nodo móvil continúa moviéndose
hacia los puntos configurados en el fichero XML, siempre en línea recta, con una velocidad uniforme y
configurable también en el fichero XML. El movimiento que hará el cliente es simplemente pasar en línea recta
paralelamente a la línea que forman los puntos de acceso en el escenario.
67
12.4.1
Resultados simulación 1
Los resultados mostrados a continuación para HMIP son todos sin optimización de ruta, puesto que esto
interferiría con la función que tiene el MAP en nuestros escenarios. Por otra parte en la simulación de MIP se
darán los resultados con la Optimización de Ruta activa y sin ella para así solucionar los problemas de
encaminamiento en triángulo que podrían aparecer.
1.
La siguiente figura muestra los diferentes tiempos de duración del handover en la capa L3, sólo se darán
los datos para MIPv6 ya que HMIPv6 no tiene disponible estos datos en el simulador de OMNET++:
F IGURA 40 -
ESCENARIO
1
HANDOVER MIPV 6
Análisis y Optimización del Handover en redes MobileIP
Tiempos de handover L3 con Optimización de ruta:
68
2,18 + 2,35 + 1,65 + 2,45 = 8,63 / 4 = 2,15 s.
Tiempos de handover L3 sin Optimización de ruta:
2,18 + 1,87 + 2,24 + 2,4 = 8,69 / 4 = 2,17 s.
2.
Para poder hacernos una idea de los tiempos de handover se usará la variable que indica los tiempo de
desconexión total (ninguna capa conectada a la red) que hay en el cliente1, de esta manera podremos comparar los
tiempos de handover de la simulación HMIPv6 y MIPv6:
Tiempo total de desconexión HMIPv6:
scalar "hmipv6SimpleNet.client1.linkLayers[0].networkInterface"
"totalDisconnectedTime"
2.26107886763 (s)
"totalDisconnectedTime"
2.2597496349 (s)
Tiempo total de desconexión MIPv6 sin RO:
scalar "mipv6SimpleNet.client1.linkLayers[0].networkInterface"
Tiempo total de desconexión MIPv6 con RO:
scalar "mipv6SimpleNet.client1.linkLayers[0].networkInterface"
"totalDisconnectedTime"
2.25527169581 (s)
Como puede verse en los tiempos anteriores HMIPv6 no mejora a ninguno de los tipos de MIPv6, aunque hay que
destacar que este no el cometido de HMIPv6, sino que su cometido es intentar un menor tráfico de información
referente a los handovers, que sature la red.
3.
Estadísticas de Ping obtenidas:
-------------------------------------------------------hmipv6SimpleNet.client1.pingApp
-------------------------------------------------------sent: 4200
drop rate (%): 3.83333
round-trip min/avg/max (ms): 400.461/581.47/1002.25
stddev (ms): 104.719
variance:0.0109661
--------------------------------------------------------
-------------------------------------------------------mipv6SimpleNet.client1.pingApp con Ro=off
-------------------------------------------------------sent: 4200
drop rate (%): 5.90476
round-trip min/avg/max (ms): 400.46/580.075/1002.22
stddev (ms): 105.444
variance:0.0111184
-------------------------------------------------------mipv6SimpleNet.client1.pingApp con RO=on
-------------------------------------------------------sent: 4200
drop rate (%): 5.47619
round-trip min/avg/max (ms): 240.529/284.428/1002.22
stddev (ms): 76.7064
variance:0.00588387
--------------------------------------------------------
A continuación mostraremos las gráficas referente a los tiempos de RTT de cada ping, y los pings perdidos:
Análisis y Optimización del Handover en redes MobileIP
--------------------------------------------------------
69
Análisis y Optimización del Handover en redes MobileIP
F IGURA 41 -
70
ESCENARIO
F IGURA 42 -
4.
1
ESCENARIO
COMPARACIÓN RTT
1
PINGS PERDIDOS
Total de mensajes emitidos:
Con estos datos se intentará mostrar si realmente HMIPv6 reduce la cantidad de mensajes referentes al Binding
Update, y así contribuir a desaturar la red.
Total de mensajes en HMIPv6:
scalar "hmipv6SimpleNet.worldProcessor" "totalMessageCount"
658816
Total de mensajes en MIPv6 sin RO:
scalar "mipv6SimpleNet.worldProcessor"
Total de mensajes en MIPv6 con RO:
"totalMessageCount"
628065
scalar "mipv6SimpleNet.worldProcessor" "totalMessageCount"
12.4.2
-
626990
Análisis de los resultados de la simulación 1
Escenarios que usan MIPv6:
En este caso la optimización de ruta no ha tenido mucho impacto en el tiempo de Handover en la capa
3(normalmente lo aumenta). Esto es debido al tiempo que se gasta en realizar el procedimiento de retorno de
direccionabilidad y el registro corresponsal. Por otra parte los pings perdidos siguen muy parejos 5,4% para RO y
5,9% para la simulación sin RO.
En lo referente al RTT tenemos que el tiempo medio para MIPv6 con RO=off es de 580.075 ms, mientras que
para MIPv6 con RO=on es de 284.428 ms, por lo tanto podemos decir que la gran mejoría que nos otorga el
Route Optimitation es el tiempo medio de RTT de los pings mandados.
-
Comparación MIPv6 con HMIPv6:
Ahora si comparamos los resultados obtenidos con MIPv6 con los de HMIPv6, podemos ver que en lo referente al
tiempo total de desconexión que tiene el nodo móvil (ninguna de la capas conectadas a la red) no hay ninguna
mejoría de HMIPv6 (2.26107886763 s) respecto a MIPv6 (2,25 s), aunque también debemos decir que esto no es
una prioridad en la implementación de HMIPv6.
Por otra parte vamos a ver los resultados que conciernen a la cantidad de mensajes usados en el escenario. Aquí si
tendríamos que distinguir una mejoría de HMIP sobre MIP, pero como podemos ver en los resultados:
Total de mensajes en HMIPv6:
scalar "hmipv6SimpleNet.worldProcessor" "totalMessageCount"
658816
scalar "mipv6SimpleNet.worldProcessor"
"totalMessageCount"
628065
"totalMessageCount"
626990
Total de mensajes en MIPv6 con RO:
scalar "mipv6SimpleNet.worldProcessor"
No hay mejora de HMIPv6, sino que envía unos 3000 mensajes más con lo que no libera a la red de una posible
saturación.
Por último y ya viendo los resultados de las gráficas referentes al RTT y los pings perdidos, podemos decir que
aquí HMIPv6 tiene una mejora aceptable sobre MIPv6, ya que pasa de una tasa de 5,9% de pings perdidos a 3,8%
(HMIPv6).
Análisis y Optimización del Handover en redes MobileIP
Total de mensajes en MIPv6 sin RO:
71
12.5 Escenario 2
Como puede verse en la figura 42, este escenario está formado por 7 routers, uno de ellos funcionando como
agente origen (ha) y otros dos como Map (en la versión de MIPv6 serán routers), cinco puntos de acceso
inalámbricos, un nodo móvil representado por una pda (client1) y un nodo corresponsal (server). Los routers
están conectados todos entre sí mediante un “internetCable” que representa a una conexión a través de Internet.
Los puntos de acceso inalámbricos (hap...apc) y el nodo corresponsal (server) están conectados a los routers a
través de un “intranetCable” que representa una conexión a través de una red local.
Análisis y Optimización del Handover en redes MobileIP
F IGURA 43 -
72
ESCENARIO
2
La simulación consiste en lo siguiente:
Al comenzar la simulación el nodo móvil se conecta al punto de acceso que tiene más cerca, el hap, y a través de él
al router que actúa como su agente origen. Registra con éste su dirección origen (HoA), pero aún no configura
una dirección de auxilio (CoA), pues no la necesita dentro de su red origen. El nodo móvil continúa moviéndose
hacia los puntos configurados en el fichero XML, siempre en línea recta, con una velocidad uniforme y
configurable también en el fichero XML. El movimiento que hará el cliente es simplemente pasar en línea recta
paralelamente a la línea que forman los puntos de acceso en el escenario.
A partir del tiempo configurado en Hmipv6Network.client1.pingApp.startTime desde el comienzo de la
simulación, el nodo móvil comienza a enviar pings al nodo corresponsal con la cadencia configurada en la variable
Hmipv6Network.client1.pingApp.interval
y
no
parará
hasta
el
tiempo
indicado
en
Hmipv6Network.client1.pingApp.stopTime, que siempre será mayor que el tiempo de simulación. Conforme el
nodo móvil se va alejando del ap1 y acercándose al ap2, la potencia de la señal que recibe del ap1 va disminuyendo
y aumentando la que recibe del ap2. Cuando la señal que recibe de su actual punto de acceso (ap1) es de menor
potencia que el umbral configurado en networkInterface.hoThresholdPower el nodo móvil busca un nuevo punto
de acceso al que conectarse. Y de entre todos los disponibles se conecta al que reciba su señal con mayor potencia,
configura su dirección de auxilio y registra esta nueva ligadura con su agente origen. Si la opción
routeOptimisation está activada en el fichero de configuración XML el nodo móvil también registra su ligadura
con su nodo corresponsal (sólo se ha usado la optimización de ruta para la simulación MIPv6). De esta forma
podemos ver que el nodo móvil realizará 4 handovers a lo largo de su recorrido por el escenario.
Para concluir con esta introducción al escenario, diremos que este escenario cuenta con dos routers con la función
de MAP y dos niveles en su jerarquía.
La simulación de MIPv6 será idéntica al escenario anterior sólo que los routers MAP no tendrán función de MAP ,
sino que serán routers corrientes.
12.5.1
Resultados simulación 2
Los resultados mostrados a continuación para HMIP son todos sin optimización de ruta, puesto que esto
interferiría con la función que tiene el MAP en nuestros escenarios. Por otra parte en la simulación de MIP se
darán los resultados con la Optimización de Ruta activa y sin ella para así solucionar los problemas de
encaminamiento en triángulo que podrían aparecer.
F IGURA 44 -
ESCENARIO
2
Tiempos de handover L3 con Optimización de ruta:
2 + 1,93 + 2,3 + 1,57 = 7,8 / 4 = 1,95 s.
Tiempos de handover L3 sin Optimización de ruta:
2 + 2,04 + 1,64 + 1,73 = 7,41 / 4 = 1,85 s.
HANDOVER MIPV 6
Análisis y Optimización del Handover en redes MobileIP
1.
La siguiente figura muestra los diferentes tiempos de duración del handover en la capa L3, sólo se darán
los datos para MIPv6 ya que HMIPv6 no tiene disponible estos datos en el simulador de OMNET++:
73
2.
Para poder hacernos una idea de lo tiempos de handover se usará la variable que indica los tiempos de
desconexión total que hay en el cliente1, de esta manera podremos comparar los tiempos de handover de la
simulación HMIPv6 y MIPv6:
Tiempo total de desconexión HMIPv6:
scalar "hmipv6Draft3.client1.linkLayers[0].networkInterface"
"totalDisconnectedTime"
1.38045706633 (s)
"totalDisconnectedTime"
2.3707206279 (s)
"totalDisconnectedTime"
2.45764573399 (s)
Tiempo total de desconexión MIPv6 sin RO:
scalar "mipv6Draft3.client1.linkLayers[0].networkInterface"
Tiempo total de desconexión MIPv6 con RO:
scalar "mipv6Draft3.client1.linkLayers[0].networkInterface"
Como puede verse en los tiempos anteriores HMIPv6 ha mejorado considerablemente los tiempos de desconexión
total respecto MIPv6.
3.
Estadísticas de Ping obtenidas:
-------------------------------------------------------hmipv6Draft3.client1.pingApp
-------------------------------------------------------sent: 3960
drop rate (%): 10.7576
round-trip min/avg/max (ms): 60.4967/87.5997/161.223
stddev (ms): 15.0292
variance:0.000225878
Análisis y Optimización del Handover en redes MobileIP
--------------------------------------------------------
74
-------------------------------------------------------mipv6Draft3.client1.pingApp con RO=off
-------------------------------------------------------sent: 3960
drop rate (%): 8.00505
round-trip min/avg/max (ms): 60.4768/122.337/199.224
stddev (ms): 28.2478
variance:0.000797939
--------------------------------------------------------------------------------------------------------------mipv6Draft3.client1.pingApp con
RO=on
-------------------------------------------------------sent: 3960
drop rate (%): 10.101
round-trip min/avg/max (ms): 60.4768/87.8421/224.514
stddev (ms): 15.3773
variance:0.000236462
--------------------------------------------------------
A continuación mostraremos las gráficas referentes a los tiempos de RTT de cada ping enviado, y los pings
perdidos:
ESCENARIO 2 COMPARACIÓN RTT
F IGURA 46 -
4.
ESCENARIO
2
PINGS PERDIDOS
Total de mensajes emitidos:
Con estos datos se intentará mostrar si realmente HMIPv6 reduce la cantidad de mensajes referentes al
Binding Update, y así contribuir a desaturar la red.
Análisis y Optimización del Handover en redes MobileIP
F IGURA 45 -
75
Total de mensajes en HMIPv6:
scalar "hmipv6Draft3.worldProcessor" "totalMessageCount"
508817
Total de mensajes en MIPv6 sin RO:
scalar "mipv6SimpleNet.worldProcessor"
"totalMessageCount"
628065
Total de mensajes en MIPv6 con RO:
scalar "mipv6Draft3.worldProcessor" "totalMessageCount"
12.5.2
-
550044
Análisis de los resultados de la simulación 2
Análisis de los escenarios con MIPv6:
Como puede verse la optimización de ruta aumenta ligeramente el tiempo de handover L3, de 1.85 s a 1,95 s.
Esto es debido al tiempo que se gasta en realizar el procedimiento de retorno de direccionabilidad y el registro
corresponsal. Y debido a este aumento del tiempo de handover también se produce un ligero aumento de las pings
perdidos, que pasa de un 8,0% a un 10.1%. Sin embargo se obtiene una gran mejoría en el tiempo medio de ida y
vuelta de los pings, que pasa de 122.337 ms a 87,8 ms, por lo que la optimización de ruta es imprescindible en
Mobile IPv6, y debe ser utilizada siempre que sea posible, esto es, siempre que el nodo corresponsal soporte
Mobile IPv6.
-
Comparación de los escenarios de HMIPv6 y MIPv6:
Análisis y Optimización del Handover en redes MobileIP
Ahora si comparamos los resultados obtenidos con MIPv6 con los de HMIPv6 podemos ver que en lo referente al
tiempo total de desconexión que tiene el nodo móvil (ninguna de la capas conectadas a la red) hay una mejoría de
HMIPv6 (1.38045706633 s) respecto a MIPv6 (2.3707206279 s), aunque también debemos decir que esto no es
una prioridad en la implementación de HMIPv6.
76
Por otra parte vamos a ver los resultados que conciernen a la cantidad de mensajes usados en el escenario. Aquí si
tendríamos que ver una mejoría de HMIP sobre MIP, como podemos ver en los resultados:
Total de mensajes en HMIPv6:
scalar "hmipv6Draft3.worldProcessor" "totalMessageCount"
508817
Total de mensajes en MIPv6 sin RO:
scalar "mipv6SimpleNet.worldProcessor"
"totalMessageCount"
628065
Total de mensajes en MIPv6 con RO:
scalar "mipv6Draft3.worldProcessor" "totalMessageCount"
550044
Hay una mejoría en número de mensajes, en torno a los 5000, esto es bastante bueno y así podemos ver una de las
grandes cualidades HMIPv6, esta mejoría se puede deber al aumento a dos de los niveles jerárquicos de la
simulación.
Por último y ya viendo los resultados de las gráficas referentes al RTT y los pings perdidos, podemos decir que
aquí HMIPv6 no tiene una mejoría aceptable sobre MIPv6, ya que HMIPv6 tiene una tasa de 10.7576% y MIPv6
del 10.1%. Esta diferencia no es muy reseñable.
12.6 Escenario 3
F IGURA 47 -
ESCENARIO
3
La simulación consiste en lo siguiente:
Al comenzar la simulación el nodo móvil se conecta al punto de acceso que tiene más cerca, el hap, y a través de él
al router que actúa como su agente origen. Registra con éste su dirección origen (HoA), pero aún no configura
una dirección de auxilio (CoA), pues no la necesita dentro de su red origen. El nodo móvil continúa moviéndose
hacia los puntos configurados en el fichero XML, lo hará en forma de onda cuadrada subiendo y bajando, y así se
irá moviendo cerca de todos los puntos de acceso del escenario.
A partir del tiempo configurado en Hmipv6Network.client1.pingApp.startTime desde el comienzo de la
simulación, el nodo móvil comienza a enviar pings al nodo corresponsal con la cadencia configurada en la variable
Hmipv6Network.client1.pingApp.interval
y
no
parará
hasta
el
tiempo
indicado
en
Hmipv6Network.client1.pingApp.stopTime, que siempre será mayor que el tiempo de simulación. Conforme el
Análisis y Optimización del Handover en redes MobileIP
Como puede verse en la figura 46, este escenario está formado por 4 routers, uno de ellos funcionando como
agente origen (ha) y otro es un Map (en la versión de MIPv6 serán routers), también tenemos nueve puntos de
acceso inalámbricos, un nodo móvil representado por una portátil (client1) y un nodo corresponsal (server). Los
routers están conectados todos entre sí mediante un “internetCable” que representa a una conexión a través de
Internet. Los puntos de acceso inalámbricos (hap...apd) y el nodo corresponsal (server) están conectados a los
routers a través de un “intranetCable” que representa una conexión a través de una red local.
77
nodo móvil se va alejando del ap1 y acercándose al ap2, la potencia de la señal que recibe del ap1 va disminuyendo
y aumentando la que recibe del ap2. Cuando la señal que recibe de su actual punto de acceso (ap1) es de menor
potencia que el umbral configurado en networkInterface.hoThresholdPower el nodo móvil busca un nuevo punto
de acceso al que conectarse. Y de entre todos los disponibles se conecta al que reciba su señal con mayor potencia,
configura su dirección de auxilio y registra esta nueva ligadura con su agente origen. Si la opción
routeOptimisation está activada en el fichero de configuración XML el nodo móvil también registra su ligadura
con su nodo corresponsal (sólo se ha usado la optimización de ruta para la simulación MIPv6). De esta forma
podemos ver que el nodo móvil realizará 8 handovers a lo largo de su recorrido por el escenario.
Para concluir con esta introducción al escenario, diremos que este escenario cuenta con únicamente un router con
la función de MAP y es una jerarquía de un único nivel.
La simulación de MIPv6 será idéntica al escenario anterior sólo que el router MAP no tendrán función de MAP ,
sino que serán routers corrientes.
12.6.1
Resultados simulación 3
Los resultados mostrados a continuación para HMIP son todos sin optimización de ruta, puesto que esto
interferiría con la función que tiene el MAP en nuestros escenarios. Por otra parte en la simulación de MIP se
darán los resultados con la Optimización de Ruta activa y sin ella para así solucionar los problemas de
encaminamiento en triángulo que podrían aparecer.
Análisis y Optimización del Handover en redes MobileIP
1.
La siguiente figura muestra los diferentes tiempos de duración del handover en la capa L3, sólo se darán
los datos para MIPv6 ya que HMIPv6 no tiene disponible estos datos en el simulador de OMNET++:
F IGURA 48 -
HANDOVER MIPV 6 ESCENARIO
3
Tiempos de handover L3 con Optimización de ruta:
2,36 + 2,15 + 2,54 + 1,3 + 2,44 + 1,76 + 1,68 + 2,38 = 16,61 / 8 = 2,07 s.
78
Tiempos de handover L3 sin Optimización de ruta:
2 ,36 + 2+ 2,48 + 1,68 + 1,5 + 2,25 + 1,60 + 1,97 = 15,84 / 8 = 1,98 s.
2.
Para poder hacernos una idea de lo tiempos de handover usaremos la variable que indica los tiempo de
desconexión total que hay en el cliente1, de esta manera podremos comparar los tiempos del handover de la
simulación HMIPv6 y MIPv6:
Tiempo total de desconexión HMIPv6:
scalar "hmipv6SaitNet.client1.linkLayers[0].networkInterface"
"totalDisconnectedTime"
3.70109915269 (s)
"totalDisconnectedTime"
3.66375191027 (s)
"totalDisconnectedTime"
3.79097444129 (s)
Tiempo total de desconexión MIPv6 sin RO:
scalar "mipv6SaitNet.client1.linkLayers[0].networkInterface"
Tiempo total de desconexión MIPv6 con RO:
scalar "mipv6SaitNet.client1.linkLayers[0].networkInterface"
Como puede verse en los tiempos anteriores HMIPv6 no tiene una mejoría considerable en los tiempos de
desconexión total respecto MIPv6.
3.
Estadísticas de Ping obtenidas:
-------------------------------------------------------hmipv6SaitNet.client1.pingApp
-------------------------------------------------------drop rate (%): 2.23611
round-trip min/avg/max (ms): 40.4599/99.0314/103.368
stddev (ms): 11.795
variance:0.000139122
--------------------------------------------------------
-------------------------------------------------------mipv6SaitNet.client1.pingApp con RO=off
-------------------------------------------------------sent: 7200
drop rate (%): 5.29167
round-trip min/avg/max (ms): 40.4599/98.8225/108.9
stddev (ms): 11.9482
variance:0.00014276
---------------------------------------------------------------------------------------------------------------
Análisis y Optimización del Handover en redes MobileIP
sent: 7200
mipv6SaitNet.client1.pingApp con RO=on
--------------------------------------------------------
79
sent: 7200
drop rate (%): 5.44444
round-trip min/avg/max (ms): 40.4599/60.3538/128.517
stddev (ms): 4.18926
variance:1.75499e-05
--------------------------------------------------------
A continuación mostraremos las gráficas referentes a los tiempos de RTT de cada ping enviado, y los pings
perdidos:
ESCENARIO
3
COMPARACIÓN RTT
Análisis y Optimización del Handover en redes MobileIP
F IGURA 49 -
F IGURA 50 -
80
ESCENARIO
3
PINGS PERDIDOS
4.
Total de mensajes emitidos:
Con estos datos se intentará mostrar si realmente HMIPv6 reduce la cantidad de mensajes referentes al Binding
Update, y así contribuir a desaturar la red.
Total de mensajes en HMIPv6:
scalar "hmipv6SaitNet.worldProcessor"
"totalMessageCount"
1218981
Total de mensajes en MIPv6 sin RO:
scalar "mipv6SaitNet.worldProcessor" "totalMessageCount"
1131903
Total de mensajes en HMIPv6 con RO:
scalar "mipv6SaitNet.worldProcessor" "totalMessageCount"
12.6.2
-
966060
Análisis de los resultados de la simulación 3
Análisis de los escenarios con MIPv6:
Como puede verse la optimización de ruta aumenta ligeramente el tiempo de handover L3, de 2,07 s a 1,98 s.
Esto es debido al tiempo que se gasta en realizar el procedimiento de retorno de direccionabilidad y el registro
corresponsal. Y debido a este aumento del tiempo de handover también se produce un ligerísimo aumento de las
pings perdidos, que pasa de un 5,29% a un 5,44%. Sin embargo se obtiene una gran mejoría en el tiempo medio
de ida y vuelta de los pings, que pasa de 98,8 ms a 60,3 ms, por lo que la optimización de ruta es imprescindible
en Mobile IPv6, y debe ser utilizada siempre que sea posible, esto es, siempre que el nodo corresponsal soporte
Mobile IPv6.
Comparación de los resultados con HMIPv6 y MIPv6:
Ahora si comparamos los resultados obtenidos con MIPv6 con los de HMIPv6 podemos ver que en lo referente al
tiempo total de desconexión que tiene el nodo móvil (ninguna de la capas conectadas a la red) hay una mejoría de
HMIPv6 (3.70109915269 s) respecto a MIPv6 (3.79097444129 s) aunque también debemos decir que esto no es
una prioridad en la implementación de HMIPv6 por lo que la mejora es muy leve.
Por otra parte vamos a ver los resultados que conciernen a la cantidad de mensajes usados en el escenario. Aquí si
tendríamos que ver una mejoría de HMIP sobre MIP, como podemos ver en los resultados:
Total de mensajes en HMIPv6:
scalar "hmipv6SaitNet.worldProcessor"
"totalMessageCount"
Total de mensajes en MIPv6 sin RO:
scalar "mipv6SaitNet.worldProcessor" "totalMessageCount"
1131903
Total de mensajes en HMIPv6 con RO:
scalar "mipv6SaitNet.worldProcessor" "totalMessageCount"
966060
1218981
Análisis y Optimización del Handover en redes MobileIP
-
81
En este caso (igual que el primer escenario) no se nota mejoría en la disminución del flujo de mensajes producido
por los handovers, sino que se aumenta el número de mensajes enviados en la simulación de HMIPv6.
Por último y ya viendo los resultados de las gráficas referentes al RTT y los pings perdidos, podemos decir que
aquí HMIPv6 en este caso tiene una gran mejoría respecto a MIPv6, en lo que se refiere a la tasa de paquetes que
pasa de 5,44% a 2,23%.
12.7 Conclusiones obtenidas de las simulaciones
Después de haber comentado y analizado los resultados de las simulaciones en cada uno de los apartados anteriores
correspondientes, ahora se pasará a explicar los mayores problemas y conclusiones que podemos sacar del uso del
software de simulación OMNET++ para el fin de comparar HMIPv6 y MIPv6.
Como conclusión principal de la simulación se puede decir que HMIPv6 no tiene una ventaja considerable con
respecto al tiempo de Handover sobre MIPv6, aunque ya se sabía por las investigaciones teóricas que HMIPv6 no
se centraba en la minimización del tiempo de dexconexión del Handover. Se debe recalcar, acerca de la
comparación de tiempos de handover entre los diferentes protocolos (MIP y HMIP), que OMNET++ no tiene la
posibilidad, para HMIPv6, de mostrar los delays de handover en la capa de transporte, L3, al contrario que para
MIPv6. Esto ha sido un gran hándicap a la hora de poder realizar las simulaciones y las comparativas entre los dos
protocolos, ya que no se sabe el tiempo exacto de desconexión de la capa de transporte, aunque para conseguir
solucionarlos nos fijamos en el tiempo total de dexconexión que había durante toda la simulación y así se sacaron
las conclusiones sobre los tiempo de handover en cada uno de los escenarios anteriores.
Análisis y Optimización del Handover en redes MobileIP
Siguiendo con los problemas surgidos al simular HMIPv6, se encontró un error, que hace que OMNET++ de un
tiempo superior al handover HMIPv6. El error es que el cliente envía un BUpdate al MAP y después un LBU
también al MAP, supuestamente sólo es necesario enviar el LBU y por ello puede verse aumentado el tiempo de
handover, como puede verse en la gráfica que se mostrará a continuación:
82
F IGURA 51 -
BINDING UPDATE EN HMIP
Después de mucho investigar en los foros sobre OMNET++ se descubrió que es un bug, que corregirán los
desarrolladores de OMNET++ (aunque han dejado de desarrollar IPv6Suite).
Por otra parte en lo que se refiere al tráfico de mensajes que se enviarían en un handover, HMIPv6 debería reducir
considerablemente la emisión de Bupdate’s, pero como se ha visto a veces incluso envía más mensajes. De todas
maneras como se ha dicho en la introducción teórica de HMIPv6 la mejoría empieza a verse cuando hay entre dos
y siete niveles en la jerarquía HMIPv6 y al menos 128 AR.
13
Conclusiones y líneas de investigación futuras
Conlusiones:
Una vez llegado al final de la beca podemos diferenciar las conclusiones obtenidas en dos vertientes bien
diferenciadas debido a la naturaleza de los trabajos desarrollados en la investigación.
Por una parte se ha realizado un proceso de investigación y puesta al día sobre el handover dentro de mobileIP, lo
que nos ha otorgado conocimientos suficientes como para comprender los diferentes protocolos que existen y
realizar simulaciones sobre ellos. Con toda la información adquirida se puede decir que el handover dentro de
Mobile IP está en continua evolución y que aún le falta bastante camino para conseguir que se implante en las
redes inalámbricas actuales, debido a incompatibilidades y deficiencias de los actuales protocolos. Los protocolos
actuales que controlan el handover sobre mobileIP están en fases de pruebas y sin una estandarización completa, se
puede decir que este es el momento idóneo para el estudio de dicha tecnología, y poder aportar propuestas e
innovaciones.
Como segundo gran punto en estas conclusiones hay que destacar que los programas de simulación actuales para
las tecnologías de mobileIP no están lo suficientemente desarrollados, un gran ejemplo lo podemos ver en este
documento con los problemas que se han tenido a la hora de comparar HMIPv6 y MIPv6 obteniendo unos
resultados no tan buenos como los esperados. Sería muy interesante conseguir licencias de las aplicaciones de pago
necesarias para realizar simulaciones lo suficientemente precisas.
•
Realización de simulaciones en escenarios virtuales
Después del proceso de investigación y búsqueda de información sobre Mobile IPv6 y sus diferentes versiones de
protocolos, hemos llegados al punto en el que se debemos poner en práctica los conocimientos adquiridos.
Una vez sopesados todos los pros y contras de las aplicaciones que permiten la simulación de redes del mercado,
como pueden ser NS-2, OMNET++ y OPNET [23], se ha llegado a la conclusión de que la que mejor podría
cubrir nuestras necesidades sería esta última (OPNET).
Las principales ventajas que hemos encontrado en el software de OPNET es la disponibilidad de la suite OPNET
Modeler y OPNET Modeler wireless que implementan los protocolos de IPv6 y Mobile IPv6, además de de otros
[24] que nos podrían resultar interesantes como el soporte de Wimax. Así se podrán realizar distintos escenarios
de simulación que nos lleven a comprobar las diferentes funcionalidades de Mobile IPv6 y llegar a conseguir una
posible mejora de la latencia del Handover con la implementación y redefiniciones del protocolo estándar.
OPNET es un programa de pago, y actualmente el grupo de investigación de GITACA está trámites de conseguir
una serie de licencias para usar este programa en labores de investigación.
•
Realización de simulaciones sobre equipos reales
Análisis y Optimización del Handover en redes MobileIP
Líneas futuras de investigación:
83
El estudio de Mobile IP y, en particular el comportamiento del handover, hasta ahora se está realizando por medio
de simuladores como se ha comentado en apartados anteriores. Sin embargo, sería muy útil poder realizar las
pruebas, en entornos reales, para comprobar el comportamiento del protocolo Mobile IP, y de cada uno de los
agentes que forman parte de esta tecnología. Entre los dispositivos que tenemos ya en el laboratorio de Ingeniería
Telemática del grupo GITACA, disponemos de un analizador de espectros que, junto con el hardware que pudiese
aportar CISCO, nos posibilitaría realizar estudios del comportamiento del protocolo en entornos de interferencias
con otras tecnologías inalámbricas.
Cisco dispone de nueva tecnologías, como CISCO IOS, que ha integrado en dispositivos de encaminamiento para
ofrecer soporte de nuevas tecnologías como Mobile IP, por lo tanto,
Las características de Mobile IP están soportadas en las siguientes plataformas de CISCO:
•
Cisco 2500 Series
•
Cisco 2600 Series
•
Cisco 3600 Series
•
Cisco 4000 Series
•
Cisco 4500 Series
•
Cisco 4700 Series
•
Cisco 7200 Series
•
Cisco 7500 Series
•
Cisco Mobile Wireless Home Agent, de la serie 7600
Análisis y Optimización del Handover en redes MobileIP
Además, CISCO dispone de la Serie 3200 donde se incluyen routers que dan un aporte adicional a las tecnologías
de comunicaciones móviles para permitir subredes móviles con soporte tanto para Mobile IP como para proxy
Mobile IP.
84
Por otra parte también sería interesante disponer de puntos de acceso inalámbrico como “Cisco Aironet Access
points” y conectarlos con dispositivos “Wlan Controllers” para permitir un control detallado de la infraestructura.
14
Referencias
[1] IP Mobility Support for IPv4. RFC 3344
[2] Mobility Support in IPv6. RFC 3775
[3] Redes de Computadores e Internet (5ª Edición). F. Halsall. Pearson Weasley, 2006.
[4] Mobile IP Technology and Applications. S. Raab, M. W. Chandra, K. Leung and F. Baker. Cisco Press,
2005.
[5] Web del grupo de Investigación GITACA: http://gitaca.unex.es/
[6] A layer 3 Movement Detection Algorithm Driving Handovers in Mobile IP. N. Blefari-Melazzi,
M. Femminella and F. Pugini. Wireless Networks Journal. Springer Netherlands. Volume 11, Number 3, May
2005. Pages 223-233. ISSN: 1022-0038.
[7] A Study On Optimal Hierarchy in Multi-Level Hierarchical Mobile IPv6 Networks. Sangheon
Pack, Minji Nam, and Yanghee Choi. IEEE Communications Society Globecom 2004, Pages 1290-1294, ISBN: 07803-8794-5
[8] Fast Handover Algorithm for Hierarchical Mobile IPv6 macro-mobility Management.Indra
Vivaldi, Mohd Hadi Hahaebi, Bcirhanuddin Mohd Ali, V. Prakash. APCC 2003. The 9th Asia-Pacific Conference
on Communiations, 2003. Volume 2, 21-24 Sept. 2003 Page(s):630 - 634
[9] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," IETF
RFC 2461, Dec. 1998.
[11] D. Plummer. "An Ethernet Address Resolution Protocol Converting Network Protocol
Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware," RFC 826, Internet
Engineering Task Force, November 1982.
[12] Proyecto MIPv6 para Linux: http://www.mobile-ipv6.org/
[13] Implementación de IPv6 para Linux: http://www.linux-ipv6.org/
[14] Software para incluir MIPv6 en Linux: http://www.mobile-ipv6.org/software/
[15] Proyecto SAM–Advanced Mobile Services: http://sam.ccaba.upc.edu/
[16] UML – User-Mode-Linux: http://user-mode-linux.sourceforge.net/
[17] Boletín red Iris sobre el proyecto SAM: http://www.rediris.es/rediris/boletin/7475/ponencia13.pdf
[18] Estudio sobre SIGMA: http://cs.ou.edu/~netlab/Pub/SIGMA_MIP_performance-ICC.pdf
[19] Estudios sobre HMIPv6: H. Soliman, C. Catelluccia, and K.E. Malki et al., “Hierarchical Mobile IPv6
mobility management (HMIPv6).” IETF DRAFT, draft-ietfmipshop- hmipv6-04.txt, December 2004.
Análisis y Optimización del Handover en redes MobileIP
[10] S. Thomson, Bellcore, T. Narten, “IPv6 Stateless Address Autoconfiguration,” IETF RFC 2462, Dec.
1998.
85
[20] Handover Blackout Duration of Layer 3 Mobility Management Schemes, Svetoslav Yankov y
Sven Wiethoelter,Universidad de Berlín: www.tkn.tuberlin.de/publications/papers/Handover_Blackout_Duration_of_L3_Mobility_Management_Schemes1.pdf
[21] Dispositivo con MobileIPv6 de Nokia: http://www.nokia.com/A4126519
[22] Estandarización de dispositivos con Mobile IP: http://cf.v6pc.jp/frames.html
[23] Web de OPNET: www.opnet.com
[24] Librería de protocolos de OPNET: http://www.opnet.com/support/des_model_library/
[25] Página de descarga OMNET++: http://www.omnetpp.org/filemgmt/viewcat.php?cid=2
[26] Página de descarga de IPv6Suite 13 Descarga:
http://ctieware.eng.monash.edu.au/twiki/pub/Simulation/IPv6SuiteInstallation/IPv6SuiteWithINET20060119.tgz
[27] White paper sobre RFID, Libera Wireless Freedom.
[28] Flow-Based Fast Handover Method for Mobile IPv6 Network, Miska Sulander, Timo Hämäläinen,
Ari Viinikainen and Jani Puttonen, Universidad de Jyväskylä: www.tzi.de/~dku/teach/enss05/01/vtc04MN_13_6.pdf
[29] Pruebas y estudio del handover entre redes heterogéneas, Vijay Kesavan:
http://blogs.intel.com/research/2008/02/wifi_wimax_handover.php
Análisis y Optimización del Handover en redes MobileIP
15
86
•
•
•
•
•
•
•
BIBLIOGRAFÍA
D. Johnson, C. Perkins, and J. Arkko. "IP Mobility Support in IPv6".
http://www.ietf.org/rfc/rfc3775.txt, June 2004. IETF.
H. Jung. "Fast Handover for Hierarchical MIPv6 (F-HMIPv6)", (work in progress).
http://tools.ietf.org/wg/mipshop/draft-jung-mipshop-fhmipv6-00.txt, October 2005. IETF.
Y. Gwon, J. Kempf, and A Yegin. "Scalability and Robustness Analysis of Mobile IPv6, Fast Mobile
IPv6, Hierarchical Mobile IPv6, and Hybrid IPv6 Mobility Protocols using a Large-Scale Simulation". In
2004
IEEE
International Conference on Communications, volume 7, pages 4087 { 4091, 20 March-24
June 2004.
H. Soliman. "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)".http://www.ietf.org/rfc/rfc4140.txt, August 2005. IETF.
R. Hsieh, Z.G. Zhou, and A. Seneviratne. "S-MIP: a seamless Hando® Architecture for Mobile IP". In
INFOCOM 2003. IEEE Twenty-Second Annual Joint Conference of the IEEE Computer and
Communications Societies., volume 3, 30 March-3 April 2003.
J. Chow and G. Garcia. "Macro- and Micro-Mobility Hando®s in Mobile IP based MBWA Networks".
In IEEE Global Telecommunications Conference, 2004. GLOBECOM '04., volume 6, pages 3921 {
3925, 29 Nov.-3 Dec. 2004.
J. Rajahalme, A. Conta, B. Carpenter, “IPv6 Flow Label Specification”, IETF draft, work in progress,
2003.
•
•
•
•
•
•
•
•
•
•
•
•
Miska Sulander, Timo Hämäläinen, Ari Viinikainen, y Jani Puttonen. Departamento de tecnología de
información
matemática
de
la
universidad
de
Finlandia.
http://kom.aau.dk/group/05gr995/05995/Links-files/fh.pdf.
Vijay Kesavan, investigador de Intel. Demo de la investigación sobre handover sin fisuras en redes
heterogéneas http://blogs.intel.com/research/2008/02/wifi_wimax_handover.php.
Información sobre la institución reguladora de IPv6 a nivel mundial, que realiza la estandarización do los
productos
que
soportan
IPv6
http://www.ipv6ready.org/pdf/IPv6_Ready_Logo_White_Paper_Final.pdf.
R. Hsieh. Fhmip ns extension. http://mobqos.ee.unsw.edu.au/ robert/opcomm/.
The network simulator ns2. http://www.isi.edu/nsnam/ns .
The ns Manual. http://www.isi.edu/nsnam/ns/ns-documentation.html .
Festag. "Optimization of Handover Performance by Link Layer Triggers in IP-Based Networks;
Parameters, Protocol Extensions, and API for Implementation, Technical Report". August 2002.
C. Perkins. Mobins2 extension to ns2. http://people.nokia.net/charliep/mobins2/ .
Columbia
University.
Columbia
IP
Micro-Mobility
Software.
http://www.comet.columbia.edu/micromobility/.index.html .
J. Widmer. No ad hoc routing agent. http://icapeople.epfl.ch/widmer/uwb/ns-2/noah/ .
T. Ernst. Mobiwan: A ns simulation platform for mobile ipv6 in wide area networks. http://www.tiwmc.nl/mobiwan2/ .
CMU
Monarch
Group.
Wireless
and
mobility
extensions
to
ns.
http://www.monarch.cs.cmu.edu/cmu-ns.html.
Helsinki University of Technology. The Dynamics Mobile IP system. http://dynamics.sourceforge.net/.
Análisis y Optimización del Handover en redes MobileIP
•
87