Modificación del Protocolo DSR para máquinas con pocos

Modificación del Protocolo DSR para máquinas
con pocos recursos
Miguel Angel Ortuño Pérez
Vicente Matellán Olivera
Departamento de Ciencias Experimentales y Tecnologı́a
Universidad Rey Juan Carlos
e-mail: mortuno@gsyc.escet.urjc.es
Septiembre de 2002
1.
Resumen
Gracias a protocolos como DSR, ordenadores heterogéneos alimentados con
baterı́as y capaces de comunicación inalámbica, pueden establecer entre ellos
una red Ad-Hoc: Una red sin infraestructura previa.
Aunque el hardware cada vez es más potente y barato, siempre habrá máquinas
de recursos limitados. Si el datagrama es pequeño, DSR es inaplicable sobre
IPv6. Como solución proponemos una modificación al protocolo que reduce notablemente sus cabeceras: Usar sólo una pequeña parte de la dirección para
encaminar, a costa de provocar que nodos distintos aparenten tener la misma
dirección.
2.
Redes Ad-Hoc
Una red ad-hoc se define como una red de comunicaciones que se forma cuando se necesita, compuesta por las estaciones que están en determinado momento
en determinado lugar y que no precisa de ninguna infraestructura externa como
pueda ser por ejemplo Internet: La tecnologı́a inalámbrica, las baterı́as y los
algoritmos adecuados permite prescindir de cableado, puntos de acceso, routers
pre-existentes o alimentación externa. [9] Estas redes están formadas por nodos
similares que cooperan entre sı́, normalmente no jerarquizados donde todos son
al tiempo encaminadores y estaciones finales. Al menos idealmente, tampoco
deben necesitar administración por parte de ningún usuario, ni usuario normal
ni súper-usuario.
Si todos los nodos pueden alcanzar a todos los demás desde su nivel de
enlace, el problema del encaminamiento está resuelto. Pero esto es muy infrecuente y probablemente un derroche de energı́a y ancho de banda. En general
cada nodo será capaz de acceder por sus propios medios sólo a los nodos más
próximos, precisando de la colaboración de la red para llegar a todos los demás.
Actuando de buena fe todos se comportarán como encaminadores además de
como productores y consumidores de paquetes.
1
2.1.
Aplicaciones de las Redes Ad-Hoc
El paradigma clásico de aplicación de las redes Ad-Hoc es una reunión de
trabajo: Un grupo de personas con ordenadores portátiles o PDAs. Son de distintas empresas y por tanto sus direcciones son distintas. Tal vez en la sala haya
acceso a internet y puedan usar por ejemplo IP móvil [11], pero ¿para qué pasear
sus datagramas por todas la ciudad o todo el pais cuando están en la misma
habitación?. Sus equipos probablemente estén dotados de puertos de infrarojos
que les permitan formar una red para la ocasión.
Como segundo ejemplo podemos pensar en una familia, donde hay un ordenador de sobremesa, el portatil del padre, de la madre y un juguete capaz
de conectarse a la red. Se podrı́an configurar para que todos estén en la misma
red. Los portátiles volverı́an a la red del trabajo al volver a la oficina. Pero esta
configuración manual es lo que desea evitarse.
En otras casos, simplemente no habrá infraestructuras de apoyo. Pensemos
en poblaciones aisladas o de orografı́a difı́cil, situaciones de emergencia, desastres naturales o escenarios bélicos. Otro ejemplo son las denominadas PAN
(Personal Area Networks) o pico-nets : Una red formada por los dispositivos de
una persona: Su reloj, su agenda, su teléfono móvil. Una red ası́ puede querer
entrar en contacto con la red de otra persona que en ese momento está enfrente.
Y aunque se puedan pensar muchos usos, la killer ap puede ser cualquier
otra aplicación que hoy no imaginamos. Probablemente no sea necesario. La
única cuestión es que con la tecnologı́a inalámbrica, necesitar infraestructuras
remotas es algo que pertenece al pasado.
2.2.
Protocolos de Encaminamiento para redes Ad-Hoc
Desde mediados de los años 90 se desarrollan una serie de protocolos para
redes Ad-Hoc. Todos ellos son del tipo Vector de Distancias (DV, Distance
Vector ), también conocidos como DBF Distributed-Bellman-Ford, donde cada
nodo lo único que conoce de la ruta para llegar a otro es el primer salto y la
distancia hasta el destino.
Actualmente destacan de forma clara dos protocolos: DSR Dynamic Source
Routing Protocol y AODV (Ad-hoc on-demand distance vector routing) [8].
Ambos trabajan bajo demanda. DSR hace encaminamiento en origen, AODV
emplea tablas de enrutamiento convencionales que actualiza frecuentemente y
con números de secuencia para determinar su frescura.
Para nuestro trabajo partimos de DSR. Estudios recientes [1] [2] apuntan
a que DSR sobrecarga menos la red con información de enrutado, y ofrecer
mejores resultados en situaciones de moderada y media tensión en la red (carga
, número de nodos y movilidad). Si bien a partir de cierto niveles, AODV puede
ser más adecuado.
2.3.
Descripción del protocolo DSR
DSR es un protocolo de encaminamiento en origen compuesto de dos mecanismos que trabajan coordinadamente: Descubrimiento de ruta y mantenimiento de ruta. Trabaja bajo demanda, no hay ninguna operación que se realice
periódicamente: Cuando el nodo emisor se mueva o cuando cambie la topologı́a
2
de la red, el algoritmo percibe los cambios y se adapta a ello, pero sólo para las
rutas que estén en uso.
Figura 1: Un ejemplo de red Ad-Hoc
2.3.1.
Descubrimiento de Ruta (Route Discovery )
Supongamos una red como la de la figura 1. El nodo A dispone de alguna
tecnologı́a inalámbrica que le permite alcanzar B pero no más allá. B llega hasta
A, C y E, etc. Si A quiere enviar un paquete al nodo D y no sabe por dónde
encaminarlo debe hacer un descubrimiento de ruta, que simplificando podemos
describir ası́:
A radia una petición de ruta hasta D a todos sus vecinos. Si quien lo
recibe no es D, reenvı́a la petición. Esto se denomina inundación, es una
técnica bien conocida [10]. Para controlar la inundación, cada petición
tiene un identificador único (request id ), de forma que cada nodo reenvı́e
esta petición sólo una vez.
En cada reenvio de la petición, el nodo añade al datagrama su propia
dirección, de tal forma que en cada datagrama queda registrada la ruta
por la que ha ido pasando
Si la petición llega a D, éste extrae la ruta del datagrama (ABCD) y se
la envı́a a A en un Route Reply. Este Route Reply volverá por el mismo
camino deshaciendo lo andado.
Una vez que A conoce la ruta para D, la incluirá en todos los paquetes
que le envı́e
2.3.2.
Mantenimiento de Ruta (Route Maintenance)
Supongamos que mientras A envı́a sus paquetes a D, el nodo C se mueve
fuera del alcance de B. Entonces B descubrirá que ya no es vecino suyo y
se lo comunicará a A con un un mensaje Route Error indicando que esta
ruta está rota.
El protocolo es best efford, en caso de ruta rota no se reenvia el paquete,
eso lo harán, si procede, niveles superiores.
3
La siguiente vez que A deba enviar un datagrama a D, si conoce un camino
alternativo, lo usará, en otro caso, lanzará una nuevo Route Request
2.3.3.
Cachés
Volvamos a la petición de ruta que A envı́a para D. Cuando llega a B, tal
vez este nodo conozca una ruta hasta D (Bien por haberla usado previamente,
bien por haber interceptado un paquete con ese destino). Esta información se
almacena en una caché, con lo que B puede atender la petición de ruta sin
necesidad de reenviarla.
2.3.4.
Otras consideraciones
Normalmente el nivel de enlace es bidireccional, con lo que la respuesta sigue
exactamente el camino inverso a la petición. Si los enlaces son unidireccionales,
es necesario generar una nueva petición. (marcándola con un flag Route Reply
para evitar una cascada de peticiones)
Mientras un nodo busca rutas para los paquetes a enviar, los almacena con
una marca de tiempo en el denominado Send Buffer. Si transcurrido cierto
tiempo no llega una ruta, se reintenta. Tras varios intentos sin éxito, se descarta
el paquete. También debe tenerse en cuenta que si hay una petición en curso, y
llega un nuevo paquete el mismo destino, no debe generarse una nueva petición.
3.
IPv6
El protocolo de la internet actual, IPv4 [13] [12] está basado en el conocimiento disponible en 1975. Cada estación se identifica por una dirección de cuatro
bytes, pero el imprevisible éxito del protocolo, ası́ como el ineficiente reparto de
las direcciones en clases hace que ya a finales de los ochenta, principios de los
noventa se perciba claramente la insuficiencia de este espacio de direcciones.
Las modificaciones mı́nimas consistirı́an en aumentar el tamaño de las direcciones, pero vista la exigencia de un nuevo protocolo, se le añaden los avances
de quince años de experiencia en una nueva versión: IPv6 [3] [7] [6].
El cambio más importante es el tamaño de las direcciones, que pasa a ser de
4 a 16 bytes. Al margen de esto, el formato del datagrama es muy similar al de
IPv4, con algunas simplificaciones.
El uso de ciertas técnicas como p.e. CIDR (Claseless Inter-Domain Routing)
está prolongando la vida útil de IPv4 por encima de las previsiones iniciales,
pero a medio plazo es incuestionable que será reemplazado por IPv6.
4.
Máquinas con recursos limitados
Es evidente el explosivo crecimiento de las comunicaciónes inalámbricas y
de la proliferación de aparatos cada vez más pequeños y baratos susceptibles
de conectarse a una red de comunicaciones. El ordenador del que hablamos
hoy ya no tiene por qué ocupar ni una habitación ni una mesa, puede ser una
agenda electrónica, un teléfono o un PDA que llevemos en el bolsillo. En un
futuro próximo es claro que veremos dispositivos de todo tipo conectados en:
vehı́culos, electrodomésticos, juguetes, equipos industriales y un largo etcétera
4
que probablemente aún no imaginamos. Lo que es seguro es que serán equipos
heterogéneos, de distintos caracterı́sticas y prestaciones.
A pesar de las continuas mejoras y abaratamientos del hardware, siempre
habrá dispositivos capaces de comunicación sin cables pero con pocos recursos, probablemente por restricciones en su precio o tal vez por limitaciones de
ocupación de espacio radioléctrico o de consumo de la energı́a de sus baterı́as.
Tomamos como ejemplo los equipos con los que los estudiantes de la asignatura de Robótica en nuestra universidad hacen prácticas: Lego Mindstorm
RCX. Cuenta con un procesador Hitachi H8/300, ROM de 16K y RAM de 32 k.
Podemos comparar sus prestaciones con las de un micro-ordenador de los años
80, el Sinclair ZX-Spectrum. Puede además comunicarse mediante infrarojos
con otros RCX o con un PC. Su protocolo de comunicaciones, LegOS, usa una
trama de 255 bytes. Dispositivos similares tienen tramas de este orden o incluso
menores.
Si a una máquina de estas caracterı́sticas o similares intentamos llevar el
protocolo DSR sobre IPv4, una buena parte del datagrama estará ocupado por
las cabeceras, 92 bytes. Pero con IPv6 será imposible, necesitarı́amos 308 bytes
cuando sólo contamos con 256. En este trabajo proponemos una modificación
al protocolo que reduce el tamaño de las cabeceras a 68 bytes.
Figura 2: Tamaños de las cabeceras
5.
Solución Propuesta
Usando un solo byte para encaminar, se ahorra una buena parte del espacio consumido por las cabeceras. Esto sin duda provocará que distintos nodos
tengan la misma dirección para DSR, lo que llamaremos colisión de direcciones.
Podrı́an buscarse algoritmos para evitar las colisiones, pero nos ha parecido más
adecuado trabajar sin evitarlas, asumiendo que se producirán. Es importante
destacar que dos estaciones tendrán la misma dirección pero sólo desde el punto
de vista de DSR, el protocolo de red inmediatamente superior, (IP en nuestro
caso), mantendá intacta su estructura, con lo que en ningún caso una aplicación
recibirá un datagrama que no le es destinado.
La figura 3 muestra la cabecera DSR para IPv4. Hasta donde sabemos, no
hay ninguna especificación para IPv6 pero deberı́a ser idéntica excepto en el
5
espacio reservado para las direcciones, que deberá ser 16 bytes y no 4 por cada
entrada.
Para compactar los 16 bytes en 1 (figura 4) podrı́an usarse diversas técnicas de hashing, o incluso direcciones aleatorias. Teniendo en cuenta el tipo de
máquina objetivo de esta variación del protocolo, usamos el hashing más sencillo: Tomar el último byte.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |F|L|Reservd|Salvage| Segs Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Address[1]
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Address[2]
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Address[n]
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 3: Cabecera DSR
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |F|L|Reservd|Salvage| Segs Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Address[1] | Address[2]
| Address[3]
| Address[4]
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Address[n-1] |
Address[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 4: Cabecera DSR Modificada
6.
Simulación
Para analizar esta solución emplearemos el simulador de redes ns-2 [4]. Es
una herramienta muy extendida, libre [5] y muy completa, implementa una gran
cantidad de protocolos, incluyendo DSR. Como inconvenientes podemos citar
su complejidad, su documentación escasa o deficiente en algunos aspectos y su
carencia de herramientas para el análisis de los resultados.
La configuración de la red, la carga de trabajo y los escenarios sobre los que
se aplica pueden ser extremadamente diversos, es difı́cil hablar de una configuración tı́pica o unos parámetros extraidos de la realidad. Además, los resultados
son muy dependientes de las condiciones iniciales, y muy variables en función
de estos. Ası́ que hemos tomado como base los parámetros de entrada usados
por Broch et al [1].
6
Debemos indicar que partimos de la implementación de DSR existente en ns2 a la que hacemos las modificaciones que hemos descrito. Esta implementación
tiene una serie de optimizaciones que sin duda habrı́a que suprimir al llevar el
protocolo a una máquina real de las caracterı́sticas de las que hablamos, pero
eso lo obviaremos ahora: Simplemente queremos comparar una implementación
DSR convencional con una con datagramas menores y colisión de direcciones.
Sobre un escenario de 1500x300 metros, durante un tiempo simulado de
900 segundos se situarán arbitrariamente 50 nodos, de los cuales 30 al tiempo
establecerán conexiones CBR a 333 bps. Cada nodo esperará cierto tiempo antes
de moverse en dirección aleatoria con velocidad aleatoria, de media 10 m/s. Este
tiempo de espera variará entre 0 (movimiento continuo) y el tiempo total de la
simulación (nodos estáticos). Cada simulación con la misma configuración se
repite 10 veces y se toma la media aritmética del resultado.
Los resultados los vemos en la figura 9 donde tomamos como métrica el
porcentaje de paquetes entregados a su destinatario. Un 0 % de colisiones se
corresponderı́a prácticamente con el protocolo original. Esta serı́a la sitiación
óptima, donde tendrı́amos la fortuna de que ningún nodo tenga la misma dirección que otro. En la gráficas correspondientes al 5 % y 15 % hemos forzado
ese porcentaje de nodos con la misma dirección. Observamos que la pérdida de
rendimiento no es muy acusada a pesar del gran ahorro en espacio en el datagrama. Como indicábamos anteriormente, con configuración idéntica repetimos
cada simulación 10 veces. En la figura 10 se representa el coeficiente de variación
del número de paquetes recibidos, podemos apreciar que es bastante alto, muy
especialmente cuando introducimos colisiones.
7.
Comportamiento de DSR
Veamos qué sucede cuando dos nodos tienen la misma dirección. Obviamente, si la colisión se produce en un nodo que no está en la ruta del nodo
destino, no afecta de ninguna manera.
En la figura 5 representamos un nodo A buscando una ruta para D, cuya
dirección colisiona con D’. La percepción que tiene el protocolo de esta situación
es la mostrada en la figura 6: Es un único nodo, para el que hay dos rutas. A
hará una petición de ruta, D y D’ responderán, A almacenará ambas y usará la
primera que llegue, y cuando tenga ambas, la de menor número de saltos. Si
la elegida resulta ser la correcta, todo funciona correctamente. En otro caso, A
encaminarı́a por una ruta que no llega a su destino, se interpreta como una ruta
rota y comienzarı́a una nueva petición.
La figura 7 muestra una colisión en un nodos intermedio, A solicita una
ruta para D. La petición de ruta llegará a C y a C’, la que pase por C llegará a su destino mientras que la que pasa por C’ será descartada, con lo que
A acabará teniendo la ruta correcta: ABCD. El problema vendrá cuando los
paquetes con esta ruta lleguen a C’. Este nodo intentará enviarlos a D, lo que
le será imposible, al cabo de cierto tiempo desistirá y se lo indicará a A, lo que
se interpretará como un desplazamiento del nodo D 8, que generará una nueva
petición de ruta. Mientras todo esto se produce, habrá paquetes que puedan
haber llegado a D.
7
Figura 5: Colisión en nodo destinatario
Figura 6: Percepción de la Colisión en nodo destinatario
8.
Conclusiones y Trabajo Futuro
Se ha mostrado una variación al protocolo DSR que permite su uso en un
entorno en el que hasta ahora no era posible. Con un gran ahorro en el tamaño
de los paquetes, la pérdida de rendimiento, en media, es moderada. Si bien con
el algoritmo actual la variabilidad es bastante elevada.
Lo expuesto también confirma la fiabilidad y robustez del protocolo DSR,
que es capaz de soportar alteraciones como la descrita, no previstas en su diseño.
8
Figura 7: Colisión en nodo intermedio
Figura 8: Percepción de la Colisión en nodo intermedio
1
0% Colisiones
5% colisiones
15% colisiones
paquetes recibidos/paquetes enviados
0.8
0.6
0.4
0.2
0
0
100
200
300
400
500
Tiempo de pausa (seg)
600
700
800
Figura 9: Paquetes Recibidos: Media
9
900
1
0% Colisiones
5% colisiones
15% colisiones
paquetes recibidos/paquetes enviados)
0.8
0.6
0.4
0.2
0
0
100
200
300
400
500
600
700
800
900
Tiempo de pausa (seg)
Figura 10: Paquetes Recibidos: Coeficiente de Variación
10
Referencias
[1] Broch, J., Maltz, D. A., Johnson, D. B., Hu, Y.-C., and Jetcheva,
J. A performance comparison of multi-hop wireless ad hoc network routing
protocols. In Mobile Computing and Networking (1998), pp. 85–97.
[2] Das, S. R., Perkins, C. E., and Royer, E. E. Performance comparison
of two on-demand routing protocols for ad hoc networks. In INFOCOM
(1) (2000), pp. 3–12.
[3] Deering,
S.
Internet
protocol,
http://www.ietf.org/rfc/rfc2460.txt, Dec. 1998.
version
6
(ipv6).
[4] Fall, K., and Varadhan, K. The ns manual. UC Berkeley and Xerox
PARC.
[5] González-Barahona, J. M., and Daddara, C.
ware/open source: Information society opportunities
http://eu.conecta.it/paper/, April 2000. 001.
Free softfor europe?
[6] Hinden, R. M. IP Next Generation overview. Communications of the
ACM 39, 6 (1996), 61–71.
[7] Huitema, C. IPv6. The New Internet Protocol. 2nd ed. Prentice Hall,
1997.
[8] Perkins, C. E. Ad-hoc on-demand distance vector routing, 1997.
[9] Perkins, C. E. Ad Hoc Networking. Addison-Wesley, 2001.
[10] Perkins, C. E., Belding-Royer, E. M., and Das, S. R. Ip flooding in ad hoc mobile networks. In Proceedings of the fifty-third Internet
Engineering Task force.
[11] Perkins, C. E., and Myles, A. Mobile IP. Proceedings of International
Telecommunications Symposium (1994), 415–419. 005.
[12] Postel, J. Internet Protocol. http://www.ietf.org/rfc/rfc791.txt, Sept.
1981.
[13] Stevens, W. R. TCP/IP Illustrated, Volume 1. Addison-Wesley, 1994.
11