摘要

  • RSVP 的数据路径由发送方发出的 Path 消息向下游铺陈，资源请求则由接收方用 Resv 消息逐跳向上游提出。每个节点仍要分别回答资源是否足够、请求者是否有权，并实际安装分类与调度状态。
  • Path/Resv 状态收不到匹配刷新就会被清除；ResvConf 也不是端到端服务证明。可信的“已预留”必须带着路径、请求、逐跳决策、安装读回、刷新纪元和数据面结果。

状态消失之时，协议才说出全部实话

设想一项业务结束，最后一个刷新报文没有再出现。路由器等待清理定时器到期，然后删除预留。没有中央机构签发撤销书，也不要求一条删除命令在整条路径上原子成功。

这不是 RSVP 的补救措施，而是 RFC 2205 的核心设计。Path 与 Resv 建立“软状态”，后续匹配消息周期性刷新它；超过清理期限仍未续期，状态就应消失。协议允许偶尔丢失控制报文，却拒绝让昨天的需求永久占用今天的资源。

因此，“已预留”不是流量的静态属性。它必须展开成一句带时态的话：哪个接收方，针对哪组发送者和流，在什么路径、策略、资源决定与刷新窗口内，拥有怎样的处理。去掉期限，便去掉了这套机制最重要的安全边界。

数据向前走，请求反向回来

RSVP 是单向流的、由接收方驱动的预留协议。发送方沿数据将要经过的路由周期性发送 Path。支持 RSVP 的节点记录路径状态，包括前一跳信息。接收方收到路径信息后，再发出 Resv，沿相反方向逐跳走向相应发送者。

这两种报文不构成同一张收据。某节点看到 Path，只说明当时存在一份可供反向信令使用的路径状态；它没有证明 Resv 已经走完全程。看到 Resv，则证明请求抵达这一点；它没有证明更上游的节点也接受了请求。

多播让差别更加明显。多个接收方可以提出不同需求，向上游传播时可能合并。节点转发的 flowspec 可能经过本地调整，也可能代表多个下游分支的合成，而不是原报文的逐字副本。若审计只保留“曾收到 Resv”，就无法恢复真实的控制路径。

每一跳都有两道门，门后还有执行

Resv 到达中间节点后，首先面对准入控制与策略控制。准入控制问：资源够不够？策略控制问：这个请求者有没有权预留？RFC 2205 要求两项都通过。

随后才是执行：节点配置包分类器与包调度器，或相应链路层机制。RSVP 负责传递服务质量和策略参数，但把它们视为不透明数据；真正解释参数并作出本地决定的是流量控制与管理系统。

于是至少有四条不能跨越的等号。资源充足不等于授权。授权不等于配置已安装。某个出接口安装成功不等于整条路径完成。控制面状态存在更不等于真实数据包获得了预期时延、丢包或带宽表现。

RFC 2208 当年就提醒，广泛部署还涉及路由器处理和存储负担、聚合、安全与策略等问题。这是历史性的适用性边界，不是今天的部署统计；它说明一套信令格式从来不能替代周围的组织和执行系统。

最像证书的消息，明确拒绝作证

接收方可以在 Resv 中请求确认。如果请求到达合并点，而已有预留等于或大于新请求，节点可以不再向上传播，直接返回 ResvConf。

从界面设计看，这很容易变成“成功”图标。可是 RFC 2205 明确写道，收到 ResvConf 不提供保证。标准给出的反例很具体：两个接收方的请求在某节点合并；第二个请求可能收到确认，而第一个请求尚未抵达匹配发送方，后来仍可能失败。ResvConf 之后甚至可能再来一个 ResvErr。

所以这张收据只能说明：一个明确节点，依据当时可见状态，处理了这项确认请求。它不能证明每一跳均已准入，每个调度器均已安装，路由没有变化，也不能证明应用真的得到端到端服务。

确认仍然有用。问题只在于，不能把局部控制事件借用成全程结果证书。

旧路径不必同步删除，它会失去续期

