Analisis y Optimizacion Del Handover en Redes MobileIP

Anlisis y Optimizacin del Handover en redes MobileIP
UNIVERSIDAD DE EXTREMADURA GTACA
Grupo de investigacin de Ingeniera Telemtica Aplicada y Comunicaciones Avanzadas www.gitaca.es

Octubre de 2008 Autores: David Corts Polo - Carlos Vecino de Casas Coordinador: Jos Luis Gonzlez Snchez

1 CONTENIDO
ACRNIMOS UTILIZADOS ...............................................................................................3 GLOSARIOTRMINOS UTILIZADOS SOBRE MOBILEIP ........................................................5 TRMINO DE MOBILE IP....................................................................................................5 TRMINOS ESPECFICOS DEL HANDOVER ................................................................................5 FIGURAS........................................................................................................................7 2 INTRODUCCIN .......................................................................................................9 3 INTRODUCCIN A MOBILEIP ............................................................................................9 4 FUNDAMENTOS DE MOBILE IP V6 .................................................................................... 10 4.1 FUNCIONAMIENTO DE MOBILE IP V6 .......................................................................... 11 4.2 DETECCIN DEL MOVIMIENTO EN UNA RED .................................................................. 11 4.2.1 PROTOCOLO NEIGHBOR DISCOVERY .................................................................... 12 4.2.2 DESCUBRIMIENTO DE OTROS HOME AGENTS........................................................... 13 4.3 ADQUISICIN DE UNA NUEVA COA ............................................................................ 13 4.3.1 DUPLICATE ADDRESS DETECTION (DAD) .............................................................. 14 4.4 ACTUALIZACIN DE LOS VNCULOS ............................................................................ 14 4.4.1 USO DE LA CACH DE VNCULOS .......................................................................... 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 REDUCCIN DE LOS CUELLOS DE BOTELLA DE LA CONECTIVIDAD .................................. 19 5.1.3 CUELLOS DE BOTELLA PRODUCIDOS POR LA LATENCIA DE RECEPCIN DE PAQUETES ........... 19 5.1.4 REDUCCIN DE LOS CUELLOS DE BOTELLA DE LA RECEPCIN DE PAQUETES ...................... 20 5.2 HIERARCHICAL MOBILE IP V6 ................................................................................... 21 6 PROYECTOS DE IMPLEMENTACIN DE MOBILEIPV6 ................................................... 23 6.1 PROYECTO MIPL.................................................................................................. 23 6.1.1 CONFIGURACIN DE IPV6 MVIL EN LINUX .................................................. 24 6.1.2 CONFIGURACIN DE IPV6 MVIL 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 EVOLUCIN DE LOS PROTOCOLOS QUE REALIZAN HANDOVER (FHMIP, SIMP, FFHMIP) 34 8.1 ALCANCE DE ESTE INFORME TCNICO ......................................................................... 34 8.2 FAST HANDOVER PARA HIERARCHICAL MOBILE IPV6 (F-HMIPV6)....................................... 35
8.2.1 VISIN 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 VISIN GENERAL DE S-MIP ................................................................................ 40 8.3.2 FUNCIONAMIENTO DE S-MIP ............................................................................. 41 8.4 FFHMIPV6 ......................................................................................................... 42 8.4.1 VISIN 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 HETEROGNEAS ..................................................... 48 9.2.1 INTRODUCCIN DE LA INVESTIGACIN .................................................................. 48 9.2.2 DEMOSTRACIN DEL HANDOVER ........................................................................ 48 9.2.3 "EL CUNDO Y POR QU" DEL HANDOVER............................................................. 49 9.2.4 "HACIA DNDE?" SE REALIZA EL HANDOVER ......................................................... 50 9.2.5 CMO SE REALIZA EL HANDOVER ...................................................................... 50 9.3 ESTANDARIZACIN Y SUPERVISIN DE PRODUCTOS PREPARADOS PARA MOBILEIPV6 ................. 51 10 OTRAS TECNOLOGAS QUE PODRAN COMPLEMENTAR A MOBILEIP .......................... 52 10.1 RFID............................................................................................................... 52 10.1.1 INTRODUCCIN ........................................................................................... 52 10.1.2 FUNDAMENTOS DE RFID ................................................................................. 55 10.1.3 ESTADO ACTUAL ........................................................................................... 58 11 SUITES DE SIMULACIN ............................................................................................... 61 11.1 NETWORK SIMULATOR ......................................................................................... 61 11.2 OMNET++...................................................................................................... 62 11.3 OPNET ........................................................................................................... 62 12 SIMULACIONES REALIZADAS ......................................................................................... 63 12.1 ELECCIN DEL SIMULADOR .................................................................................... 63 12.2 INSTALACIN DEL SIMULADOR ................................................................................ 64 12.3 INTRODUCCIN A LAS SIMULACIONES ........................................................................ 66 12.4 ESCENARIO 1 ..................................................................................................... 66 12.4.1 RESULTADOS SIMULACIN 1 ............................................................................. 68 12.4.2 ANLISIS DE LOS RESULTADOS DE LA SIMULACIN 1 ................................................. 71 12.5 ESCENARIO 2 ..................................................................................................... 72 12.5.1 RESULTADOS SIMULACIN 2 ............................................................................. 73 12.5.2 ANLISIS DE LOS RESULTADOS DE LA SIMULACIN 2 ................................................. 76 12.6 ESCENARIO 3 ..................................................................................................... 77 12.6.1 RESULTADOS SIMULACIN 3 ............................................................................. 78 12.6.2 ANLISIS DE LOS RESULTADOS DE LA SIMULACIN 3 ................................................. 81 12.7 CONCLUSIONES OBTENIDAS DE LAS SIMULACIONES ........................................................ 82 13 CONCLUSIONES Y LNEAS DE INVESTIGACIN FUTURAS ......................................................... 83 14 REFERENCIAS ........................................................................................................... 85 15 BIBLIOGRAFA ....................................................................................................... 86
ACRNIMOS UTILIZADOS
ANAccess Network APAccess Point ARAccess Router CoACare-of-Address CNCorrespondent Node DHCPDynamic Host Configuration Protocol FAForeign Agent FBACKFast Binding Acknowledge FBUFast Binding Update FMIPFast Mobile IP HAHome Agent HACKHandover Acknowledge HIHandover Initiate
HMIPHierarchical Mobile IP IETFInternet Engineering Task Force LCOAOn-Link Care-of-Address L2Layer 2 L3Layer 3 MAPMobility Anchor Point MNMobile Node NARNew Access Router NATNetwork Address Translation NCoANext Care-of-Address nFANew Foreign Agent
NLCoANext Link Care-of-Address oFAOld Foreign Agent PARPrevious Access Router PCoAPrevious Care-of-Address PLCoAPrevious Link Care-of-Address PrRtAdvProxy Router Advertisement RtSolPrRouter Solicitation for Proxy Advertisement SCTPStream Control Transmission Protocol SIPSession Initiation Protocol
GLOSARIOTRMINOS UTILIZADOS SOBRE MOBILEIP

