RFC 6371
Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
Part 1 of 14 🎀
RFC 6371: Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks ✨
Okay bestie, this is RFC 6371 💖 It's from the IETF (Internet Engineering Task Force) and it's Informational, so it's sharing knowledge, not laying down a must-follow standard 🦋 It's dated September 2011, ISSN 2070-1721.
Two editors get the credit: I. Busi (Ed.) from Alcatel-Lucent and D. Allan (Ed.) from Ericsson 👑 The header has no Obsoletes or Updates line, so nothing is replaced or amended here 💅
Abstract 🌸
MPLS-TP (the Transport Profile of Multiprotocol Label Switching) is a packet transport technology built on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures. It's giving solid foundation 🧚
This doc lays out a framework for a full set of Operations, Administration, and Maintenance (OAM) procedures. They cover the MPLS-TP OAM requirements for fault, performance, and protection-switching management, and they do not rely on the presence of a control plane. Main character energy, no backup plan needed 💜
This is a joint IETF / ITU-T (International Telecommunications Union Telecommunication Standardization Sector) effort to bring an MPLS Transport Profile into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures. The goal is to support the capabilities and functionalities of a packet transport network as the ITU-T defines them 🔥
Status of This Memo 🦋
Not an Internet Standards Track spec, just published for information. Noted 🫶
This doc is an IETF product. It represents the consensus of the IETF community, 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 see Section 2 of RFC 5741 for that tea ☕
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6371 🌈
Copyright Notice 💅
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Mine, yours, nobody's 😭
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 📜
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License. Copy the code, keep the license, no cap ⚠️
Table of Contents 📖
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Definitions ................................................7
3. Functional Components ..........................................10
3.1. Maintenance Entity and Maintenance Entity Group ...........10
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring .......13
3.3. MEG End Points (MEPs) .....................................14
3.4. MEG Intermediate Points (MIPs) ............................18
3.5. Server MEPs ...............................................20
3.6. Configuration Considerations ..............................21
3.7. P2MP Considerations .......................................21
3.8. Further Considerations of Enhanced Segment Monitoring .....22
4. Reference Model ................................................23
4.1. MPLS-TP Section Monitoring (SMEG) .........................26
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) ............27
4.3. MPLS-TP PW Monitoring (PMEG) ..............................27
4.4. MPLS-TP LSP SPME Monitoring (LSMEG) .......................28
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) .....................30
4.6. Fate-Sharing Considerations for Multilink .................31
5. OAM Functions for Proactive Monitoring .........................32
5.1. Continuity Check and Connectivity Verification ............33
5.1.1. Defects Identified by CC-V .........................35
5.1.2. Consequent Action ..................................37
5.1.3. Configuration Considerations .......................38
5.2. Remote Defect Indication ..................................40
5.2.1. Configuration Considerations .......................40
5.3. Alarm Reporting ...........................................41
5.4. Lock Reporting ............................................42
5.5. Packet Loss Measurement ...................................44
5.5.1. Configuration Considerations .......................45
5.5.2. Sampling Skew ......................................45
5.5.3. Multilink Issues ...................................45
5.6. Packet Delay Measurement ..................................46
5.6.1. Configuration Considerations .......................46
5.7. Client Failure Indication .................................47
5.7.1. Configuration Considerations .......................47
6. OAM Functions for On-Demand Monitoring .........................48
6.1. Connectivity Verification .................................48
6.1.1. Configuration Considerations .......................49
6.2. Packet Loss Measurement ...................................50
6.2.1. Configuration Considerations .......................50
6.2.2. Sampling Skew ......................................50
6.2.3. Multilink Issues ...................................50
6.3. Diagnostic Tests ..........................................50
6.3.1. Throughput Estimation ..............................51
6.3.2. Data-Plane Loopback ................................52
6.4. Route Tracing .............................................54
6.4.1. Configuration Considerations .......................54
6.5. Packet Delay Measurement ..................................54
6.5.1. Configuration Considerations .......................55
7. OAM Functions for Administration Control .......................55
7.1. Lock Instruct .............................................55
7.1.1. Locking a Transport Path ...........................56
7.1.2. Unlocking a Transport Path .........................56
8. Security Considerations ........................................57
9. Acknowledgments ................................................58
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................59
11. Contributing Authors ..........................................601. Introduction ✨
Okay so bestie, MPLS-TP (MPLS Transport Profile) is a packet-based transport technology 📦 It's built on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures from RFC 3031 [1], RFC 3985 [2], and RFC 5659 [4]. The MPLS-TP framework RFCs, RFC 5921 [8] and RFC 6215 [9], explain all of this too 💅
MPLS-TP runs a full suite of Operations, Administration, and Maintenance (OAM) procedures for fault, performance, and protection-switching management. The best part? These procedures don't depend on a control plane being there 🧚
Following [15], the plan is to reuse existing MPLS OAM mechanisms wherever possible. New OAM mechanisms or extensions only get defined when the existing ones can't meet the requirements 🎀 Some extensions might end up as aspirational capabilities and turn out to be not tractably realizable in some implementations, so that's a real possibility 🥲 And extensions never deprecate support for existing MPLS OAM capabilities 🫶
The MPLS-TP OAM framework gives a protocol-neutral description of the required OAM functions and of the data-plane OAM architecture. That's what lets a comprehensive set of OAM procedures satisfy the MPLS-TP OAM requirements of RFC 5860 [11] 🌸 It's giving similar OAM functionality to the existing Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) OAM mechanisms (e.g., [19]) ✨
The MPLS-TP OAM framework applies to:
- Sections
- Label Switched Paths (LSPs)
- Multi-Segment Pseudowires (MS-PWs)
- Sub-Path Maintenance Elements (SPMEs)
It supports co-routed and associated bidirectional P2P transport paths, as well as unidirectional P2P and P2MP transport paths 🦋
OAM packets that instrument a particular direction of a transport path get the same forwarding treatment (aka fate-share) as the user data packets 💜 In some cases, where Explicitly TC-encoded-PSC LSPs (E-LSPs) are used, they may be required to have a common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E) with the class of traffic being monitored. For a Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic needs to be monitored, so the OAM packets just have the same PSC as that monitored traffic class 🍓
OAM packets can be told apart from user data packets using the Generic Associated Channel Label (GAL) and Associated Channel Header (ACH) constructs of RFC 5586 [7] for LSP, SPME, and Section. For (MS-)PW, it's the ACH construct of RFC 5085 [3] and RFC 5586 [7] 🔥 OAM packets are never fragmented, and they're never combined with user data in the same packet payload. No mixing, periodt 🙅♀️
This framework assumes some things about how useful and how often different kinds of measurement are, and those assumptions naturally suggest that different functions should be implemented as distinct OAM flows or packets 🧩 That's dictated by two things: the class of problem being detected, and how quickly the network needs to respond to it ⏱️ For example, fault detection runs on a completely different time base than performance monitoring, and performance monitoring runs on a completely different time base than in-band management transactions. Totally different vibes 💀
The rest of this memo is structured like this:
- Section 2 covers the definitions and terminology used in this memo.
- Section 3 describes the functional component that generates and processes OAM packets.
- Section 4 describes the reference models for applying OAM functions to Sections, LSP, MS-PW, and their SPMEs.
- Sections 5, 6, and 7 give a protocol-neutral description of the OAM functions, defined in RFC 5860 [11], aimed at clarifying how the OAM protocol solutions will behave to achieve their functional objectives.
- Section 8 discusses the security implications of OAM protocol design in the MPLS-TP context.
The OAM protocol solutions designed because of this document are expected to comply with the functional behavior described in Sections 5, 6, and 7. Alternative solutions to required functional behaviors may also be defined too 🌈
OAM specifications that follow this OAM framework may be provided in different documents, each covering distinct OAM functions 📚
Last but not least, this document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort. The goal is to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures, so it can support the capabilities and functionalities of a packet transport network as defined by the ITU-T 🌟
2. Conventions Used in This Document 🎀
2.1. Terminology 📖
Here's the glossary, so everyone's speaking the same language:
AC Attachment Circuit
AIS Alarm Indication Signal
CC Continuity Check
CC-V Continuity Check and Connectivity Verification
CV Connectivity Verification
DBN Domain Border Node
E-LSP Explicitly TC-encoded-PSC LSP
ICC ITU Carrier Code
LER Label Edge Router
LKR Lock Report
L-LSP Label-Only-Inferred-PSC LSP
LM Loss Measurement
LME LSP Maintenance Entity
LMEG LSP ME Group
LSP Label Switched Path
LSR Label Switching Router
LSME LSP SPME ME
LSMEG LSP SPME ME Group
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
NMS Network Management System
PE Provider Edge
PHB Per-Hop Behavior
PM Performance Monitoring
PME PW Maintenance Entity
PMEG PW ME Group
PSC PHB Scheduling Class
PSME PW SPME ME
PSMEG PW SPME ME Group
PW Pseudowire
SLA Service Level Agreement
SME Section Maintenance Entity
SMEG Section ME Group
SPME Sub-Path Maintenance Element
S-PE Switching Provider Edge
TC Traffic Class
T-PE Terminating Provider Edge2.2. Definitions
okay bestie, so this section is basically the glossary 🎀 and it's giving "we are all using the SAME words to mean the SAME things" 💅 (super important for MPLS-TP stuff, no cap). A bunch of these terms are borrowed from other RFCs and the ITU-T Y.1731 recommendation, so let's go! ✨
This document uses the terms defined in RFC 5654 [5].
This document uses the term 'per-hop behavior' as defined in RFC 2474 [16].
This document uses the term 'LSP' to indicate either a service LSP or a transport LSP (as defined in RFC 5921 [8]). 🦋
This document uses the term 'Section' exclusively to refer to the n=0 case of the term 'Section' defined in RFC 5960 [10]. 🌸
This document uses the term 'Sub-Path Maintenance Element (SPME)' as defined in RFC 5921 [8]. 💜
This document uses the term 'traffic profile' as defined in RFC 2475 [13]. 🧚
Where appropriate, the following definitions are aligned with ITU-T recommendation Y.1731 [21] in order to have a common, unambiguous terminology. They do not however intend to imply a certain implementation but rather serve as a framework to describe the necessary OAM functions for MPLS-TP. 🫶 so these are a framework, not a blueprint for how to build it, which is lowkey important!
Adaptation function: The adaptation function is the interface between the client (sub-)layer and the server (sub-)layer.
Branch Node: A node along a point-to-multipoint transport path that is connected to more than one downstream node.
Bud Node: A node along a point-to-multipoint transport path that is at the same time a branch node and a leaf node for this transport path. 🌈
Data-plane loopback: An out-of-service test where a transport path at either an intermediate or terminating node is placed into a data-plane loopback state, such that all traffic (including both payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path.
Note: The only way to send an OAM packet to a node that has been
put into data-plane loopback mode is via Time to Live (TTL)
expiry, irrespective of whether the node is hosting MIPs or MEPs.⚠️ bestie this note is SO important: the ONLY way to reach a node in data-plane loopback with an OAM packet is TTL expiry, whether or not it's hosting MIPs or MEPs. 💀
Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP that is at the boundary between two MPLS-TP OAM domains. Such a node may be present on the edge of two domains or may be connected by a link to the DBN at the edge of another OAM domain. 🍓
Down MEP: A MEP that receives OAM packets from, and transmits them towards, the direction of a server layer.
Forwarding Engine: An abstract functional component, residing in an LSR, that forwards the packets from an ingress interface toward the egress interface(s). 🚀
In-Service: The administrative status of a transport path when it is unlocked.
Interface: An interface is the attachment point to a server (sub-)layer, e.g., a MPLS-TP Section or MPLS-TP tunnel.
Intermediate Node: An intermediate node transits traffic for an LSP or a PW. An intermediate node may originate OAM flows directed to downstream intermediate nodes or MEPs. 🦋
Loopback: See data-plane loopback and OAM loopback definitions.
Maintenance Entity (ME): Some portion of a transport path that requires management bounded by two points (called MEPs), and the relationship between those points to which maintenance and monitoring operations apply (details in Section 3.1).
Maintenance Entity Group (MEG): The set of one or more maintenance entities that maintain and monitor a section or a transport path in an OAM domain. 💖
MEP: A MEG End Point (MEP) is capable of initiating (source MEP) and terminating (sink MEP) OAM packets for fault management and performance monitoring. MEPs define the boundaries of an ME (details in Section 3.3). 👑
MIP: A MEG intermediate point (MIP) terminates and processes OAM packets that are sent to this particular MIP and may generate OAM packets in reaction to received OAM packets. It never generates unsolicited OAM packets itself. A MIP resides within a MEG between MEPs (details in Section 3.3). 🙈
OAM domain: A domain, as defined in [5], whose entities are grouped for the purpose of keeping the OAM confined within that domain. An OAM domain contains zero or more MEGs.
Note: Within the rest of this document, the term "domain" is used
to indicate an "OAM domain".OAM flow: The set of all OAM packets originating with a specific source MEP that instrument one direction of a MEG (or possibly both in the special case of data-plane loopback). 🌸
OAM loopback: The capability of a node to be directed by a received OAM packet to generate a reply back to the sender. OAM loopback can work in-service and can support different OAM functions (e.g., bidirectional on-demand connectivity verification). 🔥
OAM Packet: A packet that carries OAM information between MEPs and/or MIPs in a MEG to perform some OAM functionality (e.g., connectivity verification). 💅
Originating MEP: A MEP that originates an OAM transaction packet (toward a target MIP/MEP) and expects a reply, either in-band or out-of-band, from that target MIP/MEP. The originating MEP always generates the OAM request packets in-band and expects and processes only OAM reply packets returned by the target MIP/MEP. 🫶
Out-of-Service: The administrative status of a transport path when it is locked. When a path is in a locked condition, it is blocked from carrying client traffic. 🚫
Path Segment: It is either a segment or a concatenated segment, as defined in RFC 5654 [5]. 🧚
Signal Degrade: A condition declared by a MEP when the data forwarding capability associated with a transport path has deteriorated, as determined by performance monitoring (PM). See also ITU-T recommendation G.806 [14]. 🥀
Signal Fail: A condition declared by a MEP when the data forwarding capability associated with a transport path has failed, e.g., loss of continuity. See also ITU-T recommendation G.806 [14]. 💀
Sink MEP: A MEP acts as a sink MEP for an OAM packet when it terminates and processes the packets received from its associated MEG. 🌊
Source MEP: A MEP acts as source MEP for an OAM packet when it originates and inserts the packet into the transport path for its associated MEG. ⭐
Tandem Connection: A tandem connection is an arbitrary part of a transport path that can be monitored (via OAM) independent of the end-to-end monitoring (OAM). The tandem connection may also include the forwarding engine(s) of the node(s) at the boundaries of the tandem connection. Tandem connections may be nested but cannot overlap. See also ITU-T recommendation G.805 [20]. 🍭
Target MEP/MIP: A MEP or a MIP that is targeted by OAM transaction packets and that replies to the originating MEP that initiated the OAM transactions. The target MEP or MIP can reply either in-band or out-of-band. The target sink MEP function always receives the OAM request packets in-band, while the target source MEP function only generates the OAM reply packets that are sent in-band. 🎯
Up MEP: A MEP that transmits OAM packets towards, and receives them from, the direction of the forwarding engine. 🌙
3. Functional Components ✨
MPLS-TP is a packet-based transport technology based on the MPLS and PW data plane architectures ([1], [2], and [4]) and is capable of transporting service traffic where the characteristics of information transfer between the transport path end points can be demonstrated to comply with certain performance and quality guarantees. 🚀
In order to describe the required OAM functionality, this document introduces a set of functional components. 🎀
3.1. Maintenance Entity and Maintenance Entity Group
okay so MPLS-TP OAM lives in the world of Maintenance Entities (MEs) 💖 An ME is a relationship between two points on a transport path, and that's where the maintenance and monitoring stuff gets applied 🎀 Those two points are called Maintenance Entity Group End Points (MEPs) ✨ Then a bunch of MEs that sit on the same transport path and get maintained and monitored as one squad is a Maintenance Entity Group (MEG) 🫶 Between the MEPs you can have zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs) 🦋 MEPs and MIPs are tied to the MEG, and one MIP or MEP can be shared by more than one ME in the same MEG 💅
Here's the abstract reference model for an ME, which is giving very simple but very important 🧚
+-+ +-+ +-+ +-+
|A|----|B|----|C|----|D|
+-+ +-+ +-+ +-+Figure 1: ME Abstract Reference Model
So we get to see how this abstract model gets instantiated for the different MPLS-TP entities in Section 4 🌸 In Figure 1, nodes A and D can be Label Edge Routers (LERs) for an LSP, or the Terminating Provider Edges (T-PEs) for an MS-PW. Nodes B and C are LSRs for an LSP, or Switching PEs (S-PEs) for an MS-PW 💜 The MEPs live in nodes A and D, while the MIPs live in nodes B and C and may also live in A and D 🍓 And the links between adjacent nodes can be physical links, (sub-)layer LSPs/SPMEs, or server-layer paths 🌈
This functional model is the big picture of how all the OAM entities relate to each other from a maintenance point of view 👑 It lets each Maintenance Entity keep an eye on monitoring and management for the (sub-)layer network it's responsible for, and it makes finding problems way more efficient 🔥
An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management ⭐
Now here's the boundary situation 🙈 The MEPs that form a MEG bound the scope of an OAM flow to that MEG (i.e., within the domain of the transport path being monitored and managed). There are two exceptions to this:
- A misbranching fault may cause OAM packets to be delivered to a MEP that is not in the MEG of origin.
- An out-of-band return path may be used between a MIP or a MEP and the originating MEP.
Now the different path types, which are a lot but iykyk 💅
In the case of a unidirectional point-to-point transport path, a single unidirectional Maintenance Entity is defined to monitor it 🦋
In the case of associated bidirectional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined so each direction gets monitored on its own 🎀 This has implications for transactions that terminate at or query a MIP, because a return path from the MIP to the originating MEP does not necessarily exist in the MEG. Not me being dramatic, but this is a real gotcha 😭
In the case of co-routed bidirectional point-to-point transport paths, a single bidirectional Maintenance Entity is defined to monitor both directions congruently 🫶
In the case of unidirectional point-to-multipoint transport paths, a single unidirectional Maintenance Entity for each leaf is defined to monitor the transport path from the root to that leaf 🌸
And in all cases, portions of the transport path may be monitored by instantiating SPMEs (see Section 3.2) ✨
The reference model for the P2MP MEG is shown in Figure 2, and it's iconic 👑
+-+
/--|D|
/ +-+
+-+
/--|C|
+-+ +-+/ +-+\ +-+
|A|----|B| \--|E|
+-+ +-+\ +-+ +-+
\--|F|
+-+Figure 2: Reference Model for P2MP MEG
For P2MP transport paths, the OAM measurements are independent for each ME (A-D, A-E, and A-F) 🧚 Here's how that plays out:
- Fault conditions: some faults may impact more than one ME, depending on where the failure is located 💀
- Packet loss: packet dropping may impact more than one ME, depending on where the packets are lost 🍓
- Packet delay: it will be unique per ME 💖
Each leaf (i.e., D, E, and F) terminates OAM flows to monitor the ME between itself and the root. The root (i.e., A) generates OAM packets that are common to all the MEs of the P2MP MEG 🫶 And all nodes may implement a MIP in the corresponding MEG 🌈
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring
okay so to verify and maintain performance and quality guarantees, we need OAM functionality that isn't just at the whole transport path level (like an LSP or an MS-PW) 🎀 We also need it on arbitrary parts of transport paths, which are called tandem connections, between any two arbitrary points along a transport path 💜
Sub-Path Maintenance Elements (SPMEs), as defined in [8], are hierarchical LSPs that get set up to monitor a portion of a set of transport paths (LSPs or MS-PWs) that follow the same path between the ingress and the egress of the SPME ✨ The operational aspects of instantiating SPMEs are out of scope of this memo 🙈
SPMEs can also be used to meet the requirement to provide tandem connection monitoring (TCM), as defined by ITU-T Recommendation G.805 [20] 🦋
TCM for a given path segment of a transport path is implemented by creating an SPME that has a 1:1 association with the path segment of the transport path that is to be monitored 💅
In the TCM case, this means the SPME used to provide TCM can carry one and only one transport path. That gives us direct correlation between all the fault management and performance monitoring information gathered for the SPME and the monitored path segment of the end-to-end transport path. Literally so clean 🔥
There are a number of implications to this approach:
- The SPME would use the uniform model [23] of Traffic Class (TC) code point copying between sub-layers for Diffserv, so that the E2E markings and PHB treatment for the transport path are preserved by the SPMEs 🌈
- The SPME normally would use the short-pipe model for TTL handling [6] (no TTL copying between sub-layers). That way the TTL distance to the MIPs for the E2E entity isn't impacted by the presence of the SPME. But it should be possible for an operator to specify use of the uniform model 🍓
Note that points 1 and 2 above assume that the TTL copying mode and TC copying modes are independently configurable for an LSP 🧚
The TTL distance to the MIPs plays a critical role in delivering packets to these MIPs, as described in Section 3.4 👑
Now the uniform model of TTL copying for an SPME comes with some specific issues 😭
- A MIP in the SPME sub-layer is not part of the transport-path MEG. Hence, only an out-of-band return path for OAM originating in the transport-path MEG that addressed an SPME MIP might be available 💀
- The instantiation of a lower-level MEG, or protection-switching actions within a lower-level MEG, may change the TTL distances to MIPs in the higher-level MEGs 🫶
The end points of the SPME are MEPs, and they limit the scope of an OAM flow within the MEG that the MEPs belong to (i.e., within the domain of the SPME being monitored and managed) 💖
When you're thinking about SPMEs, it's important to remember that the following properties apply to all MPLS-TP MEGs (regardless of whether they instrument LSPs, SPMEs, or MS-PWs) 🌸
- They can be nested but not overlapped. For example, a MEG may cover a path segment of another MEG, and may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment. However, when MEGs are nested, the MEPs and MIPs in the SPME are no longer part of the encompassing MEG ✨
- MEPs of nested MEGs can reside on a single node. It is possible that MEPs of MEGs that are nested reside on a single node, but again they are implemented in such a way that they do not overlap 🦋
- Each OAM flow is associated with a single MEG. 🎀
- TTL distances can shift. When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of TTL copying. It may also change for the uniform model if the SPME is not co-routed with the original path 🧚
3.3. MEG End Points (MEPs) 🧚
okay bestie, MEPs (MEG End Points) are the source and sink points of a MEG 🎀. For an MPLS-TP LSP, only LERs can implement MEPs ✨. For an SPME, though, any LSR on the MPLS-TP LSP can be an LER of SPMEs that help build the overall monitoring setup of the transport path 🦋. For PWs, only T-PEs can implement MEPs. For SPMEs supporting one or more PWs, both T-PEs and S-PEs can implement SPME MEPs 💅. And any MPLS-TP LSR can implement a MEP for an MPLS-TP Section 🌸.
MEPs are basically in charge of originating almost all of the proactive and on-demand monitoring OAM functionality for the MEG 💖. There's a separate class of notifications (like Lock Report (LKR) and Alarm Indication Signal (AIS)) that get originated by intermediate nodes and triggered by server-layer events 👑. A MEP can originate and terminate OAM packets for fault management and performance monitoring 🔥. These OAM packets ride inside the Generic Associated Channel (G-ACh) with the proper encapsulation and an appropriate channel type, as defined in RFC 5586 [7] 🫶. A MEP terminates all the OAM packets it receives from the MEG it belongs to, and silently discards the ones that don't 🙈. (Side note: for Connectivity Verification (CV) processing in particular, a CV packet from an incorrect MEG results in a mis-connectivity defect, and further actions are taken 😭.)
The MEG an OAM packet belongs to is associated with the MPLS or PW label. Whether the label is used to infer the MEG, or the content of the OAM packet is used for that, is an implementation choice 🌈. For an MPLS-TP Section, the MEG is inferred from the port the OAM packet was received on, with the GAL at the top of the label stack 🧚.
OAM packets may need an available "out-of-band" return path (as defined in [8]) 🍓. In those cases, the originating transaction needs enough information so the OAM reply packet can be constructed and properly forwarded to the originating MEP (e.g., IP address) 💜.
Each OAM solution document will further detail the applicability of the tools it defines as a proactive or on-demand mechanism, as well as how they're used when:
- The "in-band" return path exists and it is used.
- An "out-of-band" return path exists and it is used.
- Any return path does not exist or is not used.
Once a MEG is configured, the operator can choose which proactive OAM functions to use on the MEG, but the MEPs are always enabled 🔒.
MEPs terminate all OAM packets received from the associated MEG. Since the MEP is the termination of the forwarding path for a MEG at the given (sub-)layer, OAM packets never leak outside of a MEG in a properly configured fault-free implementation ✨.
A MEP of an MPLS-TP transport path coincides with transport path termination, and it monitors that path for failures or performance degradation (e.g., based on packet counts) in an end-to-end scope 👑. Both the source MEP and sink MEP coincide with the transport path's source and sink terminations 💖.
The MEPs of an SPME are not necessarily coincident with the termination of the MPLS-TP transport path. They're used to monitor a path segment of the transport path for failures or performance degradation (e.g., based on packet counts), but only within the boundary of the MEG for the SPME 🦋.
An MPLS-TP sink MEP passes a fault indication to its client (sub-)layer network as a consequent action of fault detection. When the client layer is not MPLS-TP, the consequent actions in the client layer (e.g., ignore or generate client-layer-specific OAM notifications) are outside the scope of this document 🫶.
A node hosting a MEP can either support per-node MEP or per-interface MEP(s) 🎀. A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine 💅. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer 🌸.
Source node Up MEP Destination node Up MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| MEP | | | | | | MEP |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(1) (2)
Source node Down MEP Destination node Down MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| | | MEP | | MEP | | |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(3) (4)
Figure 3: Examples of Per-Interface MEPsFigure 3 shows four examples of per-interface Up MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4) 🧚.
Using per-interface Up MEPs extends the coverage of the ME for both fault and performance monitoring closer to the edge of the domain 🍓. It also means the location of a failure or performance degradation can be pinned down to within a node or to a link between two adjacent nodes 💜.
Each OAM solution document will further detail the implications of the tools it defines when used with per-interface or per-node MEPs, if necessary 📝.
It may happen that multiple MEPs for the same MEG are on the same node, and they're all Up MEPs, each on one side of the forwarding engine, so the MEG is entirely internal to the node 🏠.
It's worth noting that an ME may span nodes that implement per-node MEPs and per-interface MEPs. This guarantees backward compatibility with most of the existing LSRs that can implement only a per-node MEP. In fact, in many current implementations, label operations are largely performed on the ingress interface, so the exposure of the GAL as top label will occur at the ingress interface 🥰.
Note that a MEP can only exist at the beginning and end of a (sub-)layer in MPLS-TP. If there's a need to monitor some portion of that LSP or PW, a new sub-layer (in the form of an SPME) must be created that permits MEPs and associated MEGs to be created 🦋.
In the case where an intermediate node sends an OAM packet to a MEP, it uses the top label of the stack at that point 💅.
3.4. MEG Intermediate Points (MIPs) 🦋
Okay bestie, a MEG Intermediate Point (MIP) is a function that sits at a point between the MEPs of a MEG for a PW, LSP, or SPME. 💅
A MIP can react to some OAM packets and forward all the other OAM packets, and it keeps fate-sharing with user data packets while doing it 🫶. The catch is that a MIP does not start unsolicited OAM packets on its own. It can only be addressed by OAM packets that one of the MEG's MEPs sends out. It can only generate OAM packets in response to OAM packets it gets from the MEG it belongs to, and whatever it generates goes back to the originating MEP 🌸.
An intermediate node within a MEG can either:
- support per-node MIPs (i.e., a single MIP per node in an unspecified location within the node); or
- support per-interface MIPs (i.e., two or more MIPs per node on both sides of the forwarding engine).
Support of per-interface or per-node MIPs is an implementation choice 🎀. A node could even do per-interface MIPs on some MEGs and per-node MIPs on other MEGs where it's a transit node. Main character energy, no cap 👑.
Intermediate node
------------------------
| |
|----- -----|
| MIP | | MIP |
| | ---- | |
->-| In |->-| FW |->-| Out |->-
| i/f | ---- | i/f |
|----- -----|
| |
------------------------
Figure 4: Example of Per-Interface MIPsFigure 4 shows an example of two per-interface MIPs at an intermediate node of a point-to-point MEG 🦋.
Using per-interface MIPs lets the network operator figure out whether a failure or performance degradation is inside a node or on a link between two adjacent nodes. That's iconic detective work 🔍✨.
When sending an OAM packet to a MIP, the source MEP should set the TTL field to indicate the number of hops necessary to reach the node where the MIP resides 🧚.
The source MEP should also include target MIP information in the OAM packets sent to a MIP, so the MIP can be identified properly within the node 💜. The MEG an OAM packet belongs to is associated with the MPLS label. Whether the label is used to infer the MEG or the content of the OAM packet is used is an implementation choice. In the latter case, the MPLS label is checked to be the expected one 🍓.
⚠️ Heads up: using TTL expiry to deliver OAM packets to a specific MIP is NOT a fully reliable delivery mechanism, because the TTL distance of a MIP from a MEP can change 💀. Any MPLS-TP node silently discards any OAM packet that is received with an expired TTL and that is not addressed to any of its MIPs or MEPs. An MPLS-TP node that does not support OAM is also expected to silently discard any received OAM packet 🙈.
Packets directed to a MIP may not carry specific MIP identification information beyond TTL distance. In that case, a MIP would promiscuously respond to all MEP queries on its MEG 🌈. This can be useful for discovery functions (e.g., route tracing as defined in Section 6.4), or when you want the originating MEP to do the job of correlating TTL and MIP identifiers and noting changes or irregularities (by comparing against information previously extracted from the network) 🧐.
MIPs are associated with the MEG they belong to, and their identity is unique within the MEG. Their identity is not necessarily unique to the MEG, though. For example, all nodal MIPs in a node can share a common identity 🫧.
A node hosting a MEP can also support per-interface Up MEPs and per-interface MIPs on either side of the forwarding engine 💖.
Once a MEG is configured, the operator can enable or disable the MIPs on the nodes within the MEG. All the intermediate nodes, and possibly the end nodes, host MIP(s). Local policy lets them be enabled per function and per MEG. That local policy is controlled by the management system, which may delegate it to the control plane. A disabled MIP silently discards any received OAM packets 🙅♀️.
3.5. Server MEPs ✨
A server MEP is a MEP of a MEG that is either:
- defined in a layer network that is "below", which is to say encapsulates and transports the MPLS-TP layer network being referenced; or
- defined in a sub-layer of the MPLS-TP layer network that is "below", which is to say encapsulates and transports the sub-layer being referenced.
A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) (sub-)layer network 🦋.
A server MEP also gives server-layer OAM indications to the client/server adaptation function sitting between the client (MPLS-TP) (sub-)layer network and the server (sub-)layer network. The adaptation function keeps state on how MPLS-TP transport paths are mapped onto the transport path of that server (sub-)layer 🎀.
For example, a server MEP can be:
- a non-MPLS MEP at a termination point of a physical link (e.g., 802.3, an SDH Virtual Circuit, or OTN Optical Data Unit (ODU)), for the MPLS-TP Section layer network, defined in Section 4.1;
- an MPLS-TP Section MEP for MPLS-TP LSPs, defined in Section 4.2;
- an MPLS-TP LSP MEP for MPLS-TP PWs, defined in Section 4.3;
- an MPLS-TP SPME MEP used for LSP path segment monitoring, as defined in Section 4.4, for MPLS-TP LSPs or higher-level SPMEs providing LSP path segment monitoring; or
- an MPLS-TP SPME MEP used for PW path segment monitoring, as defined in Section 4.5, for MPLS-TP PWs or higher-level SPMEs providing PW path segment monitoring.
The server MEP can run the right OAM functions for fault detection within the server (sub-)layer network, and it passes a fault indication up to its client MPLS-TP layer network through the client/server adaptation function 🚨. When the server layer is not MPLS-TP, server MEP OAM functions are simply assumed to exist, but they are outside the scope of this document 🌸.
3.6. Configuration Considerations 🛠️
When a control plane is not present, the management plane configures these functional components. Otherwise, they can be configured by either the management plane or the control plane 💅.
Local policy allows disabling the usage of any available "out-of-band" return path, as defined in [8], no matter what the node originating the OAM packet requests 🙅♀️.
SPMEs are usually instantiated when the transport path is created, by either the management plane or the control plane (if present). Sometimes an SPME can be instantiated after the transport path is first created ⏰.
3.7. P2MP Considerations 🌳
All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves. So, as a consequence:
- To send an OAM packet to all leaves, the source MEP can send a single OAM packet that the forwarding plane delivers to all the leaves and that all the leaves process. A single OAM packet can therefore instrument all the MEs in a P2MP MEG at once 🤯.
- To send an OAM packet to a single leaf, the source MEP sends a single OAM packet that the forwarding plane delivers to all the leaves, but it contains enough information to identify a target leaf. Only the target leaf processes it, and the other leaves can silently discard it 🎯.
- To send an OAM packet to a single MIP, the source MEP sends a single OAM packet with the TTL field indicating the number of hops necessary to reach the node where the MIP resides. The forwarding plane delivers this packet to all intermediate nodes at the same TTL distance as the target MIP, and to any leaf located at a shorter distance. The OAM packet must contain sufficient information to identify the target MIP, so only the target MIP processes it and the others can silently discard it 🧚.
- To send an OAM packet to M leaves (i.e., a subset of all the leaves), the source MEP sends M different OAM packets, each one targeted to an individual leaf in the group of M leaves. Aggregating or subsetting mechanisms are outside the scope of this document 📦.
A bud node with a Down MEP or a per-node MEP will both terminate and relay OAM packets. Just like fault coverage is maximized by explicitly using Up MEPs, the same goes for MEPs on a bud node 🌟.
P2MP paths are unidirectional, so any return path to an originating MEP for on-demand transactions will be out-of-band. A mechanism to target "on-demand" transactions to a single MEP or MIP is required 🫶. It relieves the originating MEP of an arbitrarily large processing load, and of the need to filter and discard undesired responses. That's because normally, TTL exhaustion will address all MIPs at a given distance from the source, and failing to exhaust TTL will address all MEPs 💖.
3.8. Further Considerations of Enhanced Segment Monitoring ✨
Okay so, segment monitoring (like any in-service monitoring in a transport network) is supposed to hit these network objectives 🫶:
- Monitoring and maintaining existing transport paths has to happen in service, without any traffic disruption.
- Segment monitoring must not modify the forwarding of the segment portion of the transport path.
SPMEs from Section 3.2 totally slay both of those when they're pre-configured or pre-instantiated like in Section 3.6 💅. BUT pre-designing and pre-configuring every single SPME pattern isn't always preferable in real operation 😭. It means a ton of design work, a bunch of header consumption, extra bandwidth consumption, and so on.
When SPMEs get configured or instantiated after the transport path already exists, objective (1) can be met. You can apply and remove an SPME on a faultless monitored transport entity without any loss of traffic, e.g., with a non-disruptive "make before break" technique 🦋.
Objective (2) though? Not met 💀, because of the new assignment of MPLS labels. So generally speaking, the results of SPME monitoring aren't necessarily correlated with how traffic behaves in the monitored entity when it doesn't use an SPME. For example, slapping an SPME on a problematic or faulty monitoring entity might "fix" the problem, but only for as long as the SPME is applied 🙈. And vice versa: putting an SPME on a faultless monitored entity may make it faulty, again only as long as the SPME is applied.
Support for a more sophisticated segment-monitoring mechanism (temporal and hitless segment monitoring) to meet the two network objectives efficiently may be necessary 🧚.
One possible option for non-intrusive segment monitoring without SPMEs would require the MIPs selected as monitoring end points to implement enhanced functionality and state for the monitored transport path 👑.
For example, the MIPs need to be configured with the TTL distance to the peer, or with the address of the peer when out-of-band return paths are used.
Another thing to consider is events that change the TTL distance to the peer monitoring entity, like protection events. Those can temporarily invalidate the OAM information gleaned from this technique 🌸.
Further considerations on this technique are outside the scope of this document 🫶.
4. Reference Model 🌈
The reference model for the MPLS-TP OAM framework is built on the concept of a MEG, plus its associated MEPs and MIPs, so it can support the functional requirements specified in RFC 5860 [11] ✨.
The following MPLS-TP MEGs are specified in this document:
- A Section Maintenance Entity Group (SMEG), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs).
- An LSP Maintenance Entity Group (LMEG), allowing monitoring and management of an end-to-end LSP (between LERs).
- A PW Maintenance Entity Group (PMEG), allowing monitoring and management of an end-to-end Single-Segment Pseudowire (SS-PW) or MS-PW (between T-PEs).
- An LSP SPME ME Group (LSMEG), allowing monitoring and management of an SPME (between a given pair of LERs and/or LSRs along an LSP).
- A PW SPME ME Group (PSMEG), allowing monitoring and management of an SPME (between a given pair of T-PEs and/or S-PEs along an (MS-)PW).
The MEGs specified in this MPLS-TP OAM framework are compliant with the architecture framework for MPLS-TP [8], which includes both MS-PWs [4] and LSPs [1] 💜.
Hierarchical LSPs are also supported, in the form of SPMEs. Each LSP in the hierarchy is a different sub-layer network that can be monitored independently from higher- and lower-level LSPs in the hierarchy, on an end-to-end basis (from LER to LER) by an SPME. It's also possible to monitor a portion of a hierarchical LSP by instantiating a hierarchical SPME between any LERs/LSRs along the hierarchical LSP 🧚.
Native |<------------------ MS-PW1Z ---------------->| Native
Layer | | Layer
Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service
(AC1) V V V V V V V V (AC2)
+----+ +---+ +----+ +----+ +---+ +----+
+----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| | | |=======| |=========| |=======| | | |
| CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 |
| | | |=======| |=========| |=======| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<--- Domain 1 -->| |<--- Domain Z -->|
^----------------- PW1Z PMEG ----------------^
^--- PW13 PSMEG --^ ^--- PWXZ PSMEG --^
^-------^ ^-------^
LSP13 LMEG LSPXZ LMEG
^--^ ^--^ ^---------^ ^--^ ^--^
Sec12 Sec23 Sec3X SecXY SecYZ
SMEG SMEG SMEG SMEG SMEG
^---^ ME
^ MEP
==== LSP
.... PW
T-PE 1: Terminating Provider Edge 1
LSR 2: Label Switching Router 2
S-PE 3: Switching Provider Edge 3
S-PE X: Switching Provider Edge X
LSR Y: Label Switching Router Y
T-PE Z: Terminating Provider Edge Z
Figure 5: Reference Model for the MPLS-TP OAM FrameworkFigure 5 is a high-level reference model for the MPLS-TP OAM framework 🎀. It shows portions of two MPLS-TP-enabled network domains, Domain 1 and Domain Z. In Domain 1, T-PE 1 is adjacent to LSR 2 via the MPLS-TP Section Sec12, and LSR 2 is adjacent to S-PE 3 via the MPLS-TP Section Sec23. Similarly, in Domain Z, S-PE X is adjacent to LSR Y via the MPLS-TP Section SecXY, and LSR Y is adjacent to T-PE Z via the MPLS-TP Section SecYZ. On top of that, S-PE 3 is adjacent to S-PE X via the MPLS-TP Section Sec3X.
Figure 5 also shows a bidirectional MS-PW (MS-PW1Z) between AC1 on T-PE 1 and AC2 on T-PE Z. The MS-PW is made of three bidirectional PW path segments: 1) the PW13 path segment between T-PE 1 and S-PE 3 via the bidirectional LSP13 LSP, 2) the PW3X path segment between S-PE 3 and S-PE X via the bidirectional LSP3X LSP, and 3) the PWXZ path segment between S-PE X and T-PE Z via the bidirectional LSPXZ LSP 🦋.
The MPLS-TP OAM procedures that apply to a MEG are expected to operate independently from procedures on other MEGs. That said, this doesn't stop multiple MEGs from being affected at the same time by the same network condition, like a fiber cut event 💥.
Note that this OAM framework puts no constraints on the number or type (P2P, P2MP, LSP, or PW) of MEGs that may be instantiated on a particular node. In particular, looking at Figure 5, it should be possible to configure one or more MEPs on the same node if that node is the end point of one or more MEGs 🌸.
Figure 5 doesn't describe a PW3X PSMEG, because SPMEs are typically used to monitor an OAM domain (like the PW13 and PWXZ PSMEGs) rather than the segment between two OAM domains. However, the OAM framework doesn't pose any constraints on the way SPMEs are instantiated, as long as they don't overlap 🙌.
The subsections below define the MEGs specified in this MPLS-TP OAM architecture framework document. Unless otherwise stated, all references to domains, LSRs, MPLS-TP Sections, LSPs, pseudowires, and MEGs in this section are made in relation to those shown in Figure 5 🫶.
4.1. MPLS-TP Section Monitoring (SMEG) 🦋
An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity intended to monitor an MPLS-TP Section. An SMEG may be configured on any MPLS-TP section. SMEG OAM packets must fate-share with the user data packets sent over the monitored MPLS-TP Section 🔗.
An SMEG is meant for applications where it's preferable to monitor the link between topologically adjacent MPLS-TP LSRs (next hop in this layer network), rather than monitoring the individual LSP or PW path segments that traverse the MPLS-TP Section. It's also for when the server-layer technology doesn't provide adequate OAM capabilities 💅.
Figure 5 shows five Section MEGs configured in the network between AC1 and AC2:
- Sec12 MEG associated with the MPLS-TP Section between T-PE 1 and LSR 2,
- Sec23 MEG associated with the MPLS-TP Section between LSR 2 and S-PE 3,
- Sec3X MEG associated with the MPLS-TP Section between S-PE 3 and S-PE X,
- SecXY MEG associated with the MPLS-TP Section between S-PE X and LSR Y, and
- SecYZ MEG associated with the MPLS-TP Section between LSR Y and T-PE Z
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) 🧚
An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group intended to monitor an end-to-end LSP between its LERs. An LMEG may be configured on any MPLS LSP. LMEG OAM packets must fate-share with user data packets sent over the monitored MPLS-TP LSP 💜.
An LMEG is meant for scenarios where you want to monitor an entire LSP between its LERs, rather than, say, monitoring individual PWs 👑.
Figure 5 depicts two LMEGs configured in the network between AC1 and AC2: 1) the LSP13 LMEG between T-PE 1 and S-PE 3, and 2) the LSPXZ LMEG between S-PE X and T-PE Z. Note that a LSP3X LMEG is optional in such a configuration, so this framework doesn't preclude it. For instance, the network operator may prefer to monitor the MPLS-TP Section between the two LSRs rather than the individual LSPs 🌈.
4.3. MPLS-TP PW Monitoring (PMEG) 🎀
An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity intended to monitor an SS-PW or MS-PW between its T-PEs. A PMEG can be configured on any SS-PW or MS-PW. PMEG OAM packets must fate-share with the user data packets sent over the monitored PW 🫧.
A PMEG is meant for scenarios where you want to monitor an entire PW between a pair of MPLS-TP-enabled T-PEs, rather than monitoring the LSP that aggregates multiple PWs between PEs 💅.
Figure 5 depicts an MS-PW (MS-PW1Z) made of three path segments (PW13, PW3X, and PWXZ) and its associated end-to-end PMEG (PW1Z PMEG) 🦋.
4.4. MPLS-TP LSP SPME Monitoring (LSMEG) 🎀
Okay bestie, an LSP SPME MEG (LSMEG) is an MPLS-TP SPME with its own maintenance entity group 💖. It's built to watch an arbitrary part of an LSP between the MEPs set up for that SPME, and it's totally independent from the end-to-end monitoring (LMEG) ✨. An LSMEG can monitor an LSP path segment, and it can also include the forwarding engine(s) of the node(s) at the edge(s) of that segment 💅.
When an SPME gets set up between non-adjacent LSRs, the edges become adjacent at the LSP sub-layer network, and any LSR that used to be in the middle becomes an LSR for the SPME 🦋.
You can configure multiple hierarchical LSMEGs on any LSP 🧚. LSMEG OAM packets must fate-share with the user data packets sent over the monitored LSP path segment 🫶.
An LSME can be defined between the following entities:
- The LER and LSR of a given LSP.
- Any two LSRs of a given LSP.
An LSMEG is meant for situations where it's better to monitor how a part of an LSP (or a set of LSPs) behaves, rather than the whole LSP itself. For example, that's the case when you need to monitor a part of an LSP that goes beyond the administrative boundaries of an MPLS-TP-enabled administrative domain 👑.
|<-------------------- PW1Z ------------------->|
| |
| |<-------------LSP1Z LSP------------->| |
| |<-LSP13->| |<LSP3X>| |<-LSPXZ->| |
V V V V V V V V
+----+ +---+ +----+ +----+ +---+ +----+
+----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| |AC1| |=====================================| |AC2| |
| CE1|---|.....................PW1Z......................|---|CE2 |
| | | |=====================================| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<---- Domain 1 --->| |<---- Domain Z --->|
^---------^ ^---------^
LSP13 LSMEG LSPXZ LSMEG
^-------------------------------------^
LSP1Z LMEGDBN: Domain Border Node
PE 1: Provider Edge 1
LSR 2: Label Switching Router 2
DBN 3: Domain Border Node 3
DBN X: Domain Border Node X
LSR Y: Label Switching Router Y
PE Z: Provider Edge Z
Figure 6: MPLS-TP LSP SPME MEG (LSMEG)Figure 6 is a variation of the reference model in Figure 5, where there's an end-to-end LSP (LSP1Z) between PE 1 and PE Z 🌸. LSP1Z consists of, at least, three LSP Concatenated Segments: LSP13, LSP3X, and LSPXZ. In this scenario, there are two separate LSMEGs configured to monitor LSP1Z: 1) an LSMEG monitoring the LSP13 Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2) an LSMEG monitoring the LSPXZ Concatenated Segment on Domain Z (LSPXZ LSMEG) 🔥.
It's worth noticing that LSMEGs can coexist with the LMEG monitoring the end-to-end LSP, and that LSMEG MEPs and LMEG MEPs can be coincident in the same node. For example, PE 1 can support both the LSP1Z LMEG MEP and the LSP13 LSMEG MEP 💜.
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) 🦋
An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME with an associated maintenance entity group, intended to monitor an arbitrary part of an MS-PW between the MEPs instantiated for the SPME, independently of the end-to-end monitoring (PMEG) ✨. A PSMEG can monitor a PW path segment, and it may also include the forwarding engine(s) of the node(s) at the edge(s) of that segment. Honestly, a PSMEG is no different than an SPME. It's just named that way so we can talk about SPMEs specifically in a PW context 🎀.
When an SPME is established between non-adjacent S-PEs, the edges become adjacent at the MS-PW sub-layer network, and any S-PE that was previously in between becomes an LSR for the SPME 🧚.
S-PE placement is usually decided by things other than OAM 🌈. S-PEs often sit at operational boundaries, like the switch from distributed control plane (CP) to centralized Network Management System (NMS) control, or at a routing area boundary. So the architecture might not look like it has the flexibility that arbitrary placement of SPME segments would suggest 🙈. Supporting arbitrary placement of PSMEGs would need extra PW sub-layering to be defined. You can configure multiple hierarchical PSMEGs on any MS-PW, and PSMEG OAM packets fate-share with the user data packets sent over the monitored PW path segment 🫶.
A PSMEG doesn't add hierarchical components to the MPLS architecture. It defines the role of existing components for the purposes of discussing OAM functionality 💅.
A PSME can be defined between the following entities:
- The T-PE and any S-PE of a given MS-PW.
- Any two S-PEs of a given MS-PW.
Note that, in line with the SPME description in Section 3.2, when a PW SPME is instantiated after the MS-PW has been instantiated, the TTL distance of the MIPs may change, and MIPs in the PW SPME are no longer part of the encompassing MEG. This means the S-PE nodes hosting these MIPs stop being S-PEs and become P nodes at the SPME LSP level. The consequence is that the S-PEs hosting the PSMEG MEPs become adjacent S-PEs. This is no different than how SPMEs work in general 😭.
A PSMEG is meant for situations where it's better to monitor how a part of an MS-PW behaves than the entire end-to-end PW, for example, when monitoring an MS-PW path segment within a given network domain of an inter-domain MS-PW 👑.
Figure 5 depicts an MS-PW (MS-PW1Z) made up of three path segments: PW13, PW3X, and PWXZ, with two separate PSMEGs: 1) a PSMEG monitoring the PW13 MS-PW path segment on Domain 1 (PW13 PSMEG), and 2) a PSMEG monitoring the PWXZ MS-PW path segment on Domain Z (PWXZ PSMEG) 🔥.
It's worth noticing that PSMEGs can coexist with the PMEG monitoring the end-to-end MS-PW, and that PSMEG MEPs and PMEG MEPs can be coincident in the same node. For example, T-PE 1 can support both the PW1Z PMEG MEP and the PW13 PSMEG MEP 💖.
4.6. Fate-Sharing Considerations for Multilink 🌸
Multilink techniques are in use today and are expected to keep being used in future deployments 🍓. These techniques include Ethernet link aggregation [22] and the use of link bundling for MPLS [18], where the option to spread traffic over component links is supported and enabled. Link bundling can be controlled at the MPLS-TP layer, but use of link aggregation (or any server-layer-specific multilink) isn't necessarily under the control of the MPLS-TP layer 🤔. Other techniques may show up in the future. These techniques often share the trait that an LSP may be spread over a set of component links and therefore be reordered, but no flow within the LSP is reordered (except when very infrequent and minimally disruptive load rebalancing occurs) ✨.
The use of multilink techniques may be prohibited or permitted in any particular deployment. If multilink techniques are used, the deployment can be considered only partially MPLS-TP compliant. However, this is unlikely to stop them from being used 💅.
The OAM implications are that not all components of a multilink will be exercised, and independent server-layer OAM is required to exercise the aggregated link components 😬. This also affects MIP and MEP placement. Per-interface MIPs or Down MEPs on a multilink interface are akin to a layer violation, because they instrument at the granularity of the server layer. The implications for reduced OAM loss measurement functionality are documented in Sections 5.5.3 and 6.2.3 🫶.
5. OAM Functions for Proactive Monitoring ✨
In this document, proactive monitoring refers to OAM operations that are either configured to run periodically and continuously, or preconfigured to act on certain events such as alarm signals 🔥.
Proactive monitoring is usually performed "in-service". These transactions are universally MEP to MEP in operation, while notifications can be node to node (e.g., some MS-PW transactions) or node to MEPs (e.g., AIS). The control and measurement considerations are:
- Proactive monitoring for a MEG is typically configured at the creation time of the transport path.
- The operational characteristics of in-band measurement transactions (e.g., CV, Loss Measurement (LM), etc.) are configured at the MEPs.
- Server-layer events are reported by OAM packets originating at intermediate nodes.
- The measurements resulting from proactive monitoring are typically reported outside of the MEG (e.g., to a management system) as notification events, such as faults or indications of performance degradations (such as signal degrade conditions).
- The measurements resulting from proactive monitoring may be periodically harvested by an NMS 💜.
Proactive fault reporting is assumed to be subject to unreliable delivery and soft-state, and it needs to work even when a return path isn't available or is faulty. That's why periodic repetition is assumed to be used for reliability, instead of handshaking 🌈.
Delay measurement also requires periodic repetition, so the packet delay variation for the MEG can be estimated 🧚.
For statically provisioned transport paths, the above information is statically configured. For dynamically established transport paths, the configuration information is signaled via the control plane or configured via the management plane 🎀.
The operator may enable/disable some of the consequent actions defined in Section 5.1.2 💅.
5.1. Continuity Check and Connectivity Verification ✨
okay so Proactive Continuity Check functions, required in Section 2.2.2 of RFC 5860 [11], are how we catch a loss of continuity (LOC) defect between two MEPs in a MEG 🫶.
Proactive Connectivity Verification functions, required in Section 2.2.3 of RFC 5860 [11], catch an unexpected connectivity defect between two MEGs (think mismerging or misconnection) 👀. They also catch unexpected connectivity within the MEG when there's an unexpected MEP.
Both functions work the same way. The source MEP proactively generates OAM packets at the same rate, and the peer sink MEP(s) process them. So to save OAM bandwidth, CV gets linked with CC into Continuity Check and Connectivity Verification (CC-V) OAM packets. It's giving efficiency 🧠💅
For proactive Connectivity Verification, each CC-V OAM packet also carries a globally unique Source MEP identifier. Its value has to be configured on the source MEP and on the peer sink MEP(s) 🔑. Sometimes you'd rather not configure that identifier at all, so it's preferable to do only proactive Continuity Check. In that case the CC-V OAM packet doesn't need any globally unique Source MEP identifier. That means a MEG can be monitored only for CC, or for both CC and CV. CC-V OAM packets used for CC-only monitoring are called CC OAM packets, and CC-V OAM packets used for both CC and CV are called CV OAM packets 🎀.
Now here's the tea ☕. It's not possible to detect misconnections between two MEGs that are monitored only for continuity, because neither the OAM packet type nor the OAM packet content gives enough info to figure out an invalid source. To break it down:
- For a CC OAM packet leaking into a CC monitored MEG, it's undetectable 🙈.
- For a CV OAM packet leaking into a CC monitored MEG, receiving CV OAM packets instead of CC OAM packets (e.g., with the additional Source MEP identifier) lets you detect the fault.
- For a CC OAM packet leaking into a CV monitored MEG, receiving CC OAM packets instead of CV OAM packets (e.g., without the additional Source MEP identifier) lets you detect the fault.
- For a CV OAM packet leaking into a CV monitored MEG, receiving CV OAM packets with a different Source MEP identifier lets you identify the fault.
Having a common packet format for CC-V OAM packets would make life easier for a sink MEP, so it can properly detect all of the misconfiguration cases above 🧚.
MPLS-TP OAM supports different formats of MEP identifiers for different environments 🌈. When you want an alternative to IP addressing (for example, when MPLS-TP is deployed in transport networks that need to operate consistently with other transport technologies defined by the ITU-T), the ITU Carrier Code (ICC)-based format for MEP identification is used. This format is still under definition in [25]. When MPLS-TP is deployed where IP capabilities are available and wanted for OAM, the IP-based MEP identification is used, and it's described in [24].
CC-V OAM packets are sent at a regular rate that the operator can configure. The default CC-V transmission periods depend on the application (see Section 5.1.3) ⏰.
Proactive CC-V OAM packets are sent with the "minimum loss probability PHB" within the transport path (LSP, PW) they're monitoring 🍓. For E-LSPs, the operator can configure this PHB. For L-LSPs, it's determined as per RFC 3270 [23]. PHBs can be translated at network borders by the same function that translates them for user data traffic. This means CC-V fate-shares with much of the forwarding implementation, but not all aspects of PHB processing actually get exercised. So either on-demand tools are used for finer-grained fault finding, or an implementation may use a CC-V flow per PHB, so each CC-V flow fate-shares with its own PHB 💖.
In a co-routed or associated, bidirectional point-to-point transport path, when a MEP is enabled to generate proactive CC-V OAM packets with a configured transmission rate, it also expects to receive proactive CC-V OAM packets from its peer MEP at that same rate. This is because a common SLA applies to all components of the transport path 🤝. In a unidirectional transport path (point-to-point or point-to-multipoint), the source MEP is enabled only to generate CC-V OAM packets, and each sink MEP is configured to expect those packets at the configured rate.
MIPs, along with intermediate nodes that don't support MPLS-TP OAM, are transparent to the proactive CC-V information. They forward these packets as regular data packets 🦋.
During path setup and tear down, CC-V checks can give rise to alarms, because the path isn't fully instantiated yet 🚧. To avoid these spurious alarms, the following procedures are recommended. At initialization, the source MEP function (the one generating proactive CC-V packets) should be enabled before the corresponding sink MEP function (the one detecting continuity and connectivity defects). When disabling proactive CC-V functionality, the sink MEP function should be disabled before the corresponding source MEP function 🌸.
Different encapsulations are possible for CC-V packets. So with misconfigurations or mis-connectivity, CC-V packets might arrive with an unexpected encapsulation 🫣.
There are practical limitations to detecting an unexpected encapsulation. It's possible to have misconfiguration or mis-connectivity scenarios where OAM packets can alias as payload, for example when a transport path can carry an arbitrary payload without a pseudowire 🙃.
When CC-V packets arrive with an unexpected encapsulation that a sink MEP can parse, the CC-V packet is processed as if it had arrived with the correct encapsulation. If it isn't a manifestation of a mis-connectivity defect, a warning is raised (see Section 5.1.1.4). Otherwise, the CC-V packet may be silently discarded as unrecognized, and a LOC defect may be detected (see Section 5.1.1.1) 😭.
The defect conditions are described in no specific order.
5.1.1. Defects Identified by CC-V 🔥
Proactive CC-V functions let a sink MEP detect the defect conditions described in the subsections below. For all of the defect cases described, a sink MEP should notify the equipment fault management process of the detected defect 📣.
Sequential consecutive loss of CC-V packets is treated as an indication of an actual break, not congestive loss or physical-layer degradation. Losing 3 packets in a row (which implies a detection interval that is 3.5 times the insertion time) is interpreted as a true break, and it's a condition that won't clear by itself 💀.
A CC-V OAM packet is considered to carry an unexpected globally unique Source MEP identifier in three situations. It's a CC OAM packet received by a sink MEP monitoring the MEG for CV. It's a CV OAM packet received by a sink MEP monitoring the MEG for CC. Or it's a CV OAM packet received by a sink MEP monitoring the MEG for CV but carrying a unique Source MEP identifier that is different from the expected one. On the flip side, a CC-V packet is considered to have an expected globally unique Source MEP identifier when it's a CC OAM packet received by a sink MEP monitoring the MEG for CC, or when it's a CV OAM packet received by a sink MEP monitoring the MEG for CV that carries a unique Source MEP identifier equal to the expected one 🫶.
5.1.1.1. Loss of Continuity Defect 🕳️
When proactive CC-V is enabled, a sink MEP detects a loss of continuity (LOC) defect when it fails to receive proactive CC-V OAM packets from the source MEP.
- Entry criteria: No proactive CC-V OAM packets from the source MEP are received within the interval equal to 3.5 times the receiving MEP's configured CC-V reception period. In the case of CV, this includes the requirement to have the expected globally unique Source MEP identifier.
- Exit criteria: A proactive CC-V OAM packet from the source MEP is received. Again, in the case of CV, it has to carry the expected globally unique Source MEP identifier.
5.1.1.2. Mis-Connectivity Defect 🔀
When a proactive CC-V OAM packet is received, a sink MEP identifies a mis-connectivity defect (e.g., mismerge, misconnection, or unintended looping) when the received packet carries an unexpected globally unique Source MEP identifier.
- Entry criteria: The sink MEP receives a proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier, or with an unexpected encapsulation.
- Exit criteria: The sink MEP doesn't receive any proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with an unexpected globally unique Source MEP identifier since this defect was raised. This requires the OAM packet to self-identify the CC-V periodicity, since not all MEPs can be expected to know about all MEGs 🧠.
5.1.1.3. Period Misconfiguration Defect ⏱️
If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different from the locally configured reception period, a CC-V period misconfiguration defect is detected.
- Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different from its own CC-V-configured transmission period.
- Exit criteria: The sink MEP doesn't receive any proactive CC-V OAM packet with the expected globally unique Source MEP identifier and an incorrect transmission period for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with the expected globally unique Source MEP identifier and an incorrect transmission period since this defect was raised.
5.1.1.4. Unexpected Encapsulation Defect 🎁
If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with an unexpected encapsulation, a CC-V unexpected encapsulation defect is detected.
It should be noted that there are practical limitations to detecting an unexpected encapsulation (see Section 5.1.1) 🙈.
- Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with an unexpected encapsulation.
- Exit criteria: The sink MEP doesn't receive any proactive CC-V OAM packet with the expected globally unique Source MEP identifier and an unexpected encapsulation for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with the expected globally unique Source MEP identifier and an unexpected encapsulation since this defect was raised 🌷.
5.1.2. Consequent Action 💅
okay bestie, so a sink MEP that catches any of the defect conditions from Section 5.1.1 is like "not on my watch" 🙅♀️. It declares a defect condition and then runs through the consequent actions below 🫶
If a MEP detects a mis-connectivity defect, it blocks all the traffic (user data packets included 🙈) that it gets from the misconnected transport path. no cap, that's a hard block 💀
If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (user data packets included) coming from the transport path, but only if the operator has turned this consequent action on 🎀
It is worth noticing that the OAM requirements document [11] recommends that CC-V proactive monitoring be enabled on every MEG so connectivity defects get reliably detected ✨. BUT an operator can disable CC-V proactive monitoring for a MEG 🙃. So if a transport path that is proactively monitored for CC-V gets misconnected with one that isn't, the MEP on the monitored side will see a LOC defect that's really a connectivity problem (like a misconnection with a transport path where CC-V proactive monitoring is not enabled) instead of a continuity problem. The result? Traffic delivered to the wrong destination 😱. That's exactly why the traffic block action applies even when a LOC condition happens 🚫. This block action can be disabled through configuration. Turning the block off can be used for activating or deactivating the monitoring when it's not possible to synchronize the function activation of the two peer MEPs 🔁.
If a MEP detects a LOC defect (Section 5.1.1.1) or a mis-connectivity defect (Section 5.1.1.2), it declares a signal fail condition of the ME 🚨.
It is a matter of local policy whether or not a MEP that detects a period misconfiguration defect (Section 5.1.1.3) declares a signal fail condition of the ME 🤷♀️.
Detecting an unexpected encapsulation defect has no consequent action. It's just a warning for the network operator 📢. An implementation that can detect an unexpected encapsulation but can't verify the source MEP ID may choose to declare a mis-connectivity defect.
5.1.3. Configuration Considerations ⚙️
At all MEPs inside a MEG, the following configuration information needs to be configured when a proactive CC-V function is enabled:
- MEG-ID: the MEG identifier to which the MEP belongs.
- MEP-ID: the MEP's own identity inside the MEG.
- list of the other MEPs in the MEG: for a point-to-point MEG, the list would be the single MEP ID from which the OAM packets are expected. For the root MEP of a P2MP MEG, the list is all the leaf MEP IDs inside the MEG. For a leaf MEP of a P2MP MEG, the list is the root MEP ID (each leaf needs to know which root MEP ID it expects CC-V OAM packets from 🌳).
- PHB for E-LSPs: identifies the per-hop behavior of a CC-V packet. Proactive CC-V packets are transmitted with the "minimum loss probability PHB" previously configured within a single network operator. This PHB is configurable on the network operator's basis, and PHBs can be translated at the network borders 🌐.
- transmission rate: the default CC-V transmission periods depend on the application (fault management, performance monitoring, or protection switching) 🎯:
- Fault Management: default transmission period is
1 s(transmission rate of1 packet/second). - Performance Management: default transmission period is
100 ms(transmission rate of10 packets/second). CC-V helps with the accuracy of performance monitoring statistics by letting the defect-free periods be properly distinguished, as described in Sections 5.5.1 and 5.6.1 📊. - Protection Switching: if protection switching with CC-V and a defect entry criteria of
12 msis required (for example, alongside the requirement to support a50 msrecovery time as indicated in RFC 5654 [5]), then an implementation should use a default transmission period of3.33 ms(transmission rate of300 packets/second) ⚡. Sometimes the50 msrecovery time comes with a CC-V defect entry criteria of35 ms. In those cases, a transmission period of10 ms(transmission rate of100 packets/second) can be used. And when there's no need for such small defect entry criteria periods, a larger transmission period can be used 🫠.
- Fault Management: default transmission period is
It should be possible for the operator to configure these transmission rates for all applications, so they can satisfy specific network requirements 🧩.
Note that the reception period is the same as the configured transmission rate.
For management-provisioned transport paths, the above parameters are statically configured. For dynamically signaled transport paths, the configuration information is distributed via the control plane 📡.
The operator should be able to enable/disable some of the consequent actions. Which consequent actions can be enabled/disabled is described in Section 5.1.2 🔧.
5.2. Remote Defect Indication 📣
The Remote Defect Indication (RDI) function, as required in Section 2.2.9 of RFC 5860 [11], is an indicator transmitted by a sink MEP to tell its source MEP that a signal fail condition exists. For co-routed and associated bidirectional transport paths, RDI is tied to proactive CC-V, and the RDI indicator can be piggy-backed onto the CC-V packet 🎀. For unidirectional transport paths, the RDI indicator can only be sent using an out-of-band return path, if one exists and its usage is enabled by policy actions 🛤️.
When a MEP detects a signal fail condition (for example, in case of a continuity or connectivity defect), it should begin transmitting an RDI indicator to its peer MEP. When incorporated into CC-V, the RDI information will be included in all proactive CC-V packets that it generates for as long as the signal fail condition exists 🔁.
A MEP that receives packets from a peer MEP carrying the RDI information should determine that its peer MEP has encountered a defect condition associated with a signal fail condition 🙋♀️.
MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are transparent to the RDI indicator. They forward OAM packets that include the RDI indicator as regular data packets. In other words, the MIP should not perform any actions nor examine the indicator 👀.
When the signal fail condition clears, the MEP should stop transmitting the RDI indicator to its peer MEP. When incorporated into CC-V, the RDI indicator will not be set for subsequent transmissions of proactive CC-V packets. A MEP should clear the RDI defect upon reception of a cleared RDI indicator ✅.
5.2.1. Configuration Considerations ⚙️
To support RDI, the indication may be carried in a unique OAM packet or embedded in a CC-V packet. The in-band RDI transmission rate and PHB of the OAM packets carrying RDIs should be the same as that configured for CC-V. This lets both far-end and near-end defect conditions get resolved in a timeframe of the same order of magnitude 🕰️. That timeframe is application specific, as described in Section 5.1.3. How out-of-band RDIs are transmitted depends on the methods of the out-of-band return paths 🌈.
5.3. Alarm Reporting 🚨
The Alarm Reporting function, as required in Section 2.2.8 of RFC 5860 [11], relies on an Alarm Indication Signal (AIS) packet to suppress alarms after defect conditions are detected at the server (sub-)layer 🧚.
When a server MEP asserts a signal fail condition, it notifies the co-located MPLS-TP client/server adaptation function. That function then generates OAM packets with AIS information in the downstream direction, so secondary alarms can be suppressed at the MPLS-TP MEP in the client (sub-)layer 💅.
Generation of packets with AIS information starts immediately when the server MEP asserts a signal fail condition. These periodic OAM packets with AIS information keep getting transmitted until the signal fail condition is cleared 🔄.
It is assumed that, to avoid spurious alarm generation, a MEP detecting a loss of continuity defect (see Section 5.1.1.1) will wait for a hold-off interval before asserting an alarm to the management system ⏳. So when an MPLS-TP MEP receives an OAM packet with AIS information, it enters an AIS defect condition and suppresses reporting of alarms to the NMS about loss of continuity with its peer MEP. It does not block traffic received from the transport path 🙌. A MEP resumes loss of continuity alarm generation when it detects loss of continuity defect conditions in the absence of an AIS condition.
MIPs, as well as intermediate nodes, do not process AIS information. They forward these AIS OAM packets as regular data packets 📦.
Let's walk through an example! 🎬 Say there's a fiber cut between T-PE 1 and LSR 2 in the reference network of Figure 5. Assuming all of the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs ofSec12 SMEG,LSP13 LMEG,PW1 PSMEG, andPW1Z PMEG. But in a transport network, only the alarm associated with the fiber cut needs to be reported to an NMS, while all the secondary alarms should be suppressed (meaning not reported to the NMS, or reported only as secondary alarms) 🫶.
If the fiber cut is detected by the MEP in the physical layer (in LSR 2), LSR 2 can generate the proper alarm in the physical layer and suppress the secondary alarm associated with the LOC defect detected on Sec12 SMEG. Both MEPs live within the same node, so this doesn't involve any external protocol exchange 🏠. If the physical layer doesn't have enough OAM capabilities to detect the fiber cut, the MEP of Sec12 SMEG in LSR 2 will report a LOC alarm instead.
In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG. That function then generates AIS packets on LSP13 LMEG so its MEP in S-PE 3 can suppress the LOC alarm 🙈. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG, because the MEP of PW13 PSMEG resides within the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG, which then generates AIS packets on PW1Z PMEG so its MEP in T-PE Z can suppress the LOC alarm 💖.
Generation of AIS packets for each MEG in the MPLS-TP client (sub-)layer is configurable. In other words, the operator can enable or disable AIS generation 🎛️.
The AIS condition is cleared if no AIS packet has been received in 3.5 times the AIS transmission period ⏱️.
The AIS transmission period is traditionally one per second, but an option to configure longer periods would also be desirable. As a consequence, OAM packets need to self-identify the transmission period so that proper exit criteria can be established 🧠.
AIS packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on the network operator's basis. For L-LSPs, it is determined as per RFC 3270 [23] 🌸.
5.4. Lock Reporting 🔒✨
okay so the Lock Reporting function, the one required by Section 2.2.7 of RFC 5860 [11], is basically built around one packet: the Lock Report (LKR) 💌. Its whole job is to hush the alarms that pop off after someone administratively locks something in the server (sub-)layer. Main character energy for suppressing noise 🤫
When a server MEP gets locked, the MPLS-TP client (sub-)layer adaptation function starts generating packets with LKR information so the MEPs in the client (sub-)layer can suppress secondary alarms. ngl, we're assuming there's a hold-off for any loss of continuity alarms in the client-layer MEPs downstream of the node that originated the Lock Report 🕰️. For client (sub-)layer co-routed bidirectional transport paths, the LKR information goes out in both directions 🔁. For client (sub-)layer unidirectional transport paths, it only goes downstream ➡️. So for client (sub-)layer point-to-multipoint transport paths, the LKR information is only sent to the MEPs that are downstream from the server (sub-)layer that got administratively locked 💅. Client (sub-)layer associated bidirectional transport paths act like co-routed bidirectional ones if that locked server (sub-)layer is used by both directions. Otherwise, they act like unidirectional ones 🦋.
The generation of LKR packets starts immediately when the server MEP is locked 🚀. These periodic packets keep going until the locked condition is cleared 🫶.
When an MPLS-TP MEP receives a packet with LKR information, it enters an LKR defect condition 🙈. It suppresses the loss of continuity alarm tied to its peer MEP, but it does not block traffic received from the transport path. A MEP resumes loss of continuity alarm generation once it detects loss of continuity defect conditions without the LKR condition 💀.
MIPs and intermediate nodes don't process the LKR information. They just forward these LKR OAM packets like regular data packets 📦.
Let's look at an example 👀. Take the reference network of Figure 5, where the MPLS-TP Section between T-PE 1 and LSR 2 is administratively locked at LSR 2 (in both directions) 🔐.
Assuming all the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs of LSP13 LMEG, PW1 PSMEG, and PW1Z PMEG. However, in a transport network, all these secondary alarms should be suppressed (i.e., not reported to the NMS or reported as secondary alarms) 🧹.
The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG. That function then generates LKR packets on LSP13 LMEG so its MEPs in T-PE 1 and S-PE 3 can suppress the LOC alarm 💖. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG, because the MEP of PW13 PSMEG lives in the same node as the MEP of LSP13 LMEG 🧚. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG. That function then generates AIS packets on PW1Z PMEG so its MEP in T-PE Z can suppress the LOC alarm 🎀.
The generation of LKR packets for each MEG in the MPLS-TP client (sub-)layer is configurable. The operator can enable or disable LKR generation ⚙️.
The locked condition is cleared if no LKR packet has been received for 3.5 times the transmission period ⏳.
The LKR transmission period is traditionally one per second, but an option to configure longer periods would also be desirable 🙌. As a consequence, OAM packets need to self-identify the transmission period so proper exit criteria can be established 🧠.
LKR packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on the network operator's basis. For L-LSPs, it's determined as per RFC 3270 [23] 💜.
5.5. Packet Loss Measurement 📉💫
Packet Loss Measurement (LM) is one of the capabilities supported by the MPLS-TP Performance Monitoring (PM) function. It helps report Quality of Service (QoS) information for a transport path, as required in Section 2.2.11 of RFC 5860 [11] 📊. LM is used to exchange counter values for the number of ingress and egress packets transmitted and received by the transport path monitored by a pair of MEPs 🔢.
Proactive LM is performed by periodically sending LM OAM packets from a MEP to a peer MEP, and by receiving LM OAM packets from that peer MEP (if it's a co-routed or associated bidirectional transport path) for the whole lifetime of the transport path ⏱️. Each MEP measures its transmitted and received user data packets. These measurements get correlated in real time with the peer MEP in the ME, so we can figure out the impact of packet loss on a bunch of performance metrics for the ME in the MEG 🧮. The LM transactions are issued so the OAM packets experience the same PHB scheduling class as the measured traffic while they're transiting between the MEPs in the ME 🎯.
For a MEP, near-end packet loss refers to packet loss associated with incoming data packets (from the far-end MEP). Far-end packet loss refers to packet loss associated with egress data packets (towards the far-end MEP) 👈👉.
Proactive LM can be operated in two ways 🫧:
- One-way: a MEP sends an LM OAM packet to its peer MEP containing all the required information to facilitate near-end packet loss measurements at the peer MEP.
- Two-way: a MEP sends an LM OAM packet with an LM request to its peer MEP, which replies with an LM OAM packet as an LM response. The request/response LM OAM packets contain all the required information to facilitate both near-end and far-end packet loss measurements from the viewpoint of the originating MEP.
One-way LM is applicable to both unidirectional and bidirectional (co-routed or associated) transport paths, while two-way LM is applicable only to bidirectional (co-routed or associated) transport paths 🛤️.
MIPs and intermediate nodes don't process the LM information either. They forward these proactive LM OAM packets as regular data packets 📬.
5.5.1. Configuration Considerations 🛠️
To support proactive LM, the transmission rate and, for E-LSPs, the PHB class (associated with the LM OAM packets originating from a MEP) need to be configured as part of the LM provisioning 📝. LM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]), so the measurement stays as reliable as possible within the traffic class 🛡️.
If that PHB class isn't an ordered aggregate where the ordering constraint is that all packets with the PHB class get delivered in order, LM can produce inconsistent results 😬.
Performance monitoring (e.g., LM) is only relevant when the transport path is defect free. CC-V helps keep PM statistics accurate by letting the defect-free periods be properly distinguished 🧼. So, support of proactive LM has implications on the CC-V transmission period (see Section 5.1.3) 🔗.
5.5.2. Sampling Skew 🎢
If an implementation uses a hardware forwarding path that runs in parallel with an OAM processing path, whether hardware or software based, the packet and byte counts may be skewed. That happens if one or more packets can be processed before the OAM processing samples the counters. If OAM is implemented in software, this error can get pretty big 😵💫.
5.5.3. Multilink Issues 🧵
If multilink is used at the ingress or egress of a transport path, there may not be a single packet-processing engine where an LM packet can be injected or extracted as an atomic operation while still having accurate packet and byte counts associated with the packet 🙃.
If multilink is encountered along the route of the transport path, reordering of packets within the transport path can cause inaccurate LM results 🌀.
5.6. Packet Delay Measurement ⏰🩵
Packet Delay Measurement (DM) is one of the capabilities supported by the MPLS-TP PM function. It helps report QoS information for a transport path, as required in Section 2.2.12 of RFC 5860 [11] 📈. Specifically, proactive DM is used to measure the long-term packet delay and packet delay variation in the transport path monitored by a pair of MEPs 🐢.
Proactive DM is performed by sending periodic DM OAM packets from a MEP to a peer MEP, and by receiving DM OAM packets from that peer MEP (if it's a co-routed or associated bidirectional transport path) during a configurable time interval ⌛.
Proactive DM can be operated in two ways 🫧:
- One-way: a MEP sends a DM OAM packet to its peer MEP containing all the required information to facilitate one-way packet delay and/or one-way packet delay variation measurements at the peer MEP. Note that this requires precise time synchronization at either MEP, by means outside the scope of this framework ⏲️.
- Two-way: a MEP sends a DM OAM packet with a DM request to its peer MEP, which replies with a DM OAM packet as a DM response. The request/response DM OAM packets contain all the required information to facilitate two-way packet delay and/or two-way packet delay variation measurements from the viewpoint of the originating MEP.
One-way DM is applicable to both unidirectional and bidirectional (co-routed or associated) transport paths, while two-way DM is applicable only to bidirectional (co-routed or associated) transport paths 🛤️.
MIPs and intermediate nodes don't process the DM information. They forward these proactive DM OAM packets as regular data packets 📦.
5.6.1. Configuration Considerations 🛠️
To support proactive DM, the transmission rate and, for E-LSPs, the PHB (associated with the DM OAM packets originating from a MEP) need to be configured as part of the DM provisioning 📝. DM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]) 🛡️.
Performance monitoring (e.g., DM) is only relevant when the transport path is defect free. CC-V helps keep PM statistics accurate by letting the defect-free periods be properly distinguished 🧼. So, support of proactive DM has implications on the CC-V transmission period (see Section 5.1.3) 🔗.
5.7. Client Failure Indication 💌
okay so the Client Failure Indication (CFI) function, which is required in Section 2.2.10 of RFC 5860 [11], is basically how we deal with client defects 🚨. It takes a client signal defect condition and passes it along from the process tied to the local attachment circuit where the defect was spotted (usually the source adaptation function for the local client interface) 💅. Then it gets sent to the process on the far-end attachment circuit (usually the source adaptation function for the far-end client interface) for that same transmission path. The reason? In case the transport path's client doesn't have a native defect or alarm mechanism, like AIS 🫶.
A source MEP starts sending a CFI to its peer MEP as soon as it gets a local client signal defect notification through its local client signal fail indication 🔥. How it spots local client signal fail defects is technology specific, and so is the way it decides to stop sending client signal fail indication 🦋.
A sink MEP that gets a CFI reports the condition to its associated client process through its local CFI function 💖. What happens next toward the client attachment circuit is technology specific 🌸.
There needs to be a 1:1 correspondence between the client and the MEG 👑. If you don't have that, and multiple clients are multiplexed over one transport path, then the CFI packet needs extra info so the client instance can be identified 😭.
MIPs and intermediate nodes don't process the CFI information at all ✨. They just forward these proactive CFI OAM packets like regular data packets 🧚.
5.7.1. Configuration Considerations 🎀
To support CFI indication, you SHOULD configure the CFI transmission rate as part of the CFI config, and for E-LSPs, the PHB of the CFI OAM packets too 💜.
6. OAM Functions for On-Demand Monitoring ✨
Proactive monitoring is the always-on stuff, but on-demand monitoring is started manually and only runs for a limited amount of time 🕰️. It's usually for diagnostics, like when you're trying to figure out what's going on with a defect 🔍.
On-demand monitoring covers a mix of "in-service" and "out-of-service" monitoring functions. Here's what that means for control and measurement:
- A MEG can be told to run an "on-demand" function at any arbitrary time during the life of a transport path 💫.
- "Out-of-service" monitoring functions may need a priori configuration of both MEPs and intermediate nodes in the MEG (for example, data-plane loopback), plus sending notifications up into the client layers of the transport path that's being taken out of service (for example, lock reporting) 🔒.
- Measurements from "on-demand" monitoring usually get harvested in real time, since they're often started manually 🍓. They don't necessarily need different harvesting mechanisms than proactive monitoring telemetry does 🌈.
The functions that are strictly out-of-service are the ones in Section 6.3 💅. Everything else works for both in-service and out-of-service transport paths 🫶.
6.1. Connectivity Verification 🔗
The on-demand connectivity verification function, which is required in Section 2.2.3 of RFC 5860 [11], is a transaction that flows from the originating MEP to a target MIP or MEP. Its job is to verify the connectivity between those points 💖.
Using on-demand CV depends on having a bidirectional ME, or an associated return ME, or an out-of-band return path available 🛤️. That's because target MIPs and MEPs need to be able to send their responses back to the originating MEPs 🦋.
One possible use of on-demand CV is doing fault management without proactive CC-V, so you save network resources like bandwidth and processing time on switches 🧠. In that case, network management invokes on-demand CV on a regular schedule ⏰.
Another use is detecting and locating a connectivity problem when it's suspected or already known from other tools 🕵️♀️. Here, network management triggers the function in response to a status signal or an alarm indication 🚨.
On-demand CV works by generating on-demand CV packets that SHOULD uniquely identify the MEG being checked 🪪. This can check either the whole MEG end-to-end, or just between the originating MEP and a specific MIP 🎯. It might not be available for associated bidirectional transport paths or for unidirectional paths, since the MIP might not have a return path to the originating MEP for the on-demand CV transaction 🙈.
When on-demand CV gets invoked, the originating MEP sends a sequence of on-demand CV packets that uniquely identifies the MEG being verified 🌟. The number of packets and how fast they go out SHOULD be pre-configured at the originating MEP, so the setup accounts for normal packet-loss conditions 🧮. The source MEP SHOULD use the mechanisms defined in Sections 3.3 and 3.4 when it sends an on-demand CV packet to a target MEP or target MIP, respectively 🗂️. The target MEP/MIP SHALL return a reply on-demand CV packet for every packet it receives 📬. If the originating MEP doesn't get the expected number of on-demand CV reply packets, that's a sign a connectivity problem may exist 🚩.
On-demand CV SHOULD have the ability to carry padding, so a variety of MTU sizes can be originated to check the MTU transport capability of the transport path 📏.
MIPs that aren't targeted by on-demand CV packets, along with intermediate nodes, don't process the CV information. They forward these on-demand CV OAM packets like regular data packets 🏃♀️.
6.1.1. Configuration Considerations 🎀
For on-demand CV, the originating MEP SHOULD support configuring the number of packets to be sent and received in each sequence of transmissions, along with their packet size 📦.
Also, when the CV packet is used to check connectivity toward a target MIP, the number of hops needed to reach that target MIP SHOULD be configured 🪜.
For E-LSPs, the PHB of the on-demand CV packets SHOULD be configured as well 💅. That way you can verify both correct QoS queuing and connectivity 🧪.
6.2. Packet Loss Measurement 📉
On-demand Packet Loss Measurement (LM) is one of the capabilities of the MPLS-TP Performance Monitoring function 💜. It helps diagnose QoS performance for a transport path, as required in Section 2.2.11 of RFC 5860 [11] 🔬.
On-demand LM is super similar to the proactive LM in Section 5.5 👯♀️. This section just covers how on-demand and proactive LM are different 🤍.
On-demand LM works by periodically sending LM OAM packets from a MEP to a peer MEP, and receiving LM OAM packets back from that peer MEP (if it's a co-routed or associated bidirectional transport path) during a predefined monitoring period 📡. Each MEP measures the user data packets it sends and receives 📊. Those measurements then get correlated to evaluate the packet-loss performance metrics of the transport path 🧩.
Using packet loss measurement on an out-of-service transport path needs a traffic source, like a test device that can inject synthetic traffic 🧑🔬.
6.2.1. Configuration Considerations 🎀
To support on-demand LM, the start time and duration of the LM procedures, the transmission rate, and, for E-LSPs, the PHB class (for the LM OAM packets coming from a MEP) MUST be configured as part of the on-demand LM provisioning 🗓️. LM OAM packets SHOULD be sent with the PHB that gives the lowest drop precedence, as described in Section 5.5.1 🛡️.
6.2.2. Sampling Skew 🌀
All the same considerations from Section 5.5.2 for proactive LM also apply to on-demand LM implementations 🫧.
6.2.3. Multilink Issues 🔀
Multilink issues work the same way as described in Section 5.5.3 🧵.
6.3. Diagnostic Tests 🩺
Diagnostic tests are tests run on a MEG that's been taken out of service 🚧.
6.3.1. Throughput Estimation 🚀
Throughput estimation is an on-demand out-of-service function, required in Section 2.2.5 of RFC 5860 [11]. It lets you check the bandwidth and throughput of an MPLS-TP transport path (LSP or PW) before it goes back into service 💨.
Throughput estimation runs between MEPs, and between a MEP and a MIP 🤝. It can be done in one-way or two-way modes ↔️.
According to RFC 2544 [12], this test sends OAM test packets at increasing rates (up to the theoretical maximum), works out what percentage of those OAM test packets get received, and reports the rate where OAM test packets start to drop 📈. Generally, that rate depends on the OAM test packet size 📏.
When it's set up to do these tests, a source MEP inserts OAM test packets with a specified packet size and transmission pattern, at a rate that exercises the throughput 🏋️♀️.
The throughput test can cause congestion inside the network, which can affect other transport paths 😬. But the test traffic SHOULD comply with the traffic profile of the transport path under test, so the test's impact is never worse than what customers would cause by sending traffic at the max rate their traffic profiles allow 💁♀️. For that reason, throughput tests don't apply to transport paths without a defined traffic profile, like LSPs where statistical multiplexing is used for network capacity dimensioning 🙅♀️.
In a one-way test, the remote sink MEP receives the OAM test packets and calculates the packet loss 📥. In a two-way test, the remote MEP loops the OAM test packets back to the original MEP, and the local sink MEP calculates the packet loss 🔁.
Here's a fun fact: two-way throughput estimation only works on bidirectional (co-routed or associated) transport paths, and it can only tell you the minimum available throughput of the two directions 🫣. To figure out each direction's throughput on its own, you need to set up two one-way throughput estimation sessions 🎯. One-way throughput estimation needs the transmitting and receiving test devices to coordinate, as described in Section 6 of RFC 2544 [12] 🤙.
Also worth noting: if throughput estimation runs on transport paths that go through oversubscribed links, the test might not give comprehensive results when you look at it alone, because you also need to consider how the test affects the surrounding traffic 🌊. And the estimate only reflects the bandwidth that's available at the moment the measurement is taken ⏱️.
MIPs that aren't targeted by on-demand test OAM packets, along with intermediate nodes, don't process the throughput test information. They forward these on-demand test OAM packets like regular data packets 💫.
6.3.1.1. Configuration Considerations 🔧
okay so throughput estimation is an out-of-service tool 🚧, which means the diagnosed MEG should be put into a locked state before the diagnostic test is started. no skipping this one bestie 🔒
a MEG can be put into a locked state either via an NMS action or using the Lock Instruct OAM tool as defined in Section 7. two cute options, pick your fave 💖
at the transmitting MEP, provisioning is required for a test signal generator that is associated with the MEP. at a receiving MEP, provisioning is required for a test signal detector that is associated with the MEP. so both ends need their own test gear set up, the sender and the detector 📡✨
in order to ensure accurate measurement, care needs to be taken to enable throughput estimation only if all the MEPs within the MEG can process OAM test packets at the same rate as the payload data rates (see Section 6.3.1.2). this is the part where people get sloppy and then wonder why their numbers are wrong 🙈
6.3.1.2. Limited OAM Processing Rate 🐢
so if an implementation can process payload at a much higher data rate than it can handle OAM test packets, then accurate throughput measurement using OAM test packets is not achievable. the OAM test packets just can't keep up 😭
whether OAM packets can be processed at the same rate as payload is implementation dependent. it depends on the box, so check what yours can actually do 💅
6.3.1.3. Multilink Considerations 🔗
if multilink is used, then it may not be possible to perform throughput measurement, as the throughput test may not have a mechanism for utilizing more than one component link of the aggregated link. so the test might only be able to use one link out of the bundle, and that's a whole vibe check 🫠
6.3.2. Data-Plane Loopback 🔁
okay this one is giving main character energy ✨. data-plane loopback is an out-of-service function, as required in Section 2.2.5 of RFC 5860 [11]. it means placing a transport path, at either an intermediate or terminating node, into a data-plane loopback state. once it's there, all traffic (including both payload and OAM) received on the looped back interface gets sent back out the reverse direction of the transport path 🪞
the traffic is looped back unmodified except for normal per-hop processing such as TTL decrement. so it's basically a mirror, just with the usual hop stuff happening 💜
the data-plane loopback function requires that the MEG is locked such that user data traffic is prevented from entering or exiting that MEG. instead, test traffic is inserted at the ingress of the MEG. this test traffic can be generated from an internal process residing within the ingress node, or injected by external test equipment connected to the ingress node 🧪
it is also normal to disable proactive monitoring of the path, because the MEP located upstream with respect to the node set in the data-plane loopback mode will see all the OAM packets originated by itself. that can interfere with other measurements, and nobody wants that drama 🙃
the only way to send an OAM packet (e.g., to remove the data-plane loopback state) to the MIPs or MEPs hosted by a node set in the data-plane loopback mode is via TTL expiry. also, MIPs can be addressed with more than one TTL value on a co-routed bidirectional path set into data-plane loopback. yes that's a lot of TTL energy, iykyk 🫣
if the loopback function is to be performed at an intermediate node, it is only applicable to co-routed bidirectional paths. if the loopback is to be performed end to end, it is applicable to both co-routed bidirectional and associated bidirectional paths. so the path type decides where you can do this 🗺️
it should be noted that the data-plane loopback function itself is applied to data-plane loopback points that can reside on different interfaces from MIPs/MEPs. where a node implements data-plane loopback capability, and whether it implements it in more than one point, is implementation dependent. so the loopback spots can live on different interfaces than the MIPs and MEPs, and the rest is up to the implementation 🤷♀️
6.3.2.1. Configuration Considerations ⚙️
data-plane loopback is an out-of-service tool. the MEG that defines a diagnosed transport path should be put into a locked state before the diagnostic test is started. however, a means is required to permit the originated test traffic to be inserted at the ingress MEP when data-plane loopback is performed. so you lock it, but you still need a way to let your test traffic in, which is very ironic but also very necessary 🥹
a transport path, at either an intermediate or terminating node, can be put into data-plane loopback state via an NMS action or using an OAM tool for data-plane loopback configuration. two ways to flip the switch ✨
if the data-plane loopback point is set somewhere at an intermediate point of a co-routed bidirectional transport path, the side of the loopback function (east/west side or both sides) needs to be configured. so pick the side, or both sides, and be intentional about it 🧭
6.4. Route Tracing 🗺️
it is often necessary to trace a route covered by a MEG from an originating MEP to the peer MEP(s), including all the MIPs in between. this may be conducted after provisioning an MPLS-TP transport path for, e.g., troubleshooting purposes such as fault localization. basically it's how you find out where things went wrong 🕵️♀️
the route tracing function, as required in Section 2.2.4 of RFC 5860 [11], is providing this functionality. based on the fate-sharing requirement of OAM flows, i.e., OAM packets receive the same forwarding treatment as data packets, route tracing is a basic means to perform connectivity verification and, to a much lesser degree, continuity check. for this function to work properly, a return path must be present. no return path, no route tracing, periodt 🔙
route tracing might be implemented in different ways, and this document does not preclude any of them. so the door is open for lots of flavours 🍦
route tracing should always discover the full list of MIPs and of peer MEPs. in case a defect exists, the route tracing function will only be able to trace up to the defect. it needs to be able to return the incomplete list of OAM entities that it was able to trace, so that the fault can be localized. so even a half-finished trace is still useful, because it shows you exactly where the trouble starts 🧩
6.4.1. Configuration Considerations 🎛️
the configuration of the route tracing function must at least support the setting of the number of trace attempts before it gives up. so you need to be able to set how many tries it gets before it quits 🫡
6.5. Packet Delay Measurement ⏱️
Packet Delay Measurement (DM) is one of the capabilities supported by the MPLS-TP PM function. it facilitates reporting of QoS information for a transport path, as required in Section 2.2.12 of RFC 5860 [11]. specifically, on-demand DM is used to measure packet delay and packet delay variation in the transport path monitored by a pair of MEPs during a pre-defined monitoring period. it's the timing gossip, and it's so important 💅
on-demand DM is performed by sending periodic DM OAM packets from a MEP to a peer MEP, and by receiving DM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a configurable time interval. so both sides are chatting back and forth on a schedule 💬
on-demand DM can be operated in two modes:
- One-way: a MEP sends a DM OAM packet to its peer MEP containing all the required information to facilitate one-way packet delay and/or one-way packet delay variation measurements at the peer MEP. note that this requires precise time synchronization at either MEP by means outside the scope of this framework. ⏰ so the clocks have to be in sync, and that part is handled somewhere else
- Two-way: a MEP sends a DM OAM packet with a DM request to its peer MEP, which replies with a DM OAM packet as a DM response. the request/response DM OAM packets contain all the required information to facilitate two-way packet delay and/or two-way packet delay variation measurements from the viewpoint of the originating MEP. ping pong energy 🏓
MIPs, as well as intermediate nodes, do not process the DM information. they forward these on-demand DM OAM packets as regular data packets. so they're just passing the notes along, no reading allowed 📬
6.5.1. Configuration Considerations 📝
in order to support on-demand DM, the beginning and duration of the DM procedures, the transmission rate and, for E-LSPs, the PHB (associated with the DM OAM packets originating from a MEP) need to be configured as part of the DM provisioning. that's a whole checklist 📋
DM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]). so the lowest drop precedence is the move here, and RFC 3260 [17] has the receipts 🧾
in order to verify different performances between long and short packets (e.g., due to the processing time), it should be possible for the operator to configure the packet size of the on-demand OAM DM packet. long and short packets can behave differently, so being able to pick the size is a must-have 📏✨
7. OAM Functions for Administration Control 🔐
7.1. Lock Instruct 🔒
the Lock Instruct (LKI) function, as required in Section 2.2.6 of RFC 5860 [11], is a command allowing a MEP to instruct the peer MEP(s) to put the MPLS-TP transport path into a locked condition. it's basically a "hey, we're locking this" message 🫶
this function allows single-side provisioning for administratively locking (and unlocking) an MPLS-TP transport path. so you can set it up from just one side, which is very convenient 💖
note that it is also possible to administratively lock (and unlock) an MPLS-TP transport path using two-side provisioning, where the NMS administratively puts both MEPs into an administrative lock condition. in this case, the LKI function is not required or used. so if you're doing both sides from the NMS, LKI can sit this one out 🪑
MIPs, as well as intermediate nodes, do not process the Lock Instruct information. they forward these on-demand LKI OAM packets as regular data packets. same energy as before: just passing it along 📨
7.1.1. Locking a Transport Path 🔐
a MEP, upon receiving a single-side administrative lock command from an NMS, sends an LKI request OAM packet to its peer MEP(s). it also puts the MPLS-TP transport path into a locked state, and notifies its client (sub-)layer adaptation function upon the locked condition. so it locks itself and tells the layer below about it 📣
a MEP, upon receiving an LKI request from its peer MEP, can either accept or reject the instruction. it replies to the peer MEP with an LKI reply OAM packet indicating whether or not it has accepted the instruction. this requires either an in-band or out-of-band return path. the LKI reply is needed to allow the MEP to properly report to the NMS the actual result of the single-side administrative lock command. so the reply is how the NMS finds out if it worked 🙌
if the lock instruction has been accepted, it also puts the MPLS-TP transport path into a locked state and notifies its client (sub-)layer adaptation function upon the locked condition. same move on this side 🔒
note that if the client (sub-)layer is also MPLS-TP, Lock Report (LKR) generation at the client MPLS-TP (sub-)layer is started, as described in Section 5.4. so the layer above starts sending Lock Reports, and that's a whole chain reaction 🔗
7.1.2. Unlocking a Transport Path 🔓
a MEP, upon receiving a single-side administrative unlock command from NMS, sends an LKI removal request OAM packet to its peer MEP(s). so unlocking starts with a removal request, not a lock ✂️
the peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction. it replies with an LK removal reply OAM packet indicating whether or not it has accepted the instruction. the LKI removal reply is needed to allow the MEP to properly report to the NMS the actual result of the single-side administrative unlock command. same deal as the lock reply, just flipped 🔄
if the lock removal instruction has been accepted, it also clears the locked condition on the MPLS-TP transport path and notifies its client (sub-)layer adaptation function of this event. so the lock comes off on this side too 🎉
the MEP that has initiated the LKI clear procedure, upon receiving a positive LKI removal reply, also clears the locked condition on the MPLS-TP transport path and notifies this event to its client (sub-)layer adaptation function. so the originator clears its own lock once the reply comes back positive 🥳
note that if the client (sub-)layer is also MPLS-TP, Lock Report (LKR) generation at the client MPLS-TP (sub-)layer is terminated, as described in Section 5.4. so the Lock Reports stop, and everyone's free again 🦋
8. Security Considerations 🔐✨
Okay bestie, this part is serious, so put your listening ears on 👂 A bunch of security considerations matter for OAM applications, and you need to be obsessed with all of them.
OAM traffic can literally leak sensitive stuff like performance data and details about what the network looks like right now 👀 Inserting or modifying OAM transactions can mask the true operational state of the network. For administration control transactions, like lock or data-plane loopback instructions, those same tricks can be used for explicit denial-of-service attacks 💀 The only thing that softens this is the fate-sharing nature of OAM messaging. For in-band messaging, the managed entities whose state can be masked are limited to the ones that transit the point of malicious access to the network internals. That protection disappears when an out-of-band return path is employed 😭
So the sensitivity of OAM data suggests that one solution is some form of authentication, authorization, and encryption. This blocks unauthorized access to vital equipment and stops third parties from learning sensitive information about the transport network 🔒 Here's the catch though: between how often some OAM transactions happen, how fast OAM transaction exchange needs to be, and every permutation of unique MEP to MEP, MEP to MIP, and intermediate-system-originated transaction, setting up and maintaining a large number of security associations per MEG is not practical, whether you do it ahead of time or as required 🙅♀️
For this reason, it is assumed that the internal links of the network are physically secured from malicious access. That way, OAM transactions scoped to fault and performance management of individual MEGs don't need extra security 🧱 It's also assumed that, in multi-provider cases where OAM transactions originate outside of an individual provider's trusted domain, filtering mechanisms or further encapsulation will need to constrain the potential impact of malicious transactions 🛡️ Mechanisms that the framework does not specify might be subject to additional security considerations 👀
In case of misconfiguration, some nodes can receive OAM packets that they cannot recognize. In that situation, these OAM packets should be silently discarded, so you avoid malfunctions whose effects may look similar to malicious attacks, like degraded performance or even failure 😩 Further considerations about data-plane attacks via G-ACh are provided in RFC 5921 [8] 🦋
9. Acknowledgments 🫶
The authors wanted to thank all the teams who helped define and specify the MPLS Transport Profile: the Joint Working Team, the MPLS Interoperability Design Team in IETF, and the Ad Hoc Group on MPLS-TP in ITU-T 💜
The editors gratefully acknowledge the contributions of Adrian Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio, and Manuel Paul for the definition of per-interface MIPs and MEPs 🙌
The editors gratefully acknowledge the contributions of Malcolm Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the Lock Report and Lock Instruct descriptions 🔐
The authors would also like to thank Alessandro D'Alessandro, Loa Andersson, Malcolm Betts, Dave Black, Stewart Bryant, Rui Costa, Xuehui Dai, John Drake, Adrian Farrel, Dan Frost, Xia Liang, Liu Gouman, Peng He, Russ Housley, Feng Huang, Su Hui, Yoshionori Koike, Thomas Morin, George Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers, and Xuequin Wei for their comments and enhancements to the text ✨🎀
10. References 📚
10.1. Normative References
- [1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [2] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
- [3] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
- [4] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
- [5] 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.
- [6] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
- [7] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
- [8] 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.
- [9] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile User-to-Network and Network-to-Network Interfaces", RFC 6215, April 2011.
- [10] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
- [11] 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.
- [12] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
- [13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
- [14] ITU-T Recommendation G.806 (01/09), "Characteristics of transport equipment - Description methodology and generic functionality", January 2009.
10.2. Informative References
- [15] Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for MPLS based Transport Networks", Work in Progress, June 2011.
- [16] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [17] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
- [18] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
- [19] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node interface for the synchronous digital hierarchy (SDH)", January 2007.
- [20] ITU-T Recommendation G.805 (03/00), "Generic functional architecture of transport networks", March 2000.
- [21] ITU-T Recommendation Y.1731 (02/08), "OAM functions and mechanisms for Ethernet based networks", February 2008.
- [22] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", November 2008.
- [23] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
- [24] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
- [25] Winter, R., Ed., van Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", Work in Progress, July 2011.
11. Contributing Authors 🎀
Ben Niven-Jenkins Velocix EMail: ben@niven-jenkins.co.uk
Annamaria Fulignoli Ericsson EMail: annamaria.fulignoli@ericsson.com
Enrique Hernandez-Valencia Alcatel-Lucent EMail: Enrique.Hernandez@alcatel-lucent.com
Lieven Levrau Alcatel-Lucent EMail: Lieven.Levrau@alcatel-lucent.com
Vincenzo Sestito Alcatel-Lucent EMail: Vincenzo.Sestito@alcatel-lucent.com
Nurit Sprecher Nokia Siemens Networks EMail: nurit.sprecher@nsn.com
Huub van Helvoort Huawei Technologies EMail: hhelvoort@huawei.com
Martin Vigoureux Alcatel-Lucent EMail: Martin.Vigoureux@alcatel-lucent.com
Yaacov Weingarten Nokia Siemens Networks EMail: yaacov.weingarten@nsn.com
Rolf Winter NEC EMail: Rolf.Winter@nw.neclab.eu
Authors' Addresses 💖
Dave Allan Ericsson EMail: david.i.allan@ericsson.com
Italo Busi Alcatel-Lucent EMail: Italo.Busi@alcatel-lucent.com
📦 where this page comes from
- ietf: rfc6371 2011-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms