摘要

  • 保留 MPLS 转发表能缩短 LDP 控制面恢复，但保留下来的只是旧会话留下的主张；它必须在期限内由对端、FEC、标签空间和新一轮控制消息重新确认。
  • 恢复期允许旧绑定与新分配并存。若共同分配权威、陈旧状态期限和数据面见证不清楚，同一个标签可能同时承载两种含义，导致误投而不是简单丢包。

两个局部正确，合成一次错误转发

设想上游路由器在 LDP 会话中断后保留了转发表。对它而言，标签 24017 仍对应原来的 FEC，继续发送似乎是维持可用性的正确动作。与此同时，下游控制进程重启，没有完整继承原来的分配视图，又把 24017 分给另一 FEC。对下游而言，这也是一次有效的新分配。

问题不是哪一张表“坏掉”，而是旧权威尚未结束，新权威已经开始。数据包穿过两者边界时，同一个数字有了不同含义。RFC 3612 明确指出，恢复中的上游可能继续使用旧标签，而下游把它重新分配给另一个 FEC；结果可以是错误转发。

RFC 3612 于 2003 年 9 月作为 IETF 信息类 RFC 发布。它是 LDP 重启机制的适用性说明，对比 RFC 3478 的 graceful restart 与 RFC 3479 的 fault tolerance。它本身不是 Internet Standard，也不证明任何厂商实现、生产部署、故障或攻击。它引用的 RFC 3036 后来由 RFC 5036 取代。

这份文件的价值不在于给“优雅”贴标签，而在于揭示保留的代价。传统 LDP 把 TCP 会话失效与拆除相关 LSP、释放标签和资源联系起来。重启扩展允许状态在会话之后暂时存活，于是系统不必从零开始；代价是标签的使用期可能超过最初授权它的会话。

会话中断不等于数据通道中断

RFC 3612 把 session failure 与 node failure 分开。前者是两端设备仍运行，但 LDP 会话断开并重建；文件特意说明，即使控制在带内，会话中断也不意味着数据通道同时中断。后者则是节点或 LDP 组件重启，本地看到的是重新初始化。

这两种情形又都不能直接说明转发硬件的状态。有的架构能在控制面重启时保留硬件表，有的不能；物理资源故障还可能让数据面先失效。监控至少需要分别记录控制会话、控制进程、硬件转发表与实际数据包，而不能把一个 up/down 字段投射到四层事实。

文件也把保护路径、链路保护和隧道保护排除在范围外。LDP 状态恢复不是快速重路由的同义词。要让流量不受影响，会话两端至少都要保留转发状态。只有一端保留时，RFC 3478 仍可能帮助稍后重建，但不能据此声称中断期间业务连续。

计时器只是旧权威的租期

RFC 3478 通过 FT Session TLV 交换两个时间边界。FT Reconnect Timeout 请求邻居在通信失败后保留既有转发状态；Recovery Time 表示重启设备愿意继续保存自身状态多久。零值表示没有保存，或已经不能使用。

保留下来的条目被标记为 stale。收到新的标签映射可以解除陈旧标记；期限届满仍未刷新者应被删除。时间更长能容纳更大的标签库，却也让过时或错误的绑定活得更久。时间更短能减少暴露，却可能在同步尚未完成时拆掉仍有用的状态。

因此，配置值必须由实际恢复能力支撑：LSP 数量、控制链路吞吐、处理器能力和标签变化率共同决定同步能否完成。安静的 targeted LDP 会话与随 IGP 变化的 discovery 会话，即使写着相同的时间，也背负不同的恢复债务。

RFC 5919 后来增加 End-of-LIB 通知，帮助对端判断初始标签发布阶段何时结束。但相关能力并不保证一定发送或收到该通知；本地计时器还可以在未收到时按“已结束”继续。它证明的是一个规定阶段的边界，不是远端硬件安装、全网收敛或数据包交付。

收到、固化、执行、安装是四件事

RFC 3479 采用更重的容错办法：为受保护操作编号，确认已固化的消息，周期性做 checkpoint，在计划停机前暂停新变化，并在 TCP 重连后重发丢失操作。双方都要实现相关流程，还要能审计恢复的控制状态与转发状态。

其 ACK 语义尤其重要。接收方可以在安全记录某条消息后、尚未完全处理之前确认。于是 ACK 是“这项控制意图不会因当前会话丢失而消失”的收据，不是“结果已经生效”的收据。Label Request 被保存，不等于 Label Mapping 已生成；Mapping 被处理，不等于硬件已安装；硬件有条目，不等于包抵达目的地。

频繁确认能缩小最近变化的未确认尾部，却增加正常运行的消息与处理成本。稀疏 checkpoint 简化实现，却把更多变化留给恢复阶段。计划升级时的 cork 流程能让边界更干净，但它无法把原本错误的表变成正确的表。

保存机制会忠实保存错误

RFC 3612 的鲁棒性警告很直接：若状态已经错误，保存会让错误继续；极端情况下，被保存的错误状态本身就是故障原因。持久性做得完美，不代表内容正确。

RFC 3478 重放全部映射，有机会清理未被重新确认的旧项；但如果输入与计算路径不变，同一错误也可能再次生成。RFC 3479 可能从另一条代码路径重建部分状态，却会保留其扩展状态中的错误。恢复设计应把“状态留下来”和“状态获得新的独立证明”列为两项验收。

标签竞争还可能来自会话之外：静态配置、另一 LDP 实例、RSVP-TE 或其他分配协议可能共享空间。恢复系统保留的标签不能因为原会话已断开就被另一机制拿走。统一分配器或分段标签空间可以建立边界，但运行者必须证明它们在故障时仍是共同权威。

安全后果并不抽象。RFC 3612 指出，超过原授权会话继续使用标签会产生数据误投；RFC 3479 还讨论了过早重用可能带来的未授权服务或拒绝服务。这些是协议风险，不是某次真实攻击的证据，却足以要求标签租期进入安全审计。

给每个标签保存一条恢复收据

可审计记录首先标明对端、会话世代与故障类型，再保存能力声明、重连期限和恢复期限。每个保留条目都应有标签空间、分配者、FEC、下一跳、陈旧标记与最终处置：刷新、替换、撤回或过期。

第二部分记录执行链：消息收到、持久化、处理、安装、观测。它注明 checkpoint 前沿、重发操作、End-of-LIB 是否真实到达或被超时替代，以及恢复期是否出现新分配冲突。

第三部分只属于数据面：双向探测、两端计数器和代表性 FEC 的连续样本。它们可以与控制记录关联，不能被控制记录代替。没有包级见证时，正确答案是“未观测”，不是“同步成功所以连续”。

最小共同契约让不同实现交换足够的证据，又不强迫它们采用同一内部架构。运行代码产生状态，RFC 让状态可互认；只有独立数据面见证，才能把保留的主张提升为转发结论。

来源