摘要

  • RSVP 信令与数据共用虚电路可以减少 VC 数量和 PATH 消息的建路等待，却会让刷新消息承受数据违规所触发的丢弃。
  • 独立信令 VC 只提供独立流量合约，并不证明预留或业务成功；建路、承载、及时刷新、状态存续和数据处理都要分别留证。

最危险的环路往往由一个合理的节省决定开始。RSVP 依靠周期性的 PATH 与 RESV 消息维持预留。ATM 依靠虚电路和流量合约分配资源。既然控制消息本来就要沿着相关数据路径前进，把两者放在同一条 VC 上，可以少建一条电路，也不用先等待另一轮 ATM 信令。

局部看，每一项都更少：更少 VC、更少建路动作、更短的 PATH 启动等待。

可是一旦数据不符合这条 VC 的流量合约，丢弃对象并不会天然区分“普通数据”和“维持预留所需的控制消息”。控制包可能随违规流量一起消失。偶发丢包是 RSVP 已知的工作条件；连续丢失则会让软状态超时。状态消失后，QoS VC 可能被拆除并再次建立。原本为了减少信令而采取的共用方案，反而制造了更多信令。

软状态把“及时到达”变成正确性条件

RFC 2205 没有把预留写成永久记录。路由器和主机里的 RSVP 状态由 PATH 与 RESV 周期刷新；在清理计时器到期前没有收到匹配刷新，状态就会被删除。这样做适合会变化的路由和组播成员：旧状态即使没有可靠的删除事务，也能自行消退。

这种鲁棒性有明确边界。周期发送可以弥补偶然丢失，清理时间也可以容忍若干连续缺包；它们无法把一个长期拥塞或持续受监管丢弃的控制路径变成可靠路径。RFC 2205 因而建议为 RSVP 消息静态保留最低带宽，避免维护状态的消息被拥塞本身抹去。

于是，“发送端已发出刷新”只是一张很窄的收据。还要知道它被分到哪条 VC、得到什么流量处理、是否跨过 ATM 段、何时被对端收到，以及是否在状态过期前完成刷新。少一项，都不能把“已发送”提升为“状态仍有效”。

同理，ATM VC 仍然存在，不等于依附其上的 RSVP 状态仍然存在；RSVP 状态仍在，也不等于数据用的 QoS 呼叫已经获准；两者都为真，也不等于应用收到承诺的服务。

四种承载方式，四种代价分配

RFC 2382 列出四个主要家族。第一，信令和数据共用 VC。第二，每个预留配一条平行的 RSVP 信令 VC。第三，共享同一入口和同一组出口的多个会话，复用一条点到多点信令 VC。第四，用多条点到点信令 VC 在会话之间复用。

它们不是封装风格偏好，而是在分配失败域。

共用方案不增加 VC，也让沿数据路线发送的 PATH 消息免去额外 ATM 建路时延。代价是控制消息继承数据 VC 的合规处理。RFC 2382 特别指出：违规数据可能导致 RSVP 信令被丢弃；丢得过多，就会反复拆除和重建 QoS VC。这不是控制包“更重要”便能自动解决的问题，因为二者已进入同一个处理合同。

另一个变体把信令放在最佳努力数据路径上。它避开 QoS VC 上的违规流量，却没有避开 ATM 网络的拥塞。RFC 2382 认为 RSVP 控制消息应得到优先服务，并把 ATM 入口前由 IP 调度器优先处理控制包视为仍需研究、实现并不容易的方向。

每个预留配独立信令 VC，则获得最清楚的隔离。独立 VC 有自己的流量合约，合规控制消息不会因另一条数据 VC 上的违规流量被丢弃。但账单也清楚：最低 VC 数量翻倍，增加 ATM 信令和建立时延，还消耗稀缺连接资源。

复用减少电路，也增加解释责任

复用试图在隔离与成本之间折中。点到多点控制 VC 只能自然服务于具有同一入口、同一出口集合的会话。组播成员变化以后，入口需要寻找已有的匹配 VC、新建一条、修改现有出口，或继续向已经离开的端点发送无用流量。

因此，“节省了多少 VC”不是静态属性，而取决于当时的拓扑、流量模式和成员集合。点到点控制 VC 在骨干内可以长期存在，也可利用反向通道降低某些信令成本；所需数量仍取决于参与节点和通信组合。复用现有最佳努力 VC 会再次减少电路，却提高 RSVP 包丢失概率。

证据对象也随之变化。专用控制 VC 的记录至少可以把一个 PATH/RESV 包连接到一条控制电路及其流量合约。复用 VC 还必须保存当时的会话到 VC 映射、入口和出口集合。若只保留一张“控制 VC 正常”的图，故障后无法知道哪些预留依赖它。

给控制面更多 QoS 也有上限

最直接的反应是给信令很强的 QoS。RFC 2382 没有把这写成免费答案。RSVP 信令并不频繁，典型刷新间隔约三十秒，因此只需相对小的分配。请求过大，资源紧张时反而可能让控制 VC 的建立被拒绝。

拒绝后退回最佳努力也形成悖论：如果 QoS 呼叫因 ATM 拥塞失败，那么最佳努力包仍要穿过同一个拥塞网络，而且保护更少。“存在回退”并不能证明“回退抵达”。

这与 RFC 1755 早先防范连接抖动的目标相呼应。ATM 的连接管理本来就要避免无意义地反复创建和释放并行连接。RFC 2382 展示了另一条抖动路径：控制承载丢包，RSVP 软状态消失，QoS VC 被拆除，然后系统用更多控制动作再次建路。

真正可审计的链条至少包括：特定 RSVP 消息生成；选定 VC 和流量处理；该 VC 获准并处于活动状态；消息穿过 ATM 段；对端在期限内刷新匹配状态；数据 VC 保持安装；实际数据获得目标处理。上一环成功，不能代替下一环。

RFC 2382 没有规定所有网络必须使用同一种控制拓扑。它做了更耐久的事：要求设计者承认控制消息也要被承载，也有资源成本，也会落入具体失败域。最低共同约束不是“单独拉线”，而是让维持软状态的通道具有足够保护、可观测性和诚实的证据。