Summary

  • AIS is primarily a client-layer alarm-suppression mechanism. An AIS with a clear L-Flag reports a condition, but does not declare server-failure.
  • LKR is a separate administrative-lock indication, not a fault. R-Flag is a clearing request only for a matching message type and IF_ID.
  • The receiving MEP must validate type, version, identity and local state before deciding whether to suppress, clear, ignore or escalate.

The mechanism is deliberately layered. A server or intermediate node may emit Fault Management (FM) traffic into an affected client LSP. AIS can tell downstream client functions that a server-layer condition exists and prevent a cascade of secondary alarms. If protection is expected to restore service, AIS can carry a clear L-Flag. The L-Flag must not be set until server-failure has actually been declared. When set, the L-Flag may be treated as client-layer LOC; where fast continuity checking already detects the failure, it may instead be ignorable. Neither choice removes the receiving MEP's validation and local-treatment authority.

LKR has different semantics: it reports an administrative lock, allowing planned or controlled service restriction to be distinguished from a fault. Its L-Flag is zero and is ignored on receipt. A fault is an observed service-affecting condition; a declared server-failure is an authorized server-layer conclusion represented by L-Flag; an administrative lock is an operator-controlled state represented by LKR. Conflating these states creates misleading escalation.

On the wire, FM messages use G-ACh code point 0x0058 and must not include the ACh TLV header. A sender validates the configured Refresh Timer, which must be 1–20 seconds. It sends immediately, twice more at one-second intervals, then at the advertised interval while the condition persists. If refreshes stop, the receiver clears the condition after 3.5 times that timer. Optional fast clear uses R-Flag and three repeated clear messages, but a newly detected fault stops those clear retransmissions. A receiving MEP ignores unknown type or version; with R-Flag clear it creates or refreshes a matching condition, and with R-Flag set it clears only a matching type and IF_ID.

This separation assigns power without making it unlimited. The server or intermediate node controls emission into affected client paths. Operator configuration controls administrative lock and permitted treatment. A server-failure declaration authorizes L-Flag. The receiving MEP controls validation and local action. RFC 6371's layer boundary is therefore important: OAM evidence and consequent client action are not the same thing.

Elias Ward's analysis identifies the operational benefit as focus: operators may suppress cascaded noise, distinguish planned lock from fault and investigate the server-layer condition. The costs are periodic refresh processing, timer and IF_ID state, hierarchical propagation, optional clearing behavior and source validation. These are specified control and operational burdens, not evidence of adoption or measured alarm reduction. The packet does not establish vendors, deployment prevalence, commercial value or customer outcomes.

A practical operator path is: verify the affected client LSP and FM channel; check message type and version; confirm 0x0058 and absence of the ACh TLV header; record L-Flag, R-Flag, Refresh Timer and IF_ID; validate the source and layer identity against configuration; determine whether the condition is fault, declared server-failure or administrative lock; then apply local MEP policy. Treat LDI as client LOC only when the L-Flag is set and policy permits it, and consider it ignorable only where fast CC already detects the failure. A missing refresh should expire at 3.5 times the advertised timer. An unmatched R-Flag must not clear another condition.

Sources