Arquitectura de routing en la red mesh Zénit

Zénit no es una red al uso. Con 247 nodos operativos distribuidos geográficamente, una latencia media de 12ms y un uptime del 99.97%, su arquitectura de routing es el componente crítico que hace posible estas métricas.

Este artículo es una exploración técnica de cómo los datos encuentran su camino en la red mesh de TroncoCorp.

Topología de malla completa

A diferencia de las redes tradicionales con topología de estrella (un nodo central al que todos se conectan) o de árbol (jerarquía de nodos), Zénit utiliza una topología de malla parcial optimizada.

Cada nodo no se conecta a todos los demás (eso sería O(n^2) conexiones, inviable para 247 nodos), sino a un subconjunto de vecinos seleccionados dinámicamente. La selección de vecinos se basa en tres factores:

1. Proximidad geográfica: los nodos se conectan preferentemente a vecinos cercanos, minimizando la latencia física
2. Diversidad de rutas: cada nodo mantiene conexiones con al menos 3 vecinos que no compartan el mismo ISP o ubicación física
3. Capacidad disponible: los nodos con más ancho de banda libre atraen más conexiones

El resultado es un grafo denso pero gestionable donde cada nodo tiene entre 3 y 8 vecinos directos, y cualquier par de nodos está conectado por una ruta de máximo 4 saltos.

Protocolo de routing: OLSR adaptativo

Zénit implementa una versión modificada de OLSR (Optimized Link State Routing), adaptada para redes mesh de alta movilidad. A diferencia de OLSR estándar, la implementación de Zénit incluye:

MPRs dinámicos

Los Multi-Point Relays (MPRs) son nodos seleccionados para retransmitir mensajes de control. En Zénit, la selección de MPRs se recalcula cada 30 segundos basándose en:

• Capacidad de proceso actual: un nodo con CPU al 90% no es buen MPR
• Estabilidad del enlace: nodos con fluctuaciones frecuentes de señal se evitan
• Entrega de paquetes: ratio histórico de éxito en retransmisiones

Encaminamiento adaptativo

Cuando la red detecta congestión o latencia elevada en una ruta, el protocolo no espera a que falle para recalcular. Utiliza umbrales progresivos:

Métrica	Umbral verde	Umbral amarillo	Umbral rojo
Latencia	<15ms	15-30ms	>30ms
Pérdida	<0.1%	0.1-1%	>1%
Jitter	<5ms	5-15ms	>15ms

En umbral amarillo, el tráfico nuevo se deriva a rutas alternativas. En umbral rojo, todo el tráfico se rerutea inmediatamente y se fuerza una recalculación global de la tabla de routing.

Algoritmo de balanceo de carga

El balanceo de carga en Zénit no es round-robin ni basado en conexiones mínimas. Utiliza un algoritmo de coste ponderado multi-factor:

Coste(ruta) = w1 * latencia + w2 * (1 / ancho_de_banda_disponible) + w3 * probabilidad_pérdida + w4 * (carga_actual / capacidad_total)

Los pesos (w1-w4) se ajustan dinámicamente según el tipo de tráfico:

• Tráfico de votación: prioriza baja latencia (w1 alto)
• Transferencia de datos: prioriza ancho de banda (w2 alto)
• Streaming: prioriza bajo jitter (reflejado en w3)
• Mensajería: balanceo estándar

Recuperación ante fallos

Cuando un nodo falla, el proceso de recuperación es automático y ocurre en milisegundos:

1. Detección (50ms): los vecinos del nodo caído detectan la ausencia de heartbeats tras 3 intervalos perdidos
2. Difusión (100ms): el evento de fallo se propaga a través de la red mediante paquetes TC (Topology Control)
3. Recálculo local (200ms): cada nodo afectado recalcula sus rutas omitiendo el nodo caído
4. Convergencia (500ms): la red completa converge a un estado estable sin el nodo

En el peor caso — fallo de múltiples nodos simultáneos — la convergencia puede tomar hasta 2 segundos. El sistema está diseñado para que ninguna aplicación note la interrupción.

Cifrado a nivel de ruta

Cada salto en la red Zénit está cifrado de extremo a extremo, pero además implementa cifrado por salto (hop-by-hop). Esto significa que aunque un nodo intermedio sea comprometido, no puede leer el contenido del paquete — solo sabe a qué vecino debe reenviarlo.

El protocolo utiliza:

• TLS 1.3 para autenticación inicial entre nodos
• Claves de sesión efímeras que se rotan cada 24 horas
• Forward secrecy: si una clave de sesión se compromete, el tráfico anterior y posterior sigue siendo seguro
• Firmas Ed25519 para verificar la integridad de las tablas de routing

Simulación y modelado

Antes de desplegar cambios en el protocolo de routing, Zénit utiliza un gemelo digital de la red para simular:

• Nuevas configuraciones de vecinos
• Cambios en los pesos del algoritmo de balanceo
• Escenarios de fallo masivo
• Adición o retirada de nodos

El gemelo digital ejecuta el mismo código de routing que los nodos reales, pero en un entorno simulado con modelos de latencia de red realistas basados en datos históricos.

Rendimiento en el mundo real

Las métricas actuales de la red Zénit demuestran la eficacia del diseño:

Métrica	Valor	Percentil
Latencia media	11.8ms	P50
Latencia P95	24.3ms	P95
Latencia P99	42.1ms	P99
Paquetes perdidos	0.03%	—
Tiempo de convergencia	680ms	—
Ratio de rutas óptimas	97.2%	—

Conclusión

La arquitectura de routing de Zénit demuestra que una red mesh soberana puede igualar — y en muchos aspectos superar — el rendimiento de infraestructuras centralizadas. No necesita servidores centrales, no tiene puntos únicos de fallo, y puede operar sin intervención humana durante períodos prolongados.

Cada uno de los 247 nodos es una pieza de soberanía. Juntos, forman un sistema de comunicación que no pide permiso para funcionar.