摘要

  • BACP 先裁决同时发生的增减链路请求，BAP 再要求对端在行动前响应；真正拨号以后，Call-Status 另行报告成功、失败与是否重试。
  • Request-Ack 只证明命令有效且已收到，并不证明链路建立、分片承载或吞吐改善；为了让 ISDN 终端适配器拦截控制报文，完整 BAP 数据报还必须保持未压缩、未加密。

RFC 2125 最值得记住的，不是它让 PPP Multilink 自动增加带宽，而是它拒绝把一次“同意”写成已经增加的带宽。

RFC 1990 已经规定多条 PPP 链路如何组成一个束并重组分片。1997 年 3 月的 RFC 2125 另设 BACP 与 BAP 管理成员数量；RFC Editor 记录保存其 Standards Track 身份，IANA PPP 登记表则保留 BACP 0xc02b 与 BAP 0xc02d。

较小的数字只解决同时行动

BACP 必须协商 Favored-Peer。双方各给出一个非零的四字节 Magic-Number；如果同时发出同类的呼叫、回拨或删链请求，数值较小的一方优先。数值相等时必须换值重谈。

这是一条竞态规则，不是身份认证。它没有判断谁的流量算法更准确，也没有赋予线路所有权或经济决策权。它只回答：两端同时行动时，先处理谁。

接受命令之后，拨号才开始

准备主动拨起新链路的一端先发 Call-Request；希望对端拨号则发 Callback-Request。所有 Request 与 Indication 都必须在行动前等到 Response。Request-Ack 表示命令有效且已成功接收；Request-Nak 表示现在不做；Request-Rej 表示未实现；Request-Full-Nak 表示束已达到可用或配置的最大/最小带宽，需等总带宽改变后再试。

实际呼叫完成后，行动方必须发送 Call-Status-Indication。每次尝试各有一条；失败时还要说明不重试或重试，选择重试就必须再发送后续结果。Call-Status 沿用最初请求的 Identifier，让许可与执行可以对账，却不把它们压成同一事件。

证据因此形成阶梯：BACP Open；Favored-Peer 胜出；请求获 Ack；呼叫结果出现；通过 LCP 建立或终止成员；在新成员上观察到 Multilink 分片；应用动作最终完成。任何较低一级都不能代替全部上级。

基于利用率的删除需要共识，本地资源可以直接收回

RFC 2125 没有强制双方采用同一套带宽算法。实现可以看发送流量、双向流量，也可以不监控。若因为利用率想删除链路，必须发 Link-Drop-Query；对端按自己监控的流量回答，而且不能只凭接收方向的启发式判断。只要任一监控方仍需要链路，它就保留。

本地资源条件则不同。如果物理端口或 B 信道要用于别处，实现必须直接发送 LCP Terminate-Request。等待 Link-Drop 响应超过自身重试上限后，也可以用这种方式恢复。协议清楚地区分了合作优化与本地资源保管。

重传沿用同一 Identifier，使丢失响应不会把重复包伪装成新动作。BAP 控制包应优先于普通数据，因为要求新增容量的信号很可能正处于拥塞之中。

可拦截性压过了保密性

当不懂 Multilink 的客户端接在 ISDN 终端适配器后面时，适配器必须看见 BAP 才能控制束。因此完整 BAP 数据报不得压缩或加密；经过协商的 PPP 地址/控制字段及协议字段压缩仍可使用。更醒目的是，RFC 的 Security Considerations 只说本文不讨论安全问题。

所以 BACP Open、Ack 或成功的 Call-Status 都不能被扩写成保密、可信身份、用户同意、稳定总带宽或业务交付证明。

Lu Heng 关于运行代码优先、最小初始规范与现实层的文章在此是明确披露的现代观察框架：共同层只规定互操作所需的薄协议，本地启发式留在本地；符号性的许可不能冒充已经执行的现实。

来源