摘要

  • 请求方选择探测、TTL、回复模式、封装方式以及是否请求反向路径信息；Responder 只能提供它在自身位置能够核实的本地证据。
  • IP 模式把 127/8 地址与 UDP 放在 MPLS 标签栈内；非 IP 模式使用 ACH，不依赖 IP 路由。非 IP ACH 的回复模式 4 要求回复经反向 LSP 以 ACH 返回、不得使用 IP/UDP；没有该返回路径的节点应当丢弃请求。
  • R 标志请求 Reverse-path Target FEC Stack TLV，但响应中不得设置 R。缺少 R 或该 TLV，不得推断反向 FEC；关联的双向 LSP 也可能使用不同的反向 FEC。
  • 请求方必须验证响应接口、标签栈及适用的 FEC；验证失败必须丢弃响应，并应报告失败。GAL 是承载机制，不是目标 FEC，不能纳入待验证 FEC，也不得获得 Nil FEC TLV 或出现在 DSMAP/DDMAP 中。

这项机制适用于静态 LSP 和 PW FEC，也适用于非 IP 的 MPLS-TP 路径。DSMAP/DDMAP 与 TTL 到期使请求方能够把探测引向 LSP 上的特定点，因此某个中间点可以成为合法 Responder，而不是目标出口。Requester 拥有测试选择权；Responder 不拥有把局部回复升级为端到端结论的权力。RFC 6371 的 OAM 框架和 RFC 6370 的标识体系支持边界与关联，但不会替代 RFC 6426 的逐项验证。

验证夹具。 记录一个明确的 MPLS 标签栈、TTL 序列（例如 1、2、3）、目标静态 LSP/PW FEC、入/出接口、回复模式 4、Source Identifier 与 Destination Identifier。分别发送 IP/UDP 127/8 和非 IP ACH 样本；确认 TTL 到期点、DSMAP/DDMAP 内容、是否携带 GAL、R 标志是否仅出现在请求、响应是否带 Reverse-path Target FEC Stack TLV。若响应携带该反向 FEC 证据，请求方必须验证它。P2MP 使用 IP 地址时必须支持 RFC 6425 程序；不使用 IP 地址时适用 RFC 6426 的非 IP 程序。对每个响应比对预期接口、标签栈、目标 FEC、反向 FEC、身份和封装，并按分支关联。节点不支持或无法使用请求的回复模式时必须丢弃请求。避免在 ECMP 上使用 ACH on-demand CV：ACH 头可能改变哈希，使探测走不同于业务的路径。

操作决策路径。 先确认测试对象、FEC、身份和边界过滤规则；再选择 TTL、回复模式与封装。收到回复后先确认来源是目标点还是 TTL 选择的中间点，再验证接口和标签栈，随后验证目标 FEC及（若请求了 R）反向 FEC TLV。任何不匹配、意外 Source Identifier、缺失必需返回路径或 GAL 被误当成目标 FEC，都应丢弃并报告；无回复只能记录为证据不足，不能断言故障原因。

来源