摘要

  • PPPMuxCP 由接收端按方向提出：对端只有在收到接收能力后才能发送复用帧。即使协商成功，发送端也没有义务实际发送复用帧。
  • 默认 PID 只规定首个子帧省略协议号时如何解释。只有线上 PFF 真正为零、字段确实缺席，才能证明发生了字节节省。
  • 多个小包共享外层封装可能降低每包开销，也可能增加聚合等待，并让一次外层损坏影响更多子帧。能力、使用、恢复、测量与应用结果必须分别留据。

真正昂贵的是被重复很多次的外壳

PPP 为不同网络层协议提供统一的点到点承载，但每个独立帧都需要自己的边界、协议字段和校验。即使地址/控制字段和协议字段已经采用压缩，短小载荷仍可能被固定封装占去显著比例。若 PPP 又运行在 L2TP 隧道里，逐帧重复的隧道开销会进一步放大问题。

RFC 3153 的办法不是压缩应用数据，而是改变装箱方式。多个完整的 PPP 包成为同一外层 PPP 帧中的子帧，每个子帧前只有一个短分隔字段，用来说明协议号是否出现以及子帧占多少字节。一次外层封装由多个包分摊。

不过，第二个包尚未到达时，就没有第二份外壳可以节省。发送端若等待更多候选包，第一个包也在等待。RFC 3153 因而明确承认：聚合规模增大时，封装开销下降与复用、解复用延迟上升之间存在权衡。

所以，“支持复用”不是“链路更快”的证据。要计算收益，至少要看外层帧、实际子帧数、每个分隔字段、被省略的协议号、等待时间、传输时间和外层丢失的后果。

先由将要解包的一方划定许可范围

PPPMuxCP 在 NCP 阶段运行。接收端通过它提出：自己愿意接收并理解 PPP 复用帧。发送端在没有这项接收承诺时，不得把复用格式发给对端。

承诺是单向的。A 愿意接收 B 的复用帧，并不表示 B 也愿意接收 A 的复用帧。若操作界面只留下一个全局“已启用”，方向差异就会被抹掉。

即便方向正确、Configure 交换也已完成，发送端仍保留选择。标准写得很清楚：成功协商 PPPMuxCP 并不迫使对端发送复用帧。发送端可以挑选适合聚合的 PPP 包，也可以让它们独立通过。

这使控制面回执与数据面回执天然分开。Configure-Ack 能证明接收格式已经获准；只有后续出现协议值 0x0059 的外层帧，才能证明某次实际使用。还要把两者放在同一方向与时间线上，才不会把旧配置当成新流量。

默认 PID 先建立共同假设，未必节省一个字节

PPPMuxCP 始终协商默认 PID。该值由接收端提出，含义是：如果首个子帧没有携带协议号，接收端就用这个值补回去。若首包的协议恰好相同，发送端可以把 PFF 置零，并省去一或两个字节。

“可以”不等于“必须”。即使省略完全合法，发送端也可保留协议字段。默认 PID 的协商因此只证明双方拥有相同的解释规则，不证明线上字段已经省略。

后续子帧也依赖顺序状态。PFF 为一时，子帧带有新的协议号，并更新发送端的 Last_PID 和接收端的 Last_rcvd_PID；PFF 为零时，接收端沿用最近一次显式值。在首个显式值之前，双方从默认 PID 起步。

统计节省必须按顺序解析全部子帧。只数 PPPMux 外层帧会漏掉字段是否出现，也会漏掉协议在帧中途切换。相同数量的复用帧，可以产生完全不同的实际开销。

长度上限阻止越界，却没有替运营者选择最优等待

子帧分隔字段还包含 LXT 与 LEN。LXT 决定长度字段采用短形式还是扩展形式，LEN 给出当前子帧边界。RFC 的示例发送算法使用本地 MAX_SF_LEN，过大的候选包不进入聚合；整帧也不能越过 LCP 已协商的 MRU。

算法会在三种情况下停止：下一个包超过 MAX_SF_LEN、加入后将超过 MRU，或者队列已经没有更多候选。实现还可添加计时器，避免为了等待下一个包而无限滞留。RFC 进一步提醒，考虑延迟与分组错误时，复用帧上限可能应显著小于 MRU。

