摘要

  • RFC 3473 允许 RSVP-TE 的 Notify 直接抵达预先登记的非相邻节点，并用 RFC 2961 的 ACK 机制确认消息被收到。
  • Notify 明确不能替代 PathErr 或 ResvErr，所以 ACK 证明的是告警送达，不是状态收敛、保护切换、流量恢复或应用成功。

告警可以跑在修复前面。RFC 3473 把这个常被仪表盘抹平的时间差写进了协议。

这份 2003 年 1 月发布的标准轨文档把 RFC 3471 的 GMPLS 功能落实到 RSVP-TE。广义标签、双向路径、约束集合、保护属性、控制与数据通道分离、管理状态和重启恢复都有具体对象。RFC 3472 对 CR-LDP 做了类似工作。Notify 处理的则是一道更窄的问题：故障发生在中间，而真正能改变显式路径的节点可能在很远的上游，怎样让它尽快知道？

Path 消息可以携带 Notify Request，请求向上游报告；Resv 可以请求向下游报告。对象中写入 IPv4 或 IPv6 的 Notify Node 地址。收到对象的节点应把地址存入相应状态块，转发节点通常还要继续带上请求。

但这不是不可变的端到端身份。局部策略可以改写下一跳发出的 Notify Node。如果同一消息出现多个请求，只有第一个有意义，后续对象可以忽略且不应传播。更重要的是，请求存在并不保证将来一定生成 Notify。

当合适的错误发生时，检测节点可以把 Notify 发给一个非相邻目标。非目标节点原样转发，或者发送者用新的 IP 头直接封装到目标地址。Notify 不带 Router Alert。于是，描述故障的证据消息拥有了一条不同于故障位置、也不同于逐跳 PathErr/ResvErr 的传递路径。

ERROR_SPEC 说明错误，并给出检测节点或故障链路；会话与发送者、流描述限定受影响的 LSP。一次错误可能向两个方向发出通知，但没有先收到相应 Notify Request 的节点不得凭空生成它。

RFC 2961 提供 Message ID 与可靠投递 ACK。目标收到 Notify 后应回送 Ack。这一往返能够回答一个重要而有限的问题：这个有编号的 RSVP 消息是否抵达指定节点？

它不能回答故障陈述是否符合物理事实，不能证明每个中间节点已经删掉或刷新状态，也不能证明备用路径有容量、光交叉连接完成切换、数据包重新出现或应用恢复响应。RFC 3473 明说 Notify 不替代现有错误消息。触发 PathErr 或 ResvErr 的错误可以同时触发 Notify；快捷告警只是另一条证据链，不是原状态机的提交记录。

Path_State_Removed 位进一步区分了消息与动作。传统 PathErr 逐跳上行时，中间节点不一定采取行动。新标志可记录某个转发错误的节点确实删除了关联 Path 状态。Notify 的 ACK 与这个局部删除凭据不是同一种收据，任何一个都不能代表所有跳点。

通知还可以聚合。发往同一 Notify Node、共享 ERROR_SPEC 的通知应尽量合并。实现可以按事件、计时器或其他方式决定，计时器默认间隔是一毫秒。聚合减少严重故障时的控制负载，却也意味着信封时间不必等于每个事件的发生时间；装在同一信封里的会话更不因此共享一次原子恢复。

管理状态流程最能说明为什么收讫后仍需第二张凭据。节点发送带 Down 状态的 Notify 后，还必须在可配置期限内看到同样带 Down 的 Path 返回，默认等待三十秒。如果确认没有出现，就要向下游发送 PathTear，并向上游发送 ResvTear 或带 Path_State_Removed 的 PathErr。协议自己没有把第一声警报当成完成。

控制通道故障又增加一层。重启等待期间，邻居可以保存既有 RSVP 与 MPLS 转发状态，仿佛刷新仍在继续。节点可能报告“控制通道降级”，恢复后再报告“控制通道活动”。前者不证明数据面已经断，后者也不证明所有状态、物理信号和业务都已恢复。

直达模式还改变了安全边界。RSVP 通常采用逐跳完整性与节点认证；非逐跳 Notify 绕过这条链。RFC 3473 因而建议用 IPsec 提供相当保护，或者禁用直达模式。即使告警经过认证并收到 ACK，也只证明相应密钥持有者发送了某段消息、目标收到了它，不能认证光子、数据包或业务结果。

RFC 4090 后来定义快速重路由，RFC 4872 和 RFC 4873 又区分端到端与分段恢复。它们增加了保护动作与责任范围，却没有让通知、选择、切换和实际恢复变成一个事实。

按 Heng Lu 的运行代码优先原则，Notify 在预期状态变化被观察到之前仍是符号记录。最小初始规范解释了为何共同格式只规定告警语法，把聚合和策略留给本地。现实层次要求 ACK 不能借用“业务恢复”的权威。

诚实的故障记录应保存安装请求的 Path/Resv、策略改写后的有效目标、检测者、ERROR_SPEC、会话、Message ID、发送、接收与 ACK。另行保存 PathErr/ResvErr 的逐跳进度、状态删除、保护或拆除决策、硬件编程、物理信号、双向流量和应用结果。只有最后几层对齐，才能写“已恢复”；ACK 位于故事更早的位置。

来源