摘要

  • RFC 2129 的 PROPOSE/PROPOSE ACK 让两个邻居共享 Dedicated-VC 的 VCID，并检验电路与邻居；后续 OFFER/READY 才把来源、目的 IPv4 地址定义的流绑定到该电路。
  • 绑定是可拒绝、需刷新、会失效的邻居本地软状态。任何单一步骤都不能证明整条路径一致、终端收到数据、容量持续可用或达到 QoS。

一条电路，两份不同的收据

上游路由器选定一条 Dedicated-VC，先沿这条电路发送 PROPOSE，带上 VCID 和下游邻居的目标 IP 地址。下游若接受，则从 Default-VC 返回 PROPOSE ACK。前者是将来可能用于直通的专用电路，后者仍是普通逐跳转发与控制回信的通道。这一来一回让双方认出同一段连接，也检验连接与邻居是否工作；它没有指定要送哪条 IP 流。

第二份收据才回答流的问题。上游经 Default-VC 发出 OFFER，列出 VCID、flow-ID 和希望采用的刷新间隔。下游返回 READY，表示接受这条流，并能从 Dedicated-VC 接收它的分组。发出 OFFER 不是收到 READY；此前的 ACK 更不是流的许可。即使一个邻居已经 READY，下一跳也要独立协商，不能把一段成功写成全网贯通。

RFC 2129 是 Informational 备忘录，并不制定互联网标准。它描述的 FANP 只在相邻节点间管理“流—数据链路连接”的映射。Default-VC 保留常规 IP 逐跳处理；对匹配流的 Dedicated-VC，兼容的信元交换路由器可以按链路标识转发，不必在该点重新处理每个 IP 头。这个局部加速并没有取代上游的路由选择，也没有赋予一条跨多跳路径统一的状态。

提前备路还是临时开路

协议的起点是一项本地判断。备忘录举了按 TCP/UDP 端口和本地策略识别长会话或大量分组的触发例子。节点可以预先建立若干 VC，触发时从空闲池取用；也可以等需求出现，再通过 ATM 信令建立。前者响应快，却占着可能用不到的资源；后者少占空闲电路，却要付出建立时间。RFC 把选择交给本地节点，并未给出某家网络已经节约多少成本的实证。

名字相似也容易制造误判。此处 flow-ID 只包含来源和目的 IPv4 地址，与 IPv6 的 flow label 不同。VCID 用来标识两个邻居之间的一条链路连接，即使两端的 VPI/VCI 数值不同，也可以谈论同一段连接。两者都不是发件人身份认证。聚合流、组播、IP 层 QoS 信令和 IPv6 支持被列为未来工作，不应回填成 1997 年方案已经交付的能力。

回执为什么还会过期

两轮协商都允许失败。下游可以基于策略拒绝 PROPOSE，无法识别 VCID 类型或分配资源时也可报错；OFFER 还可能遇到未知 VCID、未知 flow-ID 类型、流策略拒绝、刷新间隔不被支持或资源不足。没有收到相应回信时，上游会重试；按规范建议的五次重传仍无答复，就应释放选中的电路。控制消息丢失不是默许。

收到 READY 也不是永久授权。下游在专用电路持续收到分组时周期性发 READY；没有包，就不继续发。上游超过失效间隔未获刷新，删除 flow-ID 与 VCID 的映射；下游长期收不到包，也清理自身映射，以处理上游无声故障。文中两分钟刷新、六分钟失效、二十分钟清理只是建议值及其先后关系，不是通用服务承诺。不同 VC 类型还可通过显式 REMOVE/ACK 或 ATM 信令撤销。

这份 1997 年文献的价值，是逼迫观察者把证据分层：触发、选中电路、得到 ACK、得到 READY、后来继续刷新，各自只说明一个局部阶段。它们不能自行证明来源可信、每一跳状态一致、端到端交付、稳定容量、QoS 或经济收益。RFC 2098 描画了相邻的 bypass 架构；RFC 2129 则揭示了一条捷径要持续可靠，邻居间的映射必须不断核对。速度不可能代替这项维护。

来源