Trmino de Mobile IP
Extracto de la terminologa de MobileIP extrada 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 Direccin 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 mvil o no. -Care-of-Address (CoA) Direccin 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 direccin actual de CoA. -Binding Asociacin de una direccin dada por la red de origen del MN y la CoA, que permanece durante el tiempo de vida de la asociacin. - Registration El proceso durante el que el MN enva un Binding Update a su HA o CN, para que se realice el binding y as se registre el nodo.
Trminos especficos 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)
CoA del MN vlida en la subred del PAR. -Next Care-of-Address (NCoA) CoA del MN vlida en la subred del NAR. -Router Solicitation for Proxy Advertisement (RtSolPr) Un mensaje del MN al PAR pidiendo informacin para un handover. -Proxy Router Advertisement (PrRtAdv) Un mensaje del PAR al MN que da informacin sobre sus vecinos facilitando la deteccin de movimientos. El mensaje tambin acta como disparador para el inicio del handover por parte de la red. -Fast Binding Update (FBU) Mensaje del MN al PAR para redirigir el trfico hacia el NAR. -Fast Binding Acknowledge (FBACK) Un mensaje del PAR en respuesta de un FBU. -Handover Initiate (HI) Un mensaje del PAR al NAR respect al handover del MN. -Handover Acknowledge (HACK) Un mensaje del NAR al PAR como respuesta al HI.
FIGURAS
Figura 1- esquema bsico de MIPv6..............................................................................................11 Figura 2 - nivel ptimo de jerarqua en relacin al nmero de AR .........................................................22 Figura 3 - escenario bsico de movilidad en IPv6 ..............................................................................24 Figura 4 - experimentos con protocolos de movilidad [17] ..................................................................27 Figura 5 - comparacin entre Real y UML. [17]...............................................................................28 Figura 6 - diseo de la red con sigma y stcp [17] ..............................................................................29 Figura 7 - seales en el proceso de handover [17] .............................................................................30 Figura 8 - topologa 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 - comparacin 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 mvil [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 opcin de ffhmipv6 [28] ..............................................................46 Figura 24 - elementos que afectan al handover [28]...........................................................................46 Figura 25 - dispositivo de nokia con mobileipv6...............................................................................47 Figura 26 - realizacin de vdeo-llamada con handover.......................................................................48 Figura 27 - vdeo de explicacin del proceso de handover...................................................................49 Figura 28 - arquitectura del sistema [29] ........................................................................................50 Figura 29 - handover predictivo en redes heterogneas [29] ................................................................51 Figura 30 - aplicaciones de rfid. IBM ............................................................................................53 Figura 31 - internet of things" nueva dimensin. ITU(Nomura Research Institute) ....................................54 Figura 32 - crecimiento del mercado rfid. IDTechEX ........................................................................54 Figura 33 - sistema rfid bsico ....................................................................................................55 Figura 34 - caractersticas de los tansponders en funcin de la frecuencia. Allied Business Intelligence Inc. .......56 Figura 35 - aplicaciones de rfid segn la frecuencia de trabajo ..............................................................57 Figura 36 - clasificacin de tags rfid..............................................................................................58 Figura 37 - diferentes tipos de tags rfid .........................................................................................58 Figura 38 - evolucin de la tarjetas rfid [27]....................................................................................60 Figura 39 - escenario 1 .............................................................................................................67 Figura 40 - escenario 1 handover mipv6 ........................................................................................68 Figura 41 - escenario 1 comparacin rtt ........................................................................................70 Figura 42 - escenario 1 pings perdidos ..........................................................................................70 Figura 43 - escenario 2 .............................................................................................................72
Figura 44 - escenario 2 handover mipv6 ........................................................................................73 Figura 45 - escenario2 comparacin 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 comparacin rtt ........................................................................................80 Figura 50 - escenario 3 pings perdidos ..........................................................................................80 Figura 51 - binding update en hmip..............................................................................................82
INTRODUCCIN
El presente informe trata de exponer el proceso de investigacin llevado a cabo desde la fecha de concesin de la beca de investigacin sobre el Handover en MobileIP realizada con la colaboracin 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 investigacin 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 tratarn son: Introduccin al mundo de la movilidad IP. Los principales fundamentos de Mobile IP. Principales problemas del Handover sobre Mobile IP bsico. Realizacin del handover en MobileIP, introduciendo los dos tipos bsicos de handover: Fast Handover y Hierachical Handover. Despus de este tiempo adaptacin y puesta al da 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 ms importantes que podan complementar al proceso de investigacin: Los puntos a tratar fueron los que siguen: Proyectos actuales sobre la implementacin de MobileIPv6. Comparativas sobre la latencia de Handover en diferentes protocolos (Sigma, FMIPv6, HMIPv6 y FHMIPv6).
Principales protocolos que son la evolucin natural de los bsicos MIPv6, FMIPv6 y HMIPv6. Actualidad de la investigacin del Handover sin fisuras realizndose en redes heterogneas (Wimax/Wifi). Dispositivos ms importantes que integran la tecnologa sobre los que se investiga. Otras tecnologas que podran ser tiles para complementar a MobileIP. Suites de simulacin de tecnologa MobileIP. Simulaciones de MIPv6 frente HMIPv6. Lneas futuras de investigacin.
Introduccin a mobileIP
Desde hace ya algunos aos, las comunicaciones inalmbricas se han convertido en un referente en el mundo de las comunicaciones, debido sobre todo al auge de los dispositivos mviles como PDAs, mviles y ordenadores
porttiles, hacen que los estudios y las investigaciones que hasta ahora se estaban llevando en entornos almbricos, no sean aplicables a los entornos inalmbricos. Este auge propicia adems, el aumento de estos dispositivos conectados a la red y que las direcciones de IPv4 se acaben mucho ms rpido de lo que estaba previsto. En este sentido, la unin de las comunicaciones mviles 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 adaptacin 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 conexin si el dispositivo mvil pasa de una red a otra (este concepto usando los protocolos de red almbrica no se poda conseguir ya que estn orientados hacia redes fijas y no mviles). Debido a lo anteriormente descrito en la introduccin, en este trabajo nos centraremos en la movilidad desde IPv6 ya que todos los trabajos relacionados con IPv4 estn siendo abandonados ya que el despliegue de la movilidad en este protocolo es mucho ms costoso as como el problema de la escasez de direcciones IP. Este documento se va a desglosar como sigue, en el captulo 2 se muestra el funcionamiento bsico de MIPv6, en el captulo 3 se muestran los mecanismos que permiten el movimiento en el protocolo MIP y por ltimo las propuestas dependiendo de la tecnologa usada.
Fundamentos de Mobile IP v6
Mobile IP es una modificacin del protocolo IP que permite a los nodos continuar recibiendo datagramas independientemente de la red a la que estn conectados, esto conlleva mensajes de control adicionales que permiten manejar el encaminamiento de los datagramas. Este protocolo ha sido diseado 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 mvil. El protocolo IP asume que una direccin IP idntica inequvocamente el punto de conexin 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.
El protocolo IPv6 proporciona mecanismos de autoconfiguracin 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 interrupcin de todas las conexiones de niveles superiores y su posterior reinicio, una vez conectados al nuevo punto de acceso. Adems, el resto de nodos no disponen de ningn mecanismo transparente para comunicarse de nuevo con el nodo mvil, al ignorar la nueva localizacin 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 travs de su home address (HoA), sin importar si se encuentra conectado a su home network o est visitando otras redes. La transicin, traspaso o handover entre redes es transparente para los niveles superiores y la prdida de conectividad que se produce durante el mismo es el correspondiente al intercambio de los mensajes de sealizacin necesarios. Dado que Mobile Ip es una extensin de IP para redes mviles, aparecen nuevos conceptos que hay que tener en cuenta para comprender correctamente el protocolo: En primer lugar el nodo mvil (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 adems dos direcciones IP. La direccin de su red origen (HoA, Home of Address) y por otro lado la direccin IP de la red que visita (CoA, Care of Address).
10
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 BSICO DE
MIP V 6
Una vez vista los elementos bsicos del protocolo, vamos a estudiar ms a fondo el protocolo.
4.1
Funcionamiento de Mobile IP v6
Mobile IP est orientado a dotar la movilidad a IPv6, la figura 1 muestra el funcionamiento bsico de Mobile IP. El funcionamiento bsico se puede dividir en varias etapas: Deteccin de movimiento en una red: Este proceso descubre el posible movimiento de un nodo mvil, de tal manera que permite comenzar el proceso de handover hacia otra red.
Adquisicin de una nueva CoA: Una vez que se ha descubierto una nueva red a la que saltar, se debe obtener una direccin vlida para ser alcanzable en esa nueva red.
Actualizacin de los vnculos: Con la nueva CoA obtenida se debe actualizar la informacin tanto en el HA como en los CN para que sepan como enviar la informacin al MN en su nueva red.
Enrutado y Tunneling: Son los mtodos usados para que que el MN sea alcanzable ya sea mediante un tnel HA-MN o mediante optimizacin de rutas entre el MN y el CN.
En los siguientes puntos se va a detallar cada una de estas fases.
4.2
Deteccin del movimiento en una red
Cuando un MN visita una nueva red, debe autoconfigurarse con los parmetros tpicos necesarios para que sea un dispositivo direccionable en una red IPv6. En particular un MN necesita determinar el prefijo de la red en el momento en el que descubre un nuevo AR y se quiere conectar a el. Una vez que mediante los anuncios de router
11
obtiene el prefijo de red, el MN tiene la informacin necesaria para poder autoconfigurarse o intentar pedir una direccin IP a un servidor DHCPv6. Sin esta nueva direccin 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 bsico 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: Comunicacin entre el nodo y el AR: El nodo para estar conectado debe de mantener siempre comunicacin con un AR, ya sea de su red origen o de una red visitada. Para esto es necesario obtener la informacin que se le enva en los mensajes de router, en la cual se obtiene informacin 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 enve esta informacin. Obtencin 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 adems puede obtener la informacin necesaria para poder autoconfigurarse [10] sin necesidad de un cliente de DHCP como era necesario en IPv4. Asignacin de una nueva CoA: Si el MN se encuentra en una red visitada, para que sea accesible necesitar de una direccin 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 mtodos 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 Mvil pedir un anuncio de router al Router de Acceso al que est conectado. Estos dos mensajes son una parte importante del proceso de Handover. Estos mensajes como se ha dicho anteriormente son heredados de IPv6 aunque dado la naturaleza de Mobile IP es necesario hacer modificaciones a estos mensajes para que proporcionen toda la informacin necesaria al MN. Por lo tanto los mensajes usados para el descubrimiento de agentes utilizarn los mensajes antes nombrados y se llamaran: Router Advertisement: Este mensaje se transmite regularmente desde el router que est haciendo de agente Mobile IP. Router Solititation: Este mensaje es la peticin del MN de que se retransmita un Router Advertisement. Normalmente los Router Advertisement tienen un tiempo de envo que vara en un intervalo mnimo de 0,3-0,7 segundos. Es decir este es el mnimo que impone Mobile IP para que se enve 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 direccin MAC de los otros nodos para comunicarse con ellos. Debido al principio de encapsulacin de IP, todos los paquetes deben contener la direccin MAC del paquete al que se dirige para que pueda ser transportado por el medio fsico. El proceso de resolucin de una direccin IP a una direccin fsica es un paso necesario en las redes de datos. En IPv4 esta resolucin la haca el protocolo Address Resolution Protocol (ARP) [11]. En IPv6 la funcin la realiza el protocolo Neighbor Discovery (ND) . El protocolo ND tambin permite a los nodos el descubrimiento de routers permitiendo el envo de paquetes hacia ellos. Este protocolo provee de mtodos para asegurar la conectividad con un vecino cuya direccin haya
12
sido resuelta con anterioridad. Estas funciones son necesarias para la comunicacin sobre un medio fsico especfico.
4.2.2
Descubrimiento de otros Home Agents
Un router que acta como HA aprende si existen otros HA en la red mediante los anuncios de router no solicitados que envan peridicamente. 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 caracterstica crea una lista de todos los routers actuando como HA en la red. Esta lista incluye tanto la direccin IP del HA como la preferencia (capacidad del mismo) y el tiempo de vida para que esa entrada expire de la lista. La direccin IP se obtiene de la cabecera del paquete y los otros dos parmetros son extrados del Home Agent Information Option si el paquete lo contiene. Estos dos parmetros cuanto mayor sea el valor que contengan, querrn decir que tienen una mejor disposicin para acoger nuevos nodos. Si en el anuncio de router no se incluye esta opcin 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 mximo 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 tena dado de alta en la lista de HA. Si el valor fuera diferente lo nico que tendra que hacer es modificar ese valor en la lista y si no existiera la entrada de ese HA se deber crear una nueva. Esta informacin 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 ms descargado. Adems con este mtodo se pueden proponer otras variaciones como que un MN al estar requiriendo ciertos parmetros de QoS se le permita conectarse a otro HA de su misma red y que le proporcione esos parmetros.
El mobile node tiene dos formas distintas de adquirir una CoA en funcin del tipo de Router Advertisement recibido. Segn esta informacin se puede generar una NewCoA para los dos tipos de autoconfiguracin 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 obtencin de su nueva CoA. O bien la direccin est configurada de manera manual en el equipo. Stateless Address Autoconfiguration: El MN genera la CoA concatenando el prefijo de red que enva el router en los Router Advertisement con la propia MAC del MN. El prefijo de subred elegido se convertir en su router por defecto. Mediante el mecanismo de IPv6 llamado Duplicate Address Detection (DAD) se detecta si la CoA obtenida ya ha sido previamente asignada a otro nodo de la red.
13
4.3
Adquisicin de una nueva CoA
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 propsito es obtener y asignar una nica direccin IP a la interfaz sin requerir de servidores de autoconfiguracin o la configuracin manual de la direccin. El MN por lo tanto tendr que mandar un DAD Neighbor Solicitation para ver si la direccin que ha calculado est duplicada o no. Normalmente a este mtodo se le conoce como DAD probe, y sirve para probar direcciones. El nodo por tanto se conecta a la direccin multicast local de comunicacin all devices (representado por FF02:: 1) Al conectarse a esta direccin multicast permite al nodo que reciba los Neigbor Advertisements de otros nodos y as detectar si hay algn nodo usando esa misma direccin. Adems de suscribirse a este grupo, el MN se ha de suscribir al grupo multicast solicited-node en el cual puede detectar si hay algn otro nodo que est itentando acceder con la misma direccin IP. Esto es posible ya que al unirse a un grupo multicast, se enva 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 direccin local para la que usar el prefijo de la red y su propia IID, esa ser la direccin con la que se intentar conectarse a la red. El nodo por lo tanto enva un mensaje Neighbor Solicitation (DAD probe) al grupo multicast solicited-node. El nodo podr enviar el mensaje probe mltiples veces, pero siempre cumpliendo la premisa de un tiempo entre los diferentes intentos. Sin embargo el nmero de probes por defecto que se enva 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 direccin que la especificada debe enviar un mensaje Neighbor Advertisement para que el MN cambie su direccin de pureba y vuelva a repetir el proceso.
4.4
Actualizacin de los vnculos
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 informacin de la nueva conexin. A este proceso se le llama actualizacin de vnculos. 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 direccin CoA a la que los paquetes sern reenviados desde el HA. En Mobile IPv6, todos los HA tienen una cach de vnculos (binding cache) que permite almacenar todos los vnculos con los MN a los que sirve de agente origen. De tal manera que slo aquellos MN que tengan una entrada vlida en la cach de vnculos sern los nodos que tengan conectividad. Para tener conectividad por lo tanto lo que se hace es que el nodo mvil enve un binding update al HA en el momento que se mueva. Cuando el HA tenga una entrada en la Cach de Vnculos vlida para esa comunicacin, todos los paquetes que lleguen al HA con destino el MN sern reenviados hacia este ltimo. En este modo de comunicacin, los CN no intervienen en la comunicacin mvil siendo el que controla toda la comunicacin el HA y por lo tanto los CN pueden ser nodos IPv6 sin que acepten el protocolo Mobile IP. A este modo de comunicacin se le llama tunneling bidireccional, refirindose a la tcnica usada entre el MN y el HA para el envo de paquetes.
14
Mobile IPv6 tambin permite a los MN y los CN comunicarse directamente sin que haya ningn HA involucrado en el envo de paquetes. Para esto, el MN tiene que establecer los vnculos (bindings) con el CN directamente. El mensaje es mucho ms 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 comunicacin.
4.4.1
Uso de la cach de vnculos
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 mvil. Estas tablas de routing tienen la direccin HoA del nodo mvil como destino y proveen de informacin de cmo deben llegar los paquetes a esa direccin. Cuando el nodo mvil es localizado mediante su CoA, la tabla de routing debe contener informacin sobre ella y de cmo llegar hasta esa direccin. De esta manera se puede producir el efecto que se comentaba anteriormente y que una HoA pueda ser transformada por una direccin CoA gracias a la cach de vnculos. Estas caches deben mantener las entradas de manera segura ya que podra ser una gran baza para los ataques a redes inalmbricas la modificacin de la cach de vnculos y es por esto que se han de poner grandes medidas de seguridad para que slo quien demuestre que es quien dice ser pueda modificar la informacin de la cach de vnculos. Los mensajes que controlan la cach de vnculos son los siguientes:

Binding Update (BU) Binding Acknowledgement (BAck) Binding Error (BERR) Binding Refresh Request (BRR)
Binding Update es un elemento crucial en el protocolo ya que controla el ncleo de Mobile IPv6, la cach de vnculos. El resto de elementos y operaciones dentro de Mobile IPv6 deben ser entendidos siempre manteniendo la relacin con Binding Update. Los mensajes de control de la cach de vnculos son estructurados como mensajes que se envan 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 extensin, la cabecera y los datos de la extensin se introducen detrs 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 adems de la CoA que contiene la cabecera de IPv6.
4.4.2
Return Routability
Dado que las comunicaciones mviles (y ms an 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 mtodo Return Routability no solo para comprobar el estado de las comunicaciones entre el
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 comunicacin. Como se coment anteriormente, la finalidad de este mtodo 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 direccin HoA del MN, mientras que CoTI y COT prueban la direccin CoA del mismo.
4.5
Enrutado y Tunneling
Una vez que el HA ha registrado en la cach de vnculos 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 vnculos los reenva hacia el nodo mvil. El trfico que proviene de la HN, no tiene que atravesar ningn 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 direccin de enlace si quieren mandar paquetes al MN. Por tanto el HA acta de proxy para ARP o ND. Esto le permite interceptar los paquetes que provengan con la direccin de HA y reenviarlos a la direccin CoA. Todos estos mensajes que sean capturados por el HA y reenviados al MN deben preservarse los mensajes originales. Es por esto que el HA realiza una encapsulacin IP sobre IP introduciendo el paquete original en otro paquete IP en el que la direccin destino sea la CoA (y la direccin fuente el HA).
De manera similar, el nodo mvil tambin 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 comunicacin 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 direccin Home Address (HoA). La direccin de destino es la CoA pero cuando llega el mensaje al MN se intercambia la informacin con la cabecera de routing de tal manera que la direccin 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 direccin de origen CoA por la direccin HoA contenida en la cabecera de routing. Estos procesos nicamente se pueden llevar a cabo si existe la entrada correspondiente a la comunicacin en la cach de vnculos para la HoA y esta es vlida.
Handover en MobileIP v6
16
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 mviles. 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 podrn usar con este protocolo y por lo tanto no se les podr proveer de movilidad en los dispositivos de nueva generacin hasta que se pueda proveer de mejores condiciones en cuanto se produzca un handover. La mayora de las alternativas, requieren de modificaciones en el Router de Acceso (AR), en el Nodo Mvil (MN), o requiere tener en cuenta informacin de antemano para poder realizar el handover. Para esto se usan diferentes mtodos como un Agente Origen (HA) local, routing Multicast, optimizacin de los protocolos de routing bi-casting, triggers de nivel 2, buffering y tunneling. De las mltiples 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 informacin 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 optimizacin de rutas, tambin han sido estudiado para reducir el tiempo de espera para la conexin con el nuevo (AR). Adems se ha desarrollado un tipo nuevo de handover que se podra 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 mtodos ms 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 despus, encaminando la informacin que se enva a la antigua CoA desde el antiguo AR hacia el nuevo mediante un tnel, mientras se registra la nueva CoA. En los puntos sucesivos se irn describiendo uno a uno los mtodos de nivel 3 de manera mas exhaustiva. Los mtodos 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 tecnologa, y esto no es aceptable en ningn caso. Es por esto que los mtodos de nivel 2 sean explicados en un anexo de este documento.
5.1
Fast Handover en Mobile IP6
1. 2. 3. 4. 5. 6.
Establecer conectividad de enlace Establecer conectividad IP Reservar recursos de red Ejecutar las aplicaciones Realizar Handover 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 direccin IP que permita la comunicacin 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 direccin local de enlace es nica. Otro de los mtodos que vimos para esto es usando el mtodo de autoconfiguracin del nodo
17
Normalmente un MN se conecta a su red de acceso, normalmente a travs de un enlace wireless usando un punto de acceso o una estacin 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 fsico. 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 bsico de MIPv6. Las acciones que debe realizar un MN se pueden resumir en las siguientes:
que permite obtener una direccin IP sin necesidad de que entre en juego alguna entidad de la red. Este proceso simplifica la asignacin de las direcciones pero requiere que se haga una comprobacin adicional realizando el Duplicate Address Detection (DAD). Una vez que se ha configurado la direccin IP del nodo, el MN realiza el descubrimiento de routers, permitiendo identificar cual es su router por defecto y crear una direccin 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 autenticacin y la autorizacin de acceso a la red. Si la autenticacin es satisfactoria se establece la conexin con el AR y es en ese momento cuando el nodo mvil puede enviar y recibir paquetes IP usando su nueva direccin IP. Una vez que el nodo establece conectividad IP, comienza la ejecucin de varios procesos que necesitan acceso a Internet como por ejemplo una aplicacin de VoIP con un CN. Una aplicacin como es VoIP necesita normalmente de ciertos parmetros de QoS de la red. Con estos parmetros 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. Adems de esto si el enlace inalmbrico que no tenga mucha velocidad, es conveniente que se implemente las funciones de compresin 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 comunicacin entre el AR y el MN para configurar los parmetros de la comunicacin 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 seleccin 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 conexin 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 adems 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 enve y reciba paquetes inmediatamente despus de que obtenga la conectividad a nivel de enlace. A esto lo llamaremos el problema del fast handover. 2. Como mantener ininterrumpido el acceso a los recursos de la red para que el corte causado por el handover en la capa de transporte sea minimizado. A esto se le llamar el problema del smooth handover o handover suave.
Hay dos puntos importante dentro del diseo de Fast Handover. El primero es que las latencias debidas a la deteccin del movimiento, la adquisicin de la direccin IP y la configuracin a consecuencia del handover deben ser reducidas. El segundo es que la latencia para que los paquetes IP lleguen al destino con la nueva direccin IP (nueva CoA) tambin debe ser reducida. Se debe tener en cuenta que los paquetes siguen llegando a su destino con la direccin IP antigua hasta que al CN se le notifique lo contrario, normalmente con el procedimiento de Return Routability (que se produce despus de un Binding Update). Estos paquetes deben ser reenrutados hacia la nueva direccin del nodo mvil hasta que la actualizacin de la localizacin sea efectiva A esto se le puede llamar mejora de la latencia del punto de recepcin de los paquetes. Tanto la latencia de conectividad como de la recepcin 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 fsico 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 direccin IP. Con el mtodo de IPv6 stateless address autoconfiguration, el MN tambin necesita realizar el protocolo de DAD para asegurarse que su direccin es nica. Ambas operaciones contribuyen a la latencia de conectividad. Algunos trabajos [prob_DAD] hablan de
18
eliminar el proceso de DAD para disminuir la latencia introduciendo mtodos para ver si la direccin est duplicada una vez que se ha comenzado a usar. Adems calculan la probabilidad de que se produzca una colisin entre dos direcciones IP iguales dentro de una red. El protocolo Mobile IP especifica mecanismos para la deteccin 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 mnimo entre anuncios de router) adems del proceso de obtencin de informacin de las capas inferiores y de Neighbor Discovery para que se detecte el cambio de la red. Incluso con anuncios de router ms frecuentes, es muy difcil detectar el movimiento de una red a otra. Si se utiliza una aproximacin hbrida basada en usar Neighbor Unreachability Detection (NUD), puede llevar a un retardo variable en la deteccin del movimiento, que puede ser mayor a cien milisegundos. Con el handover ya confirmado a una nueva red y una nica direccin IP, el MN ya podra enviar paquetes. En este caso la latencia introducida por DAD domina la configuracin de la direccin IP, normalmente por encima de un segundo. Hasta que el proceso de DAD no se complete cualquier aplicacin como la de VoIP va a seguir generando paquetes que sern desechados por el sistema operativo debido a que el interfaz de red no est configurado correctamente todava. Incluso cuando el MN tenga configurada la direccin IP, no puede usar esa direccin con el CN sin realizar primero el procedimiento de Return Routability. Esto es debido a que el CN descartar los paquetes que contengan una direccin de origen que no est reflejada en su cach de vnculos. Por lo tanto la realizacin de este procedimiento llevar consigo un retraso de 1,5 por el tiempo de Round-Trip Time (RTT) al nodo CN.
5.1.2
Reduccin de los cuellos de botella de la conectividad
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 informacin de configuracin IP (mediante los anuncios de router del AR adyacente de otra red) antes de que se conecte a ese AR. Por tanto esta informacin de configuracin permite al MN detectar rpidamente el movimiento a la nueva red y obtener la conectividad IP ms rpidamente. Esto implica que el MN conozca de antemano el nuevo router y la futura direccin IP antes de dejar el AR al que est conectado.
El mtodo 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 mvil tiene un mapa de todos futuros AR a los que se puede conectar y la informacin IP correspondiente para que el nodo se pueda conectar a cualquiera de ellos. El problema que introduce este mtodo 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 bsqueda, 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 mtodo es que los AR tengan el mapa completo de los routers adyacentes y sus caractersticas. Mediante un nuevo protocolo Candidate Access Router Discovery (CARD), se puede obtener las capacidades y caractersticas de los AR de manera que el nodo puede tomar su decisin y elegir el que ms le convenga.
5.1.3 Cuellos de botella producidos por la latencia de recepcin de paquetes

La latencia producida por la recepcin de paquetes despus de un handover es debida a que el CN necesita actualizar su cach de vnculos con la nueva direccin IP del MN. La configuracin depende de la latencia de conectividad. Una vez que el MN detecta el movimiento y configura su nueva CoA, debe enviar un mensaje
19
Binding Update a su HA para que cualquier paquete que llegue a su HN sea reenviado inmediatamente. Simultneamente a esto se enva un mensaje HoTI al CN mediante el tnel creado entre el HA y el MN y el mensaje CoTI directamente al CN sin usar el tnel. Cuando los mensajes HOT y COT lleguen, el nodo mvil 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. Adems todos los paquetes que se han enviado siguen llegando a la anterior CoA del nodo mvil. 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 recepcin refleja el retardo de sealizacin de Mobile IPv6. A esto hay que aadir la latencia de conectividad que refleja el retardo del proceso total de handover.
5.1.4 Reduccin de los cuellos de botella de la recepcin de paquetes

Una aproximacin para reducir este tipo de latencia es que de forma temporal el envo de los datos se haga desde el anterior AR hasta la nueva CoA (una vez hecho el handover). Este tipo de reenvo debe ser cuidadoso con el tiempo del movimiento del nodo. Por tanto este mtodo debe ser iniciado antes de que el MN deje su anterior AR o nicamente despus de que el MN establezca ya la comunicacin con el nuevo AR. Estableciendo la comunicacin antes del handover: Normalmente, el handover se produce cuando se pierde la potencia o la calidad de la seal de un enlace wireless. Esto pude pasar debido al movimiento del usuario. Sin embargo, en sistemas como WLAN, esto tambin puede ocurrir debido a congestin del punto de acceso debido a que no hay control de admisin. Tambin puede ser producido por interferencias de otros dispositivos o nodos que estn en la misma frecuencia pero con unos niveles de potencia mucho mayores (como microondas, cmaras de video-vigilancia, etc). Estas son consideraciones bsicas por las que la calidad de una seal puede disminuir y por lo tanto el handover sea necesario. Existen otras razones, por ejemplo, un nodo mvil descubre que un AR diferente le puede dar mejor servicio de acceso (mejor QoS). La red existente tambin 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 seal son aceptables. Por tanto hay un considerable inters en estandarizar un conjunto de triggers de nivel 2 que permitan el inicio de handovers. Presumiblemente, estos triggers debern notificar al software de movilidad en la pila IP cuando se producen ciertos eventos de inters. Como complemento decir que el working group del IEEE de la especificacin 802.21 estn 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 problemtica como puede ser esta ltima o los objetivos del protocolo CARD. Por tanto el modo de funcionamiento del establecimiento de la comunicacin 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 direccin teniendo en cuenta la informacin que est siendo recibida usando neighborhood discovery. El nodo mvil entonces manda un mensaje Fast Binding Update (FBU) al AR al que est dejando de manera que le pide la retransmisin de los paquetes que le llegue a la nueva direccin CoA que tena previamente calculada. En ese momento cierra la comunicacin con el antiguo AR y se conecta al nuevo AR. Cuando el AR anterior procesa el mensaje FBU, inmediatamente activa la entrada de reenvo en su tabla de encaminamiento, de tal manera que cualquier paquete que llegue a la antigua CoA ser tunelizada a la nueva direccin 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 mvil est presente en esta red responder a la llamada
20
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 despus de 1 segundo. Por otro lado, el nodo mvil 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 reenvo una vez hecho el handover En algunas ocasiones no es posible establecer el plano de reenvo 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 actualizacin de la tabla de enrutamiento slo se puede efectuar una vez que el MN obtenga conectividad en la nueva red. Hasta que se produzca la actualizacin se van a estar perdiendo los paquetes que se enven al MN. Incluso sin la actualizacin de las tablas de routing en el AR que se abandona, el nodo mvil se sigue beneficindose de la reduccin de la latencia en la deteccin del movimiento y en la configuracin de la nueva direccin IP. Desde que el MN tiene conocimiento de los routers adyacentes, puede detectar el movimiento a una nueva red y determinar la direccin del nuevo AR y la respectiva IP que ha de usar. Adems la probabilidad de colisin entre dos IP's iguales es muy pequea, se puede enviar un mensaje FBU inmediatamente al AR anterior para actualizar la tabla de routing y de esta manera minimizar la prdida de paquetes. Pero debido a cuestiones de seguridad muchos de los administradores de red no van a permitir el envo de datos a travs de sus redes con una direccin CoA que no ha sido verificada anteriormente. Por tanto este mtodo slo ser vlido en los casos en los que la red permita enviar un mensaje sin que haya sido verificado con anterioridad una direccin CoA. El nodo mvil puede enviar ms 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 prdida de paquetes sea mnima, si este no recibe un FBack antes de que abandone el AR anterior, reenviar un FBU cuando le sea posible desde su nueva ubicacin 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 peticin 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 implementacin del protocolo). Anuncio de un nuevo enlace con otro AR
Una vez vistas las herramientas para minimizar la prdida de paquetes con el AR anterior, tambin hay que intentar minimizar la prdida de paquetes con el nuevo AR (que podra descartarlos al no tener constancia de esa direccin 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 direccin 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 mvil todava no se ha enlazado con el nuevo AR, por lo tanto los paquetes estn siendo enviados a la nueva CoA, el nuevo AR deber almacenar los paquetes en el buffer para su posterior entrega al nodo mvil. 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 prdida 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 mvil va a seguir realizando todas las operaciones como son especificadas en el estndar. Estas operaciones van a introducir un overhead adicional de sealizacin en diversos escenarios. Por esta
21
razn nace Hierarchical Mobile IPv6 (HMIPv6), que fue diseado para evitar este overhead. Adems el protocolo puede ser til en cuestiones de privacidad en trminos de direcciones IP ya que con este mtodo la direccin CoA no es mostrada al CN. Por lo tanto, Mobile IP jerrquico es una extensin que se propone sobre MIPv6 para mejorar los handover dentro de un dominio (micro-movilidad). Para esto lo que se propone es la introduccin 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 sealizacin que transmite el MN cuando se produce un handover. Es por esto que desaparece el concepto de CoA como la direccin 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 tambin cambio de MAP se utilizarn Regional CoA (RcoA). La direccin LCoA es calculada cuando se produce un cambio en el router de acceso mientras que la direccin RCoA es calculada cuando hay un cambio de MAP. Por tanto para publicar la nueva direccin 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 sealizacin en muchos casos debido a que el mayor nmero de saltos que se van a producir en una red es dentro del mismo dominio. En [7] se estudia el nivel mximo que debe tener la jerarqua para que la red no se vea sobrecargada por los mensajes de control. En este trabajo se desarrolla un modelo analtico para la jerarqua multinivel de HMIPv6 y se llega a la conclusin de que en pequeas redes de hasta 128 AR aproximadamente, no es necesaria ninguna jerarqua para el ptimo funcionamiento de la red. En cuanto la red tiene un mayor nmero de AR, el nivel de jerarqua ptimo aumenta pasando a 2. El mximo de jerarqua que se recomienda en este trabajo es e 7 en el caso de que la red tenga ms de 248 AR.
F IGURA 2 - NIVEL PTIMO DE JERARQUA EN RELACIN AL NMERO DE AR
El fundamento de este estudio es la cantidad de informacin de control que se pasan los nodos de la jerarqua. 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 rpidos 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 tcnicas de multicasting para la continuidad de la conexin entre el MN y la red durante el salto.
22
PROYECTOS DE IMPLEMENTACIN DE MOBILEIPV6
En este apartado se van a exponer las principales vas encontradas, en lo que se refiere a investigacin sobre la implementacin real de los protocolos mviles basados en IPv6, es decir MobileIPv6, FMIPv6, HMIPv6 y FHMIPv6. Por el momento el ms desarrollado es MobileIPv6, esto es lgico ya que es el protocolo ms antiguo de los mencionados, adems de ser la base de todos los dems. Sobre las implementaciones de HMIPv6 y FHMIPv6 no se han encontrado proyectos significativos an, sino que todo lo realizado est basado en simulaciones con determinados programas como OMNET, OPNET y NS-2(con la ayuda de determinados mdulos externos).
6.1
Proyecto MIPL
La implementacin ms conocida para uso sobre Linux de MobileIPv6 es la realizada en la Universidad de Helsinki. MIPL Mobile IPv6 para Linux [12] empez en el ao 1999 como un proyecto de estudiantes. Despus el desarrollo fue tomado por GO-Core un proyecto ubicado en el laboratorio de Software de Telecomunicacin de HUT (Universidad de Helsinki). El cdigo fue desarrollndose a medida que aparecieron nuevos proyectos, y tambin nuevas versiones del ncleo de Linux. Al principio todo se desarrollo sobre la versin del kernel 2.3.59 y se lleg hasta la versin 8 del proyecto de MIPL. Despus de algunos cambios importantes en la especificacin de Mobile IPv6, se decidi que MIPL se dividira en un ncleo y una serie de mdulos que lo complementaran para hacer ms fcil el desarrollo del proyecto. A finales de 2003, se inici el desarrollo MIPL 2. El nuevo nmero de versin se implanta para hacer hincapi en que es un proyecto totalmente diferente de las anteriores versiones. Bsicamente, la versin 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 colaboracin con el proyecto HUT USAGI [13], con el principal cometido de poder obtener soporte IPv6 mvil en el principal ncleo de Linux.
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 informacin 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 lnea de investigacin abierta por si en futuros informes el proyecto se reactiva y aporta nuevos datos.
23
6.1.1
CONFIGURACIN DE IPv6 MVIL EN LINUX
F IGURA 3 -
ESCENARIO BSICO DE MOVILIDAD EN
IP V 6
En IPv6 desaparecen tanto los Foreign Agents como la obtencin de direcciones provisionales en las subredes visitadas por el nodo mvil a travs de DHCP. Estos procedimientos son sustituidos por la autoconfiguracin a travs de la recepcin 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 tericamente transparente. Existe la posibilidad de utilizar actualizacin 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 instalacin del mismo software que en el Home Agent y Nodo Mvil.
6.1.2
Configuracin de IPv6 mvil en Linux
6.1.2.1 Sistema operativo y kernel (para todos los equipos: Home Agent, Mobile Node y Correspondent Node.)

Cualquier distribucin de Linux. Las pruebas se han hecho con SuSE 7.3.
Implementacin de MIPv6: MIPL Mobile IPv6 for Linux, de la Universidad de Helsinki. Esta aplicacin es vlida para RedHat 6.1, 6.2, 7.0, Suse, Debian con kernel 2.4.x. Para su instalacin son necesarios conocimientos de IPv6, y configuracin, parcheado y compilacin del kernel. KERNEL: es posible utilizar USAGI http://www.linux-ipv6.org/ (es una implementacin del kernel de linux con nfasis en el soporte IPv6). Esta implementacin tiene la ventaja de que no es necesaria la aplicacin de ningn parche, ya que est sincronizada con la implementacin de HUT. Adems, este kernel posee buen soporte IPv6, por lo que existen diversas aplicaciones para IPv6 que slo funcionan con este kernel. La versin que se ha usado contiene el kernel 2.4.17.
Sin embargo, tambin es posible utilizar cualquier kernel 2.4.x de linux, con la ventaja de que es ms estable. Sin embargo, en este caso hay que aplicar un parche al kernel de linux. Este parche se obtiene en la distribucin 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.

24
Adems, al compilar el kernel habr que incluir las opciones que se recomiendan en (*).
6.1.2.2
Instalacin de USAGI
Despus 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 menuconfig (o "make config" o "make xconfig") (*) % 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 implementacin experimental, se recomienda que ciertas opciones se seleccionen a NO durante la configuracin: CONFIG_IPV6_DEBUG=n CONFIG_IPV6_6TO4_NEXTHOP=n CONFIG_IPV6_NDISC_DEBUG=n
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
Despus, se deben instalar las aplicaciones de USAGI haciendo:

% cd usagi/usagi % ./configure % make % make install
6.1.2.3
Instalacin de MIPL Mobile IPv6
Despus de descargar y descomprimir las fuentes de MIPL, entrar dentro del directorio mipv6-0.9.1-v2.4.16 y seguir los siguientes pasos: % ./configure % make % make install
6.1.2.3.1
Configuracin
La configuracin se realiza a travs de los ficheros de configuracin de Home Agent, Mobile Node y Correspondent Node. Aqu hay unos ejemplos comentados de los tres ficheros de configuracin: Home Agent Mobile Node Correspondent Node 6.1.2.3.2 Uso de MIPv6
Existe un script automtico de arranque del servicio MIPv6, llamado mobile-ip6, con las siguientes opciones: {start|stop|status|restart}. Otra posibilidad es cargar el mdulo a mano ejecutando insmod.
26
6.2
Proyecto SAM
Como introduccin a este proyecto se tiene que decir que su principal propsito fue la implementacin del FMIPv6, una evolucin de MobileIPv6, que reduca 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 implementacin de Mobile IPv6 MIPL. Particularmente, FMIPv6 debe correr en varias entidades diferentes, es decir, su implementacin estar dividida en varias mquinas diferentes: en los dispositivos mviles y en los puntos de acceso. De esta manera, implementarlo implica tener que hacerlo en diversas mquinas 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 mquinas 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 interacta directamente con el hardware) una o varias mquinas virtuales usando User Mode Linux (UML) [16]. Para finalizar con esta introduccin se tiene que hacer una mencin especial a la fuente de la que se ha sacado la mayor parte de la informacin sobre el proyecto: el boletn de rediris n 74 y 75 [17].
F IGURA 4 -
EXPERIMENTOS CON PROTOCOLOS DE MOVILIDAD
[17]
Para desarrollar el nuevo protocolo, se replic el escenario en un entorno UML, creando una mquina virtual por cada mquina fsica. El escenario virtual UML es idntico al real, se utilizan las mismas versiones de software y del Kernel de Linux. Se emul una Ethernet en la mquina fsica que comunicaba las mquinas virtuales, dicha Ethernet serva de red troncal para comunicar las diferentes entidades del escenario de pruebas. Para emular la interfaz IEEE 802.11 que comunica el dispositivo mvil con los enrutadores de acceso, se us tambin una Ethernet, es decir, no se emul el medio fsico ni MAC de la red inalmbrica. Dicha emulacin no es necesaria para una correcta evaluacin del protocolo. FMIPv6 extiende las funcionalidades de MIPv6, y es independiente de la tecnologa de nivel 2 utilizada. El handover en UML se emula desconectando la interfaz del enrutador de acceso y conectndola al siguiente. Usando este sistema se pueden evaluar diferentes aspectos de la implementacin. Se pueden realizar pruebas de carga del protocolo, es decir, estudiar cmo responde la implementacin usando varios dispositivos mviles. Tambin permite estudiar la cantidad de sealizacin que incorpora FMIPv6 respecto a MIPv6.
27
Una vez que se tena la topologa e implementacin anteriormente expuesta, se migr todo a un escenario real para realizar las pruebas pertinentes. Hay que destacar que el cdigo de UML se puede ejecutar en un entorno real. Como resultados de la implementacin del FMIPv6 tenemos los siguientes: Los paquetes fluyen hacia el dispositivo mvil con un retardo constante (inicio de la grfica), 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 mvil se reconecta al nuevo punto de acceso, el enrutador enva estos paquetes al dispositivo. Es por ello que los paquetes que se envan al dispositivo mvil 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 grfica).
F IGURA 5 - COMPARACIN ENTRE R EAL Y UML. [17]
7 COMPARATIVAS LATENCIA DE HANDOVER EN DIFERENTES PROTOCOLOS

MobileIP es un estndar propuesto por IETF para manejar la movilidad de los hosts de internet en los que se requieren comunicaciones con dispositivos mviles. Por ejemplo, se establece una conexin TCP que permanece viva y recibe los paquetes cuando el host mvil 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 computacin mvil, los ms importantes son: la alta latencia del Handover y la prdida 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 combinacin de los dos ltimos protocolos que es FHMIPv6 (esta combinacin la trataremos ms en profundidad en los siguientes informes, puesto que es la ms reciente y an est en desarrollo). Como se ha visto en el anterior prrafo, 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 prdida 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). Despus 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 conexin entre el nodo mvil 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
28
mucha atencin por parte de la comunidad de investigacin de comunicaciones. El Multihoming es una caracterstica que incorpora SCTP, la cual es conveniente para introducir la diversidad de IP en los entornos de computacin mviles. Hay que decir que aunque la comparativa estar hecha sobre STCP, SIGMA tambin puede utilizarse normalmente en infraestructuras basadas en IPv4 o IPv6 sin el soporte de MobileIP.
7.1
Handover en SIGMA sobre STCP
Para mostrar cmo se realizara un handover bsico en SIGMA nos fijaremos en la Figura 6. En la ilustracin los nodos mviles sern MH y es multi-homed, o lo que es lo mismo, estar conectado a travs 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 informacin al nodo MH.
F IGURA 6 - DISEO DE LA RED CON SIGMA Y STCP [17]
Despus de haber explicado la estructura de la red sobre la que se trabajar y como se conecta el nodo mvil con el emisor se pasar a explicar detalladamente cmo se realiza la operacin de handover que dividiremos en 5 pasos:
Primero se obtine la nueva direccin 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 debera obtener la nueva direccin IP (IP2). La direccin puede obtenerse mediante DHCP, DHCPv6 o mediante Stateless Address Autoconfiguration.
Se aade la direccin IP a la asociacin: Ahora MH tiene que informar a CN de su nueva direccin IP. Esto lo har a mediante la opcin de SCTP Addres Dynamic Reconfiguration. Esta opcin define dos nuevos tipos de fragmento (ASCONF y ASCONF-ACK) y diversos tipos de parmetros (aadir una direccin IP, Eliminar una direccin IP, establecer el conjunto primario de direcciones).
Se redireccionan los paquetes de datos a la nueva direccin IP: Cuando MH se mueve ms hacia el rea de cobertura, el punto de acceso2, CN tiene que redireccionar el trfico a la nueva direccin 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 direccin primaria de destino a IP2.
29
Actualizacin del administrador de ubicacin (LM): SIGMA soporta el administrador de ubicacin, que mantiene una base de datos con todas las correspondencias entre las identificaciones de MH y sus actuales IP primarias. MH slo puede usar una nica identificacin. Aqu se puede observar una diferencia entre SIGMA y MIP: el administrador de ubicacin y las funciones de transmisin de datos estn ligadas en MIP, mientras que en SIGMA estn separadas para agilizar el handover y hacer la puesta en funcionamiento del MH en la otra red ms flexible.
Desactivacin 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 opcin sera que MH pusiese a 0 la ventana de recepcin de informacin (la que corresponde a los datos que puede enviar CN a MN). SIGMA puede adaptarse ms fcilmente a movimientos en zig-zag de MH, con respeto a su posicin entre las dos redes, ya que mantiene la direccin antigua por ms tiempo y la puede reutilizar (puesto que la direccin IP1 no se extrae de la lista, sino que se desactiva como vlida y no se elimina hasta que el tiempo de vida de la IP1 expira). Esto reduce considerablemente la latencia y la sealizacin de trfico causada durante la obtencin de la nueva direccin IP. El proceso comentado anteriormente es el equivalente al siguiente diagrama:
F IGURA 7 -
SEALES EN EL PROCESO DE HANDOVER
[17]
30
7.2
Comparativa entre SIGMA, FMIPv6, HMIPv6 y FHMIPv6
Los datos que se expondrn a continuacin han sido tomados utilizando la herramienta de simulacin NS-2 simulator y expresarn la latencia del Handover, la prdida de paquetes y el Throughtput y la calidad de la red o (network friendliness).
F IGURA 8 -
TOPOLOGA DE LA RED
[17]
Para finalizar con los parmetros de simulacin 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 regin 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 estn sincronizados. Para hacer una comparativa clara se ha usado el protocolo SCTP, como protocolo de la capa de transporte para las mejoras de MIPv6.
31
Para que los datos sean coherentes la topologa 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 optimizacin de ruta y que SIGMA ha sido implementado sobre NS-2 simulator por los investigadores que realizaron el estudio [18]. La topologa 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 ubicacin. El Router2 actuar como un punto MAP para HMIPv6 y FHMIPv6, mientras que nicamente ser router para SIGMA y FMIPv6. Todas las dems caractersticas de la red como ancho de banda, delay de propagacin, etc. se muestran en la propia figura de la red.
Resultados obtenidos:
Latencia del Handover:
F IGURA 9 -
COMPARATIVA LATENCIA DEL HANDOVER EN SIGMA
[17]
En las anteriores grficas se puede ver cmo el tiempo de latencia del handover, tanto en el nodo router HA como en CN, es mucho ms bajo para SIGMA que para las evoluciones de MIPv6.
Prdida de Paquetes y Throughput:
32
F IGURA 10 -
COMPARATIVA PEDIDA DE PAQUETES Y THROUGHPUT EN SIGMA
1 [17]
F IGURA 11 -
2 [17]
F IGURA 12 -
3 [17]
En esta parte de la comparativa hay ms 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):
33
F IGURA 13 -
COMPARACIN DE LA CALIDAD DE LA RED CON SIGMA Y MIP
[17]
7.3
Conclusiones
Los resultados indican que para unos parmetros y configuracin de red tpicos, SIGMA tiene una latencia de handover ms pequea, tiene menor tasa de prdida de paquetes y una mayor productividad (Throughput). Por ltimo, se ha demostrado que SIGMA es mejor (ms amigable) para la red que MIP.
8 EVOLUCIN DE LOS PROTOCOLOS QUE REALIZAN HANDOVER (FHMIP, SIMP, FFHMIP)

