摘要

  • RFC 1989 把链路质量监测明确拆成“共同机制”和“本地规则”：双方用同一套 Link-Quality-Report 形成双向丢失证据，却可以用不同阈值判断链路是否还能运行。
  • LQR 用累计的包、字节和报告计数，把发送方声称发出的数量、接收方当时保存的观察以及稍后由对端带回的观察串成可比的增量。
  • 报告不是裁决书：两个方向可独立协商，32 位计数会回卷，Magic-Number 只辅助发现回环，规范没有定义安全保障，也没有规定唯一的恢复动作。

先问“谁要承受损失”，再问“多少算坏”

同样是百分之二的丢包，对一条有廉价备份路径的骨干链路和一条偏远地区唯一可用的拨号线路，意义并不相同。前者可能立即切换，后者可能宁愿继续传输。交互业务、批量文件和能够重试的控制流，也不会共享一个天然正确的容忍线。

PPP 没有把这些运营差异压成一个全球阈值。1992 年 5 月的 RFC 1333 首次完整描述 PPP Link Quality Monitoring；1996 年 8 月，RFC 1989 取代了它。新文本最关键的设计声明不是某个字段，而是机制与处置规则的分离：协议完整规定如何形成 Link-Quality-Report，却不规定怎样判断质量，也不规定质量不足时必须做什么。

这种克制不是缺少治理。它把必须共享的部分缩小到可互操作的证据。两台来自不同厂商的设备可以对双向收发数量使用相同含义，同时允许各自的运营者依据业务价值、备份成本和风险承受力作出不同决定。

请求报告是一个有方向的承诺

PPP 默认关闭链路质量监测。想接收监测信息的一端，要在 LCP Configure-Request 中提出类型 4 的 Quality-Protocol 选项。十六进制协议值 c025 表示 Link Quality Report。对端返回 Configure-Ack，意味着它同意发送这一协议。

这里的主语非常重要。发出请求的一端是在说“请向我报告”，不是同时承诺“我也会向你报告”。两个方向分别协商，RFC 1661 甚至允许两边采用不同的质量协议。另一方面，一端既然同意发送 LQR，就必须正确处理自己收到的 LQR，即使它没有反向请求报告，也没有本地质量判定规则。

LQR 的选项还带有四字节 Reporting-Period，以百分之一秒表示两次报告之间允许的最大间隔。它不是最低间隔，对端可以更频繁地发送。值为零时，不维持定时器，而是在收到 LQR 后立即生成回应。协商规则会阻止两端都选择零，以免双方都等待另一边先开口。

协议也规定了这项承诺怎样结束。如果收到针对 LQR 的 Protocol-Reject，发送方必须停止报告。因此，抓包中的 Configure-Ack 能证明当时接受了报告义务；它不能证明此后的每份报告都穿过了一条正在恶化的链路。

一份 LQR 里有三次观察

LQR 的字段名从接收者视角命名，因为接收者正是提出报告请求的一方。PeerOutPackets、PeerOutOctets 和 PeerOutLQRs 是发送方当前的出站累计值。报文抵达后，接收进程在本地逻辑附加 SaveInPackets、SaveInOctets、丢弃、错误和 SaveInLQRs。这些 SaveIn 字段没有在入站线上传输，它们记录接收点当时真正看到的情况。

下一次由这个接收者反向发送报告时，保存的观察会以 PeerIn... 字段返回原发送方。LastOut... 则抄回最近一次收到的、对本端先前出站数量的观察。于是，一份报告同时包含对端现在声称发出的数量，以及对端先前保存并带回来的接收视图。

协议并不给每个数据包签发回执。它使用累计计数做对账。连续两份报告相减，才得到一个区间内的变化量。PeerInPackets 的增量与 LastOutPackets 的增量相比，可以估算本端出站方向的丢失；SaveInPackets 与 PeerOutPackets 的增量相比，可以估算入站方向的丢失。字节计数提供另一种尺度，对端的丢弃和错误增量还可能把排查方向从物理线路收窄到接收设备拥塞。

“可能”不能省略。这些字段让解释受到证据约束，却不能认证对端，也不能单独证明丢失的唯一原因。

连“一个字节”都要先定义清楚

