摘要

  • RFC 3469 把 MPLS 恢复拆成检测、等待、通知、执行与流量真正重新到达；控制面完成动作并不是时钟的终点。
  • 一条预先建立的保护路径仍可能共用同一故障点、没有预留足够资源、只能提供降级服务，或在承载流量后让业务暂时失去下一层保护。

2003 年的网络管理界面可以显示一条工作路径和一条保护路径。颜色、标签、拓扑线条都很完整。真正的光纤被切断时，这些符号却不能回答最简单的问题：备用路径此刻是否存活，是否有容量，是否通向正确的汇合点，数据包何时重新出现？

RFC 3469 在 2003 年 2 月以 Informational RFC 发布。它不是互联网标准，也没有规定一套可以直接部署的恢复协议；重启问题明确不在范围内。它最重要的工作，是把“恢复”这个容易制造虚假确定性的词拆成可观察、可归责的阶段。

文档先区分重路由与保护切换。重路由在故障之后建立新路径或路径段；保护切换使用故障之前已经建立的恢复路径。两者可以连续发生：先把流量迅速送到临时绕行路径，网络进入半稳定状态，待路由协议收敛后，再建立更合适的新工作路径并第二次移动流量。

因此，“备用路径存在”只是很弱的证明。预建路径可能与工作路径共享发生故障的链路、节点或风险组；它可能已有标签，却没有预留带宽和缓存；也可能原本为别的用途建立，只是被预先认定为可接受的候选。备用路径甚至可能先于工作路径失效，或在同一物理事件中同时失效。

RFC 3469 用五段时间描述第一轮恢复。T1 从网络受损到故障被检测；T2 是可为零的等待期；T3 是故障指示信号从检测点到路径切换 LSR 的通知时间；T4 是实际恢复操作，包括路径切换点与路径汇合点之间可能发生的协调；T5 则从最后一个控制动作结束，一直计算到流量真正重新抵达遭受中断的位置。

T5 是整个框架里最值得保留的纠正。“切换完成”不等于“流量恢复”。标签项可以已经改写，而数据包仍在传播、排队、丢失或乱序；绕行路径也可能只有一部分所需资源。恢复计时不能停在配置事务提交的一刻，它必须等到数据面留下回执。

初次恢复也不是终局。回切周期从物理损伤被修复开始，经过故障清除检测、清除等待、清除通知、回切操作，最后才是流量重新回到首选路径。立刻回切不一定更可靠。若修复路径仍在抖动，过早动作会制造第二次中断；先等待稳定，再以 make-before-break 方式迁移，可能减少丢包和乱序。

动态重路由又是第三条时间线。路由协议先收敛，网络可设置有限的 hold-down，随后建立新工作路径、完成切换并观察流量。快速保护的价值是买到时间，不是保证第一次绕行就是长期最优结构。

框架把“路径如何建立”和“资源何时分配”分成两条轴。恢复路径可以预建、预先认证，或者故障后按需建立；资源可以预留，也可以故障后才争取。RFC 3469 将能保持工作路径服务保证的路径称为等价恢复路径，将无法保持同等性能的路径称为受限恢复路径。受限路径不是失败，它能在完全中断与降级运行之间争取空间；危险在于临时降级被监控系统永久遗忘。

1+1 与 1:1 也不是两个名称相近的图。1+1 持续复制流量，由汇合点选择副本，代价是持续占用资源。1:1 平时只让受保护流量走工作路径，恢复路径可以承载可被抢占的低优先级流量；故障后，保护流量会将其挤走。扩展到 1:n 或 m:n 后，保护计划必须说明哪些同时故障能够被覆盖，而不能只统计备用路径数量。

修复位置改变通知与覆盖范围。局部修复在故障链路或邻居上游迅速动作，通知距离短，却只保护特定局部。全局修复能覆盖更长的路径，或取得更完整的分离，但远端修复点必须先收到故障信息。替代出口甚至可以恢复转发，而不恢复原来的精确路径。旁路隧道能承载多条恢复路径，却可能只够其中一部分同时使用。

被保护的也未必是全部流量。文档允许只恢复某个受保护流量部分，也允许把多条工作路径捆绑处理。某个高级别业务成功恢复，不能代表普通业务没有被丢弃。文档使用的 EXP 位术语后来由 RFC 5462 明确为 Traffic Class；应保留的是“选择性保护”的控制边界，而不是旧字段名称。

检测、宣告、通知与触发同样不能合并。硬故障与性能下降不同；下降只有越过配置阈值后才成为可触发恢复的故障。下层可以提供更快的链路失败或劣化信号。发现问题的 LSR 未必拥有切换权，它可能只能把 FIS 送给路径修复点。一次观测不是一次授权，更不是一次成功恢复。

切换之后，风险并未消失。可回切模式会在原路径恢复稳定后把流量送回去；在此之前，流量已经占用了唯一恢复路径，可能暂时没有第二份保护，而原工作路径的资源仍被保留。不可回切模式可以让绕行路径成为新工作路径，也可以把修复后的旧路径改作保护，或建立一对全新的优化路径。此时仪表盘全绿，第二次故障的暴露却可能最大。

RFC 3469 因而给出两个不同的指标。“恢复时间”是检测、等待、通知、操作和流量回归的总和；“完全恢复时间”则要等到流量运行在为故障场景充分工程化的链路上。只有初次恢复已经是等价且永久的安排，两者才相同。

文档还要求比较建立期间的脆弱窗口、备用容量、附加时延、保护质量、乱序、状态开销、丢包与覆盖率。所谓类似 SONET 的 50 毫秒，只是切换设计目标的参照，不是实网测量，更不是端到端业务保证。

后来的 RFC 4090、RFC 4426、RFC 4427、RFC 4428 与 RFC 5714 分别推进了快速重路由机制、通用术语、多层恢复分析与 IP 快速重路由框架。它们证明这个问题继续演化，却不能反向证明某个 RFC 3469 方案已经部署、路径真正物理分离或应用无感完成。

用 Heng Lu 的 Running-Code Primacy 来读，配置里的“已预建”和“已恢复”都只是符号，必须由转发表、资源状态和真实流量共同证实。Minimum Initial Specification 解释了为什么文档提供可组合的最小原语，而没有宣布唯一算法。Reality Layers 则要求把受损、检测、通知、切换、数据包与应用结果分别保留。

RFC 3469 留下的历史教训不是“多建备用路径”，而是不要把路径对象当作恢复事件。谁发现了故障，谁把它宣告为故障，谁有权切换，故障时究竟有多少资源，流量在哪里重新出现，服务质量是否保持，何时重新获得下一层保护——这些回执齐全以后，“恢复”才不是配置文件里的一种愿望。

来源