En este apartado, se presenta un estudio de los enfoques de movilidad existentes, para la capa 3, que intentan que el tiempo de desconexin durante el handover sea mnimo. 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 mviles en internet, deja mucho que desear cuando se produce un handover mientras est activa una sesin de comunicacin. 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 investigacin. Se expondrn a continuacin una seleccin de los nuevos enfoques que se destinan a que el tiempo de desconexin, en la capa 3, mientras se est realizando un handover, y hay una sesin activa, se reduzca al mnimo.
8.1
Alcance de este informe tcnico
Este documento se centra en las variantes existentes del protocolo MobileIP. El inters especial que se tiene es el delay del handover, cmo de rpido podremos obtener la nueva direccin IP y actualizar la comunicacin con los dems 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 Sesin (SIP) y el Protocolo de Transmisin de Control de flujo (SCTP) se centran principalmente en la gestin de la movilidad en conexiones de extremo a
34
extremo y no tienen la posibilidad de lograr handover con delays cortos. La comunicacin y manejo de sesiones en estos protocolos son iniciadas y mantenidas a travs de servidores. El comportamiento de estos protocolos durante el handover es similar al de MobileIP y lo realiza sin buenos resultados cuando una sesin de comunicacin 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 combinacin de Fast Handover con Hierarchical Mobile IPv6 como extensin a MobileIPv6 (ms tarde otros autores han propuesto una evolucin de esta revisin con FF-HMIP, que ser comentado ms adelante). Por una parte, como combinacin tiene el potencial de reducir los gastos generales de sobrecarga de sealizacin y delay relacionadas con el Binding Update, despus de que se realice el handover en la capa 3(dirigido por HMIPv6). Por otro lado, tambin puede reducir las latencias relacionadas con la deteccin de movimiento y configuracin de nuevas CoA durante el handover en la capa 3 (dirigido por FMIPv6).
8.2.1
Visin general de F-HMIPv6
Los autores proponen el siguiente proceso de operacin 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. Despus, 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 (actualizacin de vnculos) de F-HMIPv6.
F IGURA 14 -
FH - HANDOVER PREDICTIVO INICIADO POR LA RED
[20]
35
Durante la realizacin del handover, los paquetes de datos enviados por los CNs sern tunelizados por el MAP hacia el nuevo router de acceso (NAR) por un tnel bidireccional, es similar al proceso que se utiliza en FMIPv6. Opcionalmente, el MAP debera empezar a redireccionar los paquetes al PAR y al NAR simultneamente. Hay que destacar que no se crea un tnel 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 mvil. Es ms, los handovers pueden ser predictivos y reactivos, pero en el caso de la opcin reactiva es slo razonable parcialmente como se podr ver ms 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 activacin) 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 seal de handover se lo indica al MAP. El mensaje de indicacin incluye PLCoA (Direccin anterior CoA) del MN y un identificador del NAR(capa de enlace o direccin IP). b) El MAP enva un mensaje de PrRtAvd al nodo mvil (MN), que contiene un anuncio de router del NAR. Los autores establecen que el mensaje debera llevar informacin acerca de la prxima direccin CoA (NLCoA) del MN, para ser usada en la regin del NAR (prefijo de red para stateless autoconfiguration o NLCoA para stateful configuration). Igual que el handover predictivo en la extensin HMIPv6, este esquema es ms 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 direccin NLCoA del MN o incluso dejarla a la eleccin del MN. Como en el caso HMIPv6, parece que dejar esta decisin a la NAR es lo ms adecuado.
36
F IGURA 15 -
FH - HANDOVER PREDICT . INICIADO POR LA RED
[20]
c) El nodo mvil NM enva un mensaje de FBU (fast binding update) al MAP. El mensaje contiene la PLCoA y la direccin IP del nuevo router de acceso (IP NAR).
d) MAP y NAR hacen un HI-HACK (intercambio de mensajes de Handover Initiate Handover Acknowledge) para establecer un tnel bidireccional entre ellos. e) MAP enva un mensaje FBACK hacia MN con la PLCoA y la NLCoA, y comienza el envo de paquetes a PLCoA dirigidos al NAR, por el tnel 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 travs de las dos direcciones NLCoA y PLCoA es porque el MN podra haber completado el handover L2 al NAR antes de que el mensaje FBACK haya sido recibido a travs del PAR (Figura 15).
37
F IGURA 16 -
FH - HANDOVER PREDIC . INICIADO POR
MN [20]
f) Cuando el MN detecta por un trigger en la capa de enlace que se ha movido al NAR, este enva un mensaje de FNA al NAR.
g) NAR enva los mensajes almacenados de FBACK al MN para el caso en el que el MN ha permanecido sin recibirlos. NAR tambin comienza la transmisin de paquetes almacenados y la entrega de los paquetes nuevos al MN. h) El MN enva 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.
38
F IGURA 17 -
FH - HANDOVER PREDIC . INICIADO POR MN
[20]
8.2.2.2
Handover F-HMIP predictivo iniciado por el nodo mvil

