摘要

  • RFC 3336 让 AAL2 CPS 承担 PPP 载荷的复用、分段与重组。一个小载荷完成后，可以直接交付，不必等包含许多邻居的大型 AAL5 单元先完整重组。
  • 这改变了故障域：PPPMUX/AAL5 中，一个 ATM 信元缺失可能令整捆作废；PPP/AAL2 中，损害局限于落在该信元里的分组。填充与时延收益仍取决于到达节奏、TIMER_CU、载荷大小、信元装载和实现。

真正昂贵的是先造出一捆必须共同裁决的数据

语音网关和接入设备常常要运输很多短分组。若每个分组都独占一个适配层单元，头部与填充会占用过高比例。把多个 PPP 载荷复用起来，能够分摊开销；但“装成一捆”同时创造了一个新的等待和裁决单位。

在 PPPMUX over AAL5 的排列里，多个 PPP 载荷先被放进同一个较大的 AAL5 协议数据单元。AAL5 再把它切入多个 ATM 信元。接收端必须反向完成整套动作：收齐信元、重组并验证整个 AAL5 单元，然后才能读取 PPPMUX 信息，把里面的短载荷分开。

因此，一捆数据不是物理世界预先存在的对象，而是协议堆栈主动制造的对象。它节约了包装，却要求所有成员一起等待，最后还要接受一次共同的完整性裁决。

一个缺口为何会连累不在缺口里的数据

若组成 AAL5 单元的某个 ATM 信元丢失，接收端无法完成有效重组。真正缺失的字节可能只属于一个或几个小载荷，但同捆其他信元里的完整载荷也无法越过这道整体裁决。物理故障很小，逻辑报废范围却被大容器放大。

RFC 3336 利用 AAL2 的 Common Part Sublayer 改写了顺序。CPS 本来就能把短 CPS 分组交错装入 ATM 信元；SSSAR 则为每个 PPP 分组完成分段与重组。复用不再藏在必须整体恢复的大型 AAL5 容器内部。一个 PPP 载荷完成后，接收端即可把它向上交付。

这并不意味着丢失信元没有代价。一个信元可能同时承载几个载荷的片段，这些载荷仍会受损。不同之处在于：其他信元里已经完成的载荷无需陪葬。故障影响范围更接近数据实际所在的位置，而不是它们曾经共享的巨型封装。

UUI 27 与 26 为重组过程留下边界

SSSAR 借助 User-to-User Indication 描述 PPP 分组的进度。UUI 代码点 27 表示中间片段，26 表示最后片段。收到末片段后，接收端重组 PPP 载荷，并用 16 位 CRC 检查所得内容。

这些状态不能压扁成一个“交付成功”字段。看到 26 不代表此前所有 27 都到齐；CRC 通过只说明重组出的 PPP 载荷在这一级一致，不代表上层应用采用了它；AAL2 的 connected 事件让 PPP LCP 获得链路上线指示，也不证明语音时延、抖动或可懂度合格。

可信的运行记录应分别保留 PPP 会话与 CID 映射、UUI 片段序列、CPS 序号与奇偶状态、ATM 信元丢失、SSSAR 重组结果、CRC 结果、TIMER_CU、LCP 状态以及端到端 PPP 结果。RFC 3336 缩小的是共享故障域，并没有替下游签发成功证明。

少填充多少，取决于下一个分组何时来到

AAL2 CPS 可以把多个短载荷塞进一个 ATM 信元。只要它们在适当时间内到达，信元有效载荷就能得到较充分利用，不必为每个小分组分别补齐 AAL5 边界。然而发送端不能为了等待下一份数据而无限扣住信元。

TIMER_CU 给等待设定上限。计时器到期时，即使信元尚未装满，也必须发送已有内容，剩余位置仍需填充。于是效率不是“AAL2”这个名称自动赋予的属性。它随分组大小、到达间隔、业务负载、计时器配置、调度方式和实现细节变化。

时延也有同样的条件。完成的 CPS 载荷不必等待一捆 AAL5 数据，但信元形成过程仍可能等待计时器。准确的说法是架构移除了一种强制性的整捆等待；它并未消除所有排队。标准说明了作用机制，却没有为任何真实网络保证固定百分比的节省。

PPP 所需要的仍是一条点到点关系

PPP 的基本假设是全双工点到点链路。RFC 3336 因此要求使用点到点 AAL2 虚连接，并把它呈现给 PPP，仿佛一条比特同步链路。AAL2 的 connected 与 disconnected 事件分别成为 LCP 的下层上线与下线指示。

ATM 能表达更复杂的拓扑，并不等于 PPP 的关系模型随之改变。CID 能在连接中标识载荷，却不能把多点关系变成合法的普通 PPP 链路。传输层的寻址能力与上层协议的双方契约必须分开判断。

一条 PPP 会话可以使用一个或多个 CID，但 RFC 3336 没有因此定义多业务类别的优先级体系。相关扩展属于 RFC 3337。把后者的类别语义倒写进前者，会夺走两份文档各自的历史边界。

邻近标准提供语境，却不能替部署作证

RFC 1661 定义 PPP 基本框架；RFC 2364 描述 PPP over AAL5；RFC 3153 规定 PPPMUX；RFC 2686 讨论 ATM AAL5 上的多协议封装；RFC 2507 则给出 IP 头压缩语境。这些文档解释了为何短载荷的头部、填充和等待值得优化。

RFC 3337 为 PPP/AAL2 增加类别扩展。后来的 RFC 3985 把伪线放入更一般的端到端架构，RFC 4446 记录相关 IANA 分配。文档之间有清楚的思想继承，但继承不等于运营商真的部署，也不等于硬件实现达到某个吞吐、带宽或语音质量结果。

标准文本能够证明设计目标和规定行为。部署断言还需要设备版本、配置、虚连接映射、计时器、真实流量与测量收据。若没有这些证据，历史写作只能说“它使某种结果成为可能”，不能把机制改写成市场事实。

分层位置决定谁必须一起等、一起失败

RFC 3336 表面上是在 AAL5 与 AAL2 之间选择承载方式，深处却是在选择“共同对象”形成的位置。PPPMUX/AAL5 先造大容器，再让其中所有成员经过一次整体重组。PPP/AAL2 则让复用与每个载荷的重组同处 CPS，已完成者可以逐个离开。

同一个位置变化同时触及三件事：短载荷共同填充信元时，填充可能减少；完成者不再等待大容器时，时延可能下降；一个信元丢失不再否决整捆时，丢失放大可能缩小。三项结果都不是无条件保证，但它们有同一个因果起点。

这份标准留下的长期问题很简单：接收端被要求一次裁决多大的对象？网络无法保证每个 ATM 信元都到达，却能决定一个信元丢失之后，需要有多少无辜数据随它消失。

来源