Instalación de MobileIP

1. Introducción

En este documento se explica como realizar la instalación de Mobile IP sobre linux. El trabajo se ha realizado sobre 4 PCs con la distribución de linux Debian en version testing, y los PCs tienen kernel 2.4.1.

Para empezar lo primero que hay que hacer es crear dos subredes distintas, y después instalar instalar el software necesario para hacer funcionar Mobile IP.

2. Creación de dos subredes

Lo primero que hay que hacer es crear dos subredes para poder hacer las pruebas con la implementación de Mobile IP de la Helsinki University of Technology. Para ello, uno de los requisitos es que el Home Agent y el Foreign Agent están en distintas subredes.

La estructura de la red elegida es la siguiente:

Esquema de la maqueta

Para ello hay que seguir varios pasos:

* Recompilar los kernels de los PCs con las opciones adecuadas.
* Configurar los interfaces de red.

2.1 Recompilar kernels

La primera etapa a la hora de recompilar el kernel es (si no se tienen ya) instalarse los ficheros fuentes del kernel. Para trabajar con Dynamics (la implementación de la Helsinky University of Technology para Mobile IP) es necesario tener un kernel con versión 2.2.x o superior (la versión actual a fecha de hoy del kernel de linux es la 2.4.3).

Para conseguir instalarte los ficheros fuentes del kernel puedes usar tu forma habitual de instalar paquetes en linux (a partir de la herramienta ”dselect” si tu distribución es Debian, o directamente a partir del fichero .deb también en Debian, o bien del .rpm si usas Red Hat).

El lugar por defecto donde se instalarán los fuentes es ”/usr/src/kernel-2.x.x/” (si estás en Debian). Lo siguiente que hay que hacer es arrancar una de las tres herramientas que te permiten recompilar el kernel. Para ello hay que situarse en el diretorio anteriormente mencionado y ejecutar una de estas tres opciones:

* make menuconfig
* make oldconfig
* make xconfig

Nosotros utilizamos la tercera de las opciones, ”make xconfig”, que usa las X y es más vistosa.