La forma de operacin para el handover predictivo iniciado por el nodo mvil, 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 informacin 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 enva un mensaje de RtSolPr al MAP para pedir informacin sobre el NAR. El resto de mensajes de comunicacin para la realizacin 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 envo de un mensaje de FBU mientras est todava conectado a PAR, la creacin de un tnel 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 vinculacin. Un tnel de establecimiento en este momento no es necesario, ya que el MAP puede reenviar los paquetes a NCoA directamente.
39
F IGURA 18 -
FH - HANDOVER REACTIVO
[20]
8.3
Mobile IP sin fisuras (S-MIP)
La opcin de handover que se va a presentar en este apartado es bastante interesante, pero no ha sido estandarizada por la IETF. En la referencia bibligrfica n 4 podemos ver cmo 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 poda enviar ni recibir paquetes IP. S-MIP ofrece la posibilidad de reducir an ms la perturbacin durante un handover en la capa 3( L3 ), la entrega de paquetes al MN mientras todava est conectado al PAR se combina con un pre-registro simultaneo al NAR. El paper slo sugiere el uso de un nuevo nodo llamado Decision Engine, cuyo objetivo es controlar el movimiento de los nodos mviles (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 especificacin del handover S-MIP que se describir a continuacin.
8.3.1
Visin general de S-MIP
S_MIP puede ser considerado bsicamente como una evolucin de F-HMIP. Despus de que se ha tomado la decisin de realizar el handover, cada paquete que llega de un CN al MAP, se duplicar y enviar al PAR y al NAR simultneamente. Estos paquetes sern marcados con el bit Simulcast (S bit), como un parmetro opcional en la cabecera IP. Mientras tanto, se crea un tnel 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 debera transmitir nicamente los paquetes al NAR, que no tienen activo el bit S. Adems, todos los paquetes (s / f packets) sern enviados en el canal inalmbrico por el PAR. Esto ofrece la posibilidad de que el MN pueda continuar recibiendo paquetes hasta que pierda la conexin con el PAR definitivamente.
40
F IGURA 19 -
S - MIP HANDOVER PREDICTIVO INICIADO POR EL NODO MVIL
[20]
8.3.2
Funcionamiento de S-MIP
Como en F-HMIPv6, la seal 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 slo en los mensajes iniciales y en este caso slo mostraremos como se produce el handover cuando salta el disparador del nodo mvil.
8.3.2.1
Handover S-MIP predictivo iniciado por el nodo mvil
a) El proceso comienza con el recibimiento en el nodo mvil (MN) de una seal disparada por la capa 2 (L2 trigger) que indica un handover inminente hacia el nuevo router de acceso (NAR). EL MN enva un mensaje de RtSolPr al PAR, que contiene la informacin de identificacin 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 tnel bidireccional entre ellos y averiguar la NLCoA del MN.
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 enva 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 enve al PAR y NAR. e) PAR enva un mensaje de FBACK al NLCoA y PLCoA y contina emitiendo todos los mensajes que provienen del MAP. nicamente enviar los mensajes pendientes que no tienen el bit S activado, al NAR. Estos podran 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 enva un mensaje FNA al NAR. NAR empieza a transmitir los f- packet del f-buffer. Cuando el buffer est vaco, el NAR enva 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 enva 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 envo normal de paquetes al router de acceso del MN.
8.4
FFHMIPv6
En esta seccin vamos a presentar otro mtodo para realizar el fast handover en redes MobileIPv6, el mtodo se llama Flow based Fast Handover for MIPv6, como puede extraerse de su nombre es una evolucin del FMIPv6.
8.4.1
Visin general de FFHMIPv6
FFHMIPv6 usa las caractersticas del protocolo IPv6 y los beneficios que da este protocolo al control de trfico. Al utilizar el IPv6 Flow Label cada flujo de trfico puede ser identificado y redireccionado a una nueva localizacin. Esto hace posible la recepcin de paquetes simultneamente con el proceso de registro de actualizacin de vnculos (Binding Update), minimizando as la demora experimentada en el handover. El mtodo solamente requiere algunas modificaciones en el protocolo MIPv6 existente y unos requerimientos computacionales y de memoria menores para los puntos de acceso.
El mtodo FFHMIPv6 requiere que la mayor parte de los routers que componen una red con IPv6 rellenen la propiedad de flujo de trfico (traffic flow property) y mantengan informacin de estado de los flujos de trfico. Un flujo de trfico es identificado por la etiqueta de IPv6 Flow Label y las direcciones de fuente y destino. El nodo mvil (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 trfico. Esta informacin de flujo es usada para controlar el trfico 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 direccin CoA y lo registra en el HA (Paso 2 de la figura 20). Este mensaje de registro incluye tambin una etiqueta de flujo (Flow label) de la conexin mvil. Usando esta etiqueta de flujo el router que se encuentra en el punto de cruce (AR2 de la figura 20) redireccin el flujo a la nueva localizacin del nodo mvil. Ahora se explicarn con ms precisin las funciones que tienen que realizar los nodos mviles y los routers en el mtodo de FFHMIPv6
42
F IGURA 20 -
FASES DE FFHMIPV 6
[28]
8.4.2.1
Funciones de un Nodo Mvil (MN)
El mtodo de FFHMIPv6 es usado slo cuando la direccin CoA cambia ( figura 20, paso 1). La estructura Hopby-Hop (opcin que usa IPv6), incluyendo las direcciones del HA y de los CNs y la etiqueta de Flujo, es aadida 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 parmetros usados por FFHMIPv6 son determinados por los routers. Sobre la base de esta informacin, el flujo de trfico de HA a CN (figura 20, *a) es redirigido a la nueva localizacin (Tunelizado) (figura 20, paso 4). El MN recibe y desensambla los paquetes encapsulados a paquetes IPv6. Las direcciones de fuente y destino del tnel son verificadas; la direccin fuente debe ser la de HA o la de MN y la direccin del MN la direccin antigua de CoA. De esta forma podemos tener la certeza de que los paquetes pertenecen al mtodo FFHMIPv6. El tunelizado del flujo de trfico es siempre temporal y de duracin constante (algunos segundos) as es que durante esta redireccin el MN ha tenido el tiempo suficiente para registrar la nueva direccin de CoA en el HA y CNs. Por otra parte, el nodo mvil tiene la posibilidad de deshacer el tnel IPv6 creado antes y liberar la antigua direccin CoA. Cuando el MN vuelve a ir a su red antigua, FFHMIPv6 se deshabilita para evitar los posibles bucles de enrutamiento.
43
F IGURA 21 - PROCESO D E FFHMIP V 6 [28]
8.4.2.2
Funciones de los Routers en FFHMIPv6
Los flujos de trfico pasivos tienen un tiempo de vida definido en las redes. Cuando pasa ese tiempo la informacin de estado almacenada desaparece. Como puede verse en la referencia bibliogrfica n 5 el tiempo de vida de los flujos de trfico es de 120 segundos y despus se convierten en pasivos. La informacin de estado del flujo identifica el viejo CoA, y el flujo de trfico puede ser redirigido a la nueva CoA.
La identificacin usa el mensaje de Binding Update del Hop-by-Hop frame. Todos los routers deben ir a travs de este frame(hop-by-hop). Si el router identifica la definicin de FFHMIPv6, ste maneja el frame como se indica en la ilustracin 9. Si el Flow Path (Figura 23) est definido (Flow Path = 1), FFHMIPv6 se ha hecho en la red. Utilizando la informacin del Hop-Hop frame, por el flujo de trfico, es buscado desde la informacin de estado de flujos del router. Si el flujo de trfico es encontrado, se enva un mensaje ICMP a la nueva direccin CoA del MN, y as se conoce el otro del extremo del tnel IPv6 (esto se realiza por el roturer del punto de cruce Ilustracin 7 AR2). Despus de esto, el tnel IPv6 se forma entre el router AR2 y el MN, y el flujo de trfico es redirigido por tnel. A continuacin, 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 contina.
44
F IGURA 22 -
MANEJO DE HOP - BY - HOP FRAME
[28]
En la figura 21 se describe el proceso completo de FFHMIP cronolgicamente. a) El mensaje de BU es procesado en el router AR2 (router del cruce) y el tnel IPv6 es establecido. b) Luego se procede al proceso de registro en el HA con el mensaje de BU.
c) Despus de que se ha hecho el registro en los CNs. Como se puede observar (figura 18), el flujo de trfico es redireccionado a la nueva direccin CoA antes de que el proceso de registro se haya terminado por completo.
8.4.2.3
Requerimientos especficos 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. Adems el mtodo de
45
Los paquetes de partida para la antigua direccin CoA son encapsulados en un nuevo paquete IPv6 para la nueva direccin de CoA. En otro caso, el trfico debera ser redirigido a la nueva ubicacin slo despus de que el proceso de registro ha sido realizado en HA y CNs. La conexin del tunel IPv6 permanece hasta que la direccin primaria CoA se ha registrado en HA y CNs. Despus el trfico se dirige directamente a la nueva direccin CoA sin necesidad del tunnelling.
FFHMIPv6 requiere un nuevo tipo identificador de FFHMIPv6, que se utiliza para definir los parmetros 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 opcin de Hop-by-Hop puede cambiar en la ruta. Bit 0-4 identificador de la funcin.
El que identifica al campo opcin (Option) de Hop-by-Hop fue escogido para ser el prximo disponible en la IANA (Internet Assigned Numbers Authority) (01011). Opcin Longitud de datos (Option Data Length) se determina por el nmero de conexiones mviles y de los flujos del MN. Despus 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 OPCIN DE FFHMIPV 6
[28]
El HA, MN y el CN deben enviar paquetes IPv6 utilizando el mismo Flow Label, por eso el flujo de trfico debe ser identificado correctamente. MN debe mantener la CoA antigua despus del handover, porque esta es usada dentro del tunal IPv6. Los routers deben ser capaces de realizar un tnel IPv6 y mantener la informacin de estado de los flujos de trfico.
F IGURA 24 -
ELEMENTOS QUE AFECTAN AL HANDOVER
[28]
46
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 estn implantando y testeando los equipos para realizar un estndar entre ellos.
9.1
Dispositivos
IPv6 terminal prototype de Nokia Nokia [21] y NTT Communications han desarrollado un prototipo de terminal inalmbrico que permite movilidad olvidndose de las contraseas de acceso a las redes. Esto se consigue usando una clave externa basada en tecnologa de identificacin por radio frecuencia (RFID), y es el primer prototipo del mundo que se realizar con Mobile IPv6, IPsec y protocolos RFID. En el siguiente enlace podemos ver una demostracin ilustrativa del uso del dispositivo: http://www.nokia.com/NOKIA_COM_1/About_Nokia/Research/Demos/IPv6_terminal_prototype/ipv6_te rminal3.avi.
F IGURA 25 -
DISPOSITIVO DE NOKIA CON MOBILEIPV 6
La clave de seguridad externa se introduce mediante una etiqueta con tecnologa RFID, y da un acceso fcil a la red, simplemente tocando el terminal con la etiqueta. La clave de seguridad tambin 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 inalmbricas, de manera que cuando el terminal est pasando de un punto de acceso a otro la conexin puede mantenerse.
47
9.2
Handover sin fisuras entre redes heterogneas
9.2.1
Introduccin de la investigacin
En el Congreso Mundial de mviles que se realiz el mes de Febrero en Barcelona, Intel mostr su investigacin (demo) sobre la realizacin de un handover sin fisuras entre redes WiFi y WiMAX. Otras empresas colaboradoras en el proyecto de investigacin 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 Informacin de la comandancia de servicios, mientras que Intel y Nokia se centr en los clientes de telefona mvil. Intel proporcion de funcionalidad a la Capa 2,5, incluido los eventos de la capa de enlace, la informacin del cliente y el manejo del servicio, y Nokia proporcion la gestin de Mobilidad.
9.2.2
Demostracin del handover
A continuacin se mostrar una demo que ofrece un primer vistazo a una posible solucin, aunque se va a continuar con los experimentos y mejoras de la tecnologa. En el siguiente enlace http://www.youtube.com/watch?v=hYtGG2bTEpg podemos ver al investigador Vijay Kesavan realizando una demo de cmo se realiza un handover entre WiFi / WiMAX . Si observamos el vdeo se ve cmo se est realizando una video-llamada entre el investigador y otra persona.
F IGURA 26 -
REALIZACIN DE VDEO - LLAMADA CON HANDOVER
Las innovaciones que abarcan este pequeo grupo de dispositivos orientados al consumidor (smartphones, dispositivos mviles, Internet, UMPCs, etc.) estn permitiendo que los usuarios quieran conectarse a internet e interactuar entre ellos en cualquier lugar. Un studio de ABI estima que el tamao del mercado para dispositivos mviles multimedia (con WiFi y WiMAX/3G) aumentarn de 3,4 millones de unidades en 2008 a ms de 89 millones de unidades en 2012. La demanda de la ubicuidad de mltiples servicios a travs de las nuevas redes de acceso inalmbrico se puede abordar a travs 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 mvil para la realizacin del handover horizontal (dentro de un mismo tipo de red) o vertical (a travs de la red heterognea) se pueden clasificar en tres tareas lgicas como se muestra en la figura 26, que en orden cronolgico son: 1. "cundo y por qu" El dispositivo realiza la transicin a una nueva red. 2. "donde", o a que red debera trasladarse el dispositivo.
48
3. "cmo" el dispositivo debera realizar el handover para trasladarse de una red a otra manteniendo la conectividad y sin perder la sesin. El "cundo y por qu", se activa cuando el dispositivo mvil recibe una indicacin de que un handover debera tener lugar. El handover puede ser provocado por condiciones externas, como la degradacin de la seal o la congestin de la red, el descubrimiento de una red ms adecuada, red de menor costo, mayor ancho de banda o una mejor eficiencia energtica, o ser usuario de la red a la que se va a pasar. El "dnde" pasar el dispositivo mvil, seleccionar la nueva red para conectarse, y el "cmo" se define como la forma en que el dispositivo realiza la transicin, por ejemplo, ya sea haciendo un traspaso horizontal o vertical. La red puede facilitar la seleccin de red del dispositivo mvil, proporcionando un mapa de redes que describe la presencia y caractersticas de las redes disponibles en los alrededores del dispositivo mvil. Adems la propia red puede iniciar una peticin de handover por ejemplo cuando se detecta que la carga en una de las redes de acceso est al lmite 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 -
VDEO DE EXPLICACIN DEL PROCESO DE HANDOVER
9.2.3
"El Cundo y por qu" del handover.

