Sobre eso, sugiero implementar ésto en LOR.
Nubes LOR
La idea de una “nube LOR” es poder describir fácilmente un conjunto de al menos dos enlaces físicos que formen parte de la Red Libre, con las siguentes características:
- Que esten agrupados geográficamente, ya que los enlaces físicos requieren ésto por naturaleza
- Que involucren todos los enlaces LOR reales, empezando por fibra óptica, cableado Ethernet, hasta Wi-Fi (sin excluir otras formas).
- Los miembros de una nube LOR deben intercambiar información clave antes de hacer un enlace. Por ejemplo: medio de transporte a usar (Wi-Fi? Fibra?), canal de comunicación, claves de cifrado dentro el canal, etc. Obvaimente, los miembros no pueden variar nada de ésta información.
- Las nubes LOR sólo se encargan del transporte en capa 2 – no toman decisiones de enrutamiento. Pero asumimos que una nube LOR transporta un (1) solo protocolo de enrutamiento dinámico.
Ejemplo
Podemos imaginar que creamos una nube LOR desde mi nodo.
- Los miembros de ésta nube pueden usar:
- Wi-Fi 2.4GHz en el canal 13, red Ad-Hoc WPA2 con cierta clave estática A.
- Wi-Fi 5GHz en el canal 153, red Ad-Hoc WPA2 con cierta clave estática B.
- El nombre viene de una nomenclatura previamente definida:
- La señal inicial que ha “fundado” la nube sería el nodo Alto Sopocachi, que ofrece cobertura a parte de Sopocachi y a parte de Pampahasi, Alto San Antonio, etc.
- Ya que se han abarcando de golpe grandes distancias, lo más probable es que ésta nube LOR siga creciendo, pero hacia adentro (de forma grande o pequeña) y no hacia afuera (probablemente otra nube LOR optimizada para ése lugar tome ése trabajo). Entonces, definiríamos la cobertura de ésta nube LOR usando macrodistritos de la ciudad (otro link): Cotahuma (1) y San Antonio (4).
- En una zona puede haber más de una nube LOR que ofrezca cobertura, por el medio que sea, con el protocolo más conveniente.
- Un nodo puede estar conectado a más de una nube LOR, y así beneficiarse de resilencia (resistencia a daños) y mejor enrutamiento.
Entonces, de ésta manera, una nube así podría tener un SSID ad-hoc que se parezca a éstos:
- lapaz.laotrared.net_md:cotahuma-SanAntonio
- lapaz.laotrared.net_md3-7
Se necesitan ideas para eso, algo que sea más facil de entender.
Se podría dejar eso del SSID en desorden, pero para tener una idea rapida del estado de LOR en una zona, creo que debemos normar éso.
Gráfico de la idea
- La nube Y puede ser un enlace mesh, o si la situación lo exige (ej: muy larga distancia o enlace troncal con mucho tráfico), un enlace dedicado con software especializado.
- En el ejemplo, a pesar de tener varias nubes LOR en esa ciudad imaginaria, en realidad casi todos los nodos son participantes de la Sesión BMX7 principal de LOR, excepto la nube Z ubicada en un vecindario, que por alguna razón le es más conveniente tener una sesión aparte, de algún otro protocolo (por ejemplo, si es posible cablear o si hay muchos miembros).
- Las nubes LOR separadas permiten optimizar los enlaces inalámbricos dependiendo la ubicación: frecuencias limpias en el lugar, tipo de enlace (ad-hoc? 802.11s?), etc.
- Aunque es más cómodo tener mucha gente en una nube LOR, es recomendable no poner muchos nodos en una nube, al menos en enlaces Wi-Fi; un canal Wi-Fi trae un ancho de banda limitado que todos los usuarios deben compartir, y al ser una infraestructura descentralizada (ad-hoc o 802.11s), la manera en que cada router “toma la palabra” y se haga oír por el resto (airtime) no es optimizable en absoluto.