摘要

  • RFC 2383 以“一跳一条 ATM 虚电路”的方式承载 ST2+，并区分用户、控制和管理平面；承载数据的预留通道与报告故障的控制通道不是同一个证明对象。
  • 由于 ST2+ 的恢复规则不完整，而多个代理可能同时收到 ATM 故障通知，规范要求 CONNECT 选择 NoRecover；明确拒绝一个不可靠的恢复承诺，比让双方对同一状态作出不同理解更可互操作。

预留带宽，不等于预留了一条从故障中回来的路。

1998 年 8 月发布的 RFC 2383 是一份信息类文件，讨论如何在 ATM UNI 3.1 上承载 ST2+。它给出一种看上去相当紧密的映射：一个 ST2+ 跳对应一条 ATM 虚电路，这条电路不与别的跳共用，一个跳也不拆散到多条虚电路上。于是，抽象的资源请求获得了具体承载，流量参数可以落到连接上，每段路径也有了自己的状态。

但规范在恢复问题上没有把这种确定性向外延伸。实现必须在 CONNECT 中选择 NoRecover。请求方若没有这样做，接收方就应以 REFUSE 和 NoRecover 原因拒绝。文件没有把它包装成“有限支持的自动恢复”，也没有暗示 ATM 的告警机制已经补齐 ST2+ 的恢复语义。它直接把流恢复交还给应用。

这一拒绝之所以重要，是因为系统已经拥有许多容易被误认成“恢复”的部件。ATM 可以报告连接失效；ST2+ 代理可以交换控制消息；FlowSpec 可以沿跳申请资源；另一条虚电路也可能重新建立。然而，这些事实并不能回答：由哪个代理先行动、旧状态由谁释放、并发恢复如何去重、新连接是否属于原来的数据流，以及应用是否接受这段中断前后的工作仍是同一个操作。

一跳一电路，却不只有一种状态

RFC 2383 将用户平面、控制平面和管理平面分开。用户平面上的 ST2+ 数据经过为这一跳分配的 ATM 连接；控制平面上的代理交换 SCMP 消息；管理平面处理寻址、建连和状态观察。三者相互关联，却不能被压成同一条“通路正常”信号。

SCMP 使用哪条虚电路，文件有意不作统一规定。实现可以复用 IPv4 虚电路，也可以为 ST2+ 控制另建专用连接。一个数据流的数据和 SCMP 消息必须沿相同的 ST2+ 路由方向行进，但到同一 IP 地址的 IPv4 方向可能不同。这意味着控制消息还能到达时，预留的数据电路可能已经断开；反过来，控制路径也可能先失效，而用户数据所在电路尚未表现出同样的故障。

因此，“网络可达”只是一个缺少对象的句子。它可能表示 IPv4 找到了路由，也可能表示 SCMP 找到了代理，或者 ATM 交换机仍记得呼叫，又或者用户数据确实穿过了那条特定 VC。每一项都是不同现实层的证据，任何一项都不会自动为其余各项背书。

一跳一 VC 的规则让证据边界更清楚。虚电路是这一跳的具体承载，不是分散在任意路径上的抽象许诺。可是一条端到端数据流通常包含多个跳、多个电路和多个代理。一个电路失效，只能确定某一段已经断裂；它不能凭自身完成整条数据流的重建。

故障检测没有产生恢复权威

规范允许 ATM 环境不支持 ST2+ 的 HELLO 功能，因为 ATM 被认为能够提供足够的连接故障通知。表面上看，周期性的 HELLO 因而显得重复；但同一文件紧接着指出，数据和 SCMP 控制可以走不同虚电路。一个路径上的 HELLO 即使成功，也证明不了另一个路径的状态。

恢复的难点也来自这种分离。RFC 1819 曾描述 ST2+ 恢复，但 RFC 2383 认为相关规则在此环境下不够清楚、也不完整。ATM 可能把同一故障通知给所有受影响方，于是多个 ST2+ 代理几乎同时发现问题。如果每个代理都独立恢复，行动就会竞争：一个代理正在释放旧状态，另一个可能正在把新段接上；两个代理可能创建互相冲突的替代连接；下游还可能把状态接到错误的恢复尝试上。

触发器不是协议。安全恢复至少需要一个权威选择规则、一致的恢复身份、可执行的顺序，以及分别确认故障发现、旧资源释放、新资源准入、跳状态重建、端到端接续和应用确认的回执。RFC 2383 没有把这些内容定义成可互操作合约，所以 NoRecover 不是技术悲观，而是对控制面缺口的准确命名。

交换机可以如实说“这条 VC 已经消失”，代理可以如实说“我收到了通知”，新电路也可以如实说“准入成功”。应用仍可能没有拿到预期的数据流，或者在中断处收到改变业务结果的重复、缺口与乱序。故障事实、新建事实和完成事实必须分别保管。

应用接过最后一段责任

RFC 2383 明确说不支持数据流恢复，应用必须负责。这个句子并没有凭空赋予应用恢复能力，而是把未解决的义务交给唯一可能理解业务连续性含义的层。

对某个应用，恢复可能意味着以序列号续传；对另一个应用，它可能意味着建立全新的流、丢弃所有部分结果，或者让人判断重复交付是否可以接受。网络只知道如何提供路径，不知道旧路径和新路径能否合成一次有效工作。