El objetivo es proporcionar una informacin exacta y predictiva de la situacin de las redes para que la capa de enlace pueda tener constancia de cuando hay que hacer un handover por la inminente degradacin o prdida de la seal inalmbrica. Un proceso de tres etapas predice con un alto nivel de precisin la calidad de la seal dnde se realizar el traspaso. Se pueden: 1. Suavizar las caractersticas de la seal. 2. Predecir el nivel de la seal en el futuro cercano. 3. Realizar un anlisis de las tendencias, centrndose en los mtodos que proporcionan precisin con clculos generales bsicos. Para los anteriores cometidos se usa la media exponencial para suavizado de la seal, "Lnea Recta" para la prediccin y la Transformada Rpida de Fourier, para el anlisis de las tendencias de la ventana tanto a corto como a largo plazo. Los resultados muestran que se predecir la degradacin de la capa de enlace en Wi-Fi y WiMAX con alrededor del 90% de precisin y proporcionar esta indicacin alrededor de 800 mseg a 1 segundo antes de que la prdida ocurra, con lo cual se tiene un importante margen de tiempo para adoptar medidas.
49
F IGURA 28 -
ARQUITECTURA DEL SISTEMA
[29]
9.2.4
"Hacia Dnde?" se realiza el handover
Una vez que la indicacin de una inminente desconexin es recibida, la siguiente decisin ser la seleccin de una nueva red a la que conectarse. En el entorno inalmbrico la capacidad de descubrir las redes depende de la proximidad de la fuente de la seal y el medio ambiente, por ejemplo, interferencias, obstculos, etc. Los dispositivos mviles tienden a escanear peridicamente el espacio para la "bsqueda" de redes inalmbricas, con lo que consumen energa. Aqu es donde la informacin adquirida desde la red a la que se est conectado ( por ejemplo, red informacin de ruta que describe y la presencia y las caractersticas de las otras redes) ayuda a mejorar la eficiencia energtica mediante el escaneo slo sobre los interfaces en reas geogrficas especficas. 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 batera, trmica, etc.). Las preferencias del usuario (por ejemplo, costo monetario , Operador, etc.)
Preferencias definidas por el operador de red / operador de red virtual que da servicio al dispositivo mvil.
9.2.5
Cmo se realiza el Handover
Esta seccin ya es parte de la ejecucin del handover. Hay muchos mtodos disponibles para la manipulacin se sesiones del handover, por ejemplo, Mobile IP (MIP), Proxy Mobile IP, el Protocolo de Inicio de Sesin (SIP), Voice Call Continuity (VCC 3GPP). En este caso se han utilizado aplicaciones basadas en SIP A/V.
50
F IGURA 29 -
HANDOVER PREDICTIVO EN REDES HETEROGNEAS
[29]
Usando la optimizacin que se mencion anteriormente, podemos ver en la figura 27 que podemos iniciar la ruptura antes de que los dos seales inalmbricas se solapen completamente, con suficiente margen de tiempo para que se realice el handover sin fisuras de sesiones multimedia (hay que sealar que la autenticacin no se ha tenido en cuenta aqu). Esta implementacin de Intel est basada en la especificacin del borrador de IEEE 802,21 para el cliente y los componentes de la red (Informacin del servidor y manejo del servidor) pero esto es slo una opcin de lograr el objetivo del handover sin fisuras entre redes heterogneas.
9.3 Estandarizacin y supervisin de productos preparados para MobileIpv6

En lo que se refiere a estandarizacin de los dispositivos en Japn [22] hay un grupo que se dedica a ver si los terminales que salen al mercado pasan una serie de pruebas y estn preparados para soportar Ipv6. La institucin que se encarga de esto es IPv6 Promotion Council. 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 bsico y otro ms avanzando, que sera el que nos interesara 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 direccin: http://cf.v6pc.jp/frames.html
51
Una vez que los dispositivos han pasado los test se almacenan en una base de datos que puede consultarse mediante la siguiente direccin: 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 bibliogrfica n 8 el whitepaper que contiene toda la informacin necesaria sobre los tests realizados y la instituacin.
10 OTRAS TECNOLOGAS QUE PODRAN COMPLEMENTAR A MOBILEIP

