OSLDR

OSLDR Concepto: Demonio de Enrutamiento de Estado de Enlace Optimizado.

OLSRD: Optimized Link State Routing Daemon—olsrd—(Demonio de Enrutamiento de Estado de Enlace Optimizado) de olsr.org es una aplicación desarrollada para el enrutamiento de redes inalámbricas.

Optimized Link State Routing Daemon

Este software de enrutamiento por varias razones es un proyecto fuente abierta (open-source) que admite Mac OS X, [Windows] 98, 2000, XP, [Linux], FreeBSD, OpenBSD y NetBSD. Olsrd está disponible para puntos de acceso que ejecutan Linux, como Linksys WRT54G, Asus Wl500g, AccessCube, o Pocket PC que ejecutan Linux Familiar, y viene incluido en los equipos Metrix que ejecutan Metrix Pyramid. Olsrd puede manejar interfaces múltiples y puede extenderse con diferentes plug-ins. Admite IPv6 y está siendo desarrollado y utilizado activamente en redes comunitarias alrededor del mundo.

Existen varias implementaciones para OLSR, que comenzaron como un borrador IETF escrito en el INRIA en [Francia]. La implementación de olsr.org comenzó como la tesis de máster de Andreas Toennesen en la Universidad UniK. El demonio de enrutamiento se modificó con base en la experiencia práctica de las redes comunitarias gratuitas. El Olsrd actual difiere significativamente del borrador original porque incluye un mecanismo denominado Link Quality Extension (Extensión de la Calidad del Enlace) que mide la cantidad de paquetes perdidos entre nodos y calcula las rutas de acuerdo con esta información. Esta extensión rompe la compatibilidad con los demonios de enrutamiento que adhieren al borrador del INRIA. El olsrd disponible en olsr.org puede ser configurado para comportarse de acuerdo con el borrador del IETF que carece de esta característica—pero no hay una razón para deshabilitar el Link Quality Extension (Extensión de la Calidad del Enlace) a menos que se requiera la concordancia con otras implementaciones.

Teoría

Después de haber ejecutado olsrd por un rato, cada nodo adquiere conocimiento acerca de la existencia de los otros nodos en la nube mallada y sabe cuáles nodos pueden ser utilizados para enrutar el tráfico hacia ellos. Cada nodo mantiene una tabla de enrutamiento que cubre la totalidad de la nube mesh. Este enfoque de enrutamiento mallado es denominado enrutamiento proactivo. En contraste, los algoritmos de enrutamiento reactivo buscan rutas sólo cuando es necesario enviar datos a un nodo específico. Hay argumentos en favor y en contra del enrutamiento proactivo, y hay muchas otras ideas acerca de cómo hacer el enrutamiento mallado que vale la pena mencionar. La ventaja más grande del enrutamiento proactivo es que sabemos quién está dentro o fuera de la red, y no debemos esperar hasta que se encuentre una ruta. El alto tráfico de protocolo y la mayor cantidad de carga de CPU son algunas de las desventajas. En [Berlín], la comunidad de Freifunk está operando una nube mallada donde olsrd tiene que administrar más de 600 interfaces. El promedio de carga del [CPU] causada por olsrd en un [[Linksys WRT54G]] funcionando a 200 MHz es aproximadamente del 30% en la mesh de Berlín. Hay un límite al grado hasta el cual la extensión de un protocolo proactivo puede escalar que depende de cuántas interfaces estén involucradas y cuán a menudo se actualicen las tablas de enrutamiento. Mantener rutas en una nube mallada con nodos estáticos toma menos esfuerzo que hacerlo en una mesh compuesta de nodos que están en constante movimiento, ya que la tabla de enrutamiento no necesita ser actualizada tan a menudo.

Mecanismo

