Alarm information is communicated in both Path (downstream) and Resv (upstream) messages so that every node along an LSP has equal visibility into current alarm state. This enables operator display and diagnostic use at any point along the LSP.

ALARM_SPEC uses the same format as ERROR_SPEC but a different C-Num (198 vs the existing ERROR_SPEC class) to avoid triggering error-processing semantics. Alarm information relates to data plane state changes without changes in control state, and is carried in Path/Resv rather than PathErr/ResvErr/Notify messages.

The existing PathErr/ResvErr/Notify mechanism was insufficient for alarm communication because those messages indicate control state problems and can only report one problem at a time, making it impossible to communicate alarm clearance or correlate all problems associated with a single LSP.

At GMPLS UNI and E-NNI boundaries, core-nodes MAY filter or modify alarm information from the core network before forwarding to client-node or peering LSPs, to protect internal network information or facilitate the peer's understanding of failures. Core-nodes MAY also choose not to request alarm reporting on outgoing Path messages.

Non-supporting nodes will pass ALARM_SPEC objects through unmodified per RFC 2205 rules because the C-Num value 198 is in the 11bbbbbb range, which mandates forwarding without processing. This ensures backward compatibility in mixed networks.

A node that receives or generates an Admin_Status object with the A or I bits set SHOULD remove all locally generated alarm information from the matching LSP's outgoing Path and Resv messages.

ALARM_SPEC objects SHOULD NOT be added to LSPs in 'alarm communication inhibited' state (I bit set). They MAY be added to LSPs in 'administratively down' state (A bit set).

All ALARM_SPEC objects received in Path messages SHOULD be passed unmodified downstream. All ALARM_SPEC objects received in Resv messages SHOULD be passed unmodified upstream. Nodes SHOULD store alarm information from received ALARM_SPEC objects.

All changes in ALARM_SPEC objects SHOULD be processed as trigger messages, including changes in object contents or in the number of ALARM_SPEC objects present.

Defined TLVs MUST follow any interface-identifying TLVs within an IF_ID ALARM_SPEC or ERROR_SPEC object.

The processing of non-locally generated ALARM_SPEC objects MUST NOT be impacted by the contents of the Admin_Status object; received ALARM_SPEC objects MUST be forwarded unchanged regardless of I and A bit settings.

The REFERENCE_COUNT field MUST NOT be set to zero on generation, and TLVs received with this field set to zero MUST be ignored.

When generating a local ALARM_SPEC object, appropriate Error Node Address, Error Code, and Error Values MUST be set. The InPlace and NotGuilty flags SHOULD NOT be set, as they have meaning only in ERROR_SPEC objects.

A new RSVP Error Code value 31 ('Alarms') is defined for use in both ERROR_SPEC and ALARM_SPEC objects. Error Values for this code are identical to the IANAItuProbableCause Textual Convention values in the Alarm MIB (RFC 3877).

registry

The Admin_Status object is extended with a new Inhibit Alarm Communication (I) bit (value 0x00000010). When set, it indicates that alarm communication is disabled for the LSP and nodes SHOULD NOT add local alarm information.

registry

The ALARM_SPEC object carries alarm information in Path and Resv messages. It uses the same format as the ERROR_SPEC object but with class number 198 (C-Num 11bbbbbb). C-Types 1 and 2 are reserved; C-Types 3 and 4 are IPv4 and IPv6 IF_ID ALARM_SPEC objects respectively.

registry, security

IANA assigned Error Code 31 ('Alarms') in the RSVP Parameters Error Codes and Values registry. Error Value sub-codes have values and meanings identical to IANAItuProbableCause in IANA-ITU-ALARM-TC-MIB.

registry

IANA assigned five new Interface_ID Types in the GMPLS Signaling Parameters registry: 512 (REFERENCE_COUNT, 8 bytes), 513 (SEVERITY, 8 bytes), 514 (GLOBAL_TIMESTAMP, 8 bytes), 515 (LOCAL_TIMESTAMP, 8 bytes), 516 (ERROR_STRING, variable).

registry

IANA created a new 'Administrative Status Information Flags' section in the GMPLS Signaling Parameters registry. Assigned values include: 0x80000000 (Reflect R), 0x00000010 (Inhibit Alarm Communication I, new), 0x00000004 (Testing T), 0x00000002 (Administratively down A), 0x00000001 (Deletion in progress D).

registry

IANA created the ALARM_SPEC object (Class 198) in the RSVP Parameters registry. C-Types 1 and 2 are reserved, C-Type 3 is IPv4 IF_ID ALARM_SPEC, and C-Type 4 is IPv6 IF_ID ALARM_SPEC.

registry

Some operators may consider alarm information sensitive. Implementations SHOULD allow users to disable ALARM_SPEC object generation or filter/correlate them at domain boundaries to protect confidential network topology or operational state. If protocol security from RFC 3473 is breached, alarm information may be spoofed, but such spoofing is limited to causing annoyance and minor control plane performance degradation since alarm details do not trigger protocol actions.

security, privacy

The ERROR_STRING TLV (Type 516, variable length) carries a US-ASCII display string representing the alarm/error type, padded to the next 4-byte boundary with null characters. Multiple ERROR_STRING TLVs may be included in a single object.

The GLOBAL_TIMESTAMP TLV (Type 514, Length 8) contains a 32-bit unsigned fixed-point integer representing seconds since 00:00:00 UT on 1 January 1970. It MAY include leap seconds and SHOULD match the timestamp used in Management Plane alarm reports.

The LOCAL_TIMESTAMP TLV (Type 515, Length 8) contains a 32-bit value representing the local system clock time at alarm detection, meaningful only in the context of the originating node (e.g., seconds since reboot).

The REFERENCE_COUNT TLV (Type 512, Length 8) contains a 32-bit unsigned integer indicating the number of times an alarm has been repeated. This field MUST NOT be set to zero; TLVs with a zero value MUST be ignored.

The SEVERITY TLV (Type 513, Length 8) contains a 20-bit Reserved field, a 4-bit Impact field (0=Unspecified, 1=Non-Service Affecting, 2=Service Affecting), and an 8-bit Severity field (0=Cleared, 1=Indeterminate, 2=Critical, 3=Major, 4=Minor, 5=Warning).