摘要

  • LLC 封装把协议类型放进每个 AAL5 PDU，因此一条 ATM 虚电路可以承载多种协议；基于 VC 的复用则不携带通用类型标签，而是规定一条 VC 只承载一种协议。
  • 基于 VC 的复用减少了报头与处理开销，却把解释权交给 PVC 配置或 SVC 呼叫协商。AAL5 重组成功，只证明外层数据单元成立，并不证明虚电路绑定、上层解析和应用结果都正确。

标签从数据里搬进了关系表

ATM 把可变长度的数据切成固定长度的单元。接收端等到最后一个单元，AAL5 才能还原 CPCS-PDU，读取长度并核对 CRC。到了这一步，外层信封已经完整，但接收端仍然要回答：里面应当交给哪个协议？

1993 年 7 月发布的 RFC 1483 给出了两种答案。第一种是 LLC 封装：在所承载的 PDU 前放置 IEEE 802.2 LLC 头，必要时再接 SNAP。对于非 ISO 的路由协议，AA-AA-03、OUI 与 PID/EtherType 共同说明类型；IP 的示例使用零 OUI 和 0x0800。每个 PDU 都带着自己的分发标签，所以多种协议可以共用一条 VC。

第二种是基于 VC 的复用。AAL5 载荷中不再放通用的多协议标签。接收端根据“这条 VC 只属于某一种协议”的约定来选择解析器。需要承载三种协议，就建立三条各自有类型含义的 VC。

RFC 1483 的信息页用“多种协议共享一条 VC”与“每种协议使用独立 VC”概括这个选择。真正发生变化的不是协议类型是否存在，而是类型证据存放在哪里：随 PDU 一起到达，还是存在于 PDU 之外的电路关系中。

外层完整性不能替代内层含义

桥接 PDU 更能说明边界。RFC 1483 的 SNAP OUI/PID 不只表示“这是一帧”，还表示原始介质类型，以及原来的 FCS 是否保留。AAL5 CRC 正确，并不能告诉桥接端如何还原内部帧。外层收据与内层解释是两张收据。

VC 复用省去了反复出现的 LLC/SNAP 分发字节，也减少了相应处理。在某些包长下，少几个字节甚至可以避免多占一个 ATM 单元。但被省掉的字段并没有变成常识。PVC 两端必须事先配置相同的封装方式和协议；SVC 则要在呼叫建立时协商。

这类优化容易产生一种错觉：包头更短，系统状态就更少。实际恰好相反。原来可以从当前 PDU 读取的事实，变成了“VC 标识 → 协议”的外部映射。一次包内读取被换成了对配置、信令与生命周期的依赖。

故障的形状也随之变化。LLC/SNAP 标签损坏，可能只影响一个 PDU。VC 映射错误，则可能让这条电路上所有结构完整的 PDU 都进入错误的解析器。规范能定义格式，却不能证明某个未命名现场的两端配置始终一致。

PVC 在运行前约定，SVC 在呼叫时约定

RFC 1483 把永久虚电路的选择交给人工配置。用户数据出现之前，两端已经要知道采用 LLC 还是 VC 复用；若采用后者，还要知道这条电路代表哪一种协议。

随后发布的 RFC 1755把交换式虚电路的协商写得更具体。呼叫方可以在 B-LLI 中按偏好提供封装方式，被叫方选择自己支持的一种；没有共同方式或缺少必要信息时，呼叫可以被清除。RFC 1755 信息页把它定位为 Classical IP over ATM 的信令实现指南。

这套机制能在传数据之前排除一类歧义，但 CONNECT 仍不是交付凭证。呼叫建立、资源分配和封装选择成功，只能证明控制面完成了这些动作。后来有没有 PDU 到达、CRC 是否通过、IP 是否接收、应用是否完成，必须分别观察。

默认值解决互操作起点，不制造运行事实

RFC 2225把 LLC/SNAP 设为 Classical IP 与 ATMARP 的默认封装：没有其他知识或约定时，双方至少有一个共同起点。RFC 2225 信息页显示它是 Classical IP and ARP over ATM 的稳定基线。

同一文本也明确说明，AAL 类型并不写进 ATM 单元头。PVC 的端点通过管理配置知道类型；SVC 的端点通过呼叫建立获知。默认封装、VC 的 AAL 类型和 PDU 自己的协议标签，处在不同位置。

RFC 2225 还拒绝把 AAL5 说成可靠交付。它保证一条 VC 内的单元顺序并提供错误检测，但服务是非保证的；重传属于更高层。CRC 通过是一个数据单元的事实，不是端到端应用的承诺。

PPP 证明共享外层不会统一内层权威

RFC 2364把这两种方式继续用于 PPP over AAL5。它直接区分：VC 复用的载荷类型由两端通过配置或控制面程序隐式同意；LLC 封装则在每个 PDU 中显式标识类型。RFC 2364 信息页说明这是一种利用 PPP 链路控制、认证和压缩能力的点到点设计。

即使存在 PPP 认证，边界也没有消失。RFC 2364 警告，某个 PPP 会话的认证不能自动保护同一 VC 上其他 LLC 流。共享同一条电路、同一个 AAL5 外层，不会让内部会话获得同一身份与授权。

替代文本保留了选择，也写下了限度

1999 年的 RFC 2684替代 RFC 1483，并保留了两种封装。它澄清：多协议场景中 LLC 通常需要较少 VC，VC 复用通常降低每 PDU 开销；PVC 通过配置选择，SVC 通过信令协商。RFC 2684 信息页记录的是规范替代关系，并不证明早期实现同时消失。

RFC 2684 最重要的限制是：多协议封装对 ATM 上的路由与桥接是必要条件，但通常并不充分。Classical IP 还需要地址解析和逻辑子网模型，PPP 有自己的点到点契约，其他场景也需要各自控制服务。封装只回答“如何携带并识别”，不回答“谁有权发送、路径为何成立、接收是否完成”。

资料来源