Resumen

  • RFC 9657 presenta casos deterministas de Time-Variant Routing para preservar recursos, mejorar eficiencia y anticipar alcance dinámico, sin definir un mecanismo concreto.
  • El coste puede convertirse en función del tiempo y justificar filtrado, acumulación o store-and-forward, pero la ventana prevista no prueba custodia, aparición del enlace, tarifa real ni entrega.
  • La evidencia separa fuente y revisión del pronóstico, autoridad del reloj, política local, cálculo, cola, adjacency observada, reenvío y recepción final.

Una ruta que incluye quedarse quieto

La imagen habitual de routing es espacial: elegir por qué enlaces avanza un paquete. RFC 9657 añade otra dimensión. A veces la mejor decisión consiste en no avanzar todavía.

En su caso de eficiencia operativa, el coste de un nodo o camino puede variar con el tiempo. Para que el cálculo tenga sentido, el coste debe ser medible y predecible, durar lo suficiente para reaccionar y cambiar en magnitud suficiente. Un nodo puede evitar un enlace caro, acumular volumen para una transmisión larga o esperar mejores condiciones ambientales.

RFC 9657 es Informational y no define protocolo ni formato. Establece que el tiempo puede informar la ruta. No convierte la predicción de una tarifa o contacto en un hecho consumado.

De N1 a N3 pasando por una noche en N2

El ejemplo más claro envía datos de N1 a N2 en t1 y los guarda hasta t3, cuando el segundo tramo cuesta menos. La topología temporal incluye almacenamiento. El camino ya no se describe sólo por enlaces, sino por enlace, custodia, espera y otro enlace.

RFC 4838 explica la arquitectura de redes tolerantes a retrasos, y RFC 9171 define Bundle Protocol Version 7. Ese contexto muestra por qué conservar datos hasta una oportunidad futura puede ser una operación legítima.

También muestra lo que debe probarse. ¿N2 aceptó custodia? ¿Había espacio? ¿Cuál era la expiración? ¿Seguían íntegros los datos? ¿La ventana t3 comenzó según el mismo reloj? ¿Se liberó la cola? ¿N3 confirmó recepción? Sin esas respuestas, la ruta más barata sigue siendo un plan.

El coste previsto tiene autor y versión

La eficiencia puede significar tarifa celular, coste eléctrico, carga de refrigeración o impacto ambiental. El documento contempla además redes “tidales”, donde puertos se apagan o encienden según patrones previsibles de demanda.

Cada función de coste procede de una autoridad. Una tabla comercial, un pronóstico energético, una política de carbono o una proyección de tráfico pueden cambiar en momentos distintos. El cálculo debe guardar cuál usó, cuándo se emitió, cuánto duraba y qué versión de política convirtió ese número en una acción.

RFC 9845 amplía las oportunidades de gestión para redes más sostenibles. Pero una ruta programada como “verde” no prueba ahorro de energía ni reducción de emisiones. Esos resultados necesitan medición y una comparación que conserve la utilidad del servicio.

Conservar recursos puede cambiar la topología

Otra familia de RFC 9657 cubre nodos con energía, temperatura o almacenamiento limitados. Una radio puede apagarse para prolongar la vida del nodo, entrar en modo térmico seguro o reservar energía para recoger datos. El caso supone gasto conocido, acumulación predecible y política suficientemente consistente.

La desaparición planificada no es necesariamente avería. El regreso planificado tampoco es todavía reachability. El RFC advierte de que, tras reincorporarse, descubrimiento y sincronización del vecindario pueden retrasar el forwarding. En una ventana breve, ese retraso puede consumir toda la oportunidad.

El recibo une umbral de recurso, transición física, descubrimiento, instalación de ruta, primer paquete y resultado. El calendario sólo ocupa el principio.

El movimiento deja caducar enlaces

La tercera familia es reachability dinámica. Si la trayectoria y el entorno son previsibles, el cálculo puede anticipar cuándo expira o vuelve una adjacency, cómo cambia la tasa o si conviene filtrar un enlace que caerá pronto.

Satélites, ferris y aviones ofrecen movimientos planificables. Eso no elimina fallos de enlaces intersatélite, tormentas, ocultación, errores de apuntado o tasas menores. RFC 9657 excluye los escenarios puramente no deterministas, como vehículo a vehículo, pero no afirma que lo determinista sea perfecto.

“Expirará a T2” es una proposición del modelo. “Se perdió a T2” necesita telemetría de adjacency. “El tráfico cambió de camino” necesita estado de forwarding. “Llegó” necesita evidencia del destino.

Manipular el reloj altera la red

RFC 3339 normaliza cómo expresar fechas y horas. RFC 5905 define NTPv4 y RFC 8633 ofrece prácticas para proteger el tiempo. Una marca válida no prueba sincronía, y la sincronía no prueba una fuente autorizada.

RFC 9657 considera crítica la sincronización y advierte que cambios no autorizados del reloj pueden interrumpir el funcionamiento o producir DoS. Un desplazamiento puede hacer que N1 crea abierta la ventana mientras N2 la considera cerrada. La función de coste es la misma; la coordenada compartida dejó de serlo.

Conserve fuente temporal, offset, incertidumbre, estado y eventos de ajuste junto a la decisión. El reloj forma parte del control plane.

Calendario válido, pronóstico obsoleto

RFC 9922 define grupos YANG reutilizables para recurrencia, validación y estado, pero no presupone la acción y deja fuera la resolución de conflictos. RFC 7758 expone capacidad temporal en NETCONF.

Esas piezas sirven para expresar y administrar una ventana. No validan la tarifa, trayectoria, energía o demanda que la originó. Esta comisión no repite el límite ya publicado de RFC 9922 entre estado del horario y ejecución; posee el límite entre pronóstico de estado de red y resultado observado.

Construir la cadena completa

Registre objetivo, productor del pronóstico, modelo, hipótesis, versión y validez. Añada representación temporal, reloj, distribución y aceptación local. Guarde el route computation, la acción elegida y las alternativas rechazadas.

Para datos diferidos, asigne identidad a cola, custodia, expiración y liberación. Para el enlace, mida aparición, vecinos, tasa y próximo salto. Para el cierre, capture recepción o resultado de aplicación. Conserve los pronósticos fallidos para medir error y evitar una historia escrita sólo por éxitos.

Las capas de realidad de Heng Lu separan forecast, calendario, política y resultado. La Especificación Inicial Mínima permite coordinar el mínimo sin trasladar toda autoridad. La primacía del código en ejecución exige el recibo de forwarding y entrega.

Fuentes