摘要

  • RFC 3475 要求 Call Release 被接收并处理后，触发释放该 Call 关联的全部 Connections。
  • 每条 Connection 仍走普通 Label Withdraw 与 Label Release 流程，因此 Call 层确认不能证明所有分支已原子完成、物理资源已归还或业务已经关闭。

一条“关闭”命令，可能只是许多后续动作的起点。2003 年 3 月发布的 RFC 3475，把这个事实写进 ASON 控制平面。

它的身份是 Informational，而不是 Internet Standard。文件的直接目的，是为 ITU-T ASON 工作选用的 CR-LDP 扩展记录 IANA 码点；它还明确说，如何使用这些扩展由 ITU-T 文件规定。因此它证明的是当时存在一套协议提案，不是普遍部署。

ASON 将 Call 与 Connection 分开。Call 是参与方之间的关系，Connection 才是占用网络资源的实现。一段 Call 可以关联多条 Connections。Call Setup 与 Call Release 作用于上层关系，而标签流程继续逐条操作下层实现。

Call Release 携带 Source ID、Destination ID 与 CALL_ID。网络中的任何实体都可以用它终止已建立的 Call。随后一条带适当状态码的 Notification 向发起者确认释放。若只看这一层，过程很像一次操作加一张回执。

紧接着的规则打破了这种错觉：接收并处理 Call Release 必须触发释放所有关联 Connections。每条 Connection 的释放仍依赖普通 CR-LDP Label Release 与 Label Withdraw。一个上层动作由此展开为多个对等体、FEC 和标签状态变更。

RFC 3036 说明了分支为什么不能合并。下游 LSR 用 Label Withdraw 撤销映射，接收方必须回应 Label Release；上游在不再需要映射时也发送 Label Release。这些消息各有明确的对等关系与标签范围，并不存在一位全局见证者宣布“一切已经清空”。

如果一个 Call 关联三条 Connections，它们完全可能分别处于已释放、等待对端、仍保留本地状态。RFC 3475 要求最终释放全部，但没有创造同时完成的原子事务。Call 层 Notification 与逐分支完成清单是两种不同证据。

因此必须冻结释放时刻的关联集合。后来看到一个空列表，不能说明当时有几条 Connection、哪条先完成、哪条重试，也不能排除某条记录在硬件资源归还前就从清单中消失。

CALL_ID 能把扇出过程关联在一起，却不能提供完成证明。它不能证明每个 Withdraw 都被处理、每个标签映射都删除、每个 cross-connect 都归还容量，也不能证明光信号、流量、客户会话或计费已经停止。

soft permanent connection 又增加一层边界。其用户到网络段可以长期预配置，网络段才由控制平面建立和拆除。释放交换 Connection，不代表永久边缘段也发生变化。

Crankback 从建立失败的方向提供对照。Notification 可以用 ER-HOP 指出资源短缺位置，让发起者重新计算绕行路线。知道第一条请求在哪里受阻，并不能证明替代路径有资源，更不能证明下一次建立成功。

后来的 RFC 4139、RFC 4974 等文件继续完善 ASON 与 Call 程序，但不能倒灌为 RFC 3475 的标准地位，也不能证明某个运营商实际使用了这些 CR-LDP 消息。

按照 Heng Lu 的现实分层，Call Release 是符号层指令，节点处理是一次决策，每条 Label Withdraw/Release 是范围有限的协议回执，本地状态删除、硬件重编程、物理信号、流量与商业关闭又是不同观测。负责任的系统应记录释放时的 Connection 快照，为每个分支保存独立结果，最后才关闭整个 Call。

这还要求记录失败，而不是只保存成功。某条 Connection 超时、某个对等体失联、某项资源等待人工清理，都应保留自己的状态、责任方与下一次检查时间。若总状态只剩“Call 已释放”，系统便失去区分已完成、可重试和仍占用资源三种现实的能力。聚合结果只有在分母固定、每个成员都有结论时才具有可审计意义。

来源