摘要

  • 普通 IOAM Direct Export 可以让 A、B、C、D、E 都上报，却不能仅凭这些节点记录判断 E 位于 C 之后还是 D 之后。
  • RFC 9630 提供八字节 Multicast Branch ID，也提供在分叉前导出累计 trace、按区段重新开始的方案，从而减少重复又保留拼接依据。
  • 可靠运营仍须分别记录报文选择、分支标识时期、导出覆盖、明信片传输、收集器保管、树重建、接收端到达与应用结果。

节点齐全，不代表边已经存在

一份报文从 A 到达 B。B 复制两份，一份经 C 到 E，另一份经 D。五台设备都生成本地明信片。收集器可以确认五个节点都出现过，却无法从这组明信片本身确定 E 的父节点。

问题不在记录数量，而在关系缺席。节点集合不是图。若可视化为了画出完整树而把 E 自动挂到 D 下面，随后计算出的链路时延、丢包位置和故障责任都会落错地方。错误的边比空白更危险，因为它看起来更确定。

控制平面拓扑可以帮助推断，但此时结论来自两套证据的连接。应明确记录哪条边由数据平面直接证明，哪条边由 Mtrace2 或路由状态补足，不能把推断伪装成原始观测。

完整 trace 用重复换来了顺序

把 IOAM trace 留在组播报文里，可以保留节点顺序。代价发生在复制点：每个子报文继承此前积累的全部 trace。叶节点拿到的多份记录含有相同公共前缀，只在末端分支上不同。树越宽、路径越长，重复越严重。

这些重复占用报文头空间、网络带宽和收集器处理能力。DEX 明信片只导出本节点数据，能消除公共前缀，却同时丢掉“谁接在谁之后”的连接信息。RFC 9630 的核心不是简单选择 trace 或 postcard，而是保留最小的分叉关联。

效率不能以删除证据结构为代价。真正需要保存的是每次复制产生的分支身份，以及该身份在下一处分叉前的有效范围。

Branch ID 标识两处分叉之间的区段

DEX 方案把三字节 Branching Node ID 与两字节 Interface Index 组合起来，再以三个必须为零的未使用字节补成八字节。每个分叉节点为本组播树实例的每条输出分支生成不同组合；这个组合沿分支保持不变，直到下一处分叉重新赋值。

下游每个节点必须把收到的 Branch ID 放进导出明信片。Flow ID 和 Sequence Number 把同一流、同一报文的记录聚在一起；Branch ID 再告诉收集器这些记录属于哪段分支。C 与 E 可以显示它们共同承接 B 的第一条分支，D 则承接第二条。

这不是跨时间永恒不变的链路名称。接口索引可能复用，树也会收敛。保管记录必须同时包含 IOAM namespace、树实例、流、序列、时间和配置时期。丢掉时期后，合法复用会被误读成连续关系。

N 与 I 不能拆开解释

RFC 9326 的一个扩展标志对应四字节可选数据，八字节 Branch ID 因而需要两个标志。N 表示分叉节点部分，I 表示接口部分。两者必须同时置位或同时清除。只出现一半时，头部就是 malformed，报文必须丢弃。

三个未使用字节也必须全为零。严格规则避免宽松解析器从残缺字段或垃圾位构造一条似是而非的边。它也带来可观测的副作用：错误遥测编码可能使数据报文本身被丢弃。

运营指标必须区分三件事：报文没有选择此可选项、报文因 malformed 被丢弃、报文正常转发但导出明信片后来丢失。把它们都归为“无数据”，就无法找到故障发生在哪一层。

按区段导出把证据切口放在分叉处

第二种方案不修改 IOAM trace 格式。分叉节点先把截至本节点的累计 trace 作为明信片导出，再复制报文；各子报文保留分叉节点信息作为新区段的起点，清空 node-data list，并把 RemainingLen 恢复到初始值。叶节点负责导出最后区段。

公共路径只发送一次，分叉节点成为父段与子段的接缝。代价从头部格式转移到部署配置：每个应参与的分叉点和叶节点都必须在正确时刻执行导出与重置。

复制之前，只能把各副本真正共有的事实放进公共记录。入口接口和入口时间可能相同；出口接口、出口时间与每份副本的节点延迟则可能不同。若在复制前把它们压成一个值，恰好抹掉了需要调查的差异。

限制放大会同时限制覆盖

组播天然复制，DEX 导出又可能增加流量。RFC 9630 因而要求比单播更严格的保护，可以选择部分报文、限制导出速率，或只让分叉节点等子集处理选项。如何抽样、如何避免压垮网络或收集器，明确不在本文规范范围内。

这些保护合理，却改变结论的分母。重建的是“被选中报文、被启用节点所证明的树”，不是每份报文的完整现实。缺一张明信片可能来自抽样排除、限速、导出丢失、节点未启用、收集器拒绝，也可能确实没有该分支。

因此覆盖策略必须与树一起展示：选择规则、预期观察者集合、配额、各层丢弃计数和生效时间。否则“没有观察到”会在图形界面中悄悄变成“不存在”。

Mtrace2 与 IOAM 回答不同问题

Mtrace2 从接收端沿建树消息方向追向源端，并在途中添加诊断块。管理系统可以用它了解相关路由器。RFC 9630 同时说明 Mtrace2 并未直接与 IOAM 集成。

控制平面记录的是预期建立的路径，IOAM 明信片记录的是所选数据报文的实际观测。二者一致可以增强信心；不一致则是诊断入口。若收集器用前者填补后者缺失的边，必须标注来源，而不是覆盖差异。

在 PIM、PIM-SSM、MVPN、mLDP、P2MP RSVP-TE、Ingress Replication 或 PIM MDT 环境里，还要保存 VPN、隧道和树时期。同一组节点在不同上下文中可能表示完全不同的转发关系。

树重建完成，不等于接收结果完成

RFC 9630 的目标包括树可视化、每条路径的时延抖动以及丢包位置。Branch ID 让这些分析拥有可拼接的输入，却没有在接收应用内生成回执。

末跳路由器观察到报文之后，接入链路仍可丢包；终端收到包后，关键帧仍可能无法解码；某个采样序列路径正常，不代表未采样突发相同。漂亮的树只说明收集器能解释手中证据。

完整证据梯应分开：进入 IOAM 域、处理选项、创建分支标识、产生明信片、导出传输、收集器保管、图关联、独立转发验证、接收端到达、应用结果。RFC 9630 修复的是其中“关联”这一阶。

事故结束后仍要保留空白

每次重建应保存 Branch ID 原始字节和解析值、namespace、Flow ID、Sequence Number、源与组地址、树和隧道上下文、时间窗与配置时期。每张明信片还要保存导出者、节点数据、发送和到达时间、重复状态、拒绝原因与保管哈希。

图构建器应输出无父节点、标识冲突、重复卡片、缺失序列与外部推断边。不能因为布局算法需要一个父节点就补画连接。带有明确原因的残缺图，远比假设拼成的完整图更适合作为决策证据。

来源