摘要

  • draft-ietf-mpls-stamp-pw-21 明确指出，控制平面上送路径的限速对 STAMP 而言与网络中的真实丢包无法区分，因此会被报告成丢包。
  • 任何把丢包告警转化为定责或调路指令的系统，都应先保留会话、封装、双端限速器、正反向路径、MTU、ECMP、返回上下文和独立业务观测。

红色数字没有告诉你包死在哪里

监控平台显示丢包率 4.7%。这个数字可以精确，却仍然没有回答最重要的问题：包在哪里消失？

在最直观的故事里，探针进入 MPLS 网络，在中间某处被丢弃。可 revision 21 写出了另一条完整因果链。探针可能顺利到达 Provider Edge，随后被控制通道机制从普通转发面取出，上送给控制平面处理。因为每枚测试报文都会消耗 CPU 和内存，Session-Sender 与 Session-Reflector 都必须用限速保护自己免受过载和拒绝服务攻击。

限速器丢掉探针，发送端收不到回包；中间路径丢掉探针，发送端同样收不到回包。两个事件在一个只看 STAMP 完成率的面板上具有相同外形。

草案第 7.2 节因此写得很克制：punt path 上的限速与网络实际丢包不可区分，并可被报告为丢包。它承认的不是测量失败，而是测量权力的边界。STAMP 能证明一次预期的测试循环没有完成；单凭这项事实，它不能判决业务路径有罪。

已获批准，但仍不是 RFC

当前文本是 2026 年 9 月 10 日的 revision 21。IESG 于 9 月 14 日批准，翌日送入 RFC Editor 队列；历史记录仍显示编辑与 IANA 工作。它计划成为 Proposed Standard，并在正式发布后更新 RFC 8762 与 RFC 8972。今天仍须称为 Internet-Draft。

范围也不能扩写。它覆盖单一管理域内点到点 LSP，以及点到点、单段 pseudowire；点到多点和多段 pseudowire 不在范围内。草案没有证明任何具名厂商、运营商或真实事故采用了本文描述的机制。

审议历史反而给出了很好的治理证据。IESG 评审者指出，某些控制通道方法会在两端把每枚测试包送上控制平面，要求规范明确说明限速会被 STAMP 看成网络丢包。revision 21 接受了意见。审议没有制造歧义，而是拒绝让歧义藏在实现细节里。

测试包与业务包在终点处分道

RFC 8762 定义 STAMP 基础交换，RFC 8972 定义 SSID 和可选扩展。MPLS 草案提供两种封装。Format 1 保留 IP/UDP；Format 2 不带 IP/UDP，并用两个新的 G-ACh 类型分别标识发送端和反射端报文。两向报文都必须携带非零 SSID。

Format 1 可以结合地址、端口和 SSID 识别会话。Format 2 没有四元组，只能把 SSID、收到报文时的 LSP/PW 上下文与本地配置合起来判断。依赖 IP/UDP 字段的 TLV 也不能在 Format 2 中使用。

这套设计努力让探针与业务流使用同一标签栈，却又必须让探针在 PE 端被例外处理。业务包继续转发；测试包离开转发面，进入受保护的处理资源。也就是说，对数据面的测量最终落在另一套队列、CPU 和限速规则上。

保护机制不能取消。问题在于它的动作必须进入告警证据。草案建议让运营者知道限速何时发生：Format 1 可结合 UDP 端口，Format 2 可结合 LSP/PW 上下文与通道类型，再与故障通知关联。入向 policing 不应比给测试流量分配的带宽更严格，否则保护器会亲自生成无效测量。

RFC 5085 的 VCCV 指南也被继承，其中针对部分控制报文提出低于相关 PW 比特率 5% 的限速建议。这个比例是资源保护规则，不是“测量必然有效”的认证。多个会话仍可能共享一个聚合 policer；突发、攻击或别的控制流也可能挤占同一资源。

返回方向是独立的证据面

Reflector 收到 G-ACh 测试报文后，应沿双向 LSP 或 PW 的反方向回送。它根据收到的 PW 标签或末级 LSP 标签找到反向上下文。找不到时，规范要求丢弃收到的测试报文，而且不得回复。

Sender 看到的依旧只是沉默。这个沉默可能来自正向路径、上送过程、Reflector、反向上下文查找、反向路径，或最终接收端的控制平面限速。

容量也必须按方向分别配置。Reflector 对每枚接受的探针产生回复，反方向可能承受与正方向相近的测试速率，而其容量未必相同。一个 round-trip 丢包率会把两个方向和两个端点合并成一项指标。若底层证据未保留，正向路径的负责人可能为反向控制平面问题背锅。

相同标签栈仍不等于相同经历

草案要求探针考虑业务使用的标签栈、Control Word 与 Entropy Label，以尽量复制转发选择。这个目标受多个条件约束。

Format 1 的 IP 地址可能不同于被测业务流。使用 IP 做 ECMP 的设备可能因此选择另一条链路。合规设备不应把特殊用途标签纳入 ECMP；不合规设备却可能因 GAL 改变路径。此时更适合选用不增加标签的控制通道方式。

MTU 是另一条界线。G-ACh、GAL、IP/UDP 和可选填充都会增加字节数，且正反方向必须分别检查。过大的 G-ACh 探针不会被分片，而是被丢弃并表现为丢包。它证明探针封装过大，不必然证明更小的业务包受损。

相反，断裂的 LSP 可能让 Format 1 探针经另一条 MPLS 或 IP 路径抵达 Reflector，从而生成“成功”测量。不可路由地址和边界过滤能降低部分风险，却不能让每个回包都成为路径凭证。测量既可能假阳性，也可能假阴性。