Esta seccin es creada para ir considerando diversas tecnologas que puedan complementar y facilitar el proceso en el que MobileIP realice el handover. Bsicamente iremos observando tecnologas que puedan facilitar la autenticacin en las redes, o mejorer la calidad de las mismas. Como primer paso se va a comentar la tecnologa RFID de forma bsica y general, aunque en otros informes posteriores se intentar enfocar ms hacia la autenticacin sobre redes wireless.
10.1 RFID
10.1.1
Introduccin
En trminos generales, la tecnologa RFID (Radio Frequency IDentification) permite la identificacin de objetos de forma inalmbrica, sin necesidad de que exista entre el lector y el objeto contacto o lnea de visin directa, requisito indispensable para otras tecnologas como la lectura lser de cdigos de barras. Esta identificacin se realiza mediante la incorporacin o fijacin 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 tecnologa no es nueva, los avances tcnicos en aspectos tales como alcance, seguridad, almacenamiento o velocidad de lectura entre otros, han suscitado el inters de la industria por ella, considerndola como el sustituto natural del cdigo de barras dada la importante oportunidad que RFID ofrece para conseguir una importante reduccin de costes en las cadenas de produccin y logstica. Grande empresas internacionales con una importante carga logstica o de produccin han comenzado a implantar la tecnologa o han exigido a sus proveedores que la incorporen, motivadas por las notables mejoras que supone su introduccin 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 aplicacin natural de esta tecnologa sea dentro de la cadena de produccin y distribucin, diariamente aparecen nuevas aplicaciones y oportunidades de negocio alrededor de las distintas variantes de esta tecnologa de identificacin y su combinacin con otras tecnologas. Aplicaciones sobre las que se puede encontrar una amplia bibliografa 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 (autobs, metro), pago con telfono mvil. Identificacin, localizacin y monitorizacin de personas, animales o materiales: en
52
combinacin con sensores (temperatura, humedad), tecnologa inalmbrica (wlan) o tecnologa de localizacin (GPS). Autenticidad de productos (anticounterfeiting) o documentos. Autenticacin en Redes Wireless.
F IGURA 30 -
APLICACIONES DE RFID .
IBM
Son tantas las posibilidades de utilizacin de la tecnologa RFID en todos los sectores de actividad, hoy da, que se la considera uno de los pilares bsicos de la siguiente evolucin de las redes de comunicacin, la cual ha recibido varias denominaciones (Internet of things, Ambient Intelligence, Ubiquitous Computing) aunque todas ellas se refieren al mismo concepto: la interaccin automtica e inteligente entre dispositivos en cualquier circunstancia o ubicacin, y su comunicacin con sistemas remotos de datos a travs de las redes de telecomunicacin.
53
F IGURA 31 -
INTERNET OF THINGS " NUEVA DIMENSIN .
ITU(N OMURA R ESEARCH I NSTITUTE )
Aunque an es necesario investigar y combinar distintas tecnologas para llegar a este nivel de conectividad (sensores, inteligencia artificial, nanotecnologa, movilidad, bateras), la aportacin de la tecnologa RFID es clara y fundamental en esta visin del futuro de las comunicaciones: la introduccin a bajo coste de un cdigo identificativo nico y universal en los objetos, el cual les permita autentificarse e interactuar con otro sistemas, tanto locales como remotos. Esta es la visin que los organismos responsables de la normalizacin y estandarizacin de RFID a nivel mundial (EPCGlobal, Auto-ID Labs, ISO) estn desarrollando e intentando implantar en coordinacin con todos los agentes involucrados (fabricantes, desarrolladores de software, reguladores de telecomunicaciones nacionales e internacionales). Todas estas expectativas han contribuido a que, inicialmente, la industria estimara un enorme y rpido crecimiento del mercado y de la implantacin de la tecnologa RFID a nivel mundial. El volumen de negocio total derivado de la introduccin de RFID, incluyendo tecnologas relacionadas, desarrollo de software y servicios especializados (consultora, integracin) es difcil de calcular, por lo que la mayora de los anlisis incluyen slo el derivado directamente de la introduccin de las etiquetas y equipos lectores RFID en las cadenas de produccin y suministro de forma equivalente al cdigo de barras.
F IGURA 32 -
CRECIMIENTO DEL MERCADO RFID .
IDT ECH EX
54
Sin embargo, a da de hoy, aunque los analistas siguen coincidiendo en mantener las previsiones de negocio de la tecnologa, los datos de actividad que muestra el mercado inducen a revisar las previsiones en el tiempo, ampliando el periodo de implantacin de la tecnologa a nivel mundial, dadas las barreras intrnsecas que supone no slo en cuanto a precio (el cdigo de barras no tiene coste y ya se encuentra implantado en todas las cadenas de produccin), sino tambin a nivel de complejidad tcnica (software y hardware) y a nivel normativo y regulatorio.
10.1.2
Fundamentos de RFID
En un primer acercamiento, un sistema RFID bsico se puede definir en los siguientes puntos: El objetivo de la tecnologa es la identificacin de objetos a distancia, va radio, sin necesidad de contacto ni lnea de visin directa. Una solucin bsica basada en RFID se compone de un lector con una o ms antenas, etiquetas de identificacin (tags) y un software que realice el tratamiento de la informacin recogida por los lectores.
F IGURA 33 -
SISTEMA RFID BSICO
Hay que tener en cuenta que la potencia de la tecnologa RFID reside tanto en su bajo coste como en la universalidad (serialization) y unicidad del cdigo identificador del tag (EPC, Electronic Product Code), fundamentales para las aplicaciones de la cadena de suministro. Por tanto, la estandarizacin a nivel mundial tanto del cdigo EPC (concebido como evolucin del cdigo UPC, Universal Product Code de los cdigos de barras) como de los mecanismos para su asignacin y para garantizar la interoperabilidad de los distintos sistemas es vital cuando se habla de RFID. Dada su importancia, en este documento se considerarn tambin como partes de un sistema RFID los elementos que componen lo que se ha denominado EPCGlobal Network: Cdigo EPC (EPC) Middleware EPC (Savant) ONS (Object Name Service)
EPCIS (EPC Information Services) En los siguientes apartados se revisarn las caractersticas principales de la tecnologa y de cada uno de estos componentes.
55
F IGURA 34 - CARACTERSTICAS DE LOS TANSPONDERS EN FUNCIN DE LA FRECUENCIA . A LLIED B USINESS I NTELLIGENCE I NC .
10.1.2.1
Frecuencias de funcionamiento
Han pasado ms de cincuenta aos desde el nacimiento de la tecnologa RFID, pero es en estos ltimos aos, con la intervencin de grandes retailers multinacionales, fabricantes y operadores logsticos, y la consolidacin de EPCGlobal como organismo internacional de estandarizacin, cuando se ha producido un aumento del nmero de aplicaciones que hacen uso de ella. El desarrollo progresivo de las tecnologas de fabricacin de circuitos integrados ha posibilitado el abaratamiento de los costes de produccin y la evolucin de la tecnologa hacia frecuencias de transmisin ms elevadas, lo que supone reduccin de tamao y mayor velocidad de transferencia de datos. La frecuencia de trabajo de la etiqueta y de los lectores condiciona las caractersticas fsicas de propagacin del campo electromagntico y, por tanto, las de la transmisin de los datos: tipo de acoplamiento, distancia mxima de lectura, velocidad de transmisin, sensibilidad a los materiales. Estas caractersticas condicionan tambin las aplicaciones comerciales para las que se puede utilizar la tecnologa RFID, como se puede apreciar en la siguiente ilustracin:
56
F IGURA 35 -
APLICACIONES DE RFID SEGN LA FRECUENCIA DE TRABAJO
La regulacin 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 tecnologas (WiFi, Bluetooth). Sin embargo, ste es uno de los problemas de compatibilidad a nivel mundial de la tecnologa, 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 unificacin internacional de las frecuencias a utilizar o el desarrollo de lectores y etiquetas multibanda ser necesario para que la tecnologa se pueda utilizar en todo el mundo sin problemas de compatibilidad.
10.1.2.2
Tipos de etiquetas
Una etiqueta o tag consta bsicamente de un inductor (LF, HF) o antena (UHF, W) y de un circuito integrado de distintas caractersticas segn el fabricante. Atendiendo a las distintas caractersticas de los tags, se pueden realizar las siguientes clasificaciones:
57
F IGURA 36 -
CLASIFICACIN DE TAGS RFID
En la siguiente imagen se pueden apreciar distintos diseos de tags en funcin de su alimentacin:
F IGURA 37 -
DIFERENTES TIPOS DE TAGS RFID
10.1.3
Estado actual
10.1.3.1
Tecnologa
Actualmente, el mayor desarrollo de la tecnologa RFID se est llevando a cabo en UHF debido, sobre todo, a las grandes expectativas derivadas de la trazabilidad e identificacin de productos en la cadena de produccin, y a que el mercado de productos para las aplicaciones en otras bandas de frecuencia se encuentra consolidado. Los nuevos desarrollos que se estn realizando en la industria (estndares, tcnicos) estn encaminados a eliminar las limitaciones de la tecnologa 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 diseo preciso de la antena (tamao y forma) lograr una mayor eficiencia en la recepcin, al igual que la adecuada eleccin 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 utilizacin de etiquetas activas, que poseen una alimentacin propia.
58
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 leda por un solo lector. Sin embargo, las situaciones normales sern aquellas en las que mltiples etiquetas se sitan dentro del rea de interrogacin 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 simultneamente, los rangos de lectura de las etiquetas se ven claramente reducidos debido a las interferencias en la transmisin. Los avances de la industria en este aspecto se centran en el desarrollo de los mecanismos de anticolisin, como se observa en la mejora introducida al pasar del modelo de rbol binario determinista del estndar ISO180006B al protocolo de anticolisin probabilstica Aloha ranurado que sigue el estndar EPC Class1 Gen2. Por otro lado para el caso de mltiples lectores interfirindose entre s, es suficiente con implementar una multiplexacin en frecuencia (FDMA) como la del estndar 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 composicin del objeto a etiquetar, prestando especial atencin 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 metlica 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 separacin entre el tag y el objeto es, en la mayora de los casos, suficiente para recuperar gran parte del alcance y evitar la completa desintonizacin de la antena, aunque implica mayor coste de produccin. En cuanto al mapa de memoria, hay que resaltar que aparte del identificador (tag ID), se estn desarrollando tags con memoria de usuario (User Memory), que hace posible el almacenamiento de informacin adicional referente al producto dentro de la etiqueta, lo que permite la modificacin de ciertas variables relacionadas con sus caractersticas en tiempo real. 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 modificacin del contenido de la etiqueta a partir de su aplicacin, y KILL, que deshabilita los tags volvindolos a un estado inactivo permanente, evitando que puedan volver a ser detectados una vez que los objetos a los que acompaan hayan sido adquiridos por el consumidor.
Finalmente, otras lneas de desarrollo actuales dentro de la industria buscan la integracin de la tecnologa con otras tecnologas o equipos de transmisin radio, de forma que la identificacin nica de los tems que ofrece RFID permita la autentificacin e interaccin automtica de los equipos. As, la tecnologa NFC (Near Field Communication), encaminada a las transacciones de pago y al establecimiento de conexin de forma intuitiva por parte del usuario, se basa en la tecnologa RFID de HF y en los estndares de las tarjetas prepago. Por otro lado, la integracin de RFID con equipos de redes malladas (Mesh) y sensores permitir la identificacin unvoca automtica de cada nodo y su interaccin dinmica con el resto de nodos que compongan la red.
59
60
F IGURA 38 EVOLUCIN DE LA TARJETAS RFID
[27]
11
Suites de simulacin
Una vez llegados al punto del proceso de investigacin en el que se ha conseguido una familiarizacin con la tecnologa y protocolos de MobileIPv6, se est en el punto que es necesario poner en prctica los conocimientos mediante la simulacin de posibles escenarios y variaciones de los protocolos originales. En esta seccin se pasar a ver cules son las ventajas e inconvenientes de los principales programas de simulacin 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 distribucin y que ya se est familiarizado con su programacin de escenarios en fichero tcl ( fue usado en la asignatura de Redes). En su contra se puede destacar la falta de soporte tcnico, y que no soporta ningn protocolo de movilidad en su versin base, si se quiere utilizar para este cometido es necesario instalar nuevos mdulos al programa base. En el siguiente esquema se puede ver las principales extensiones de ns-2 referentes a tecnologa MobileIP:
CMU Monarch Groups extensions de mobilidad y Wireless para NS
Mobiwan
Sun Microsystems => Mobins2, extensin que implementa MIP

Noah routing agent y mejora de HO, es implementado por Joerg Widmer
Extensin de FHMIP realizada por Hsieh.
CIMS
Ahora se pasar a explicar en qu consisten cada una de las extensiones:
61
CMU Monarch's \Wireless and Mobility Extensions to ns2: fue la primera extensin 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 posicin determinadas, era muy bsico. Actualmente est obsoleto. SUN Microsystems con Mobins2: esta es la primera extensin de ns-2 que soporta el protocolo de Mobile IP (MIP), slo implementa el handover bsico. NOAH: es un agente de ruta wireless que nicamente soporta comunicacin directa entre BSs y los nodos mviles. Por otra parte mejora la implementacin bsica de MobileIP proporcionada por SUN. Este mdulo ser de gran utilidad a los siguientes que se comentarn, y que ya realizan la implementacin de protocolos MobileIP ms evolucionados. Extensin que implementa FMIP: esta extensin soporta los protocolos MIP, HMIP y la combinacin de MIP+FMIP y HMIP+FMIP. Esta extensin est basada en la implementacin proporcionada por el proyecto de NOAH. Mobiwan: este fue un proyecto que quera estudiar la movilidad de nodos en redes de rea extensa y sobre IPv6. Los resultados del proyecto fueron la implementacin de los protocolos MIPv6 y HMIPv6. CIMS: esta extensin realiza la implementacin de la micromovilidad en el protocolo HMIP. Se necesita el mdulo MIP (de SUN) y la implementacin del agente de ruta de NOAH. Por la gran cantidad de mdulos y por la falta de robustez del sistema de simulacin que conseguiramos, esta opcin se desechar en un principio si no se encuentra nada con mejores garantas.
11.2 OMNET++
OMNET++ es un entorno de simulacin de eventos discretos, modular, orientado a objetos y de cdigo abierto. Los mdulos son programados en C++, y se ensamblan en componentes ms grandes y modelos, usando un lenguaje de alto nivel (NED), lo que permite la reusabilidad de dichos mdulos. Cuenta con una interfaz grfica de usuario muy potente y su principal rea de aplicacin es la simulacin de redes de comunicaciones, aunque tambin 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 cientfica y tambin en la industria, y han sido publicados modelos de simulacin en el mbito de internet como IP, IPv6, MPLS, protocolos de movilidad OMNET++ es gratis para uso acadmico y sin nimo de lucro, pero para su uso comercial es necesario obtener una licencia. Para las necesidades de simulacin de este proyecto, OMNET++ dispone del modelo de simulacin 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 quedara algo corto para las pretensiones de simulacin de nuestro proyecto. Tambin hay que decir que este proyecto ha quedado parado y se ha pasado a desarrollar INETFrameWork que slo incluye MobileIPv6.
11.3 OPNET
OPNET [23] es quizs algo ms que un lenguaje de programacin orientado a las comunicaciones. Proporciona acceso directo al cdigo 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.
62
OPNET dispone de un modelo de IPv6 [24] que incluye muchas caractersticas importantes para nuestras investigaciones como: Direccionamiento expandido. Implementacinde doble pila, IPv4 e IPv6. Protocolos de routing IPv6: RIPng, OSFv3, y enrutamiento esttico. Mobile IPv6. Tneles IPv6. ICMPv6. Neighbour discovery. Autoconfiguracin de direcciones IP stateless.
Adems de lo comentado anteriormente dispone de una suite (Modeler Wireless) dedicada expresamente a la simulacin en escenarios con movilidad, y entre otros protocolos da soporte a tecnologas tan punteras como el WIMAX. El nico gran inconveniente de esta aplicacin es que es de pago y slo se podra conseguir mediante la realizacin de un convenio de investigacin entre la UNEX y OPNET.
12
Simulaciones Realizadas
Despus de valorar las opciones de ms peso que hay en el mercado, en lo referente a simuladores con soporte de MobileIPv6, se lleg a la conclusin de que el ms idneo era OPNET por ser el que ms garantas y funcionalidad poda ofrecernos. El problema que se tena para usar OPNET era su licencia de pago, por lo que se intent la realizacin de un convenio entre la Universidad de Extremadura y OPNET para la adquisicin de licencias para usos acadmicos y de investigacin. Para llevar a cabo el convenio se sigui un proceso de varias semanas de contactos con la empresa para proporcionarles la informacin y datos del proyecto de investigacin que hara uso de las aplicaciones de la compaa, 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 concesin de licencias puesto que OPNET pens que su uso para el apoyo de becas de CISCO Systems podra tener un uso comercial, en vez de mramente acadmico y de investigacin. Debido a los sucesos anteriormente expuestos se opt por el uso del software de OMNET++, con el mdulo de ampliacin IPv6SuiteWithINET. Ms concretamente hemos utilizado la versin 3.3 de OMNeT++ y el CVS 20060809 de la IPv6SuiteWithINET, las ltimas disponibles, para la realizacin de todas las pruebas y
63
12.1 Eleccin del simulador
simulaciones. La eleccin de OMNeT++ se ha llevado a cabo por tratarse de un simulador de cdigo 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 instalacin, que vamos a explicar en el siguiente apartado, despus tendremos que hacer un proceso de investigacin y aprendizaje del software para comprender su funcionamiento y conseguir las estadsticas necesarias para la comparacin de las diferentes simulaciones.
12.2 Instalacin del simulador