PPP 可以由一个软件进程实现，也可以把成帧、转义或计数交给硬件和转换设备。若一端能看到异步转义后的线缆表示，另一端只能看到转义前的帧，两边直接抄硬件字节计数，就会把表示差异误认成传输损失。

RFC 1989 因而规定抽象的计数参考点。凡参与 FCS 计算的字节都计入，FCS 本身也计入，每帧再计一个 Flag；额外的 Flag 以及转义位或转义字节不计。目的不是测量物理介质消耗的每一个符号，而是让不同实现得到可复现的信息量。InGoodOctets 还要排除被列为丢弃或错误的帧所含字节。

在把计数写入 LQR 时，数字必须已经包含这份 LQR 自身预期贡献的包和字节。计数单调增加，但字段只有 32 位，走到最大值后会回到零；计算增量必须识别回卷。部分接口计数在 LCP 进入建立阶段时也不会被统一清零，所以同步依靠相邻报告的相对变化，而不是虚构一个共同起点。

这些细节看似琐碎，却决定了告警是否可信。若一端把转义算进去，差值就会随流量增长；若回卷被当作普通有符号减法，一个健康区间会突然出现荒谬的负数。互操作不只是交换数字，更是共享数字背后的定义。

报告沉默一次，还不足以判死

LQR 在 PPP 多路复用中应获得最高优先级，以减少普通流量排队对证据时效的影响。但更快报告不等于更快知道真相。链路良好时，LQR 本身是额外负担；间隔太短会干扰业务。间隔较长能平滑偶发损失，却会推迟对完全中断的发现。

方向不对称会让简单定时器误导操作。如果入站 LQR 还能到达，并显示本端出站方向很差，本端继续加快发送也未必有用，因为新报告很可能仍在出站途中丢失。反之，如果出站良好而入站恶化，多发几次可能让其中一份成功抵达，并帮助对端形成自己的判断。

RFC 1989 不允许把一个缺席样本直接变成算法裁决。预期报告没有到达，或收到的报告显示链路确实很差时，至少还应再发送一份 LQR。要作算法决定，至少需要两个往返间隔：第一次信号可能来自短时负载，也可能只是那份报告本身丢了。

规范建议采用迟滞，并给出最近 N 个周期中至少 K 次成功的规则作为例子，但没有把 K、N 或阈值写成协议。恢复过程同样未规定。关闭网络控制协议、继续发送 LQR，等质量恢复后再配置，是一种建议；切路、断线或保持现状都可以是本地选择。

c025 不是一枚可信印章

如果协商过 Magic-Number，LQR 中的该字段可以辅助检查回环：收到自己的号码，是链路把本端流量绕回来的线索。没有协商时，字段必须为零并被忽略。它和 PPP 其他 Magic-Number 用法一样，只是异常检测线索，不是设备、人员或组织身份凭证。

RFC 1989 直接写明没有讨论安全问题。它没有为报告定义加密完整性，也没有给计数声明附加独立凭证。对端认证属于 PPP 的认证阶段和对应协议。某个观察点看到 c025，只能证明该处出现了一份符合 LQR 表示的报文；它不能证明计数对外部世界绝对真实，更不能证明应用流量已经交付。

所以运行记录要把多个环节分开保存：Quality-Protocol 请求和 Ack/Reject、协商周期、实际到达时间、原始计数、回卷处理、增量计算、本地阈值、规则版本和后续动作。把整条链压成一个“链路坏”时间戳，会抹掉裁决究竟由谁、按什么规则产生。

共同机制越窄，本地运行空间越大

LQR 的历史价值，不在于它找到了完美的故障算法，而在于它准确找到了双方必须同意的最小范围。请求格式、最大报告间隔、计量位置、双向观察的回传和增量含义必须相同；服务可接受的质量和可承担的恢复成本不必相同。

于是，两端可以运行不同的迟滞窗口、K/N 规则或恢复策略，仍能读懂同一份报告。新的实现不需要中央决策者批准一个更严格的阈值，只需要履行自己协商接受的共同机制。

证据链也因此保持分层。IANA 的 c025 登记证明协议类型；Configure-Ack 证明当时接受了报告义务；计数增量支持损失估算；丢弃和错误帮助缩小解释。只有本地规则能产生可用性判断，只有后续路由、NCP、物理链路和应用结果能证明判断之后发生了什么。

报告让分歧有了共同事实基础，但它从未被授权替所有人消灭分歧。

资料来源