En principio es claro que hay que abordarla con un enfoque disruptivo y no evolutivo sobre lo que históricamente ha sido la red packet; basicamente se trata de pensar en un piso de capacidades que empiece en el 1 Mbps y pueda ser tan alto como 100 Mbps en condiciones controladas; es decir, similar o compatible con lo que puede ser una conexión casera de internet.
Todavia el relevamiento está en la fase "explosiva", como todo tema que se comienza a explorar el patrón de evolución es predecible.
Los progresos son lentos pero hasta ahora he logrado profundizar en la plataforma dd-Wrt (que descarté) y la OpenWrt que creo que es la clave de la infraestructura de la red. Esta última está mucho mas alineada con una actividad de ham radio por su naturaleza abierta pero además porque es una arquitectura mucho mas potente. Se trata de una distribución especial Debian adaptada a la arquitectura MIPS en la que se basan la mayor parte de los routers inalámbricos (con distintas variantes). La curva de aprendizaje es un poco dura al comienzo pero el resultado es disponer de una computadora corriendo un Linux y con enorme flexibilidad para operar como router (incluso en AX.25) al precio de un router hogareño (unas pocas decenas de dolares).
Y ahi aparece la primer brecha tecnológica que obliga a pensar la iniciativa en forma distinta; los procesadores embebidos agregan una dimensión a la arquitectura inexistente hace una década cuando se luchaba con la red AX.25 en base a paquetes propietarios corriendo en una PC. Simplemente usar los mismos paquetes mayormente obsoletos en PC que son dos ordenes de magnitud mas grandes para hacer lo mismo carece de sentido. El enfoque claraemente va por el lado de los "utilitarios".
Es decir la arquitectura tiene que empezar a pensarse como el "appliance" corriendo un Linux especializado encargandose de la red y que es accedido por un "cliente" que es nuestra PC normal. Una de las cosas que "mataba" a la red packet era que no pocas estaciones eran erráticas en su disponibilidad, este enfoque soluciona el problema.
OpenWrt tiene una versión que además corre en procesadores Intel (X86). Y no hay que sacarle ni por un momento la vista de encima a la placa Raspberry Pi que creo tiene un enorme potencial para aplicaciones de aficionados. Gracias a la gestión de Pedro (LU7ABF) se han definido en el espacio ampr.org de Argentina tres subnets clase C (cor, lpg y mdq) con los cuales se están haciendo las pruebas.
Paralelamente, y por una afortunada coincidencia, me encuentro desarrollando una disertación sobre ambientes para desarrollos de sistemas embebidos que daré a comienzos del año próximo. Y digo que es una afortunada coincidencia porque el proceso de investigación me lleva a tener que evaluar varios ambientes embebidos... sin tenerlos. Eso me llevo a crear un ambiente de simulación, mayormente basado en el paquete QEMU, capaz de emular las arquitecturas ARM, MIPS, X86, SPARC y PowerPC. Es decir uno puede tener una "placa" embebida corriendo en un ambiente virtual en la PC que le provee un ecosistema tal que para el software es "indistinguible". Este ambiente tiene enormes ventajas no solo para el desarrollo sino también eventualmente para la ejecución de componentes de la red (una Raspberry PI emulada en mi máquina PC actual con una fracción de sus recursos no es mucho mas chica que mi máquina PC de hace una década).
Además de los "sistemas" y las "distribuciones" que de por si son un tema inagotable hay un número muy importante de cuestiones prácticas que resolver.
La primera es como crear los "túneles" que permitan la conectividad de los distintos LAN en tiempo real, asumiendo que no todos o incluso la mayoría no puedan establecerse por medios radiales puros. Para implementarlos se requiere definir que mecanismo de Point to Point es el mas efectivo, hay varias variantes posibles para establecer VPN que implementen estos enlaces "privados" a traves de Internet; es probable que alguna variante simple de PPTP (point to point tunneling protocol) sea el mas adecuado; sin embargo está claro que hay que comprender como hacer funcionar el ip forwarding por medio del IPIP protocol (tunel IP-IP, se encapsulan datagramas IP de una red en otra) pues es el que usa el gateway ampr.org para hacer el ruteo global. Hay un problema técnico aún no resuelto sobre como operar este protocolo en un medio que hace NAT/Masquereading.
El establecimiento de túneles es esencial tanto para el ruteo "aguas arriba" (conglomeración de MAN) como "aguas abajo" (conglomeración de LAN) de forma que la red pueda escalar en tamaño y en capilaridad.
El transporte en RF no le he prestado demasiada atención aún, pero estimo que deberá hacerse en banda de 5 GHz para aprovechar equipos comerciales ligeramente modificados (con la posible excepcion de utilizar equipos aún mas comunes de sin modificar para 2.4 GHz , los tradicionales Wi-Fi, si se logra una autorización limitada de la CNC para su uso por radioaficionados).
Muy lejos aún de ocupar el centro de la escena es "¿para que?"; como dije en una entrada anterior la respuesta ahora es facil.... el aprendizaje necesario es enorme y eso solo justifica la iniciativa. Pero en un plazo mas largo quizás hay que fijarse en iniciativas como "Buenos Aires Libre" como un modelo de utilización y gestión para la red resultante (que curiosamente no rutea Internet).
Ahhh, y además tenqo que completar una nueva versión del programa MM2OR antes del WAE DX SSB que se viene en un par de semanas (!!!).
No hay comentarios:
Publicar un comentario