摘要

  • 摘要刷新引用此前完整通告过的 Path 或 Resv 状态，不携带一份新的资源预留说明。它可以延续已有状态，不能代替建立或改变状态的完整消息。
  • 找不到标识符时，接收方可以要求补发完整描述；记录还在但内容已损坏，则可能逃过这种检查。RFC 2961 明确承认，两种刷新方式的错误恢复能力并不完全相同。
  • 后续扩展把重启恢复、可靠投递和邻接故障检测分别纳入设计。节约周期性重复的成本，不等于这些重复原来承担的工作已经消失。

空位反而比较容易发现

设想路由器收到一串它应该认得的编号。其中一个找不到对应状态，它便能指出缺口，请邻居重新发送完整说明。现在换一种情况：编号能找到，记录也还占着原来的位置，只是里面某项状态已经不对了。短消息没有把那项内容再送来，接收方又凭什么在续期时发现错误？

这不是一宗被还原的网络事故，而是 RSVP 设计文档自己留下的问题。2001 年 4 月的 RFC 2961 在介绍摘要刷新之后，专门讨论了内部状态损坏。短消息能应付常见丢包和路由变化，却不能完整保留普通刷新所具有的错误恢复能力。

这段保留意见比“消息变短了”更能说明扩展改变了什么。旧消息不只说“继续保留”，也再次带来“保留的究竟是什么”。新消息可以只指向已经存好的说明。它保留了续期动作，却不总是提供重新核对内容的材料。

一次重复，原来做着两份工作

1997 年 9 月的 RFC 2205 将 RSVP 建立在软状态之上。Path 和 Resv 周期性刷新，维持沿途的路径与资源预留状态；足够长时间收不到刷新，状态便会清理。显式拆除能够加快释放，但即使拆除消息丢失，状态也不应永久留下。

周期性重发完整描述还有另一项作用：此前丢失、没有及时传递或需要恢复的信息，可以在后续刷新中重新到达。路由改变时，新的路径上的节点也需要取得相应状态。重复并非纯粹浪费，其中一部分是让协议不必假定每次变化都被完美记录的代价。

因此，调整刷新周期有双向影响。周期长，维护消息少了，某些恢复与清理也可能变慢；周期短，反复处理的负担就更重。这不是一个只要把数值调大就能免费解决的问题。尤其当设备维持大量状态时，报文开销和每条状态的处理工作会一起进入控制面的预算。

RFC 2961 试图减少重复描述，而没有把所有变化都交给编号来表达。文档严格区分触发消息与刷新消息：新增状态或已有内容变化，应发送触发消息；原样重复才是刷新。即使带宽数值看起来相同，只要策略对象或其他相关信息改变，也不能继续把旧编号当作充分说明。

编号并不包含那份说明

扩展中的 MESSAGE_ID 由标识符和 epoch 配合使用，后者帮助区分不同运行时期。它还依赖生成者地址所界定的范围，并不是全网唯一的一张“资源所有权证书”。对于原来的 Path 与 Resv，生成者地址来自 RSVP_HOP；不能一概把外层 IP 源地址当作同一个东西。

这些细节解决的是“你指的是哪一次通告、哪一份状态”。它们没有把状态本身压进一个可验证的摘要。MESSAGE_ID 不是内容哈希，也不是认证码。节点在初次完整通告中建立编号与状态的关系，后来才有条件用编号代替重复的内容。

Srefresh 正是在这个前提下工作。发送方列出此前通告过的 Path 或 Resv 标识符，接收方找到相应状态后刷新它。2001 年的设计还要求，这种摘要刷新不能比被替代的普通刷新更稀疏。最初省下的是每次携带的描述，并不是任意延长彼此沉默的时间。

同一文档还定义了 Bundle 和消息确认。Bundle 将若干完整 RSVP 消息装进一个 IP 数据报，减少封装层面的重复；它没有把多个资源要求合并成一个获准的请求。确认和快速重传则改善单条消息的投递。三种机制可以配合，却不能被缩成一句“收到一个包，就确认了全部预留”。

一条否认，只能指出它看见的缺口

若合适的接收节点无法识别摘要中的状态，就通过 MESSAGE_ID_NACK 指出缺失的标识符。发送方若仍持有对应状态，必须补发标准 Path 或 Resv；自己也已没有相应状态，则无从补出一份描述。

这里的否定确认不表示“你要的带宽太大，拒绝分配”，而是“我没有找到你正在引用的状态”。准入决定与记忆缺口是不同问题。把两者混在一起，会让运营人员把一次同步问题当成容量不足，或者把一次补发成功误记成资源申请已经通过。

