摘要

  • RFC 3654 没有规定失去 Control Element（CE）关联后，Forwarding Element（FE）必须始终继续转发或一律停止。它要求架构能够检测关联丢失、恢复关联、重同步状态，并预先设定 FE 的响应。
  • RFC 7121 后来定义了两种不同的恢复模式：一种返回预关联阶段；另一种可轮询备用 CE，并在计时器到期前选择继续转发。重新关联本身并不证明 FE 的全部状态都已恢复。

一台路由器可以是一套系统，也可以分成两个逻辑角色

2003 年 11 月，RFC 3654 将网络元素描述为控制与转发组件协同工作的整体，对外仍可表现为一个集成的 IP 设备。Control Element 负责路由、信令等控制功能；Forwarding Element 负责逐包处理。这里的分离是逻辑架构，不要求两台物理设备。RFC 3654 提到可扩展性和两个平面独立演进的好处，但没有声称这一架构已被普遍部署。 RFC 3654

难题出现在 FE 仍保留已配置的表和功能，却不再与 CE 关联时。“控制器故障”并不能回答包会怎样处理。FE 可能沿用现有状态继续转发，也可能停下，或尝试联系备用 CE。RFC 3654 把这些原本容易混为一谈的问题拆开了。

要求必须先作选择，却没有给所有设备同一个答案

架构要求 7 包含四件事：检测关联丢失、恢复关联、有效地重同步状态，以及预设 FE 失去 CE 后的动作。文中以继续转发或停止运行为例，但并未替所有网络元素选定其中一种。协议要求 8 再次强调相同边界。 RFC 3654

继续转发可能保住流量，但 FE 只能使用目前掌握的状态；停止则缩短这段不确定时期，却使服务依赖控制关联。它们是系统设计者需要评估的后果，不是 RFC 声称已经发生的故障。关键在于，动作应当在关联中断之前就由架构明确，而不是让实现的沉默替它作决定。

后续高可用规范将选择写进状态与计时器

RFC 5810 于 2010 年作为 Standards Track 协议规范发布，定义了 ForCES 协议及其传输映射层，以满足 RFC 3654 的协议要求。RFC 5812 则描述 FE 模型中的能力、当前状态、配置以及逻辑功能块。三者不可混为一谈：FE 能做什么、此刻正在做什么、CE 希望它做什么，分别是不同信息。 RFC 5810 RFC 5812

2014 年的 RFC 7121 补充了 ForCES 网络元素内部的高可用程序。FE Protocol Object 记录主 CE 与备用 CE；heartbeat 间隔和策略用于发现连接问题。模式 0 是默认模式，关联丢失后 FE 返回预关联阶段；以后重新建立关联时，需要重新创建 FE 状态。模式 1 则使用重启恢复：FE 按轮询顺序尝试备用 CE，同时运行 CE Failover Timeout Interval。在“未关联”状态下，FE 可根据已配置的策略继续转发。若超时仍未关联，它就转入预关联阶段并关闭转发路径。重新连上之后，CE 可以尝试同步 FE 在断开期间丢失的状态；但这种同步方法不属于 ForCES 架构范围，通常会涉及新的配置消息和查询。 RFC 7121

这也解释了 heartbeat 为什么不是路径正确性的判决。RFC 3654 允许关联检测用的 heartbeat 优先考虑及时性，而不要求严格可靠送达；配置和转发表等关键载荷则必须可靠。一个信号缺失可以触发关联状态转换，却不能单独证明物理设备损坏、路由错误或整个网络元素消失。 RFC 3654

另一份 ForCES 文档 RFC 3532 讨论资源动态重分配，以及控制器所持模型可能落后于转发元素的情形。那是相邻但不同的机制。本文只追踪关联丢失后的预设动作与高可用恢复，不重复资源分配或陈旧清单问题。RFC 3654 属于 Informational；后续规范说明设计如何继续细化，并不证明某个运营商已经采用。 RFC 3532 RFC 3746 RFC 1812 RFC Editor 的 RFC 3654 记录 IETF Datatracker 的 RFC 3654 记录

来源