Una vez arrancada la herramienta para recompilar el kernel, se han de seleccionar las siguientes opciones para que funcione correctamente la solución Dynamics de la Helsinky University of Technology para Mobile IP. Las opciones que hay que seleccionar son las siguientes (todas incluidas dentro de la sección Networking options:

* Packet socket (opción CONFIG_PACKET)
* Kernel/User netlink socket (opción CONFIG_NETLINK)
* Routing messages (opción CONFIG_RTNETLINK)
* Socket filtering (opción CONFIG_FILTER, para los MNs; opcional pero recomendado)
* IP: advanced router (opción CONFIG_ADVANCED_ROUTER, para los FAs)
* IP: policy routing (opción CONFIG_IP_MULTIPLE_TABLES, para los FAs)
* IP: tunneling (opción CONFIG_NET_IPIP)

Aunque vienen opciones con el comentario ”para los MNs” o ”para los FAs ” es conveniente marcarlas todas a pesar de que nuestra máquina no vaya hacer la función que se cita.

Con las opciones ya marcadas, sólo queda guardar los cambios y recompilar el kernel:

* make dep
* make clean
* make bzImage
* make modules
* make modules_install

Ya está preparado el kernel para poder funcionar con Dynamics y para que la máquina encargada de hacer de router de las redes encamine los paquetes. Sólo queda actualizar LILO. Para ello hay que hacer una copia de la imagen del kernel recién compilado (bajo ”/usr/src/kernel/2.x.x/arch/i386/boot/bzImage”) dentro del directorio con las imágenes de kernel habitual (normalmente en ”/boot”):

* cp arch/i386/boot/bzImage /boot/vmlinuz-2.x.x

Ahora hay que añadir una nueva entrada en el fichero ”/etc/lilo.conf” con el siguiente texto:


image=/boot/vmlinuz-2.x.x
label=Linux-2.x.x
readonly

Si se han completado todos estos pasos satisfactoriamente, lo único que queda es ejectuar ”lilo” desde un terminal (para que los cambios realizados en ”/etc/lilo.conf” tengan efecto) y reiniciar la máquina. Cuando aparezca LILO escribiremos Linux-2.x.x y ya tendremos nuestro equipo con la configuración adecuada.

2.2 Configurar interfaces de red

El fichero clave a la hora de configurar las interfaces de red es el fichero ”/etc/network/interfaces”. De este fichero coge la información el kernel cuando arranca para configurar las interfaces de red que tenga la máquina.

El fichero de configuración de interfaces para el router de nuestras redes tienen el siguiente aspecto:

# /etc/network/interfaces — configuration file for ifup(8), ifdown(8)

# The loopback interface
# automatically added when upgrading
auto lo
iface lo inet loopback

# The first network card – this entry was created during the Debian installation
# (network, broadcast and gateway are optional)
# automatically added when upgrading
auto eth1
iface eth1 inet static
address 192.168.242.3
netmask 255.255.255.0
network 192.168.242.0
broadcast 192.168.242.255
gateway 192.168.242.3
auto eth0
iface eth0 inet static
address 192.168.240.3
netmask 255.255.255.0
network 192.168.240.0
broadcast 192.168.240.255
gateway 192.168.240.3

Tras configurar la interfaz de loopback, se configuran las dos tarjetas de red que tiene el router, eth0 y eth1 con las direcciones IP 192.18.240.3 y 192.168.242.3 respectivamente.

Otras informaciones relevantes son la máscara de red, la dirección de la red, la dirección de broadcast y el gateway.

Para asegurarse que las interfaces de red están correctamente configuradas se puede usar el comando ”ifconfig” desde un terminal. Si las interfaces están bien configuradas debería mostrarse una información como la que sigue (ejemplo de una máquina con una sola tarjeta de red):

eth0 Link encap:Ethernet HWaddr 00:01:02:29:3E:59
inet addr:192.168.242.3 Bcast:192.168.242.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1617627 errors:0 dropped:0 overruns:0 frame:0
TX packets:80109 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:787664102 (751.1 Mb) TX bytes:23374191 (22.2 Mb)
Interrupt:10 Base address:0xd800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16144 Metric:1
RX packets:269 errors:0 dropped:0 overruns:0 frame:0
TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:14508 (14.1 Kb) TX bytes:14508 (14.1 Kb)

Para activar/desactivar interfaces de red se usa este mismo comando ”ifconfig” con una serie de argumentos. Así, para desactivar la interfaz eth0 se usa:

* ifconfig eth0 down

Si lo que se quiere es levantar un interfaz se ha de usar la siguiente línea (por ejemplo, para levantar la interfaz de la máquina cuya dirección IP es la 192.168.242.1):

* ifconfig eth0 192.168.242.1 up

Con el comando ”netstat -rn” se puede visualizar la tabla de encaminamiento del kernel de una máquina:

debian:# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface
192.168.242.1 0.0.0.0 255.255.255.0 U 40 0 0
eth0

Para añadir una nueva ruta a esta tabla de encaminamiento se usa el comando ”route” de la siguiente forma:

* route add -net 0.0.0.0 gw 192.168.242.1 dev eth0

Otro aspecto a tener en cuenta en la máquina que hace de router es el contenido del fichero ”/proc/sys/net/ipv4/ip_forward”. Para que el router funcione perfectamente ha de contener un 1, pues por defecto el valor que trae es 0.

Con toda esta información, ya es posible montar dos subredes como las de la figura al comienzo del capítulo y comenzar a probar la implementación Dynamics para Mobile IP de la Helsinky University of Technology.

3. Instalar Mobile IP

Una vez que las dos redes están montadas y funcionan perfectamente ya podemos empezar a instalar el software necesario para hacer funcionar Mobile IP en nuestras subredes.

3.1 Instalación del software

El software utilizado lo puedes encontrar en http://www.cs.hut.fi/Research/Dynamics/software.html. Actualmente está disponible en paquetes .deb, .rpm (hasta versión 0.6.1), pero tuvimos problemas con esta versión que se arreglaron cuando pasamos a la versión 0.6.2, disponible solamente en formato .tar.gz.

La implementación necesita como mí­nimo un kernel 2.2.x, y resumiendo las opciones necesarias son las siguiente:

* Networking options:

Packet socket (CONFIG_PACKET)
Kernel/User netlink socket (CONFIG_NETLINK)
Routing messages (CONFIG_RTNETLINK)
IP: Socket Filtering (CONFIG_FILTER)
IP: tunneling (CONFIG_NET_IPIP)

* Adicionalmente para los Foreign Agents:

IP: Advanced router (CONFIG_IP_ADVANCED_ROUTER)
IP: policy routing (CONFIG_IP_MULTIPLE_TABLES)

* Opción adicional para el MN si se quiere probar con wireless:

Wireless LAN (non-hamradio) (CONFIG_NET_RADIO)

Por lo tanto el primer paso es conseguir esos paquetes y prepararnos para instalarlo en cada uno de los nodos (Mobile Node, Foreign Agent y Home Agent). Descomprimimos los fuentes:

tar xvfz dynamics-0.6.2.tar.gz

Después compilamos e instalamos de la manera tradicional:

* ./configure
* make
* make install

Tenemos que seguir esos pasos en cada uno de los nodos, y ya tendremos instalado el software para trabajar con Mobile IP sobre IPv4.

3.2 Configuración

Lo siguiente que tenemos que hacer es configurar cada uno de los nodos, para que haga la función de MN, HA o FA. Para ello tenemos unos ficheros de configuración bastante bien comentads en /usr/local/etc/ que se llaman:

* /usr/local/etc/dynmnd.conf: Para el Mobile Node.
* /usr/local/etc/dynhad.conf: Para el Home Agent.
* /usr/Local/etc/dynfad.conf: Para el Foreign Agent.

Después de instalar, los ficheros ya tienen por defecto una configuración básica para probar Mobile IP. Esta configuración es la siguiente:

Las direcciones IP son las que se muestran al principio del documento, y el comienzo de la prueba comienza cuando el MN está en la red de “casa”, es decir con el HA.

Al comenzar la ejecución el HA manda mensajes para ver si el MN está en casa, si es así­ el MN se registra en su HA y todo el tráfico del MN va directamente desde y hacia el MN (CN->MN y MN->CN).

Cuando cambiamos al MN de su red y lo llevamos a la red del Foreign Agent, el FA está mandando mensajes a ver si llega el MN, y cuando llega (sin cambiar la dirección IP) se registra en el FA, y entonces el FA establece un tunnel entre el FA y el HA. Desde ese momento todo el tráfico del MN, pasa desde el CN->HA->FA->MN y al revés MN->FA->HA->CN. Este modo se llama FA decapsulation, porque los paquetes llegan “encapsulados” hasta el FA, que es quien los desencapsula y se los entrega al MN.

Los parámetros de configuración más importantes de cada uno de los nodos son los siguientes:

* Home Agent:

# Dirección IP del Home Agent
HAIPAddress 192.168.242.1

# Número máximo de nodos conectados
MaxBindings 20

# Tiempo de vida del tunnel
HADefaultTunnelLifetime 600

# Especifica que manda avisos para localizar al MN
SendAdvertisements TRUE

# Tiempo entre avisos
AdvertisementInterval 1

# Triangle tunneling. Los paquetes van MN->FA->HA->CN y CN->HA->FA->MN
EnableTriangleTunneling TRUE

* Mobile Node:

# Dirección IP del MN
MNHomeIPAddress 192.168.242.2

# Dirección IP del HA
HAIPAddress 192.168.242.1

# FADecapsulation. Los paquetes hacia el MN son desencapsulados por el
# FA. Esto debe ser así­ si la dirección IP del MN no cambia cuando se
# va a la Foreign Network
EnableFADecapsulation TRUE

* Foreign Agent:

# Se especifica el interfaz que utiliza en FA, y el intervalo de
# tiempo entre los mensajes de aviso que manda.
INTERFACES_BEGIN
# interface type agentadv interval force_IP_addr
eth0 1 1 30

# Dirección IP del FA mayor. Esta opción y la siguiente se utiliza
# porque puede haber una estructura de FA en árbol, y solo el HighestFA
# se comunica con el HA
dHighestFAIPAddress 192.168.240.1

# Especifica si este nodo es el HiguestFA, quien se comunica con el HA.
HighestFA TRUE

3.3 Ejecución

Después de configurar los nodos, hay que lanzar los demonios que corren en cada uno de ellos y empezar a hacer pruebas. Para arrancar los demonios:

* MN: dynmnd -fg -debug -no-wireless Con esto conseguimos que se ejecute en ForeGround y en modo debug para poder observar posibles errores, y ver todo el proceso de comunicación entre los nodos. También se indica que no se utiliza wireless.
* HA: dynhad -fg -debug Igual que antes, se ejecuta en foreground y en modo debug.
* FA: dynfad -fg -debug Idem …

Con todos estos pasos se consigue hacer funcionar Mobile IP, pero hay muchas opciones que se pueden variar en los ficheros de configuración para poder hacer pruebas …

4. Experiencia Propia

Bueno, pues a partir de aquí­ vamos a contar un poco cual ha sido nuestra experiencia con este software y cuales han sido los problemillas que hemos ido teniendo.

Nuestras primeras pruebas las hicimos con los ficheros de configuración tal cual vienen con los fuentes, pero esto no nos termino de funcionar. El problema que teniamos era con el parámetro timestamp, definido en el Home Agent, que por defecto venía puesto a 400. Este parámetro comprueba algo así­ como la diferencia horaria entre el HA y FA, hace alguna comprobación de ese tipo por razones de seguridad. Lo que hicimos fue sincronizar los relojes y reducir ese tiempo poniéndolo a 120 y empezá a funcionar más o menos bien.

Después teníamos el problema de que tardaba mucho en empezar a establecerse el tunnel cuando el MN se cambiaba a la Foreign Network. Después de investigar mucho, y al final recurriendo al código fuente, observamos que el tiempo que tardaba en empezar a establecerse el tunel era igual a 3 veces el intervalo de tiempo con el que el HA mandaba mensajes de aviso. Es algo aparentemente sin sentido, pero puede que tenga alguno, hemos mandado un mensaje a los desarrolladores para que nos lo expliquen, pero todavía no nos han contestado. La solución a este problema es reducir el intervalo de tiempo en el que el HA manda los mensajes de aviso al MN, y el tiempo que tarda en empezar a establecerse el tunel también se reduce. Actualmente tenemos puesto este intervalo a 1 segundo. (Este parámetro, que está en el fichero de configuración del HA se llama AdvertisementInterval).

Montaje de una maqueta de movilidad IP sobre IPv4

1. Introducción

En este documento se explica el montaje de una maqueta construida sobre una serie de PCs, para hacer pruebas sobre varias implementaciones de movilidad en IPV4 y también una implementación de Cellular IP.

La parte fundamental de la maqueta se basa en el siguiente esquema:

Esquema de la maqueta

El objetivo de este esquema es poder tener el mayor número de subredes, con el menor número de ordenadores. Tenemos 5 ordenadores, y también tenemos 5 subredes. Solamente 1 ordenador está conectado directamente a Internet, y hace de ProxyARP para que los demás también puedan acceder.

Las direcciones IP que usamos para las subredes tienen la siguiente estructura: 29 bits para la direccién de red, y 3 bits para la dirección de máquina. Por tanto podemos tener 6 máquinas en cada una de las subredes, lo que es más que suficiente ..

2. Mobile IP sobre la maqueta

La implementación de Mobile IP utilizada para el montaje sobre la maqueta es la de la universidad de Helsinki: http://www.cs.hut.fi/Research/Dynamics/

Para la instalación de Mobile IP sobre la maqueta la configuramos de la siguiente manera:

Configuración de Mobile IP

Tenemos las 5 subredes:

* Subred 1: 193.147.71.40 / 255.255.255.248
* Subred 2: 193.147.71.8 / 255.255.255.248
* Subred 3: 193.147.71.16 / 255.255.255.248
* Subred 4: 193.147.71.24 / 255.255.255.248
* Subred 5: 193.147.71.32 / 255.255.255.248

Tenemos un MN, con dirección 212.128.1.104, tiene una tarjeta wavelan mediante la que se conecta a los Foreign Agents (FA3, FA4 y FA2) que también tienen tarjetas wavelan, y todas ellas están configuradas de modo Ad-Hoc.

El MN se va moviendo por las subredes, y va cambiando de Foreign Agent sin cambiar su dirección IP, ya que usamos FA encapsulation. De este modo los paquetes que van desde el Correspondent Node al MN pasan por el HA, que encapsula los paquetes y se los envía al FA mediante un túnel, y después es el FA el que desencapsula el paquete y se lo entrega al MN.

Con la maqueta que tenemos también hacemos uso de los FA jerárquicos. Esto ocurre entre el FA1 y los FA3 y FA4. Esto proporciona cambios de subred para el MN más rápidos, ya que el túnel que tiene el HA siempre lo tiene con el FA1, y después dependiendo de si el MN está en el FA3 o el FA4, existirá otro tunel entre el FA1 y el FA3, o entre el FA1 y el FA4. Por eso cuando el MN cambia por ejemplo del FA3 al FA4, lo único que cambia es que el túnel entre FA1-FA3 se elimina y se crea otro entre FA1-FA4.

En el caso de no usar FA jerárquicos, como por ejemplo al cambiar del FA3 al FA2, el establecimiento de conexión del MN tiene un mayor retardo, ya que se debe establecer un tunel entre el HA y el FA2 y eso es más lento que el caso que se comentaba antes.

3. Cellular IP sobre la maqueta

La implementación de Cellular IP utilizada es la de la Universidad de Columbia: http://comet.ctr.columbia.edu/cellularip/

La configuración de la maqueta para el uso de Cellular IP es la siguiente:

Uso de Cellular IP

Con Cellular IP, el Mobile Host pertenece a las subredes de los Base Station para poder conectarse a ellos. En este caso el Mobile Host tiene una tarjeta wavelan, y los Base Station también tienen otra cada uno y todas configuradas en modo Ad-Hoc.

Con Cellular IP, en todo momento el Gateway sabe a que Base Station está conectado el Mobile Host, y lo que hace es enrutar los paquetes desde/hacia el MH por el Base Station adecuado en cada momento.

Los cambios de Base Station son más rápidos que los cambios de FA en Mobile IP, ya que aquí­ solo hay que cambiar una ruta en el Gateway-CellularIP y no hace falta establecer túneles ni encapsular paquetes que luego hay que desencapsular.

La solución ideal sería utilizar Cellular IP en las partes inferiores del árbol y Mobile IP para las partes más altas …

4. Herramientas utilizadas para las pruebas de MobileIP

Las pruebas realizadas con Mobile IP sobre la maqueta se han realizado con algunas herramientas existentes para este fin, y otras herramientas implementadas para determinadas pruebas.

Para la automatización de las pruebas se han realizado scripts en perl. En estos script se definen el tipo de pruebas, se lanza el proceso, y se generan algunos ficheros con los resultados.

Básicamente existe un script principal en el que se define el tipo de pruebas, la duración, el número de repeticiones, el programa utilizado para realizar la medición, … Y luego existen tantos scripts como herramientas de medición existen, en el que se indica la forma de ejecutar el programa de medición, y la forma de recoger sus resultados.

Los programas utilizados para las mediciones son netperf, y una implementación de un programa cliente/servidor que básicamente consiste en la medida de los paquetes que se pierden en una transferencia de paquetes entre el cliente/servidor.

5. Pruebas ancho de banda en Mobile IP

Se han realizado una serie de pruebas sobre la maqueta para comprobar el rendimiento de Mobile IP.

Para ello las pruebas realizadas consisten en medir el ancho de banda que se consigue entre el Mobile Node y el Correspondent Node, sobre distintos escenarios.

Para las pruebas se ha utilizado la herramienta netperf. Esta herramienta consisite en un modelo cliente/servidor, ejecutamos el servidor en el CN y el cliente en el MN. Durante el tiempo que dura cada prueba este programa realiza una transferencia entre ambos y mide el ancho de banda que se consigue…

Para la automatización de las pruebas se han construido unos scripts en perl, que realizan todas las pruebas que se le indiquen durante el tiempo que se le indique.

Las pruebas con netperf consisten en medir el ancho de banda conseguido entre ambos nodos, cuando el número de handoffs del MN varí­a. Se han tomado medidas cuando el MN no hace handoffs, y también se han hecho medidas cuando el MN hace unos handoffs de 8, 5, 4, 3 y 2 segundos. Los handoffs consisten en que el MN va cambiando de FA al que se conecta.

También se han hecho pruebas utilizando FA jerárquicos y sin utilizarlos para comprobar cual es la mejora que proporcionan los FA jerárquicos, en el que el túnel entre el HA y el FA superior no varía.

También se ha utilizado el programa nistnet, que sirve para variar el comportamiento de ciertos paquetes en la red. Por ejemplo para nuestras pruebas hemos hecho que el nistnet retrase todos los paquetes desde/hacia el HA 1 segundo, para simular cual sería la situación en la que el HA se encontrara lejos del MN.

Los resultados son los siguientes:

5.1 Resultados con FA jerárquicos

5.1.1 Con TCP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 3.20125 2.9025 3.06625 3.13875 2.8025

Túneles jerárquicos - TCP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 0.8875 0.83 0.7325 0.5875 0.19

Túneles jerárquicos - TCP - HA alejado

5.1.2 Con UDP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.5325 2.56 2.65125 2.665 2.7

Túneles jerárquicos - UDP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 3.23 3.195 3.1825 3.15 2.89

Túneles jerárquicos - UDP - HA alejado

5.2 Resultados sin FA jerárquicos

5.2.1 Con TCP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.40125 2.20125 2.50875 2.65625 2.7675

Túneles no jerárquicos - TCP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 0.1525 0.0575 0.03 0.0275 0.1075

Túneles no jerárquicos - TCP - HA alejado

5.2.2 Con UDP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.595 2.683 2.73625 2.5475 2.5537

Túneles no jerárquicos - UDP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.69 2.455 2.3875 2.4175 2.32

Túneles no jerárquicos - UDP - HA alejado

6. Pruebas pérdida de paquetes UDP en Mobile IP

Otro tipo de pruebas realizado consiste en medir el número de paquetes que se pierden entre el MN y el CN, con diferentes parámetros de configuración de la maqueta.

Para las pruebas de pérdida de paquetes se han realizado unos simples programas en Ada, utilizando la librería de comunicaciones Lower Layer, que consisten en un modelo cliente/servidor en el que se enví­an paquetes UDP de distinto tamaño, y se mide el número de paquetes perdidos.

En las pruebas de pérdidas de paquetes el método es el mismo pero se han realizado con tiempos de handoffs de 15, 12, 10, 8, 6, 5, 4, 3 y 2 segundos.

También se han usado FA jerárquicos y FA no jerárquicos, y también se ha utilizado la herramienta nistnet para alejar al HA.

6.1 Resultados con FA jerárquicos

6.1.1 Con tamaño de paquete de 32 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 0 0 2 2 2 2 4 2 7

Túneles jerárquicos - UDP (32b)

6.1.2 Con tamaño de paquete de 64 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 0 2 2 2 2 0 0 0 3

Túneles jerárquicos - UDP (64b)

6.1.3 Con tamaño de paquete de 512 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 0 0 7 7 5 2 5 7 1

Túneles jerárquicos - UDP (512b)

6.2 Resultados sin FA jerárquicos

6.2.1 Con tamaño de paquete de 32 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 12 16 20 24 29 26 11 3 4

Túneles No jerárquicos - UDP (32b)

6.2.2 Con tamaño de paquete de 64 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 13 16 19 24 29 21 12 2 5

Túneles No jerárquicos - UDP (64b)

6.2.3 Con tamaño de paquete de 512 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 14 17 23 26 31 21 25 11 4

Túneles No jerárquicos - UDP (512b)

Referencias

Implementación de Mobile IPv4 por el HUT

Grupo del IETF sobre Mobile IP

Implementación de Mobile IPv6 para Linux

Implementación de Cellular IP

Recursos sobre redes inalámbricas para linux

¿Qué es TCP/IP?

TCP/IP es un conjunto de protocolos en los que se basan la mayorí­a comunicaciones que se realizan hoy en día entre computadores.

El proceso de comunicación entre ordenadores consta de una serie de acciones que se deben realizar para que la comunicación se realice correctamente: división de los datos en paquetes de tamaño pequeño, control de errores, transmisiones físicas, enrutamiento, …

Para que este proceso de comunicación no está formado por un gran proceso complejo que aglutine muchas tareas, lo que se hace es dividir el mismo en procesos más pequeños que se denominan niveles o capas, y cada una de esas capas es la encargada de realizar parte de la funcionalidad del proceso de comunicación.

Las capas del modelo TCP/IP están basadas en el modelo de referencia OSI aunque no son exactamente las mismas. El modelo TCP/IP ha agrupado varias de las capas del modelo OSI y ha definido las capas siguientes:

– Capa de Aplicación (protoclos HTTP, FTP, DNS, …)
– Capa de Transporte (protocolos TCP, UDP)
– Capa de Interred (protocolos IPv4, IPv6)
– Capa de Enlace (protocolos Ethernet, Token Ring, …)

¿Qué es el protocolo IP?

IP es un protocolo del nivel de red (capa 3) del modelo OSI o del nivel de internet (capa 2) del modelo TCP/IP. IP es el protocolo encargado del transporte de paquetes desde el origen hasta el destino en una comunicación. Es un protocolo de mejor esfuerzo, lo que significa que no garantiza la fiabilidad aunque trata de hacer todo lo posible para que los paquetes lleguen al destino.

IP se basa en el encaminamiento que se produce entre dispositivos de la capa 3 (OSI) y en los identificadores únicos (direcciones IP) que asigna a cada dispositivo para que pueda comunicarse. Cada dispositivo de capa 3 realiza el proceso de encaminamiento en base a su tabla de rutas, que le indica el camino mas adecuado para llegar a cada destino.