组播还要多一层判断。收到摘要的节点并不都应该持有相同状态；协议使用源、组和反向路径检查，避免与该流无关的接收方因为查不到记录而不断要求补发。编号查找发生在具体的邻接和转发语境中，不是向整个网络询问一本公共总账。

然而，否定确认通道再清楚，也只会报告被它识别为缺失的东西。若记录仍可匹配，单凭没有 NACK，无法证明它的每个字段都和发送方一致。一个安静的修复通道，可以意味着没有缺失，也可以只是没有看到另一类错误。

不能把两种校验合成一种保证

RFC 2961 第 5.5 节给出了两种补充办法，但它们针对的情况并不相同。

第一种是在发送触发消息时，对内部状态计算并保存校验值，后来重新计算，以发现本应产生触发消息、却没有被通告出去的状态变化。文档紧接着提醒：这个办法不保护内部状态损坏。它补的是漏发变化通知，不能被描述成对远端所有保存内容的一次完整体检。

第二种更直接：即使用了摘要刷新，也隔一段更长的时间发送标准 Path 和 Resv。完整描述再次出现，便恢复了普通 RSVP 刷新所覆盖的那类错误恢复机会。为保留节省效果，它应比摘要刷新稀疏；同一周期发了完整刷新，就不必再为相同状态发一份摘要。两者的相对频率可以由管理者配置。

这不是优化失败后不得不退回原点。更准确地说，周期性工作被拆开了：多数轮次负责低成本维持，较少轮次重新带来完整信息。管理者获得了控制重复成本的空间，也必须接受恢复观察机会与成本之间的关系。

认证不能替代这项选择。RFC 2747 讨论的 RSVP 完整性保护，处理的是消息及其发送者在密钥假设下是否可信；它不是加密，也不是对被引用状态的自动复核。即使每一条短消息都确实来自那个邻居，消息没有携带的字段，也不会因为来源真实而突然出现。这里引用的是历史机制，而非今日密码配置建议。

邻居记得，不代表转发状态可以凭空长出来

2007 年 10 月的 RFC 5063 将这套工具用于 GMPLS RSVP 的重启恢复，出现了一个有意思的方向变化：下游节点可以向刚重启的上游控制器，摘要列出自己此前收到的 Path 状态，而不是普通摘要刷新中发送方自己通告出去的状态。

这种记忆有助于恢复信令。能匹配旧标识符，就可能少传一份完整的 RecoveryPath；不能匹配，则需要更充分的描述。能力位与恢复标记负责让双方知道，这不是普通续期。

但下游的记忆没有获得创造转发状态的权力。恢复过程要将信令重新关联到保留下来的转发状态；RecoveryPath 本身不能凭空建立缺失的数据面。若需要建立新的转发，仍须走上游 Path 或入口管理命令及其策略要求等相应程序。

规范的安全讨论也没有把可信邻居等同于正确映射。能认证它是谁，不表示它提供的重启前后关系必然正确。于是，“记录恢复了”与“数据确实按预期转发”之间，仍需保留一项独立检查。

后来，故障检测被交给了别的工作

2009 年的 RFC 5439 分析 RSVP-TE 扩展性时，提醒读者关注状态数量、内存和处理成本。一个很长的标识符列表仍有逐项处理的工作；报文变少，不代表每条预留的负担也消失。那份分析不能提供今天所有设备通用的容量上限。

2018 年 5 月的 RFC 8370 则进一步拉长刷新周期，但并非只改定时器。它将可靠投递、未获确认状态的较短刷新、信令邻接故障检测和能力声明放在一起。邻接被判定失败时，通过该邻接学到的 Path 与 Resv 状态要按超时处理。

因此，较长间隔背后的变化，是故障检测不能再主要等待那次遥远的普通刷新。文档加强了确认要求，又保留对不支持新能力的邻居使用传统较短间隔的规则。不能把这些要求倒写成 2001 年已有的保证，也不能根据标准发布推断所有运营网络都已采用。

IANA 的 RSVP 参数登记 记录了消息类型、对象类别和后续能力位。共同的编号使实现能解释相同字段，真正允许双方减少重复的，仍是运行中的能力判断。邻居不再声明支持时，不能仅凭它过去支持过，就继续假定短消息有效。

这段历史的落点不是“重复应该全部删掉”。重复有时提供的不只是存活信号，还有重新取得描述、纠正遗漏和暴露故障的机会。摘要刷新成功地减少了一项成本，却也让协议必须更精确地回答：留下来的每一次检查，究竟检查了什么？