认证保护报文，不替报文解释世界

STAMP 的完整性保护在无 IP/UDP 的 Format 2 里仍可工作，因为计算覆盖 STAMP 报文本身。它可以帮助判断收到的报文是否属于可信会话。

但它不证明探针与客户流走过同一 ECMP 成员，不解释缺失发生在哪里，也不会把限速计数器自动写进丢包率。安全章节还提醒：伪造回包会污染时延和丢包结果；伪造请求会消耗回程与 punt path 资源；压制探针则能让健康的 LSP/PW 看起来失效。

完整性、路径一致性、容量保护和因果归属是四个控制面，不能用其中一个代替其余三个。

一次丢包告警需要十二张收据

可审计的告警至少应连接：

  1. 具体草案或 RFC 版本及本次测量语义；
  2. SSID、Sender、Reflector 与本地会话参数；
  3. LSP/PW 上下文和被测方向；
  4. Format、IP 版本与端口、通道类型、CW、GAL/TTL、标签栈及报文大小；
  5. 两向测试速率与各自分配带宽；
  6. 两端 punt-path policer 的配置、计数和时间；
  7. 发送、反射与接收数量，以及存在时的 T1–T4；
  8. 反向上下文查找成功或丢弃记录；
  9. 双向 MTU 与封装开销检查；
  10. ECMP、Entropy Label 与异常设备证据；
  11. 同时间窗口的业务数据面计数或独立观测；
  12. 告警规则、置信度、未排除原因、处置、复测与恢复证据。

这组收据允许监控系统先说一句正确但有限的话：“观察到探针路径丢失。”路径故障、客户影响和操作责任，必须由后续证据分别建立。

不要让告警系统替网络完成归因

把限速计数器接入监控并不等于一看到计数增长，就可以把所有丢包都归给控制平面。时间关联仍需说明粒度：哪个 policer、哪个接口、哪个通道类型、哪个时间窗，以及该 policer 是否还承载了别的 OAM 或异常流量。聚合计数器只能证明一个共享资源发生了丢弃，不能天然证明这枚 SSID 的每个缺口都在此产生。

同样，业务计数没有变化也不能单独宣告业务完全健康。客户流可能没有被同一观测点覆盖，采样周期可能错开，或损失只影响某个 ECMP 成员。正确做法是让每条证据保留自己的覆盖范围，再看它们是否收敛。探针缺失、policer 动作、数据面丢弃、接口拥塞和客户体验是五种记录，而不是一个布尔字段。

操作流程应允许“原因未定”成为正式状态。这个状态不是拖延，而是阻止系统在证据最薄弱时行使最大权力。它可以自动触发低频复测、换用另一种封装、检查双向 MTU、读取两端限速器、对比被动遥测，或者在受控窗口内用另一条独立探针验证。只有当这些动作改变了证据结构，置信度才应上升。

恢复也必须分层。探针重新返回，可能只是 limiter 压力下降；业务恢复，可能是调路的结果；告警清除，可能只是阈值滑出窗口。清除一次事件时，应写明恢复的是测试会话、控制平面容量、目标 LSP/PW、客户服务，还是其中若干项。否则“绿灯恢复”会抹掉最需要学习的那一段因果链。

规范给的是边界，运行者给的是责任

标准可以定义字段、封装、处理条件和应当记录的风险，却无法替每个网络指定谁有权解释告警。一个管理域并不意味着只有一个团队、一个供应商或一套预算。发送端、反射端、传输路径、自动化平台和客户支持可能分别归属不同责任中心。

因此部署评审不应只问“是否支持 STAMP”。还应问：谁配置测试带宽，谁管理聚合 policer，谁保存两个方向的计数器，谁验证软件升级后的 ECMP 行为，谁批准从调查升级为调路，谁向客户说明仍未排除的原因，谁负责在错误动作后回滚。缺少这些答案时，协议已经运行，治理链仍然断裂。

Heng Lu 笔记中的核心约束在这里很具体：参与测量不等于取得处置权；管理记录不等于运行现实；稳定监控系统不等于稳定客户网络。真正的 running-code primacy 不是崇拜任何一个计数器，而是要求每项决定向实际执行路径和可复核结果负责。

采购与验收同样需要改变。若测试只验证“能够生成丢包率”，供应商很容易交付一个没有归因能力的漂亮面板。验收用例应主动制造至少四种情形：中间路径真实丢包、端点 policer 丢弃、反向上下文缺失、探针 MTU 超限；再检查系统能否把它们标记为不同证据状态，而不是全部压缩为同一种红灯。还应加入 LSP 断裂但探针经替代路径到达的反例，防止系统把错误成功当作稳定性。

这种测试不会要求测量平台凭空知道一切。它只要求平台诚实表达“已知、未知、可疑和已排除”。一个愿意显示不确定性的系统，比一个总能给出故障归属的系统更适合承载自动化，因为它保留了升级决策所需的边界。

留存周期也应覆盖争议与复盘，而不只覆盖实时告警窗口。短期保存原始会话与限速计数，中期保存标准化关联记录，长期保存决定、证据摘要和复测结果。这样既不必无限积累每枚探针，也不会在客户申诉或供应商争议出现时只剩一张无法解释的图。证据可以分层压缩，但因果链不能被压没。

最终目标不是消灭告警，而是让每次升级都能回答：观察来自哪里，解释由谁作出，行动依据什么授权，结果由什么运行事实确认。

只有这样，实际运行速度才不会以可审计性为代价。

来源