因此，MRU 是安全边界，不是填充目标；MAX_SF_LEN 是本地准入条件，不是全网最优值；计时器是发送策略，不是接收端授予的能力。

更大的聚合可以更充分地摊薄外壳，却会让早到的包等待更久，也让更多子帧共同承受一次外层损坏或丢失。链路速率、错误率、流量突发性、包长分布和应用延迟预算都会改变答案。

解包不仅要找回边界，还要守住原有次序

接收端看到 0x0059 后，依次读取每个子帧长度，获取或补回协议号，再把恢复的 PPP 包交给普通处理逻辑。如果某个长度超过剩余数据，最后一个子帧必须丢弃；真正错误的长度既可能位于最后一个，也可能是更早的字段导致解析位置偏移。

复用帧不得嵌套在复用帧中，LCP 帧也不得放进复用帧。更重要的是，无论一个包独立发送还是装在复用帧里，发送端与接收端都不应改变其顺序。

验证次序不能只看“成功拆出几个包”。应保留外层到达序列、独立帧的位置、内部边界与恢复后的交付顺序，否则一个表面完整的计数可能掩盖对邻近独立包的超越。

解复用输出仍不是端到端交付。下游协议可能继续丢弃、延迟或重组，应用也可能从未看到它。恢复回执只能回答这一层完成了什么。

与 MP、CCP、ECP 的先后关系决定看到哪一组字节

在 Multilink PPP 中，PPPMux 为整个 bundle 协商，而不是每条成员链路分别协商。发送路径先执行 PPP 复用，再进入 MP 封装，所以 MP 头位于 PPPMux 头之外；Multilink 帧本身不得成为 PPPMux 子帧。

压缩与加密又增加一层约束。PPPMux 位于 bundle 级 CCP/ECP 之后，却位于 MP 以及逐链路 CCP/ECP 之前。如果某实现无法把 PPPMux 放在逐链路 CCP 或 ECP 之上，就必须在已经协商 PPPMux 时对相应逐链路形式发出 Protocol-Reject。

这种顺序不是文档附注。它决定每一层处理哪些字节，也决定两个实现能否得出同样的结果。设备功能清单同时出现“复用、Multilink、压缩、加密”，不证明它们按可互操作顺序执行。

抓包点也必须说明。MP 之前的 bundle 视图与成员链路上的视图不是同一个对象；ECP 控制协商成功也不证明某一复用帧实际受到保护。

“没有新增安全考虑”从未等同于提供安全能力

RFC 3153 表示，它没有引入超出 PPP 和 PPP 头压缩方案之外的额外安全考虑。这个边界说明文档没有声称新的威胁类别，并不赋予 PPPMux 身份认证、完整性、机密性或抗重放能力。

畸形长度、解析器差异或 PID 状态偏离仍可造成运行故障。一个被正确拆解的包，也可能来自未经充分认证的对端；一个格式有效的结果，也可能在应用层触发不安全决策。

安全判断仍需 PPP 认证状态、实际 ECP 状态、帧完整性、无效输入拒绝行为与下游处置等独立证据。能读懂格式，只证明兼容，不证明可信。

最小共同规则为选择划界，而不是替代选择

RFC 3153 共同规定的是确定性部分：接收端必须先提出能力，协议值与标志如何解释，长度如何界定，顺序如何恢复，以及它在其他 PPP 功能中的位置。发送端面对实时队列时，仍可自行决定是否采用可选优化。

协商后不用，并不会使发送端失效；未经接收端许可就发，才越过互操作边界。这正是把共同规范保持在最小必要范围内：格式严格，采用自愿，效果可测。

相应地，证据也形成阶梯。控制交换证明许可，0x0059 证明一次使用，PFF/LXT/LEN 证明编码，接收跟踪证明恢复，成对测量证明字节与时间，应用才证明业务结果。

RFC 3153 留下的历史价值，不只是把小包放进大包。它示范了如何让一项优化被允许，却不被假装已经发生：接收端说“我能读”，发送端仍要回答“我这次是否值得写”。

来源