RFC 6669
An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks
Okay bestie, let's start with the receipts 🧾✨ This is RFC 6669, An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks. It was written by N. Sprecher from Nokia Siemens Networks and L. Fang from Cisco Systems, and it came out in July 2012. It's Informational, which means it's not a standards track spec 🎀 Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there 🫶
Abstract ✨
Okay so this doc gives you the full tea on the OAM toolset (Operations, Administration, and Maintenance) for MPLS-based transport networks 🦋 The toolset is giving fault management and performance monitoring, all running in the data plane 💜 It's built for transport networks like [RFC5860] says, and it works across the network and services at different nested levels 🌸
It also does a quick recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions, plus the generic mechanisms in the MPLS data plane that let OAM packets ride in-band and share their fate with data packets 🧚 The actual protocol definitions for each MPLS-TP OAM tool live in separate documents (RFCs or Working Group documents), and this doc references them 🍓
Status of This Memo
Bestie, this part is the legal-ish bit, but it's important 💅 This document is not an Internet Standards Track specification. It's published for informational purposes only 🌈
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community ✨ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈
Info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6669 🔥
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully because they spell out your rights and restrictions 👑 Any Code Components pulled from this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶
Table of Contents 🎀
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Acronyms ...................................................5
2. Basic OAM Infrastructure Functionality ..........................6
3. MPLS-TP OAM Functions ...........................................8
3.1. Continuity Check and Connectivity Verification .............8
3.1.1. Documents for CC-CV Tools ...........................8
3.2. Remote Defect Indication ...................................8
3.2.1. Documents for RDI ...................................9
3.3. Route Tracing ..............................................9
3.3.1. Documents for Route Tracing .........................9
3.4. Alarm Reporting ............................................9
3.4.1. Documents for Alarm Reporting .......................9
3.5. Lock Instruct ..............................................9
3.5.1. Documents for Lock Instruct ........................10
3.6. Lock Reporting ............................................10
3.6.1. Documents for Lock Reporting .......................10
3.7. Diagnostic ................................................10
3.7.1. Documents for Diagnostic Testing ...................10
3.8. Packet Loss Measurement ...................................10
3.8.1. Documents for Packet Loss Measurement ..............11
3.9. Packet Delay Measurement ..................................11
3.9.1. Documents for Delay Measurement ....................11
4. MPLS-TP OAM Documents Guide ....................................12
5. OAM Toolset Applicability and Utilization ......................13
5.1. Connectivity Check and Connectivity Verification ..........14
5.2. Diagnostic Tests and Lock Instruct ........................14
5.3. Lock Reporting ............................................15
5.4. Alarm Reporting and Link Down Indication ..................15
5.5. Remote Defect Indication ..................................16
5.6. Packet Loss and Delay Measurement .........................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
Contributors ......................................................211. Introduction ✨
1.1. Scope
Okay, so the MPLS Transport Profile (MPLS-TP) architectural framework is defined in [RFC5921] 🦋 It describes a shared set of protocol functions that supports the operational models and capabilities typical of transport networks 💜
OAM is a big deal in carrier networks 👑 It gives you methods for fault management and performance monitoring in both the transport and service layers. The goal is to keep services with guaranteed and strict Service Level Agreements (SLAs) running well while also cutting operational costs 💅
[RFC5654] covers the general picture, and [RFC5860] covers the specifics. Together they define a set of requirements for OAM functionality for MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and Sections 🧚
The OAM solution came out of the joint IETF and ITU-T MPLS-TP project, and it has three objectives 🌸
- The OAM toolset should be developed based on existing MPLS architecture, technology, and toolsets.
- The OAM operational experience should be similar to that in other transport networks.
- The OAM toolset developed for MPLS-based transport networks needs to be fully interoperable with existing MPLS OAM tools as documented in Section 2.1.5. of [RFC5860].
The MPLS-TP OAM toolset is built on these existing tools 🍓
- LSP ping, as defined in [RFC4379].
- Bidirectional Forwarding Detection (BFD), as defined in [RFC5880] and refined in [RFC5884].
- ITU-T OAM for the Ethernet toolset, as defined in [Y.1731]. This has been used as functionality guidelines for the performance measurement tools that were not previously supported in MPLS.
Note that certain extensions and adjustments have been specified, relative to the existing MPLS tools, so the toolset fits the transport environment and the requirements of MPLS-TP 🙈 Even so, compatibility with the existing MPLS tools has been maintained, which is the real W here 🔥
This doc gives an overview of the MPLS-TP OAM toolset, which has tools for MPLS-TP fault management and performance monitoring 💖 It also recaps the MPLS-TP OAM requirements, their functions, and the generic mechanisms used to support MPLS-TP OAM operation ✨
The protocol definitions for individual MPLS-TP OAM tools are specified in separate RFCs (or Working Group documents), and this doc references them 🫶
On top of that, this doc has a table that cross-references the solution documents for the OAM functionality supported. It also covers the applicability and utilization of each tool in the MPLS-TP OAM toolset 👑
1.2. Acronyms
This doc uses the following acronyms, and yes, there are a lot of them 💀
ACH Associated Channel Header
AIS Alarm Indication Signal
BFD Bidirectional Forwarding Detection
CC-CV Continuity Check and Connectivity Verification
DM Delay Measurement
FM Fault Management
G-ACh Generic Associated Channel
GAL G-ACh Label
GMPLS Generalized Multiprotocol Label Switching
IANA Internet Assigned Numbers Authority
LDI Link Down Indication
LKR Lock Report
LM Loss Measurement
LOC Loss of Continuity
LSP Label Switched Path
MEP Maintenance Entity Group End Point
MEG Maintenance Entity Group
MIP Maintenance Entity Group Intermediate Point
MPLS Multiprotocol Label Switching
MPLS-TP Transport Profile for MPLS
OAM Operations, Administration, and Maintenance
PM Performance Monitoring
PW Pseudowire
RDI Remote Defect Indication
SLA Service Level Agreement
TLV Type, Length, Value
VCCV Virtual Circuit Connectivity Verification2. Basic OAM Infrastructure Functionality ✨
okay so before we dive in, [RFC5860] is the doc that lays out the requirements for OAM architecture and the general principles of how it all operates. we're going to check the basics against it 🧐💅
[RFC5860] says that --
- OAM mechanisms in MPLS-TP are independent of the transmission media and the client service being emulated by the PW ([RFC5860], Section 2.1.2). 🫶
- MPLS-TP OAM MUST be able to support both an IP-based and non-IP-based environment. if the network is IP based, i.e., IP routing and forwarding are available, then it MUST be possible to choose to make use of IP capabilities. on the other hand, in environments where IP functionality is not available, the OAM tools MUST still be able to operate independent of IP forwarding and routing ([RFC5860], Section 2.1.4). it is REQUIRED to have OAM interoperability between distinct domains materializing the environments ([RFC5860], Section 2.1.5). 🌈
- All OAM protocols support identification information, at least in the form of IP addressing structure, and are extensible to support additional identification schemes ([RFC5860], Section 2.1.4). 🎀
- OAM packets and the user traffic are congruent (i.e., OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane packets [RFC5860], Section 2.1.3. inherent in this requirement is the principle that full operation of the MPLS-TP OAM MUST be possible independently of the control or management plane used to operate the network [RFC5860], Section 2.1.3. 🔥
- MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections ([RFC5860], Section 2.1.1). the applicability of particular MPLS-TP OAM functions to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs, is described in [RFC5860], Section 2.2. in addition, MPLS-TP OAM supports these LSPs and PWs when they span either single or multiple domains ([RFC5860], Section 2.1.1). 🦋
- OAM packets MAY be directed to an intermediate point of an LSP/PW ([RFC5860], Sections 2.2.3, 2.2.4, and 2.2.5). 🧚
[RFC5860], Section 2.2 RECOMMENDS that any protocol solution meeting one or more functional requirement(s) be the same for PWs, LSPs, and Sections. bestie, that's giving consistency 👑
The following document set addresses the basic requirements listed above:
- [RFC6371] describes the architectural framework for conformance to the basic requirements listed above. it also defines the basic relationships between the MPLS structures, e.g., LSP, PW, and the structures necessary for OAM functionality, i.e., the Maintenance Entity Group (MEG), its end points, and intermediate points. 🍓
- [RFC5586] specifies the use of the MPLS-TP in-band control channels. it generalizes the applicability of the PW ACH to MPLS LSPs and Sections by defining a Generic Associated Channel (G-ACh). the G-ACh allows control packets to be multiplexed transparently over LSPs and Sections similar to that of PW VCCV [RFC5085]. the Generic Association Label (GAL) is defined by assigning a reserved MPLS label value and is used to identify the OAM control packets. the value of the ACH Channel Type field indicates the specific protocol carried on the associated control channel. each MPLS-TP OAM protocol has an IANA-assigned channel type allocated to it. 💖
[RFC5085] defines an Associated Channel Header (ACH) that provides a PW associated control channel between a PW's end points, over which OAM and other control messages can be exchanged. [RFC5586] generalizes the PW Associated Channel Header (ACH) to provide common in-band control channels also at the LSP and MPLS-TP link levels. the G-ACh allows control packets to be multiplexed transparently over the same LSP or MPLS-TP link as in PW VCCV. multiple control channels can exist between end points. ✨
[RFC5085] also defines a label-based exception mechanism that helps a Label Switching Router (LSR) to identify the control packets and direct them to the appropriate entity for processing. the use of G-ACh and GAL provides the necessary mechanisms to allow OAM packets to run in-band and share their fate with data packets. it is expected that all of the OAM protocols will be used in conjunction with this Generic Associated Channel. 🌸
- [RFC6370] provides an IP-based identifier set for MPLS-TP that can be used to identify the transport entities in the network and referenced by the different OAM protocols. 🧁
Note: [MPLS-TP-ITU-Idents] augments that set of identifiers to include identifier information in a format used by the ITU-T. Other identifier sets MAY be defined as well.
3. MPLS-TP OAM Functions 🎀
these are the OAM functions that are REQUIRED in [RFC5860] and expanded upon in [RFC6371]. let's gooo 💅
3.1. Continuity Check and Connectivity Verification
Continuity Check and Connectivity Verification (CC-CV) are OAM operations generally used in tandem and complement each other. they're generally run proactively, but they may also be used on-demand for diagnosing a specific condition. [RFC5860] states that the function SHOULD allow the MEPs to proactively monitor the liveliness and connectivity of a transport path (LSP, PW, or a Section) between them. in on-demand mode, this function SHOULD support monitoring between the MEPs and between a MEP and MIP. note that as specified in [RFC6371], Sections 3.3 and 3.4, a MEP and a MIP can reside in an unspecified location within a node, or in a particular interface on a specific side of the forwarding engine. 🦋
[RFC6371] highlights the need for the CC-CV messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. the function, both proactively and in on-demand mode, needs to be transmitted at regular transmission rates pre-configured by the operator. 🔥
3.1.1. Documents for CC-CV Tools
[RFC6428] defines BFD extensions to support proactive CC-CV applications. 🌈
[RFC6426] provides LSP ping extensions that are used to implement on-demand connectivity verification. 🧚
Both of these tools will be used within the basic functionality framework described in Section 2. 💜
3.2. Remote Defect Indication
Remote Defect Indication (RDI) is used by a path end point to report that a defect is detected on a bidirectional connection to its peer end point. [RFC5860] points out that this function MAY be applied to a unidirectional LSP only if a return path exists. [RFC6371] points out that this function is associated with the proactive CC-CV function. 🫶
3.2.1. Documents for RDI
[RFC6428] provides an extension for BFD that includes the RDI indication in the BFD format and a specification of how this indication is to be used. 🍓
3.3. Route Tracing
[RFC5860] defines the need for functionality that would allow a path end point to identify the intermediate points (if any) and end point(s) along the path (LSP, PW, or a Section). this function would be used in on-demand mode. normally, this path will be used for bidirectional PW, LSP, and Sections; however, unidirectional paths MAY be supported only if a return path exists. ✨
3.3.1. Documents for Route Tracing
[RFC6426] specifies that the LSP ping enhancements for MPLS-TP on-demand connectivity verification include information on the use of LSP ping for route tracing of an MPLS-TP path. 🌸
3.4. Alarm Reporting
Alarm Reporting is a function used by an intermediate point of a path (LSP or PW) to report to the end points of the path that a fault exists on the path. [RFC6371] states that this MAY occur as a result of a defect condition discovered at a server layer. the intermediate point generates an Alarm Indication Signal (AIS) that continues until the fault is cleared. the consequent action of this function is detailed in [RFC6371]. 🔥
3.4.1. Documents for Alarm Reporting
MPLS-TP defines a new protocol to address this functionality that is documented in [RFC6427]. this protocol uses all of the basic mechanisms detailed in Section 2. 💅
3.5. Lock Instruct
The Lock Instruct function is an administrative control tool that allows a path end point to instruct its peer end point to lock the path (LSP, PW, or Section). the tool is necessary to support single-side provisioning for administrative locking, according to [RFC6371]. this function is used on-demand. 🔒✨
3.5.1. Documents for Lock Instruct
[RFC6435] describes the details of a new ACH-based protocol format for this functionality. 🧚
3.6. Lock Reporting
Lock Reporting, defined in [RFC5860], is similar to the Alarm Reporting function described above. it is used by an intermediate point to notify the end points of a transport path (LSP or PW) that an administrative lock condition exists for the transport path. 🦋
3.6.1. Documents for Lock Reporting
MPLS-TP defines a new protocol to address this functionality that is documented in [RFC6427]. this protocol uses all the basic mechanisms detailed in Section 2. 🌈
3.7. Diagnostic
[RFC5860] indicates a need to provide an OAM function that would enable conducting different diagnostic tests on a PW, LSP, or Section. [RFC6371] provides two types of specific tests to be used through this functionality:
- Throughput estimation - allowing the provider to verify the bandwidth/throughput of a transport path. this is an out-of-service tool that uses special packets of varying sizes to test the actual bandwidth and/or throughput of the path. 💖
- Data-plane loopback - this out-of-service tool causes all traffic that reaches the target node, either a MEP or MIP, to be looped back to the originating MEP. for targeting MIPs, a co-routed bidirectional path is REQUIRED. 🔥
3.7.1. Documents for Diagnostic Testing
[RFC6435] describes the details of a new ACH-based protocol format for the data-plane loopback functionality. 🧁
The tool for throughput estimation is under study. 🧐
3.8. Packet Loss Measurement
Packet Loss Measurement is REQUIRED by [RFC5860] to provide a quantification of the packet loss ratio on a transport path. this is the ratio of the number of user packets lost to the total number of user packets during a defined time interval. to employ this function, [RFC6371] defines that the two end points of the transport path SHOULD exchange counters of messages transmitted and received within a time period bounded by loss-measurement messages. the framework warns that there may be small errors in the computation, which result from various issues. 💀
3.8.1. Documents for Packet Loss Measurement
[RFC6374] describes the protocol formats and procedures for using the tool and enabling efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks. [RFC6375] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffice to meet the specific requirements of MPLS-TP. note that the tool logic is based on the behavior of the parallel function described in [Y.1731]. 🎀
3.9. Packet Delay Measurement ✨
Okay bestie, packet delay measurement is the function that measures how long packets take to get between a pair of end points on a path (PW, LSP, or Section) 🕰️💖 See [RFC5860] for the details. There are two flavours:
- One-way delay 🚀 is the time from when a source node starts transmitting the first bit of the packet until the destination node receives the last bit of that packet.
- Two-way delay 🔁 is the time from when a source node starts transmitting the first bit of the packet until the source node gets back the loop-backed packet. The loopback happens at the packet's destination node.
[RFC6371] explains how the tool could be used, both proactively and on demand, for one-way or two-way measurement 🎀 But it warns that the one-way option requires precise time synchronization between the end points. No cap, that's a big ask 😭
3.9.1. Documents for Delay Measurement
[RFC6374] describes the protocol formats and procedures for using the tool, and for measuring packet loss, delay, and throughput efficiently and accurately in MPLS networks 🌈 [RFC6375] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that's enough to meet the specific requirements of MPLS-TP 💅 Also, the tool logic is based on the behaviour of the parallel function described in [Y.1731], so that's the sibling you'd want to peek at 👯♀️
4. MPLS-TP OAM Documents Guide 🗺️
The full MPLS-TP OAM protocol suite is covered by a small set of existing IETF documents 🧚 This set might grow later to cover more OAM functionality. So that you can make sense of the set, there's a cross-reference of the existing documents (RFCs or Working Group documents) for the initial phase of the specification of MPLS-based transport networks right below 💜
[RFC5586] gives you the specification of the basic structure of protocol messages for in-band data-plane OAM in an MPLS environment 🍓
[RFC6370] gives you definitions of different formats that can be used within OAM protocol messages to identify the network elements of an MPLS-based transport network 🌸
Next up is Table 1, which summarises the proactive MPLS-TP OAM Fault Management toolset functions, the tool or protocol for each, and the RFCs where they're defined 📋✨
+--------------------------+-------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+--------------------------+-------------------------------+---------+
| Continuity Check and | Bidirectional Forwarding |[RFC6428]|
| Connectivity | Detection (BFD) | |
| Verification | | |
+--------------------------+-------------------------------+---------+
| Remote Defect Indication | Flag in Bidirectional |[RFC6428]|
| (RDI) | Forwarding Detection (BFD) | |
| | message | |
+--------------------------+-------------------------------+---------+
| Alarm Indication Signal | G-ACh-based AIS message |[RFC6427]|
| (AIS) | | |
+--------------------------+-------------------------------+---------+
| Link Down Indication | Flag in AIS message |[RFC6427]|
| (LDI) | | |
+--------------------------+-------------------------------+---------+
| Lock Reporting (LKR) | G-ACh-based LKR message |[RFC6427]|
| | | |
+--------------------------+-------------------------------+---------+
Table 1. Proactive Fault Management OAM ToolsetTable 2 is the on-demand version, with the same deal: the OAM functions, their tools or protocols, and the RFCs that define them 🔍💖
+------------------------+---------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+---------+
| Connectivity | LSP Ping |[RFC6426]|
| Verification | | |
+------------------------+---------------------------------+---------+
| Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]|
| | (2) Lock Instruct (LI) | |
+------------------------+---------------------------------+---------+
| Lock Report (LKR) | Flag in AIS message |[RFC6426]|
| | | |
+------------------------+---------------------------------+---------+
Table 2. On Demand Fault Management OAM ToolsetTable 3 covers Performance Monitoring Functions, the tool or protocol definitions for each, and the RFCs that define them 📊🌈
+----------------------+--------------------------+-----------------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+----------------------+--------------------------+-----------------+
| Packet Loss | G-ACh-based LM & DM | [RFC6374] |
| Measurement (LM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Packet Delay | G-ACh-based LM & DM | [RFC6374] |
| Measurement (DM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Throughput | derived from Loss | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Delay Variation | derived from Delay | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
Table 3. Performance Monitoring OAM Toolset5. OAM Toolset Applicability and Utilization 🛠️
The next subsections look at the MPLS-TP OAM toolset from the point of view of the specified protocols, and they point out which required functionality each protocol supports 💅
5.1. Connectivity Check and Connectivity Verification 🔗
Proactive Continuity Check and Connectivity Verification (CC-CV) functions are used to detect loss of continuity (LOC) and unintended connectivity between two MEPs 🫶 The CC-CV tools can catch loss of connectivity, mis-merging, mis-connectivity, or unexpected Maintenance Entity Group End Points (MEPs) 👀 See Sections 3.1, 3.2, 3.3 in this document for CC-CV protocol references.
CC-CV is used to support MPLS-TP fault management, performance management, and protection switching ✨ The source MEP sends proactive CC-CV control packets to the sink MEP. The sink MEP keeps an eye on when those packets arrive and detects the defect 🕵️♀️ For bidirectional transport paths, the CC-CV protocol is usually sent in both directions at the same time 🦋
The transmission interval of the CC-CV control packets can be configured. For example:
- 3.3 ms is the default interval for protection switching.
- 100 ms is the default interval for performance monitoring.
- 1 s is the default interval for fault management.
5.2. Diagnostic Tests and Lock Instruct 🧪
[RFC6435] describes a protocol that gives you a way to Lock and Unlock traffic (for example data and control traffic, or specific OAM traffic) at a specific LSR on the path of the MPLS-TP LSP, so the traffic can be looped back to the source 🔄💜
These diagnostic functions apply to associated bidirectional MPLS-TP LSPs. That includes MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering (RSVP-TE) tunnels (relevant for the MPLS-TP dynamic control-plane option with GMPLS), and single-segment and multi-segment Pseudowires 🌟 [RFC6435] provides the protocol definition for diagnostic tests functions.
Here's the lock mechanism: [RFC6435] defines a setup where a management application sends a lock instruction to both ends of a point-to-point LSP, asking them to take the LSP out of service 🔒 When an end point gets the management request, it locks the LSP and sends a Lock Instruct message to the other end of the LSP 💌 The Lock Instruct message is carried in a Generic ACH message and gets sent periodically. The time between successive messages is no longer than the value set in the Refresh Timer field of the Lock Instruct message ⏱️ An LSP end point keeps the LSP locked while it's either receiving those periodic Lock Instruct messages or has an in-force lock instruction from the management application 🔐
Here's the tea ☕ Since the management application gets a management plane response from both ends of the LSP confirming the LSP is locked, there's no requirement for the Lock Instruct message to have a response. That's why [RFC6435] doesn't define a Lock Instruct response message 🙈
The loopback operations include:
- Lock: take an LSP out of service for maintenance.
- Unlock: Restore a previously locked LSP to service.
- Set_Full_Loopback and Set_OAM_Loopback.
- Unset_Full_Loopback and Set_OAM_Loopback.
Operators can use the loopback mode to test the connectivity or performance (loss, delay, delay variation, and throughput) of a given LSP up to a specific node on the LSP's path 🧚♀️💖
5.3. Lock Reporting 🔐
The Lock Report (LKR) function is used to tell the MEPS of the client (sub-)layer MEPs about the administrative locking of a server (sub-)layer MEP, plus the resulting interruption of data traffic forwarding in the client layer 📣 See Section 3.6 in this document for Lock Reporting protocol references.
When an operator takes the LSP out of service for maintenance or another operational reason, the LKR function can help tell apart administrative locking from a defect condition 🎀
The Lock Report function may also do alarm suppression in the MPLS-TP network above the level where the Lock has occurred 🙅♀️ Getting an LKR message may be treated as the equivalent of loss of continuity at the client layer 💀
5.4. Alarm Reporting and Link Down Indication ✨
okay so the Alarm Indication Signal (AIS) message is basically the "hey, quiet down, we already know something broke" text 📢. It's used to suppress alarms after a defect is detected at the server (sub-)layer. And when the Link Down Indication (LDI) is set, the AIS message may be used to trigger recovery mechanisms 🔄✨
when a server MEP detects the failure, it asserts LOC or signal fail, which sets the flag up to generate an OAM packet with the AIS message 🚨 the AIS message then gets forwarded to the downstream sink MEP in the client layer, so the client layer can stop generating secondary alarms 🤫 main character energy for sure 💅
the LDI flag is defined in the AIS message 🎀 it gets set in response to detecting a fatal failure in the server layer. receiving an AIS message with this flag set may be interpreted by a MEP as an indication of signal fail at the client layer 😭
the protocols for AIS and LDI are defined in [RFC6427] 📚
fault OAM messages are generated by intermediate nodes where an LSP is switched, and they get propagated to the end points (MEPs) 🦋
and here's the practical tea 🍵 when both proactive Continuity Check functions and LDI are used, you might run the proactive Continuity Check functions at a slower rate (e.g., longer BFD hello intervals), and rely on LDI to trigger fast protection switchover upon failure detection in a given LSP ⚡ lowkey genius, ngl 🧠💖
5.5. Remote Defect Indication 🫶
the Remote Defect Indication (RDI) function lets an end point tell its peer end point that a fault or defect condition has been detected on the PW, LSP, or Section 📣
the RDI OAM function is supported through BFD control packets [RFC6428] 📦 RDI is only used for bidirectional connections, and it's associated with proactive CC-CV activation 🔁
when an end point (MEP) detects a signal failure condition, it sets the flag up by setting the diagnostic field of the BFD control packet to a particular value, to indicate the failure condition on the associated PW, LSP, or Section 🚩 on top of that, the BFD control packet gets transmitted with the failure flag up to the other end point (its peer MEP) 💌
the RDI function can be used to facilitate protection switching by synchronizing the two end points when a unidirectional failure occurs and is detected by one end 🔀 bestie, the sync is everything 🥹
5.6. Packet Loss and Delay Measurement 📏🌸
the packet loss and delay measurement toolset lets operators measure the quality of packet transmission over a PW, LSP, or Section 📊 Section 3.8 in this document defines the protocols for packet loss measurement, and Section 3.9 defines the protocols for packet delay measurement 🧚
the loss and delay protocols have the following characteristics and capabilities, and honestly the list is giving 🤩
- They support the measurement of packet loss, delay, and throughput over Label Switched Paths (LSPs), Pseudowires, and MPLS Sections 🛤️
- The same LM and DM protocols can be used for both continuous/proactive and selective/on-demand measurements 🔄
- The LM and DM protocols use a simple query/response model for bidirectional measurement, which allows a single node (the querier) to measure the loss or delay in both directions 🙌
- The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can either be carried out at the downstream node(s), or at the querier if an out-of-band return path is available 🪞
- The LM and DM protocols do not require that the transmit-and-receive interfaces be the same when performing bidirectional measurement 🙅♀️✨
- The LM supports test-message-based measurement (i.e., inferred mode) as well as measurement based on data-plane counters (i.e., direct mode) 📨🧮
- The LM protocol supports both 32-bit and 64-bit counters 🔢
- The LM protocol supports measurement in terms of both packet counts and octet counts, although for simplicity only packet counters are currently included in the MPLS-TP profile 📦 simple is iconic 🫧
- The LM protocol can be used to measure channel throughput as well as packet loss 🚰
- The DM protocol supports varying the measurement message size, so you can measure delays associated with different packet sizes 📐
- The DM protocol uses IEEE 1588 timestamps [IEEE1588] by default, but also supports other timestamp formats, such as NTP ⏱️💜
6. Security Considerations 🔐
okay this part is SERIOUS bestie, so read it carefully 🥺🚨
this document, as an overview of MPLS OAM tools, does not by itself raise any particular security considerations 📄
the general security considerations are provided in [RFC5920] and [MPLS-TP-SEC]. Security considerations for each function within the OAM toolset have been recorded in each document that specifies a particular functionality 🗂️
in general, OAM is always an area where the security risk is high 😰 for example, confidential information may be intercepted by attackers to gain access to networks. That's why authentication, authorization, and encryption must be enforced to prevent security breaches 🔒💀
it's also super important to strictly follow operational security procedures 🧷 for example, in the case of MPLS-TP static provisioning, the operator interacts directly with the Network Management System (NMS) and devices, and that is critical in order to prevent human errors and malicious attacks 🫣
since MPLS-TP OAM uses G-ACh, the security risks and mitigations described in [RFC5085] also apply here. In short, messages on the G-ACh could be intercepted, or false G-ACh packets could be inserted 😱
additionally, DoS attacks can be mounted by flooding G-ACh messages to peer devices 🌊 to mitigate this type of attack, throttling mechanisms or rate limits can be used. For more details, please see [RFC5085] 🚦
7. Acknowledgements 💜
the authors would like to thank the MPLS-TP experts from both the IETF and ITU-T for their helpful comments 🙏 in particular, they'd like to thank Loa Andersson and the Area Directors for their suggestions and enhancements to the text 🫶
thanks to Tom Petch for useful comments and discussions 💬
thanks to Rui Costa for his review and comments, which helped improve this document 🌟
8. References 📚
8.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
May 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, September 2011.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6375] Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and
Delay Measurement Profile for MPLS-Based Transport
Networks", RFC 6375, September 2011.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011.
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Boutros, S., and D. Ward, "MPLS Fault Management
Operations, Administration, and Maintenance (OAM)", RFC
6427, November 2011.
[RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
"Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, November 2011.
[RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
Profile Lock Instruct and Loopback Functions", RFC 6435,
November 2011.8.2. Informative References 🧠
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", March 2008.
[MPLS-TP-ITU-Idents]
Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions", Work in
Progress, March 2012.
[MPLS-TP-SEC]
Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
Security Framework", Work in Progress, March 2012.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[Y.1731] International Telecommunications Union - Standardization,
"OAM functions and mechanisms for Ethernet based
networks", ITU Y.1731, May 2006.Contributors 🎀
Elisa Bellagamba Ericsson
Yaacov Weingarten Nokia Siemens Networks
Dan Frost Cisco
Nabil Bitar Verizon
Raymond Zhang Alcatel Lucent
Lei Wang Telenor
Kam Lee Yap XO Communications
John Drake Juniper
Yaakov Stein RAD
Anamaria Fulignoli Ericsson
Italo Busi Alcatel Lucent
Huub van Helvoort Huawei
Thomas Nadeau Computer Associate
Henry Yu TW Telecom
Mach Chen Huawei
Manuel Paul Deutsche TelekomAuthors' Addresses 🌍
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
EMail: nurit.sprecher@nsn.com
Luyuan Fang
Cisco Systems
111 Wood Avenue South
Iselin, NJ 08830
USA
EMail: lufang@cisco.com📦 where this page comes from
- ietf: rfc6669 2012-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms