摘要

  • AIS 是沿受影响客户 LSP 向下游发送的故障管理指示，首要作用是压制客户层的级联告警；它本身不是服务器故障的裁决。
  • L-Flag 只有在服务器故障已经被声明后才能置位。置位的 LDI 可按客户层 LOC 处理，但若快速 CC 已经发现故障，在相应配置下也可忽略它。
  • LKR 表示管理性锁定，不表示故障；其 L-Flag 必须为零，接收端应忽略该标志。R-Flag 只清除匹配的消息类型和 IF_ID 条件。

RFC 6427 将 AIS 与 LKR 分成两个服务中断条件：故障和管理性锁定。服务器或中间节点可以把指示注入受影响的客户 LSP，但接收 MEP 仍负责校验、解释并按本地配置处理。这个分工意味着“谁发出消息”“谁声明服务器失败”“谁决定客户侧动作”不是同一个权力。

AIS 使用 G-ACh 的 FM 通道类型 0x0058，不得包含 ACh TLV 头。接收端必须验证消息类型和版本；未知的类型或版本应忽略。可复核的报文夹具是：通道类型 0x0058、有效 FM 类型与版本、AIS 或 LKR 的 L-Flag/R-Flag、Refresh Timer、IF_ID，以及可关联的全局身份。仅看到正确通道，不足以证明来源可信。

Refresh Timer 的允许范围是 1—20 秒。发送方在条件出现时立即发送，随后以一秒间隔再发送两次；条件仍存在时，按报文公布的定时器周期刷新。停止刷新后，接收状态在 3.5 × Refresh Timer 后清除。可选的快速清除会置 R-Flag 并重复三条清除报文；但若新故障出现，发送方必须停止这些清除重传。接收端只有在类型与 IF_ID 都匹配时才清除；不匹配的 R-Flag 不能抹掉另一项条件。

AIS 的 L-Flag 清零，可以表示故障存在但保护仍有望恢复服务，不能直接升级为服务器失败。只有已声明的服务器失败才授权置位 L-Flag。LKR 是计划性或管理性锁定的信号，应让客户区分锁定和故障。LDI 是否按客户 LOC 使用、或在快速 CC 已能检测故障时予以忽略，属于接收侧语义和配置问题，不是发送者单方面的结论。

操作员决策路径

  1. 先确认受影响客户 LSP、发送节点或中间节点、接收 MEP 与本地处置策略。
  2. 抓包核对 0x0058、消息类型/版本、L-Flag、R-Flag、Refresh Timer、IF_ID 和身份；检查是否含有不应出现的 ACh TLV 头。
  3. 将服务器或中间节点证据、保护状态和故障声明分开记录；不要用静默告警替代故障定位。
  4. AIS 清零 L-Flag 时按故障指示但非服务器失败处理；AIS 置位 L-Flag 时，结合本地规则判断 LOC 或快速 CC 已覆盖的情形。
  5. 看到 LKR 时按管理性锁定处理，不按故障升级；看到清除时只接受匹配类型和 IF_ID。
  6. 若刷新缺失，等待 3.5 倍定时器的状态转移，并调查丢包、源状态和配置，而不是立即宣告恢复。

这里的事实来自 RFC 6427 及其官方勘误；RFC 5586 仅支撑 G-ACh 承载，RFC 5654 支撑 MPLS-TP 需求，RFC 5860 支撑 OAM 需求，RFC 5921 支撑传送架构，RFC 6370 支撑标识，RFC 6371 支撑 OAM 框架与层边界。它们不构成部署规模、厂商采用或客户结果的证据。Elias Ward 的分析是：正确区分这些权威边界，可以把级联噪声和根因调查分开；这不是告警减少量或商业收益的主张。数据包如何抵达、运营者如何配置、服务器是否声明失败、MEP 如何本地处置，必须分别验证。来源包没有记录相关指控；厂商采用率、部署普及度、现实告警减少量、商业影响和客户影响均未知。

来源