因此，运营者不能仅凭 ATM 建立了替代 VC，就把数据流标为“已恢复”。证明链必须连接旧电路和新电路的身份、故障通知、预留资源的释放、ST2+ 跳状态重建、端到端数据流身份以及应用自己的完成信号。少了任一环，“恢复”都只是目标状态，不是已经观察到的结果。

从 Heng Lu 的现实层视角看，物理链路、ATM 呼叫、ST2+ 代理、SCMP 交换、应用会话和用户看到的结果属于相邻却不同的层。把它们压成一个绿色灯号，会让仪表盘获得整洁，却丢掉判断陈述真假的关键差异。这种整洁本身就是符号权力：命名者获得了“已经恢复”的叙述权，承担重复或丢失后果的人却未必拥有相同证据。

准入方向同时也是政策方向

即使没有故障，建连也需要确定行动方。对于交换虚电路，RFC 2383 允许按照运营或计费政策决定由哪一方发起 ATM 连接。这个方向与构建 ST2+ 数据流时的发送者—接收者方向相互独立。

原因并不抽象：付费的一方可能负责发起呼叫，构建数据流的一方可能期待下一跳采取行动，最先看见故障的代理却未必有权创建一条会产生费用的新连接。一个忽视这些权限和激励边界的恢复设计，可以在图上成立，却无法在运营中执行。

FlowSpec 到 ATM 的映射也有硬边界。ST2+ 的流量特征和服务质量被转换为 ATM 参数，并参考 RFC 2211、RFC 2212 的服务模型和 RFC 1755 的 ATM 信令规则。UNI 3.1 不支持在既有连接上修改 QoS。若一次受支持的 FlowSpec 变更需要新的资源，实现就要释放旧的 ATM 连接，再创建新的连接。

这不是原地修改，而是两份资源配置之间的交接。旧电路何时停止、新电路何时准入、失败时是否保留可用旧状态，都取决于实现和政策。RFC 2383 规定了映射和重建需要，却没有发布无损切换测量、应用连续性结果或任何特定部署事实。

这也把本文与 RFC 2380 的既有研究区分开来。RFC 2380 关注在变更预留时，旧分配、新分配与 reduced reservation 的承诺边界；RFC 2383 的独有问题则是 ATM 故障被多个代理同时看见时，协议没有完整的恢复权威。两者都研究资源状态，但不拥有同一个论点。

明确拒绝也是一种互操作

NoRecover 容易被看作“功能还没完成”。它同时也是积极的互操作选择。如果一个实现采用私有恢复顺序，另一个实现却用不同方式理解相同状态，双方可能制造重复数据流、遗留预留，或让应用两端对结果形成不同认知。

强制该标志，使限制在建立连接时就可见。请求恢复的对端会收到带有明确原因的 REFUSE，而不是在未来故障中才发现双方从未共享同一恢复模型。一个可以准确失败的接口，比一个对成功含义含混的接口更可靠。

按照 Heng Lu 的最小初始规范视角，克制并不是空白。最小规范不应在尚未证明的领域填入看似保证的文字；它应规定共同核心，把未共享的决策留在本地，并允许后续运行代码以证据扩展边界。在这里，专用虚电路、寻址、建连与资源映射属于共同核心；流恢复不属于。

若未来要删除 NoRecover，仅增加一段规范文字不够。运行代码必须在对抗性测试中证明：多个代理同时收到同一 ATM 故障通知时，系统能选出唯一恢复权威、抑制重复动作、结清旧预留、建立新承载、接回正确流，并向应用给出无歧义结果。测试还要覆盖控制消息丢失、非对称路由，以及数据 VC 与控制 VC 不同时故障。

RFC 2383 没有声称完成这些测试。它的信息类地位也限制了历史解释：这是协议说明，不是部署调查。IETF 数据跟踪器记录了文件形成过程，却不能据此推断 ST2+ over ATM 得到广泛部署。

安全只覆盖证明链的一条边

文件的安全论述同样保持边界。它认为这些最小 ATM 扩展和错误修正没有削弱 ST2+ 或 UNI 3.1 的安全，并指出，若网络提供的主叫号码经过验证，它可以帮助认证。

“帮助”并不是“完成”。主叫身份可以说明谁发起电路，却不能证明 FlowSpec 获得应用授权、当前端点仍由同一主体控制、新 VC 确实属于旧数据流，或应用接受了重建后的会话。身份、资源、协议状态与结果需要各自证据。

现代读者也应保持同样克制。RFC 2383 不能证明某个运营商部署过这种协议，不能证明电路达到某项时延指标，不能证明某次中断被恢复，也不能证明计费政策选择了某个发起方。这些都需要独立运行记录。

它真正留下的结论更长久：资源预留、故障检测、控制可达、流重建和应用成功是五个不同陈述。系统可以拥有前三者而没有第四者，也可以重建基础设施却仍未获得第五者。1998 年的 RFC 2383 用一个毫不含混的标志守住了这个边界：NoRecover。

这不意味着失败后什么也不能做。它意味着，在权威、顺序和最终回执尚未标准化之前，网络不应许诺已经完成恢复。电路可以预留资源，代理可以得知它已经断裂，而“重新开始究竟意味着什么”仍由应用负责。

来源