A Priori el proceso de instalacin parece sencillo como podemos ver a continuacin en las indicaciones bsicas 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 distribucin 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 Aadimos al fichero .bashrc las siguientes lneas:
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. 3. Chequeamos el fichero configure.user para asegurarnos que contiene la configuracin que queremos.
4. Por ltimo seguimos el mtodo habitual de compilacin en Linux:

./configure
Revisamos que la salida del configure sea correcta, si no lo es posiblemente sea porque falta alguna librera que deberemos instalar y si lo es:
Make
5. Para chequear la instalacin ejecutamos los siguientes comandos:

cd ~/omnetpp/samples/dyna ./dyna
Una vez hayamos comprobado que OMNeT++ est correctamente instalado procederemos a la instalacin 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 libreras 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_instalacin]/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 instalacin 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 El contenido del script ser el siguiente: ../../../tkINET $* Lanzar el script que hemos creado, de esta forma se iniciar la simulacin del ejemplo MIPv6Network. Si la simulacin arranca y se ejecuta correctamente es porque la instalacin fue correcta.
En el equipo elegido para la simulacin, que constaba de un ordenador porttil Macbook, con sistema operativo Ubuntu 8.04, ha sido imposible instalar la extensin IPv6Suite, por problemas con la versin que llevaba Ubuntu del compilador gcc 4.2.3 y g++ 4.2.3. Parece ser que la implementacin en C++ de IPv6Suite no segua los estndares ISO actuales de C++ y no se poda llevar a cabo la compilacin del programa en el proceso de instalacin. Como solucin se opt por virtualizar el sistema operativo Deban (kernel 2.4.27) con el programa VirtualBox, de esta manera tenamos una versin antigua de gcc, en concreto la versin 3.3.5 y se pudo llevar a cabo la instalacin con xito.
65
12.3 Introduccin a las simulaciones

Como IPv6Suite da soporte a MobileIPv6 y a HMIPv6, el objetivo que tendrn 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 mvil va a seguir realizando todas las operaciones como son especificadas en el estndar. Estas operaciones van a introducir un overhead adicional de sealizacin en diversos escenarios. Por esta razn nace Hierarchical Mobile IPv6 (HMIPv6), que fue diseado para evitar este overhead. Adems el protocolo puede ser til en cuestiones de privacidad en trminos de direcciones IP ya que con este mtodo la direccin CoA no es mostrada al CN. Por lo tanto, Mobile IP jerrquico es una extensin que se propone sobre MIPv6 para mejorar los handover dentro de un dominio (micromovilidad). Para esto lo que se propone es la introduccin 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 sera 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. Nmero de mensajes emitidos en el escenario, para ver si es realmente una ventaja de HMIPv6 sobre MIPv6. Y aspectos bsicos sobre los paquetes perdidos y RRT de stos.
12.4 Escenario 1
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 versin de MIPv6 ser un router), cinco puntos de acceso inalmbricos, un nodo mvil representado por un porttil (client1) y un nodo corresponsal (server). Los routers estn conectados todos entre s mediante un internetCable que representa a una conexin a travs de Internet. Los puntos de acceso inalmbricos (ap1...ap4) y el nodo corresponsal (server) estn conectados a los routers a travs de un intranetCable que representa una conexin a travs de una red local.
66
F IGURA 39 -
ESCENARIO
La simulacin consiste en lo siguiente: Al comenzar la simulacin el nodo mvil se conecta al punto de acceso que tiene ms cerca, el Hap, y a travs de l al router que acta como su agente origen. Registra con ste su direccin origen (HoA), pero an no configura una direccin de auxilio (CoA), pues no la necesita dentro de su red origen. El nodo mvil contina movindose hacia los puntos configurados en el fichero XML, siempre en lnea recta, con una velocidad uniforme y configurable tambin en el fichero XML. El movimiento que har el cliente es simplemente pasar en lnea recta paralelamente a la lnea que forman los puntos de acceso en el escenario. A partir del tiempo configurado en Hmipv6Network.client1.pingApp.startTime desde el comienzo de la simulacin, el nodo mvil 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 simulacin. Conforme el nodo mvil se va alejando del ap1 y acercndose al ap2, la potencia de la seal que recibe del ap1 va disminuyendo y aumentando la que recibe del ap2. Cuando la seal que recibe de su actual punto de acceso (ap1) es de menor potencia que el umbral configurado en networkInterface.hoThresholdPower el nodo mvil busca un nuevo punto de acceso al que conectarse. Y de entre todos los disponibles se conecta al que reciba su seal con mayor potencia, configura su direccin de auxilio y registra esta nueva ligadura con su agente origen. Si la opcin routeOptimisation est activada en el fichero de configuracin XML el nodo mvil tambin registra su ligadura con su nodo corresponsal (slo se ha usado la optimizacin de ruta para la simulacin MIPv6). De esta forma podemos ver que el nodo mvil realizar 4 handovers a lo largo de su recorrido por el escenario. Para concluir con esta introduccin 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 simulacin de MIPv6 ser idntica al escenario anterior slo que el router MAP no tendr funcin de MAP , sino que ser un router corriente.
67
12.4.1
Resultados simulacin 1
Los resultados mostrados a continuacin para HMIP son todos sin optimizacin de ruta, puesto que esto interferira con la funcin que tiene el MAP en nuestros escenarios. Por otra parte en la simulacin de MIP se darn los resultados con la Optimizacin de Ruta activa y sin ella para as solucionar los problemas de encaminamiento en tringulo que podran aparecer. 1. La siguiente figura muestra los diferentes tiempos de duracin del handover en la capa L3, slo se darn los datos para MIPv6 ya que HMIPv6 no tiene disponible estos datos en el simulador de OMNET++:
F IGURA 40 -
ESCENARIO
HANDOVER MIPV 6
Tiempos de handover L3 con Optimizacin de ruta:

2,18 + 2,35 + 1,65 + 2,45 = 8,63 / 4 = 2,15 s. Tiempos de handover L3 sin Optimizacin 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 desconexin total (ninguna capa conectada a la red) que hay en el cliente1, de esta manera podremos comparar los tiempos de handover de la simulacin HMIPv6 y MIPv6: Tiempo total de desconexin HMIPv6: scalar "hmipv6SimpleNet.client1.linkLayers[0].networkInterface" Tiempo total de desconexin MIPv6 sin RO: scalar "mipv6SimpleNet.client1.linkLayers[0].networkInterface" Tiempo total de desconexin MIPv6 con RO: "totalDisconnectedTime" 2.2597496349 (s) "totalDisconnectedTime" 2.26107886763 (s)
68
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 trfico de informacin referente a los handovers, que sature la red. 3. Estadsticas 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
--------------------------------------------------------
-------------------------------------------------------mipv6SimpleNet.client1.pingApp con RO=on -------------------------------------------------------sent: 4200 drop rate (%): 5.47619
--------------------------------------------------------
A continuacin mostraremos las grficas referente a los tiempos de RTT de cada ping, y los pings perdidos:
69
F IGURA 41 -
ESCENARIO
COMPARACIN RTT
F IGURA 42 -
ESCENARIO
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 "hmipv6SimpleNet.worldProcessor" "totalMessageCount" Total de mensajes en MIPv6 sin RO: scalar "mipv6SimpleNet.worldProcessor" Total de mensajes en MIPv6 con RO: "totalMessageCount" 628065 658816
70
scalar "mipv6SimpleNet.worldProcessor" "totalMessageCount"
626990
12.4.2
-
Anlisis de los resultados de la simulacin 1
Escenarios que usan MIPv6:
En este caso la optimizacin 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 simulacin 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 mejora que nos otorga el Route Optimitation es el tiempo medio de RTT de los pings mandados. Comparacin 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 desconexin que tiene el nodo mvil (ninguna de la capas conectadas a la red) no hay ninguna mejora de HMIPv6 (2.26107886763 s) respecto a MIPv6 (2,25 s), aunque tambin debemos decir que esto no es una prioridad en la implementacin de HMIPv6. Por otra parte vamos a ver los resultados que conciernen a la cantidad de mensajes usados en el escenario. Aqu si tendramos que distinguir una mejora de HMIP sobre MIP, pero como podemos ver en los resultados: Total de mensajes en HMIPv6: scalar "hmipv6SimpleNet.worldProcessor" "totalMessageCount" Total de mensajes en MIPv6 sin RO: scalar "mipv6SimpleNet.worldProcessor" Total de mensajes en MIPv6 con RO: scalar "mipv6SimpleNet.worldProcessor" "totalMessageCount" 626990 "totalMessageCount" 628065
658816
No hay mejora de HMIPv6, sino que enva unos 3000 mensajes ms con lo que no libera a la red de una posible saturacin. Por ltimo y ya viendo los resultados de las grficas 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).
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 versin de MIPv6 sern routers), cinco puntos de acceso inalmbricos, un nodo mvil representado por una pda (client1) y un nodo corresponsal (server). Los routers estn conectados todos entre s mediante un internetCable que representa a una conexin a travs de Internet. Los puntos de acceso inalmbricos (hap...apc) y el nodo corresponsal (server) estn conectados a los routers a travs de un intranetCable que representa una conexin a travs de una red local.
F IGURA 43 -
ESCENARIO
La simulacin consiste en lo siguiente: Al comenzar la simulacin el nodo mvil se conecta al punto de acceso que tiene ms cerca, el hap, y a travs de l al router que acta como su agente origen. Registra con ste su direccin origen (HoA), pero an no configura una direccin de auxilio (CoA), pues no la necesita dentro de su red origen. El nodo mvil contina movindose hacia los puntos configurados en el fichero XML, siempre en lnea recta, con una velocidad uniforme y configurable tambin en el fichero XML. El movimiento que har el cliente es simplemente pasar en lnea recta paralelamente a la lnea que forman los puntos de acceso en el escenario. A partir del tiempo configurado en Hmipv6Network.client1.pingApp.startTime desde el comienzo de la simulacin, el nodo mvil 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 simulacin. Conforme el nodo mvil se va alejando del ap1 y acercndose al ap2, la potencia de la seal que recibe del ap1 va disminuyendo y aumentando la que recibe del ap2. Cuando la seal que recibe de su actual punto de acceso (ap1) es de menor potencia que el umbral configurado en networkInterface.hoThresholdPower el nodo mvil busca un nuevo punto de acceso al que conectarse. Y de entre todos los disponibles se conecta al que reciba su seal con mayor potencia, configura su direccin de auxilio y registra esta nueva ligadura con su agente origen. Si la opcin routeOptimisation est activada en el fichero de configuracin XML el nodo mvil tambin registra su ligadura
72
con su nodo corresponsal (slo se ha usado la optimizacin de ruta para la simulacin MIPv6). De esta forma podemos ver que el nodo mvil realizar 4 handovers a lo largo de su recorrido por el escenario. Para concluir con esta introduccin al escenario, diremos que este escenario cuenta con dos routers con la funcin de MAP y dos niveles en su jerarqua. La simulacin de MIPv6 ser idntica al escenario anterior slo que los routers MAP no tendrn funcin de MAP , sino que sern routers corrientes.
12.5.1
F IGURA 44 -
ESCENARIO
HANDOVER MIPV 6
Tiempos de handover L3 con Optimizacin de ruta: 2 + 1,93 + 2,3 + 1,57 = 7,8 / 4 = 1,95 s. Tiempos de handover L3 sin Optimizacin de ruta: 2 + 2,04 + 1,64 + 1,73 = 7,41 / 4 = 1,85 s.
73
2. Para poder hacernos una idea de lo tiempos de handover se usar la variable que indica los tiempos de desconexin total que hay en el cliente1, de esta manera podremos comparar los tiempos de handover de la simulacin HMIPv6 y MIPv6: Tiempo total de desconexin HMIPv6: scalar "hmipv6Draft3.client1.linkLayers[0].networkInterface" Tiempo total de desconexin MIPv6 sin RO: scalar "mipv6Draft3.client1.linkLayers[0].networkInterface" Tiempo total de desconexin MIPv6 con RO: scalar "mipv6Draft3.client1.linkLayers[0].networkInterface" "totalDisconnectedTime" 2.45764573399 (s) "totalDisconnectedTime" 2.3707206279 (s) "totalDisconnectedTime" 1.38045706633 (s)
Como puede verse en los tiempos anteriores HMIPv6 ha mejorado considerablemente los tiempos de desconexin total respecto MIPv6. 3. Estadsticas de Ping obtenidas:
-------------------------------------------------------hmipv6Draft3.client1.pingApp -------------------------------------------------------sent: 3960 drop rate (%): 10.7576
--------------------------------------------------------
-------------------------------------------------------mipv6Draft3.client1.pingApp con RO=off -------------------------------------------------------sent: 3960 drop rate (%): 8.00505
--------------------------------------------------------------------------------------------------------------mipv6Draft3.client1.pingApp con RO=on
-------------------------------------------------------sent: 3960 drop rate (%): 10.101
74
--------------------------------------------------------
A continuacin mostraremos las grficas referentes a los tiempos de RTT de cada ping enviado, y los pings perdidos:
F IGURA 45 -
ESCENARIO 2 COMPARACIN RTT
F IGURA 46 -
ESCENARIO
PINGS PERDIDOS
4.
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.
75
Total de mensajes en HMIPv6: scalar "hmipv6Draft3.worldProcessor" "totalMessageCount" Total de mensajes en MIPv6 sin RO: scalar "mipv6SimpleNet.worldProcessor" Total de mensajes en MIPv6 con RO: scalar "mipv6Draft3.worldProcessor" "totalMessageCount" 550044 "totalMessageCount" 628065 508817
12.5.2
-
Anlisis de los escenarios con MIPv6:
Como puede verse la optimizacin 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 tambin 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 mejora 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 optimizacin 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.
Comparacin de los escenarios de 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 desconexin que tiene el nodo mvil (ninguna de la capas conectadas a la red) hay una mejora de HMIPv6 (1.38045706633 s) respecto a MIPv6 (2.3707206279 s), aunque tambin debemos decir que esto no es una prioridad en la implementacin de HMIPv6.
Por otra parte vamos a ver los resultados que conciernen a la cantidad de mensajes usados en el escenario. Aqu si tendramos que ver una mejora de HMIP sobre MIP, como podemos ver en los resultados: Total de mensajes en HMIPv6: scalar "hmipv6Draft3.worldProcessor" "totalMessageCount" Total de mensajes en MIPv6 sin RO: scalar "mipv6SimpleNet.worldProcessor" Total de mensajes en MIPv6 con RO: scalar "mipv6Draft3.worldProcessor" "totalMessageCount" 550044 "totalMessageCount" 628065 508817
Hay una mejora en nmero de mensajes, en torno a los 5000, esto es bastante bueno y as podemos ver una de las grandes cualidades HMIPv6, esta mejora se puede deber al aumento a dos de los niveles jerrquicos de la simulacin.
76
Por ltimo y ya viendo los resultados de las grficas referentes al RTT y los pings perdidos, podemos decir que aqu HMIPv6 no tiene una mejora aceptable sobre MIPv6, ya que HMIPv6 tiene una tasa de 10.7576% y MIPv6 del 10.1%. Esta diferencia no es muy reseable.
12.6 Escenario 3
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 versin de MIPv6 sern routers), tambin tenemos nueve puntos de acceso inalmbricos, un nodo mvil representado por una porttil (client1) y un nodo corresponsal (server). Los routers estn conectados todos entre s mediante un internetCable que representa a una conexin a travs de Internet. Los puntos de acceso inalmbricos (hap...apd) y el nodo corresponsal (server) estn conectados a los routers a travs de un intranetCable que representa una conexin a travs de una red local.
F IGURA 47 -
ESCENARIO
La simulacin consiste en lo siguiente: Al comenzar la simulacin el nodo mvil se conecta al punto de acceso que tiene ms cerca, el hap, y a travs de l al router que acta como su agente origen. Registra con ste su direccin origen (HoA), pero an no configura una direccin de auxilio (CoA), pues no la necesita dentro de su red origen. El nodo mvil contina movindose 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 simulacin, el nodo mvil 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 simulacin. Conforme el
77
nodo mvil se va alejando del ap1 y acercndose al ap2, la potencia de la seal que recibe del ap1 va disminuyendo y aumentando la que recibe del ap2. Cuando la seal que recibe de su actual punto de acceso (ap1) es de menor potencia que el umbral configurado en networkInterface.hoThresholdPower el nodo mvil busca un nuevo punto de acceso al que conectarse. Y de entre todos los disponibles se conecta al que reciba su seal con mayor potencia, configura su direccin de auxilio y registra esta nueva ligadura con su agente origen. Si la opcin routeOptimisation est activada en el fichero de configuracin XML el nodo mvil tambin registra su ligadura con su nodo corresponsal (slo se ha usado la optimizacin de ruta para la simulacin MIPv6). De esta forma podemos ver que el nodo mvil realizar 8 handovers a lo largo de su recorrido por el escenario. Para concluir con esta introduccin al escenario, diremos que este escenario cuenta con nicamente un router con la funcin de MAP y es una jerarqua de un nico nivel. La simulacin de MIPv6 ser idntica al escenario anterior slo que el router MAP no tendrn funcin de MAP , sino que sern routers corrientes.
12.6.1
F IGURA 48 -
HANDOVER MIPV 6 ESCENARIO
Tiempos de handover L3 con Optimizacin 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 Optimizacin 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 desconexin total que hay en el cliente1, de esta manera podremos comparar los tiempos del handover de la simulacin HMIPv6 y MIPv6: Tiempo total de desconexin HMIPv6: scalar "hmipv6SaitNet.client1.linkLayers[0].networkInterface" Tiempo total de desconexin MIPv6 sin RO: scalar "mipv6SaitNet.client1.linkLayers[0].networkInterface" Tiempo total de desconexin MIPv6 con RO: scalar "mipv6SaitNet.client1.linkLayers[0].networkInterface" "totalDisconnectedTime" 3.79097444129 (s) "totalDisconnectedTime" 3.66375191027 (s) "totalDisconnectedTime" 3.70109915269 (s)
Como puede verse en los tiempos anteriores HMIPv6 no tiene una mejora considerable en los tiempos de desconexin total respecto MIPv6. 3. Estadsticas de Ping obtenidas:
-------------------------------------------------------hmipv6SaitNet.client1.pingApp -------------------------------------------------------sent: 7200 drop rate (%): 2.23611
--------------------------------------------------------
-------------------------------------------------------mipv6SaitNet.client1.pingApp con RO=off -------------------------------------------------------sent: 7200 drop rate (%): 5.29167
--------------------------------------------------------------------------------------------------------------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 continuacin mostraremos las grficas referentes a los tiempos de RTT de cada ping enviado, y los pings perdidos:
F IGURA 49 -
ESCENARIO
COMPARACIN RTT
F IGURA 50 -
ESCENARIO
PINGS PERDIDOS
80
4.
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" Total de mensajes en MIPv6 sin RO: scalar "mipv6SaitNet.worldProcessor" "totalMessageCount" Total de mensajes en HMIPv6 con RO: scalar "mipv6SaitNet.worldProcessor" "totalMessageCount" 966060 1131903 "totalMessageCount" 1218981
12.6.2
-
Anlisis de los escenarios con MIPv6:
Como puede verse la optimizacin 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 tambin se produce un ligersimo aumento de las pings perdidos, que pasa de un 5,29% a un 5,44%. Sin embargo se obtiene una gran mejora 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 optimizacin 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. Comparacin 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 desconexin que tiene el nodo mvil (ninguna de la capas conectadas a la red) hay una mejora de HMIPv6 (3.70109915269 s) respecto a MIPv6 (3.79097444129 s) aunque tambin debemos decir que esto no es una prioridad en la implementacin 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 tendramos que ver una mejora de HMIP sobre MIP, como podemos ver en los resultados: Total de mensajes en HMIPv6: scalar "hmipv6SaitNet.worldProcessor" Total de mensajes en MIPv6 sin RO: scalar "mipv6SaitNet.worldProcessor" "totalMessageCount" Total de mensajes en HMIPv6 con RO: scalar "mipv6SaitNet.worldProcessor" "totalMessageCount" 966060 1131903 "totalMessageCount" 1218981
81
En este caso (igual que el primer escenario) no se nota mejora en la disminucin del flujo de mensajes producido por los handovers, sino que se aumenta el nmero de mensajes enviados en la simulacin de HMIPv6. Por ltimo y ya viendo los resultados de las grficas referentes al RTT y los pings perdidos, podemos decir que aqu HMIPv6 en este caso tiene una gran mejora 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