Un nodo que ejecuta olsrd envía constantemente mensajes de “Hello” con un intervalo dado para que sus vecinos puedan detectar su presencia. Cada nodo computa una estadística de cuántos “Hellos” ha recibido y perdido desde cada vecino—de esta forma obtiene información sobre la topología y la calidad de enlace de los nodos en el vecindario. La información de topología obtenida es difundida como mensajes de control de topología (TC messages) y reenviada por los vecinos que olsrd ha elegido para ser relevadores “multipunto”. El concepto de transmisores multipunto es una nueva idea en el enrutamiento proactivo que viene desde el borrador de OLSR. Si cada nodo retransmite la información de topología que ha recibido, se puede generar una sobrecarga innecesaria. Dichas transmisiones son redundantes si un nodo tiene muchos vecinos. Por esta razón, un nodo olsrd decide cuáles vecinos son transmisores multipunto favorables, encargados de reenviar los mensajes de control de topología. Nótese que los relevadores multipunto son elegidos exclusivamente con el propósito de reenviar mensajes de CT. La carga útil (payload) se enruta utilizando todos los nodos disponibles.

Existen otros dos tipos de mensajes en OLSR que informan cuándo un nodo ofrece una pasarela (gateway) a otras redes (mensajes HNA) o tiene múltiples interfaces (mensajes MID). No hay mucho más que decir acerca de estos mensajes más allá del hecho de que existen. Los mensajes HNA hacen al olsrd muy conveniente para conectarse a Internet con un dispositivo móvil. Cuando un nodo mesh se mueve detectará pasarelas a otras redes y siempre elegirá la pasarela a la que tenga la mejor ruta. No obstante, olsrd no es a prueba de balas. Si un nodo anuncia que es una pasarela a Internet—cuando en realidad no lo es, porque nunca tuvo acceso o lo perdió—los otros nodos van a creer esta información de todas formas. La seudo-pasarela es un agujero negro. Para solucionar este problema se desarrolló una aplicación de pasarela dinámica. La aplicación detecta automáticamente si la pasarela está verdaderamente conectada y si el enlace está activo. Si no es así, olsrd interrumpe el envío de mensajes [HNA] falsos. Es muy recomendable construir y utilizar esta aplicación en lugar de depender de los mensajes HNA estáticos.

Práctica

Olsrd implementa enrutamiento IP en una aplicación interna de los usuarios. La instalación es bastante sencilla. Los paquetes de instalación están disponibles para [OpenWRT], AccessCube, [Mac ] OSX, [Debian ] GNU/Linux y [Windows]. OLSR es una parte estándar de [Metrix Pyramid]. Si debe compilar desde la fuente, por favor lea la documentación que viene con el paquete. Si todo está configurado correctamente, lo único que tiene que hacer es iniciar el programa OLSR. En primer lugar debe asegurarse de que cada una de las interfaces del nodo de la mesh tenga asignada una dirección IP estática. No se recomienda (ni es práctico) utilizar DHCP en una red IP mallada. Una solicitud DHCP no va a ser contestada por un servidor DHCP si el nodo que la solicita necesita un enlace de múltiples saltos para alcanzarlo, y aplicar relevo de DHCP (DHCP relay) en toda una malla es poco práctico. El problema podría ser resuelto utilizando IPv6, puesto que se dispone de suficientes direcciones para generar una IP desde la dirección MAC para cada tarjeta involucrada (como se sugiere en "IPv6 Stateless Address Autoconfiguration in large mobile ad hoc networks" por K. Weniger y M. Zitterbart, 2002). Una página donde todas las personas interesadas pueden elegir una dirección IPv4 para cada interfaz que esté ejecutando el demonio OLSR puede funcionar bastante bien para este propósito. No existe una manera sencilla de automatizar el proceso cuando se utilza IPv4. En general, la dirección de difusión en las interfaces mesh debe ser 255.255.255.255, por convención. No hay una razón para ingresar explícitamente la dirección de difusión, ya que olsrd puede ser configurado para reemplazar cualquier dirección de difusión con su valor por convención. Sólo debemos asegurarnos de que las configuraciones sean las mismas en todos lados. Olsrd puede hacer esto por sí mismo. Cuando se establece un archivo de configuración olsrd por defecto, esta característica debe ser habilitada para eliminar confusiones

Parte de una configuración olsrd simple

Fuentes

• Redes Inalámbricas en los Países en Desarrollo Tercera edición, septiembre de 2008
• WNDW