摘要

  • RFC 1663 没有把可靠传输强加给所有 PPP 链路，而是让两个端点通过 LCP 的编号模式选项自愿启用。启用后，序号窗口、确认、重传计时器以及失败后的退回路径共同构成一套有限的链路契约。
  • 两端可以声明不同大小的接收窗口，却必须使用同一种序号模数。较小的 Magic-Number 只决定由谁先发起建立过程，不能证明端点身份；地址与控制字段压缩则因会抹去编号信息而被禁止。
  • SABM 或 SABME 与 UA 只建立编号链路。身份认证、链路质量判断、NCP 配置、路由可达和应用结果仍各自需要证据，任何一层的确认都不能越级成为整条路径的收据。

丢掉一个数据报，可能打乱后续字典

在 HDLC 类链路上，普通 PPP 把每个分组看作相对独立的数据报。常见的地址字段是 All-Stations 地址，控制字段取无编号信息，也就是 UI。一个帧的校验失败时，接收方可以丢弃它；链路协议通常不负责把它重新放回原有顺序。

这种简单性在分组之间没有共享状态时很划算。RFC 1663 特别指出压缩带来的例外：若发送方和接收方共同维护一个压缩字典，某个压缩数据报丢失，后来完好抵达的数据报也可能无法解码。有些压缩方法可以廉价重置状态，另一些方法则更需要按序且可靠的链路流。

PPP 工作组没有因此改写所有链路。1994 年 7 月发布的 RFC 1663 把可靠传输做成 LCP 配置选项 11，即 Numbered-Mode。想使用它的一端必须在链路建立阶段提出请求，另一端必须接受；默认仍然是无连接的 UI 方式。

这是一项范围很小的共同决定。不需要恢复循环的实现仍可保持简洁；因共享状态而无法承受丢包的相邻端点，则可协商增加它。标准只解决互操作所需的公共部分，并不宣称每种线路、每种压缩方法都应承担同一成本。

两个小字段改变了链路语言

编号模式没有发明另一种 PPP 分组。协议字段、信息字段、填充、帧校验序列和标志仍承担原来的作用。变化集中在地址字段与控制字段，采用与 ISO 7776 LAPB 相联的编号过程。一旦进入此模式，同一链路上的所有帧都必须使用它，不能把编号帧与普通 UI 帧随意混用。

这也解释了为什么一种常见优化必须退出。普通 PPP 可把反复出现的 ff 03 地址与控制字段压缩掉；在编号模式中，它们不再是恒定装饰，而携带链路地址、序号和控制意义。RFC 1663 因而禁止协商地址与控制字段压缩。RFC 1662 给出的更一般规则也是：使用非默认地址或控制值，必须先达成协议，不能再把它们当作默认值省略。

FCS 覆盖变化后的地址与控制字段。校验正确可以说明眼前的比特符合帧校验，却不能单独说明双方仍处于同一轮编号状态。帧是否有效，不只取决于比特，也取决于当前协商状态。

窗口同时选择了序号语法

Numbered-Mode 选项带有 1 到 127 的 Window 值。它既表示接收方最多愿意缓存多少帧，也限定发送方在未收到确认前最多可以悬而未决多少帧。窗口公开了容量，也限制了不确定性。

窗口还决定序号空间。小于 8 的窗口使用模 8；8 以上使用模 128。两端的缓存能力不同，所以可以报告不同的窗口；但它们不能使用不同的模数。一端按三位序号循环、另一端按七位序号解释，不是轻微的性能差异，而是两种不相容的链路语言。

Configure-Nak 可以建议缩小窗口，却不能要求把窗口放大。资源较少的一端由此可以把边界向内收，而不必替对方许诺自己没有的缓存。这个规则也防止一份否定应答把对方悄悄推入其从未提出的更宽序号格式。

选项中还携带 HDLC 地址。零不能成为最终地址，必须用合适的地址回绝。双方提议冲突时，协议先比较窗口和地址，只有在这些条件仍无法区分时才随机选择。这套程序解决的是形成链路所需的协调，不是组织或设备身份的证明。

Magic-Number 只决定谁先说话

