Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks
Extracted elements (24)
It is anticipated that implementers may wish to implement OAM message handling in hardware; while not a requirement, this is noted as a design consideration that influenced the functional requirements to keep OAM processing tractable at line rate.
OAM functions are required to operate in both IP-capable and non-IP-capable MPLS-TP environments because MPLS-TP deployments may or may not include IP in the data plane; this decoupling ensures OAM is universally applicable across all MPLS-TP scenarios.
OAM packets must run in-band and follow the same data path as user traffic (fate sharing) so that OAM accurately reflects the actual forwarding behavior experienced by user packets, enabling meaningful fault and performance monitoring.
When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate existing IP/MPLS and PW OAM protocols such as LSP-Ping (RFC 4379), MPLS-BFD, VCCV (RFC 5085), and VCCV-BFD, ensuring backward compatibility with deployed OAM toolsets.
A mechanism (e.g., rate limiting) MUST be provided to prevent OAM packets from causing congestion in the Packet Switched Network.
A mechanism for enabling the encapsulation and differentiation of OAM messages on a PW, LSP, or Section MUST be provided, and SHOULD also support encapsulation and differentiation of existing IP/MPLS and PW OAM messages.
If a defect or fault occurs on a PW, LSP, or Section, mechanisms MUST be provided to detect, diagnose, localize, and notify appropriate nodes. Mechanisms MUST also be available for a service provider to be aware of faults outside his domain.
It MUST be possible to deploy OAM functionality with or without relying on IP capabilities, and it MUST be possible to choose to make use of IP capabilities when present.
OAM functions MUST operate and be configurable even in the absence of a control plane. Customers MUST NOT perceive service degradation as a result of OAM enabling/disabling, and procedures to prevent traffic impairment MUST be defined.
OAM interoperability between distinct domains (IP-capable and non-IP-capable) is REQUIRED. When MPLS-TP is run with IP routing and forwarding, it MUST be possible to operate existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping, MPLS-BFD, VCCV, VCCV-BFD).
OAM packets MUST run in-band; OAM packets for a specific PW, LSP, or Section MUST follow the exact same data path as user traffic (fate sharing). It MUST be possible to discriminate user traffic from OAM packets.
OAM protocol solutions MUST at least be applicable to point-to-point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections.
OAM solutions MUST be applicable to end-to-end and to segments, and it MUST be possible to operate OAM functions on a per-domain basis and across multiple domains.
Since LSPs may be stacked, the protocol solution(s) MUST be applicable on any LSP regardless of label stack depth, and it MUST be possible to estimate OAM fault and performance metrics of a single or aggregate PW/LSP segment.
The MPLS-TP OAM toolset MUST provide a Client Failure Indication function to propagate client-layer defect/fault information from edge to edge of an MPLS-TP network when client-layer OAM lacks alarm propagation.
The MPLS-TP OAM toolset MUST provide Alarm Reporting functionality to enable an Intermediate Point of a PW or LSP to report a fault or defect condition indirectly affecting that PW or LSP to an End Point.
The MPLS-TP OAM toolset MUST provide diagnostic test functions (e.g., loopback, bandwidth estimation) on a PW, LSP, or Section; this function SHOULD be performed on-demand.
The MPLS-TP OAM toolset MUST provide packet delay measurement to quantify one-way and (if appropriate) two-way delay of a PW, LSP, or Section; accurate one-way delay quantification may require clock synchronization.
The MPLS-TP OAM toolset MUST provide route tracing functionality to enable an End Point to discover Intermediate and End Points along a PW, LSP, or Section; collected information MUST include identifiers for nodes and interfaces.
The OAM encapsulation/differentiation mechanism MUST support differentiating OAM messages that rely on IP capabilities from those that do not. Protocol solutions MUST support identification information as an IP addressing structure and MUST be extensible to support additional identification schemes.
The OAM mechanisms SHALL be extensible and SHALL NOT preclude additional OAM functionalities in the future. Experimental OAM functions MUST be supported and MUST be disabled by default.
The use of any OAM function MUST be optional, and it MUST be possible to select the set of OAM functions to use on any PW, LSP, or Section. Unless otherwise stated, OAM functionalities MUST NOT rely on user traffic.
An OAM packet received over a PW, LSP, or Section MUST NOT be forwarded beyond the End Point of that PW, LSP, or Section, to prevent the OAM packet from leaving the current administrative domain.
OAM messages can reveal sensitive information such as passwords, performance data, and network topology details. OAM protocol solutions MUST include authentication facilities to prove message origin and verify destination; use of such facilities MUST be configurable. OAM systems SHOULD be designed so functions cannot be accessed without authorization.