Despus 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 simulacin OMNET++ para el fin de comparar HMIPv6 y MIPv6. Como conclusin principal de la simulacin se puede decir que HMIPv6 no tiene una ventaja considerable con respecto al tiempo de Handover sobre MIPv6, aunque ya se saba por las investigaciones tericas que HMIPv6 no se centraba en la minimizacin del tiempo de dexconexin del Handover. Se debe recalcar, acerca de la comparacin 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 hndicap a la hora de poder realizar las simulaciones y las comparativas entre los dos protocolos, ya que no se sabe el tiempo exacto de desconexin de la capa de transporte, aunque para conseguir solucionarlos nos fijamos en el tiempo total de dexconexin que haba durante toda la simulacin y as se sacaron las conclusiones sobre los tiempo de handover en cada uno de los escenarios anteriores. 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 enva un BUpdate al MAP y despus un LBU tambin al MAP, supuestamente slo es necesario enviar el LBU y por ello puede verse aumentado el tiempo de handover, como puede verse en la grfica que se mostrar a continuacin:
F IGURA 51 -
BINDING UPDATE EN HMIP
82
Despus de mucho investigar en los foros sobre OMNET++ se descubri que es un bug, que corregirn los desarrolladores de OMNET++ (aunque han dejado de desarrollar IPv6Suite). Por otra parte en lo que se refiere al trfico de mensajes que se enviaran en un handover, HMIPv6 debera reducir considerablemente la emisin de Bupdates, pero como se ha visto a veces incluso enva ms mensajes. De todas maneras como se ha dicho en la introduccin terica de HMIPv6 la mejora empieza a verse cuando hay entre dos y siete niveles en la jerarqua HMIPv6 y al menos 128 AR.
13
Conclusiones y lneas de investigacin 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 investigacin. Por una parte se ha realizado un proceso de investigacin y puesta al da 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 informacin adquirida se puede decir que el handover dentro de Mobile IP est en continua evolucin y que an le falta bastante camino para conseguir que se implante en las redes inalmbricas actuales, debido a incompatibilidades y deficiencias de los actuales protocolos. Los protocolos actuales que controlan el handover sobre mobileIP estn en fases de pruebas y sin una estandarizacin completa, se puede decir que este es el momento idneo para el estudio de dicha tecnologa, y poder aportar propuestas e innovaciones. Como segundo gran punto en estas conclusiones hay que destacar que los programas de simulacin actuales para las tecnologas de mobileIP no estn 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. Sera muy interesante conseguir licencias de las aplicaciones de pago necesarias para realizar simulaciones lo suficientemente precisas. Lneas futuras de investigacin: Realizacin de simulaciones en escenarios virtuales
Despus del proceso de investigacin y bsqueda de informacin sobre Mobile IPv6 y sus diferentes versiones de protocolos, hemos llegados al punto en el que se debemos poner en prctica los conocimientos adquiridos. Una vez sopesados todos los pros y contras de las aplicaciones que permiten la simulacin de redes del mercado, como pueden ser NS-2, OMNET++ y OPNET [23], se ha llegado a la conclusin de que la que mejor podra cubrir nuestras necesidades sera 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, adems de de otros [24] que nos podran resultar interesantes como el soporte de Wimax. As se podrn realizar distintos escenarios de simulacin 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 implementacin y redefiniciones del protocolo estndar. OPNET es un programa de pago, y actualmente el grupo de investigacin de GITACA est trmites de conseguir una serie de licencias para usar este programa en labores de investigacin.
Realizacin de simulaciones sobre equipos reales
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, sera 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 tecnologa. Entre los dispositivos que tenemos ya en el laboratorio de Ingeniera Telemtica del grupo GITACA, disponemos de un analizador de espectros que, junto con el hardware que pudiese aportar CISCO, nos posibilitara realizar estudios del comportamiento del protocolo en entornos de interferencias con otras tecnologas inalmbricas. Cisco dispone de nueva tecnologas, como CISCO IOS, que ha integrado en dispositivos de encaminamiento para ofrecer soporte de nuevas tecnologas como Mobile IP, por lo tanto, Las caractersticas de Mobile IP estn 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
Adems, CISCO dispone de la Serie 3200 donde se incluyen routers que dan un aporte adicional a las tecnologas de comunicaciones mviles para permitir subredes mviles con soporte tanto para Mobile IP como para proxy Mobile IP.
Por otra parte tambin sera interesante disponer de puntos de acceso inalmbrico como Cisco Aironet Access points y conectarlos con dispositivos Wlan Controllers para permitir un control detallado de la infraestructura.
84
14
Referencias
[1] IP Mobility Support for IPv4. RFC 3344 [2] Mobility Support in IPv6. RFC 3775 [3] Redes de Computadores e Internet (5 Edicin). 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 Investigacin 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. [10] S. Thomson, Bellcore, T. Narten, IPv6 Stateless Address Autoconfiguration, IETF RFC 2462, 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] Implementacin de IPv6 para Linux: http://www.linux-ipv6.org/ [14] Software para incluir MIPv6 en Linux: http://www.mobile-ipv6.org/software/ [15] Proyecto SAMAdvanced Mobile Services: http://sam.ccaba.upc.edu/ [16] UML User-Mode-Linux: http://user-mode-linux.sourceforge.net/ [17] Boletn 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.
85
[20] Handover Blackout Duration of Layer 3 Mobility Management Schemes, Svetoslav Yankov y Sven Wiethoelter,Universidad de Berln: 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] Estandarizacin de dispositivos con Mobile IP: http://cf.v6pc.jp/frames.html [23] Web de OPNET: www.opnet.com [24] Librera de protocolos de OPNET: http://www.opnet.com/support/des_model_library/ [25] Pgina de descarga OMNET++: http://www.omnetpp.org/filemgmt/viewcat.php?cid=2 [26] Pgina 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 Hmlinen, Ari Viinikainen and Jani Puttonen, Universidad de Jyvskyl: www.tzi.de/~dku/teach/enss05/01/vtc04MN_13_6.pdf [29] Pruebas y estudio del handover entre redes heterogneas, Vijay Kesavan: http://blogs.intel.com/research/2008/02/wifi_wimax_handover.php
15
BIBLIOGRAFA
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 2004IEEEInternational 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 Handos 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.
86
Miska Sulander, Timo Hmlinen, Ari Viinikainen, y Jani Puttonen. Departamento de tecnologa de informacin matemtica de la universidad de Finlandia. http://kom.aau.dk/group/05gr995/05995/Links-files/fh.pdf. Vijay Kesavan, investigador de Intel. Demo de la investigacin sobre handover sin fisuras en redes heterogneas http://blogs.intel.com/research/2008/02/wifi_wimax_handover.php. Informacin sobre la institucin reguladora de IPv6 a nivel mundial, que realiza la estandarizacin 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/.
87

Analisis y Optimizacion Del Handover en Redes MobileIP

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Analisis y Optimizacion Del Handover en Redes MobileIP

Caricato da

Copyright:

Formati disponibili

Anlisis y Optimizacin del Handover en redes MobileIP

UNIVERSIDAD DE EXTREMADURA GTACA

Grupo de investigacin de Ingeniera Telemtica Aplicada y Comunicaciones Avanzadas www.gitaca.es

Anlisis y Optimizacin del Handover en redes MobileIP

Anlisis y Optimizacin del Handover en redes MobileIP

Anlisis y Optimizacin del Handover en redes MobileIP

Anlisis y Optimizacin del Handover en redes MobileIP

GLOSARIOTRMINOS UTILIZADOS SOBRE MOBILEIP

Trminos especficos del handover

Anlisis y Optimizacin del Handover en redes MobileIP

Anlisis y Optimizacin del Handover en redes MobileIP

Anlisis y Optimizacin del Handover en redes MobileIP

En los siguientes puntos se va a detallar cada una de estas fases.

Deteccin del movimiento en una red

Anlisis y Optimizacin del Handover en redes MobileIP

Protocolo Neighbor Discovery

Descubrimiento de otros Home Agents

Anlisis y Optimizacin del Handover en redes MobileIP

Adquisicin de una nueva CoA

Duplicate Address Detection (DAD)

Actualizacin de los vnculos

Uso de la cach de vnculos

Alternate Care-of Address Binding Authorization Data Binding Refresh Advice

Fast Handover en Mobile IP6

Anlisis y Optimizacin del Handover en redes MobileIP

5.1.1 Cuellos de botella producidos por la latencia de conectividad

Reduccin de los cuellos de botella de la conectividad

5.1.3 Cuellos de botella producidos por la latencia de recepcin de paquetes

5.1.4 Reduccin de los cuellos de botella de la recepcin de paquetes

Anlisis y Optimizacin del Handover en redes MobileIP

Anlisis y Optimizacin del Handover en redes MobileIP

F IGURA 2 - NIVEL PTIMO DE JERARQUA EN RELACIN AL NMERO DE AR

PROYECTOS DE IMPLEMENTACIN DE MOBILEIPV6

CONFIGURACIN DE IPv6 MVIL EN LINUX

ESCENARIO BSICO DE MOVILIDAD EN

Configuracin de IPv6 mvil en Linux

Anlisis y Optimizacin del Handover en redes MobileIP

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

Despus, se deben instalar las aplicaciones de USAGI haciendo:

% cd usagi/usagi % ./configure % make % make install

Instalacin de MIPL Mobile IPv6

Anlisis y Optimizacin del Handover en redes MobileIP

EXPERIMENTOS CON PROTOCOLOS DE MOVILIDAD

Anlisis y Optimizacin del Handover en redes MobileIP

F IGURA 5 - COMPARACIN ENTRE R EAL Y UML. [17]

7 COMPARATIVAS LATENCIA DE HANDOVER EN DIFERENTES PROTOCOLOS

Handover en SIGMA sobre STCP

F IGURA 6 - DISEO DE LA RED CON SIGMA Y STCP [17]

Anlisis y Optimizacin del Handover en redes MobileIP

SEALES EN EL PROCESO DE HANDOVER

Comparativa entre SIGMA, FMIPv6, HMIPv6 y FHMIPv6

Anlisis y Optimizacin del Handover en redes MobileIP

Latencia del Handover:

COMPARATIVA LATENCIA DEL HANDOVER EN SIGMA

Anlisis y Optimizacin del Handover en redes MobileIP

Prdida de Paquetes y Throughput:

COMPARATIVA PEDIDA DE PAQUETES Y THROUGHPUT EN SIGMA

COMPARATIVA PEDIDA DE PAQUETES Y THROUGHPUT EN SIGMA

COMPARATIVA PEDIDA DE PAQUETES Y THROUGHPUT EN SIGMA

Calidad de la red o (network friendliness):

Anlisis y Optimizacin del Handover en redes MobileIP

COMPARACIN DE LA CALIDAD DE LA RED CON SIGMA Y MIP

8 EVOLUCIN DE LOS PROTOCOLOS QUE REALIZAN HANDOVER (FHMIP, SIMP, FFHMIP)

Alcance de este informe tcnico