编号模式要求双方成功协商 Magic-Number。LCP 接受配置以后，数值较小的一端负责首先发送 SABM（模 8）或 SABME（模 128），另一端返回 UA。双方不用另设一个中心裁判，就能从已有的协商值推导出发言次序。

若 SABM、SABME 或 UA 丢失，重试由 LCP 的 Restart Timer 和计数参数约束。UA 很容易被读得过宽；在这里，它只说明相邻端点接受了编号链路的建立过程。按照 PPP 的阶段结构，身份认证、链路质量判断和网络控制协议配置都在数据链路建立之后。UA 不能证明凭证被接受、线路质量达标、IP 已配置、路由存在，更不能证明远端应用收到了一次请求。

Magic-Number 也要按同样的边界理解。它可以帮助分辨两端和发现环回链路，却不是凭证、签名或授权。RFC 1663 明确没有讨论安全问题。即使一个值同时参与角色选择和环回检测，链路可靠与对端可信仍是两件不同的事。

失败也有共同出口

一套可靠机制若不能让双方识别状态已分歧，就谈不上互操作。RFC 1663 没有让一条“一半编号、一半无编号”的链路无限拖延，而是规定了明确的退回动作。

重新协商时，双方暂时继续使用编号模式；若选项未能再次成功协商，就必须在进入认证、质量判断和 NCP 配置之前退回 UI。一个支持编号模式但当前处于无编号状态的实现，若收到 FCS 正确的非 UI 帧，应返回 DM（Disconnected Mode）并立刻重启 LCP。处于编号状态的一端收到 DM，则退回 UI，并发送新的 LCP Configure-Request。

这些动作把分歧变成可观测事件。比特校验正确但不符合当前控制过程的帧，不会因此被提升为有效链路状态；某一端的记忆也不足以单独维持编号模式。

重传循环本身同样有边界。T1 是信息帧等待响应的最长时间，超时即重传。规范建议根据实测 LAPB 往返时延动态调整；无法测量时，可用帧长、线路速率和处理时间估算。T3 表示链路空闲，必须大于 T1。N2 限定一个帧的最大重传次数，超过后应终止链路；规范建议默认值为 3。

三次不是互联网的普遍真理，只是这套相邻链路程序的建议默认界限。N2 耗尽并不能单独解释对端为什么沉默，应用也不能把链路层的重传次数直接当成自己的交易重试预算。

并行链路不会自动变成一条链路

两个系统之间存在多条物理链路时，这条边界尤其重要。PPP 默认对每条链路独立建立、配置和终止。依赖序列的压缩状态也必须按链路维持，除非另有程序明确把多条链路组合起来。

RFC 1663 提到 ISO Multi-Link 的寻址办法，却不建议实现它，并指向后来形成 RFC 1990 的 PPP Multilink 工作。编号模式与多链路排序解决相邻但不同的问题：前者在一条成员链路内恢复有序交付，后者给一个链路束建立跨成员的片段序号空间。看到一个机制，不能推断另一个机制已经存在。

因此，一份编号确认只能归属于某条已协商链路、某个地址组合、某种模数和某一轮状态。它不能挪给并行链路，更不能越过路由器扩展成端到端收据。

确认有价值，恰恰因为它知道在哪里停止

IANA 登记让 Numbered-Mode 稳定地对应 LCP 选项 11。这个登记证明实现可以使用同一个名字和编号。LCP Configure-Ack 证明某一轮协商接受了具体参数；SABM 或 SABME 加 UA 证明编号过程在当时建立；序号、确认和重传记录可以支持某个链路帧如何推进的判断；DM、LCP 重启或 N2 耗尽则说明这份状态已经丢失或被放弃。

每一步都是证据，却没有任何一步能代表整个系统。身份协议负责提供身份材料，链路质量监测负责给出测量与本地判断，NCP 负责网络层配置，路由记录说明可达性，应用自己的标识和响应才能说明应用结果。

RFC 1663 的历史意义，不是保证数据已经安全抵达最终用途，而是给出了一个更小、可检验的契约：两个 PPP 端点自愿选择可靠传输时，共用一种序号语言，限制未确认工作，承认相邻进度，并在状态分歧时按同一办法重启。

确认没有被授权替高层说话，正因如此，它在链路层的含义反而更清楚。

来源