OSLDR - Historial de revisiones

Javiermartin jc: Texto reemplazado: «
» por «»

2019-08-26T21:51:37Z

Texto reemplazado: «<div align="justify">» por «»

Mario art.jc en 20:15 24 nov 2011

2011-11-24T20:15:57Z

Maydelys art.jc en 16:26 24 nov 2011

2011-11-24T16:26:22Z

Maydelys art.jc en 16:22 24 nov 2011

2011-11-24T16:22:43Z

Maydelys art.jc en 16:20 24 nov 2011

2011-11-24T16:20:47Z

Maydelys art.jc en 16:18 24 nov 2011

2011-11-24T16:18:04Z

Yalexy idict en 21:03 22 nov 2011

2011-11-22T21:03:03Z

Mario art.jc en 18:25 20 nov 2011

2011-11-20T18:25:04Z

Mario art.jc: Página creada con '
{{Definición|Nombre=Protocolo OSLDR|imagen=mesh.jpg|concepto=Demonio de Enrutamiento de Estado de Enlace Optimizado. .}} == Enrutamiento mallado con olsr...'

2011-11-20T18:16:29Z

Página creada con '<div align="justify"> {{Definición|Nombre=Protocolo OSLDR|imagen=mesh.jpg|concepto=Demonio de Enrutamiento de Estado de Enlace Optimizado. .}} == Enrutamiento mallado con olsr...'

Página nueva

<div align="justify">
{{Definición|Nombre=Protocolo OSLDR|imagen=mesh.jpg|concepto=Demonio de Enrutamiento
de Estado de Enlace Optimizado. .}}
== Enrutamiento mallado con olsrd ==

== Optimized Link State Routing Daemon ==
El 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. Nos vamos a concentrar en 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
nterfaces. 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 wiki 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 ==

[[Image:config1.jpg]]

== Fuentes ==
*Redes Inalámbricas en los Países en Desarrollo Tercera edición, septiembre de 2008
*[http://wndw.net/'''WNDW''']

[[Category:Telecomunicaciones]] [[Category:Protocolos]]

@@ Línea 3: / Línea 3: @@
 de Estado de Enlace Optimizado.}}
-'''OSLDR''': Optimized Link State Routing Daemon—olsrd—(Demonio de Enrutamiento
+'''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.
@@ Línea 11: / Línea 11: @@
 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
+[[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
@@ Línea 36: / Línea 36: @@
 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
+[[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.
@@ Línea 47: / Línea 47: @@
 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
+[[Linksys
-WRT54G] funcionando a 200 MHz es aproximadamente del 30% en la mesh de
+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
@@ Línea 110: / Línea 110: @@
 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
+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.

@@ Línea 1: / Línea 1: @@
-<div align="justify">
 {{Definición|Nombre=Protocolo OSLDR|imagen=mesh.jpg|concepto=Demonio de Enrutamiento
 de Estado de Enlace Optimizado.}}

@@ Línea 127: / Línea 127: @@
 == Fuentes ==
- *Redes Inalámbricas en los Países en Desarrollo Tercera edición, septiembre de 2008
+*Redes Inalámbricas en los Países en Desarrollo Tercera edición, septiembre de 2008
- *[http://wndw.net/'''WNDW''']
+*[http://wndw.net/'''WNDW''']
- [[Category:Telecomunicaciones]] [[Category:Protocolos]]
+[[Category:Telecomunicaciones]] [[Category:Protocolos]]

@@ Línea 2: / Línea 2: @@
 {{Normalizar}}
 {{Definición|Nombre=Protocolo OSLDR|imagen=mesh.jpg|concepto=Demonio de Enrutamiento
-de Estado de Enlace Optimizado. .}}
+de Estado de Enlace Optimizado.}}
-== Enrutamiento mallado con olsrd ==
 == Optimized Link State Routing Daemon ==
-El Optimized Link State Routing Daemon—olsrd—(Demonio de Enrutamiento
+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

@@ Línea 9: / Línea 9: @@
 el enrutamiento de redes inalámbricas. Nos vamos a concentrar en 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
+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
+[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
@@ Línea 18: / Línea 18: @@
 Existen  varias implementaciones para  OLSR, que comenzaron como un
-borrador  IETF escrito en el INRIA en Francia. La implementación de olsr.org
+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
@@ Línea 36: / Línea 36: @@
 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
+[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.
@@ Línea 44: / Línea 44: @@
 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
+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
-nterfaces. El  promedio de carga  del CPU causada por  olsrd  en  un  Linksys
+interfaces. El  promedio de carga  del [CPU] causada por  olsrd  en  un
-WRT54G funcionando a 200 MHz es aproximadamente del 30% en la mesh de
+[Linksys
 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
@@ Línea 87: / Línea 88: @@
 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
+mensajes [HNA] falsos. Es muy recomendable construir y utilizar  esta aplicación
 en lugar de depender de los mensajes HNA estáticos.
@@ Línea 93: / Línea 94: @@
 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
+disponibles  para  [OpenWRT],  AccessCube,  [Mac ] OSX,  [Debian ] GNU/Linux  y
-Windows. OLSR es una parte estándar  de Metrix Pyramid. Si debe compilar
+[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
@@ Línea 108: / Línea 109: @@
 Stateless Address Autoconfiguration  in large mobile ad hoc  networks"  por  K.
 Weniger y M. Zitterbart, 2002).
-Una página wiki donde todas las personas interesadas pueden elegir  una
+Una página donde todas las personas interesadas pueden elegir  una
-dirección IPv4 para cada interfaz que esté ejecutando el demonio OLSR puede
+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.