Resumen

  • RFC 3654 no ordenó que un Forwarding Element siguiera reenviando siempre ni que se detuviera siempre al perder su asociación con el Control Element. Exigió detectar la pérdida, restaurar la asociación, resincronizar el estado y definir de antemano la respuesta del FE.
  • RFC 7121 describió después dos modos de recuperación: uno vuelve a preasociación; otro puede probar CE de respaldo y mantener el reenvío hasta que venza un plazo. Volver a asociarse no demuestra por sí solo que se haya restaurado todo el estado del FE.

Un router integrado podía tener dos centros de decisión

En noviembre de 2003, RFC 3654 describió el elemento de red como componentes de control y reenvío que cooperan y pueden parecer un router integrado ante los sistemas externos. El Control Element (CE) ejecuta funciones como los protocolos de enrutamiento y señalización; el Forwarding Element (FE) procesa paquetes. La separación es lógica: el documento no exige dos equipos físicos ni afirma que hubiera despliegue generalizado. Su argumento es que mecanismos comunes pueden mejorar la escala y permitir que ambos planos evolucionen por separado. RFC 3654

La situación difícil aparece si el FE conserva tablas y funciones programadas pero deja de estar asociado con su CE. «Falló el controlador» no revela qué pasó con los paquetes. El FE podría continuar con su estado vigente, detenerse o intentar llegar a un control de respaldo. RFC 3654 convierte esas posibilidades en preguntas explícitas.

La exigencia dejó abierta la respuesta, no la decisión

El requisito arquitectónico 7 reúne cuatro trabajos: detectar la pérdida de asociación, restaurarla, resincronizar el estado con eficiencia y predefinir la acción del FE. El texto cita seguir reenviando y detener las operaciones como ejemplos; no escoge una respuesta universal. El requisito de protocolo 8 repite la misma frontera. RFC 3654

Continuar puede conservar el tráfico, pero el FE sigue con el estado que ya tiene; detenerse limita ese intervalo, aunque vuelve el servicio dependiente de la asociación de control. Son consecuencias que debe valorar quien diseña el sistema, no fallos que RFC 3654 diga haber observado. La exigencia evita que el silencio accidental de una implementación tome la decisión sin haberla hecho visible.

Los estándares posteriores convirtieron la elección en una secuencia

RFC 5810, publicada en 2010 como especificación de protocolo del Standards Track, definió el protocolo ForCES y su Transport Mapping Layer para cumplir los requisitos de RFC 3654. RFC 5812 describió capacidades del FE, su estado actual, la configuración deseada y los bloques funcionales lógicos. Capacidad, estado y configuración son cosas distintas: lo que un FE puede hacer no es necesariamente lo que está haciendo ni lo que se le ha pedido hacer. RFC 5810 RFC 5812

RFC 7121, de 2014, agregó alta disponibilidad dentro del elemento de red. Su FE Protocol Object identifica el CE maestro y los de respaldo; los intervalos de heartbeat y la política de failover ayudan a detectar problemas de conexión. En el modo 0, predeterminado, el FE vuelve a preasociación tras perder el vínculo; si después se asocia, habrá que recrear su estado. En el modo 1, el FE intenta asociarse con los CE de respaldo por turnos durante el CE Failover Timeout Interval. Puede seguir reenviando mientras está «no asociado», según la política configurada. Si el plazo vence sin conexión, pasa a preasociación y baja su camino de reenvío. Una vez reconectado, el CE puede intentar sincronizar el estado perdido; el método queda fuera de la arquitectura ForCES y normalmente requiere nuevos mensajes de configuración y consultas. RFC 7121

La señal de heartbeat tampoco equivale a una ruta correcta. RFC 3654 dice que los heartbeats pueden priorizar la rapidez sobre una entrega estrictamente fiable, mientras que configuraciones y tablas de reenvío críticas requieren entrega robusta. Una señal ausente puede participar en el cambio de estado de asociación; por sí sola no prueba fallo físico, rutas erróneas ni pérdida completa del dispositivo. RFC 3654

RFC 3532 trató otro problema ForCES: la reasignación dinámica de recursos y la posibilidad de que la representación del controlador quedara desfasada. Aquí el límite es distinto: la respuesta predefinida del FE y la recuperación tras perder la asociación. RFC 3654 es Informational; los estándares posteriores muestran que el diseño se detalló, no que un operador concreto lo implementara. RFC 3532 RFC 3746 RFC 1812 Registro RFC 3654 Datatracker RFC 3654

Fuentes