Path 与 Resv 是幂等的。路由变化后，下一条 Path 在新路径上建立状态，后续 Resv 再建立相应预留；旧路径上不再使用的状态则等待超时。

PathTear 和 ResvTear 可以加快删除，但它们也没有可靠传送保证。删除消息丢失不会让协议永久卡住，因为没有刷新，旧状态最终仍会被清理。自动遗忘比一次完美送达的撤销命令更可靠。

与此同时，端到端失败并不要求所有下游状态立刻消失。上游某节点准入失败时，失败点下游的预留可以继续存在，既可能提供部分服务，也可能让短暂路由摆动恢复得更快。于是“这里有预留状态”和“端到端预留未完成”可以同时为真。

真正有用的记录必须标明失败止于何处、哪些状态仍在、何时过期。一个全局布尔值做不到。

刷新可以压缩，租约不能被偷换

完整 Path 与 Resv 周期性重发会带来负担。RFC 2961 因此引入消息标识、针对特定触发报文的逐跳确认、打包和 Summary Refresh。已知状态可以通过标识符续期，不必每次重复整份对象。

减少的是字节与处理，不是过期条件。Summary Refresh 必须保持普通刷新所具有的状态同步属性；接收方找不到标识对应的状态时，可以返回刷新 NACK。某邻居确认收到消息，只证明那一跳的信令，不证明端到端服务。

审计时至少要保留四套时钟：请求纪元、各节点的刷新与清理时限、邻居之间的 MESSAGE_ID 纪元，以及数据面测量窗口。把它们压成一个“启用时间”，只是用简洁制造错误。

诊断看到的是内存切片

RFC 2745 的 DREQ 与 DREP 可以沿 RSVP 节点收集 Path 或预留状态。每一跳可附上诊断响应，帮助操作人员找到状态缺失或分歧的位置。

诊断本身也有边界。响应可能分片，可能因错误提前返回，回程可能不同，也可能受防火墙或超时影响。即使完整，它呈现的仍是若干节点在经过时保存的控制状态。它没有自动读回分类器与调度器，更没有测到应用实际经历的时延、丢包与吞吐。

DREP 增加了一位证人，却没有把控制面的证词变成数据面的事实。

把人物放回共同设计的坐标

IETF Datatracker 将 Lixia Zhang 列为 RFC 2205 作者之一。她在 UCLA 的个人介绍说明，RSVP 在其 Xerox PARC 时期被构思和开发。RFC 本身则列 Robert Braden 为编辑，Zhang、Steven Berson、Shai Herzog、Sugih Jamin 为作者，并致谢更广泛的研究与标准社群。

Internet Hall of Fame 把她的贡献与 RSVP 及后来 RSVP-TE 的实践联系起来。这是机构性的历史评价，不是运营商数量或流量份额调查；原始综合服务 RSVP 与后续流量工程扩展也不能混为一谈。

证据足以支持“共同设计者、共同作者、标准贡献者”。它不支持“唯一发明者、现任运营者、IETF 共识所有者或任何现实服务的担保人”。这种克制不会削弱人物，反而避免以声望填补本该由设备、管理员和测量提供的证据。

七张收据，才能说一个“预留”

第一张记录路径：发送方、会话、路由、前一跳和观察时间。第二张记录请求：接收方、Resv 原文、过滤与流规范、确认要求和纪元。第三张记录权限：每个相关节点的准入与策略决定。

第四张是安装：分类器和调度器目标、事务结果及配置读回。第五张是续期：刷新间隔、最后匹配刷新、清理期限、Summary Refresh 标识与 NACK。第六张限制确认或诊断的范围：谁回答、看见什么、何时回答。第七张记录结果：真实数据路径与特定时间窗内的服务测量。

没有哪张收据能替其他收据作证。把七者按路径与纪元连接后，才可以作出精确而有限的判断：某接收方提出了请求，明确节点在各自权限下接受并安装，状态仍在有效刷新期，数据包在测量窗口内得到某种结果。这比常亮绿灯更窄，也更可信。

来源