摘要

  • RFC 2379 建议 RSVP 控制消息复用已经存在的 best-effort 数据路径，即便这些消息的目的，是建立带有明确服务质量参数的另一条 ATM 虚电路。
  • 它更长久的价值是一条证据纪律：PATH 或 RESV 消息、RSVP 状态、准入结果、已配置的 VC 与应用实际得到的服务，是相互关联的凭据，却从来不是同一件事。

用未获保障的路径请求保障

RSVP 用于请求资源预留，ATM 又能够建立带有服务参数的虚电路。按直觉，控制消息似乎也该先获得一条可靠专线。RFC 2379 却给出了更节制的答案：单播 RSVP 消息沿着已经用于到达目的地的 best-effort VC 发送；多播消息则沿着已经承载发往该组普通流量的路径发送。

原因不是哲学，而是电路数量。会话能够建立、预留能够启动之前，普通数据路径本来就必须存在。让控制消息复用它，可以避免为了申请 QoS 电路而先配置更多信令专用电路。于是出现了一个重要的不对称：控制面可以通过较弱的传输，要求较强的数据服务。

RFC 并没有把较弱的路径重新命名为可靠路径。它承认 best-effort VC 可能无法提供 RSVP 理想中的信令可靠性。容错来自 RSVP 的时间结构：预留是需要定期刷新的软状态。个别控制包丢失不一定立即破坏同步，因为后续刷新还可以维持或重建状态。

这不等于丢包无关紧要。一次丢失的含义，要由随后的刷新、状态是否过期、准入是否仍有效以及相关电路是否存续共同判断。同样，一条已经发出的消息也不能单独证明预留已经成立。可靠性属于一个持续过程，而不属于某一个包的标签。

一份预留，一条独立 VC

ATM 天然鼓励聚合。理论上，多条 RSVP 会话可以共享虚电路，减少资源消耗。但在 RFC 2379 写成时，如何聚合仍是研究问题。它因此建议每份 RSVP 预留使用独立 VC。

这个看似保守的选择，让整条转换链变得可见。RSVP 会话不是 ATM 电路；实现需要把预留翻译成 ATM 服务参数，执行准入，创建或选取 VC，再把流量分类到正确电路上。反过来，一条已经存在的 VC 也不能证明数据包获得了请求中的服务。

同期文件有意拆分职责。RFC 2380 规定实现要求；RFC 2381 处理 Integrated Services 的 controlled-load 与 guaranteed service 如何映射到 ATM；RFC 2382 提供总体框架。文档之间的分工，正对应运行证据之间的分工：没有任何一次成功信令可以代替整条链的成功。

捷径的终点不是自己发现的

ATM shortcut 可以跨越逻辑 IP 子网，使 PATH 与 RESV 经过不对称路径。RFC 2379 依赖 RSVP 已有机制来适应这种情况：NHOP 对象保留上一跳信息，收到消息的接口不对时，设备可以继续转发。

更关键的是终点决定权。QoS shortcut 不应独立发明自己的终点。如果 best-effort 流量已经建立 shortcut，RSVP 触发的 QoS VC 应使用同一终点。按照推荐模型，如果 best-effort shortcut 从未建立，跨子网 QoS shortcut 也不会凭空出现。

这并不等于 QoS 服务无法创建。逐跳 QoS VC 仍然可以存在。限制针对的是 shortcut 的终点从何而来：best-effort 转发上下文先作出选择，QoS 建设继承这个选择。新电路能证明配置动作发生过，却不能倒推路径发现、准入和服务交付都成功了。

多播无法被压成一种答案

一个多播会话里，不同接收方可以请求不同 QoS，也可以完全不请求。配套框架列出了完全异构、有限异构、同构和修正同构等模型。RFC 2379 没有宣布某一种适合所有网络，而是要求至少支持有限异构或修正同构，最好同时支持并提供选择机制。

这种克制本身就是互联网历史的一部分。BCP 没有为了让架构图更整齐而抹掉真实接收方之间的差异；它给出可执行的最低要求，同时保留差异可见性。

至少四张凭据

理解 RFC 2379 最稳妥的方法，是分别保存四类凭据：best-effort 路径承载过控制；RSVP 状态得到建立和刷新；准入与配置过程创建了 ATM VC；计数器及应用观察显示数据实际得到了什么。

发出 PATH 不代表收到 RESV；收到 RESV 不代表准入；VC 存活不代表分类正确；QoS 标签更不代表时延、丢包或交付结果。这个架构之所以能够工作，正是因为它连接了这些层，却没有宣布它们彼此等同。