GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration
Extracted elements (30)
OAM alarms are suppressed during the entire OAM establishment and parameter adjustment process to avoid spurious alarms caused by missing or unidentified OAM messages before both endpoints are fully configured. Alarms are only enabled after a dedicated Path/Resv exchange with the 'OAM Alarms Enabled' flag set.
OAM setup and configuration is bound to RSVP-TE connection establishment signaling to avoid two separate management/configuration steps. Separate steps increase delay and processing time and are prone to misconfiguration errors.
The OAM configuration framework is intentionally technology-agnostic at the generic level, with technology-specific OAM parameters carried in separate sub-TLVs. This allows the framework to support MPLS, MPLS-TP, Ethernet PBB-TE, SDH/SONET, and WSON without requiring changes to the base specification.
An egress LSR not supporting these extensions silently ignores the new LSP attribute flags and OAM Configuration TLV per RFC 5420. An ingress LSR can detect this by noting the absence of the OAM Configuration TLV in the Resv message, and SHOULD tear down the LSP or re-signal without OAM configuration.
An OAM Configuration TLV MUST NOT contain more than one technology-specific sub-TLV. Technology-specific sub-TLVs are OPTIONAL and are defined by separate documents outside of this specification.
Before initiating a Path message with OAM configuration, the initiating node MUST establish and configure OAM entities locally. OAM source functions MUST NOT start sending any OAM messages until the LSP is established.
For P2MP LSPs, when multiple Path messages are used, the root node MUST include the same OAM configuration information in all Path messages. Each branching node MUST copy the OAM configuration unchanged (Admin_Status bits, LSP attribute flags, OAM Configuration TLV) into downstream Path messages.
For P2MP OAM, leaves MUST create and configure OAM sink functions per the Path message parameters; there is no per-leaf parameter negotiation. If a leaf cannot accept the OAM parameters, it MUST use the RRO Attributes sub-object to notify the root.
If the OAM configuration hierarchy is broken—for example, the 'OAM MEP entities desired' flag is not set but an OAM Configuration TLV is present—an error MUST be generated: 'OAM Problem/Configuration Error'.
Path messages MUST be sent with the 'OAM Alarms Enabled' Admin_Status flag cleared during OAM establishment to achieve alarm suppression while OAM entities are being configured. OAM alarms MUST be suppressed at the sink until the LSP is fully established.
The control plane MAY provide information on whether OAM entities need to be set up. If OAM entities are created, control-plane signaling MUST provide a means to activate/deactivate OAM message flows and associated alarms.
The OAM Configuration TLV MUST always include a single instance of the OAM Function Flags Sub-TLV, and it MUST always be the first sub-TLV. If the selected OAM functions are not supported, an error MUST be generated: 'OAM Problem/Unsupported OAM Function'.
The 'OAM MIP entities desired' bit MUST NOT be set unless the 'OAM MEP entities desired' bit is also set. If MEP or MIP establishment is not supported at a node, an error MUST be generated ('OAM Problem/MEP establishment not supported' or 'MIP establishment not supported').
When adjusting OAM parameters, the receiving side SHOULD NOT update requested parameters to an extent that provides lower performance (e.g., lower frequency of monitoring packets) than what had previously been in place, to avoid an extensive negotiation phase.
When deleting OAM entities, OAM source functions MUST be deleted first. Only after OAM alarms are disabled may associated OAM sink functions be removed, ensuring OAM messages do not leak outside the LSP.
When the OAM Configuration TLV is carried in the LSP_REQUIRED_ATTRIBUTES object and the requested OAM type is not supported, an error MUST be generated: 'OAM Problem/Unsupported OAM Type'. Ingress and egress nodes supporting the TLV but not a specific OAM Type MUST also respond with this error.
When the 'OAM Flows Enabled' bit is set, OAM mechanisms MUST be enabled; if cleared, OAM mechanisms MUST be disabled. When 'OAM Alarms Enabled' is set, consequent actions MUST be executed including management system notification; when cleared, no action SHOULD be executed and the management system SHOULD NOT be notified.
When the Path message arrives at the receiver, the remote end MUST establish and configure OAM entities per the OAM information in the Path message. If this is not possible, a PathErr message SHOULD be sent and neither the OAM entities nor the LSP SHOULD be established.
A new RSVP Error Code 40 'OAM Problem' is defined with six error values: 1=MEP establishment not supported, 2=MIP establishment not supported, 3=Unsupported OAM Type, 4=Configuration Error, 5=OAM Type Mismatch, 6=Unsupported OAM Function. Values 32768-65535 are reserved for private use.
Two bits are allocated in the Admin_Status object: bit 23 'OAM Flows Enabled' (M, hex 0x00000100) controls enabling/disabling OAM mechanisms, and bit 24 'OAM Alarms Enabled' (O, hex 0x00000080) controls whether OAM-triggered alarms and consequent actions are executed.
Two LSP Attribute Flags are defined: bit 10 'OAM MEP entities desired' (used in LSP_ATTRIBUTES) requests MEP establishment at LSP endpoints; bit 11 'OAM MIP entities desired' (used in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES) requests MIP establishment at every transit node. Both are valid on Path, Resv, and RRO.
Two maintenance point types are defined: Maintenance Entity Group End Points (MEPs) at LSP endpoints that initiate/terminate OAM messages, and Maintenance Entity Group Intermediate Points (MIPs) at transit nodes that react to but do not initiate OAM messages. Together they form a Maintenance Entity (ME) monitoring an LSP.
IANA allocated OAM Configuration TLV as Type 3 in the RSVP-TE Parameters 'Attributes TLV Space' sub-registry, permitted on both LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects.
IANA allocated two new Admin_Status Object Bit Flags: bit 23 (0x00000100) 'OAM Flows Enabled (M)' and bit 24 (0x00000080) 'OAM Alarms Enabled (O)' in the GMPLS Signaling Parameters registry.
IANA created the 'RSVP-TE OAM Configuration Registry' with three sub-registries: 'OAM Types' (range 0-255, IETF Review, initially empty); 'OAM Sub-TLVs' (0-31 generic, 32-65534 technology-specific, 65535-65536 experimental, all IETF Review); and 'OAM Function Flags' (IETF Review, bits 0-5 initially defined).
Automatic establishment of OAM entities based on RSVP-TE messages creates an overload attack vector: a remote attacker could send frequent Path messages requesting liveliness monitoring of large numbers of LSPs. This is mitigated by deploying message integrity and node authentication per RFC 2747 (RSVP Cryptographic Authentication).
OAM establishment sequence: (1) initiator locally configures OAM entities but MUST NOT start OAM source; (2) Path message sent with 'OAM Alarms Enabled' flag cleared; (3) receiver establishes OAM entities and starts OAM source for bidirectional LSPs; (4) Resv returned with OAM Configuration TLV; (5) initiator enables OAM source; (6) subsequent Path/Resv enables alarms.
OAM parameter adjustment sequence: (1) re-signal LSP with 'OAM Alarms Enabled' cleared and updated OAM Configuration TLV; (2) initiator suppresses alarms while keeping OAM running; (3) receiver disables alarms, updates parameters, replies with Resv; (4) initiator updates after Resv; (5) subsequent Path/Resv exchange re-enables alarms.
The OAM Configuration TLV (Type=3) contains a 16-bit Type, 16-bit Length, 8-bit OAM Type field, 24 reserved bits, and variable-length sub-TLVs. The TLV MUST be zero-padded to 4-octet alignment. Length indicates total padded size in octets.
The OAM Function Flags Sub-TLV (Type=1) contains a 16-bit Type, 16-bit Length, and an extensible bitmap of OAM functions padded to 4-octet alignment. Defined bits (0-5) indicate: CC, CV, FMS, PM/Loss, PM/Delay, PM/Throughput.