摘要

  • RFC 9546 要求主动 OAM 包在 S-Label 后紧接 d-ACH，并在该头部内使用独立的 8 位循环序列号。
  • PREOF 处理 OAM 时必须采用 d-ACH 序列号；规范明文规定 App-flow 与 OAM 使用不同的序列号空间。
  • 连续的 OAM 序列只能说明某个 Node ID、Level、Session ID 与时间范围内的测试历史，不能补写业务包历史，更不能代替应用回执。

值班工程师先看见的是一条漂亮的绿线。测试包被复制，后到的副本被消除，输出顺序也没有缺口。几乎在同一时刻，生产控制系统发出告警：一条有严格截止时间的指令没有进入执行状态。

最省事的解释是应用误报。探测包与业务流带着同一个 S-Label，也经过相应的 DetNet 特殊功能；既然 OAM 顺序完整，业务自然应该完整。但 RFC 9546 恰恰不允许这种推理。标准让两类包建立关联，同时又把它们的序列历史分开。

S-Label 说明测试属于谁，不说明它替代了谁

在 DetNet 服务子层，S-Label 用来标识一个流。主动 OAM 包必须把 DetNet Associated Channel Header，也就是 d-ACH，放在 S-Label 之后。节点由此知道这是一份针对相应服务的测试信息，并可按该服务的规则处理。

然而，d-ACH 自带序列号。PREOF 对主动 OAM 包执行复制、消重或排序时，必须把这个字段当作序列信息来源。规范随后给出决定性的边界：App-flow 和 OAM 使用不同的序列号空间。

因此，OAM 的 41 号紧随 40 号，只能证明这段测试会话在观测点呈现连续。它不能告诉我们当时业务流运行到第几个包，也不能说明哪个业务副本被消除、哪个包超出排序窗口，更不能证明应用在截止时间前采用了有效载荷。标准没有定义“OAM 41 等于业务 41”这样的映射。

同一个 S-Label 是关系键，不是共同主键。它回答“这项测试针对哪个服务”，却不回答“这项测试代表哪个生产事件”。若数据平台只保留标签与数字，再把两个表自动连接，就把有关联的两本账篡改成了一本账。

d-ACH 的各字段共同限定证据范围

d-ACH 开头四位固定为 0001，用于区别 IP 包与 DetNet 数据包；随后是四位版本号，RFC 9546 定义版本 0。头部还包括 8 位循环 Sequence Number、16 位 Channel Type、20 位 Node ID、3 位 Level、5 位 Flags 和 4 位 Session ID。

这些字段不是排版细节，而是一份测试记录的管辖边界。Node ID 标识发出该包的 DetNet 节点，并且必须在 DetNet 域内唯一。规范没有规定怎样分发 Node ID。这意味着一个可解析的 20 位数值既不证明全球唯一，也不证明配置台账正确。运维系统还要保存域、当时占用该值的设备、分配版本以及碰撞处置方法。

Level 的语义类似维护域层级。内层设备团队和外层服务团队可能观察同一个服务，但可见范围不同，不能让某一层的绿灯自动替另一层发言。Session ID 用于区分同一节点、同一 Level 上同时运行的多个 OAM 会话。Channel Type 则说明承载的是哪种关联信道协议。

所以，一条可审计的 OAM 历史至少要包含 S-Label、Node ID、Level、Session ID、Channel Type、配置纪元、观测点和时间。脱离这些范围的 8 位序列号不是历史，只是一串容易被错误拼接的数字。

计数器会回绕，证据不能失去纪元

发送节点必须在发包前设置序列号。初始值应该随机或不可预测；通常每发一个主动 OAM 包就加一。规范也允许其他策略，例如故意制造异常顺序来负向测试 Packet Ordering Function。

计数范围只有 0 到 255。RFC 9546 认为足够，是因为主动 OAM 的速率显著低于业务流，回绕不会成为预期场景下的问题。这是一项限定在 OAM 用途中的工程判断，不是对任何测试频率、任何保存周期或任何部署的永久保证。

采集器看到 254、255、0、1 时，需要知道这是正常回绕还是新会话开始。重复值可能是副本、回绕、重启，也可能是两个 Session ID 被丢弃后错误合并。缺号可能来自网络丢失、采集失败、生成器切换，或者一次事先批准的乱序测试。

因此，只有“正常／异常”两种状态的面板不够。原始 d-ACH 字段、S-Label、接收时间、观测节点、测试配置和配置纪元都应保留。颜色可以是视图，不能成为唯一档案。

PREOF 的成功属于它实际处理的序列空间

Packet Replication, Elimination and Ordering Functions 可以复制包、去除后到副本并恢复输出顺序，从而提高按时交付概率。它们的价值真实存在，但每一次决定都有局部范围：看见了哪些包、维护了怎样的历史窗口、采用什么延迟规则、读取哪个序列字段。

对 OAM 而言，序列来源是 d-ACH；对 App-flow 而言，生产序列属于业务数据自己的控制上下文。OAM 副本被正确消除，并不能说明业务流选择了哪个副本。OAM 被顺利排序，也不能证明业务排序缓冲区看见相同到达、采用相同计时器，或者在应用截止时间内完成输出。

即使运营者已经证明探测包与业务流共享路径与处理方式，两套计数器也不会因此合并。路径、ECMP/LAG、封装、整形和资源待遇属于“探测是否等价”的问题；本文讨论的是更早的记账约束：即便待遇等价，OAM 历史仍不能替代业务历史。

可以关联，但不能冒名

可操作的证据链至少有四份记录。第一份证明主动 OAM 包带着预期 S-Label，而且 d-ACH 位置有效。第二份以 Node ID、Level、Session ID、Channel Type、纪元和测试策略界定会话。第三份保存各节点对 OAM 序列执行复制、消重和排序的决定。第四份独立追踪 App-flow 自己的序列、PREOF 决定、接收端状态与应用结果。

随后可以做相关分析。若两套历史在同一有界时间内出现缺口，足以触发调查；若它们都在一次配置变更后改变，因果假设会增强。但结论必须保持来源：两项有限观察同期发生，而不是“OAM 数字证明了某个业务包已经交付”。

分账之后，故障才变得可诊断。OAM 生成器可能重启；Node ID 可能碰撞；采集器可能漏收记录；业务副本可能共享测试流未覆盖的风险；生产排序窗口可能过期；应用也可能拒绝网络已经送达的数据。单条绿线没有权限裁决这些情形。

来源