Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)
Guidelines for addressing maintenance checkpoints on network interfaces in carrier-grade MPLS.
Farrel, A., Endo, H., Winter, R., Koike, Y., and M. Paul, "Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)", RFC 7054, DOI 10.17487/RFC7054, November 2013, <https://www.rfc-editor.org/info/rfc7054>.
@misc{rfc7054,
series = {Request for Comments},
number = 7054,
howpublished = {RFC 7054},
publisher = {RFC Editor},
doi = {10.17487/RFC7054},
url = {https://www.rfc-editor.org/info/rfc7054},
author = {A. Farrel and H. Endo and R. Winter and Y. Koike and M. Paul},
title = {{Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)}},
pagetotal = 11,
year = 2013,
month = nov,
} RFC text
Contents
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7054 Juniper Networks
Category: Informational H. Endo
ISSN: 2070-1721 Hitachi, Ltd.
R. Winter
NEC
Y. Koike
NTT
M. Paul
Deutsche Telekom
November 2013
Addressing Requirements and Design Considerations for
Per-Interface Maintenance Entity Group Intermediate Points (MIPs)
Abstract
The framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) describes how the
Maintenance Entity Group Intermediate Points (MIPs) may be situated
within network nodes at incoming and outgoing interfaces.
This document elaborates on important considerations for internal MIP
addressing. More precisely, it describes important restrictions for
any mechanism that specifies a way of forming OAM messages so that
they can be targeted at MIPs on either incoming or outgoing
interfaces and forwarded correctly through the forwarding engine.
Furthermore, the document includes considerations for node
implementations where there is no distinction between the incoming
and outgoing MIP.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7054.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Summary of the Problem Statement ................................3
4. Requirements and Design Considerations for Internal-MIP
Addressing ......................................................6
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
1. Introduction
The framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM
Framework, [RFC6371]) distinguishes two configurations for the
Maintenance Entity Group Intermediate Points (MIPs) on a node. It
defines per-node MIPs and per-interface MIPs, where a per-node MIP is
a single MIP per node in an unspecified location within the node and
per-interface MIPs are two (or more) MIPs per node on each side of
the forwarding engine.
In-band OAM messages are sent using the Generic Associated Channel
(G-ACh) [RFC5586]. OAM messages for the transit points of
pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using
the expiration of the MPLS shim header Time-to-Live (TTL) field. OAM
messages for the end points of PWs and LSPs are simply delivered as
normal.
OAM messages delivered to end points or transit points are
distinguished from other (data) packets so that they can be processed
as OAM. In LSPs, the mechanism used is the presence of the Generic
Associated Channel Label (GAL) in the Label Stack Entry (LSE) under
the top LSE [RFC5586]. In PWs, the mechanism used is the presence of
the PW Associated Channel Header (PWACH) [RFC4385] or the presence of
a GAL [RFC6423].
If multiple MIPs are present on a single node, these mechanisms alone
provide no way to address one particular MIP out of the set of MIPs.
A mechanism that addresses this shortcoming has to obey a few
important design considerations, which are discussed in this
document.
2. Terminology
In this document, we use the term in-MIP (incoming MIP) to refer to
the MIP that processes OAM messages before they pass through the
forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM
messages after they have passed the forwarding engine of the node.
The two together are referred to as internal MIPs. The term
"forwarding engine" is used as defined in [RFC6371].
Note that the acronym "OAM" is used in conformance with [RFC6291].
3. Summary of the Problem Statement
Figure 1 shows an abstract functional representation of an MPLS-TP
node. It is decomposed as an incoming interface (labeled "In"), a
forwarding engine (FW), and an outgoing interface (labeled "Out").
As per the discussion in [RFC6371], MIPs may be placed in each of the
functional interface components.
------------------------
|----- -----|
| MIP | | MIP |
| | ---- | |
----->-| In |->-| FW |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
Figure 1: Abstract Functional Representation of an MPLS-TP Node
Several distinct OAM functions are required within this architectural
model for both PWs and LSPs, such as:
o Connectivity Verification (CV) between a Maintenance Entity Group
End Point (MEP) and a MIP
o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing
MIPs
o data-plane loopback configuration at a MIP
o diagnostic tests
The MIPs in these OAM functions may also be the MIPs at the incoming
or outgoing interfaces.
Per-interface MIPs have the advantage that they enable a more
accurate localization and identification of faults and diagnostic
tests. In particular, the identification of whether a problem is
located between nodes or on a particular node and where on that node
is greatly enhanced. For obvious reasons, it is important to narrow
down the cause of a fault quickly to initiate a timely and well-
directed maintenance action to resume normal network operation.
The following two figures illustrate the fundamental difference
between using per-node and per-interface MEPs and MIPs for OAM.
Figure 2 depicts OAM using per-node MIPs and MEPs. For reasons of
exposition, we pick a location for the MIPs on the nodes but the
standard does not mandate the exact location for the per-node model.
In the figure, a bidirectional LSP is depicted where in the forward
(FWD) direction MEP1, MIP1, and MEP2 are located on the ingress
interface. In the backward (BWD) direction MEP1', MIP1' and MEP2'
are located on the egress interface, i.e., the same interfaces. S1
in the figure denotes the segment from PE1 In to P1 In and S2 denotes
the segment from PE1 In to P2 In. Figure 3, on the other hand, shows
the same basic network, but per-interface maintenance points are
configured for OAM operations. Note that these figures are merely
examples. It is important to note that per-interface MEPs or per-
interface MIPs must logically be placed at a point before (for
in-MIP) or after (for out-MIP) passing the forwarding engine as
defined in [RFC6371]. All traffic associated with the MEP/MIP must
pass through or be terminated at that point.
Customer| Operator's Administrative | Customer
Domain | Domain | Domain
------> |<--------------------------------------->| <------
CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD PW/LSP | o-------------------------- > |
| V-------------*-------------V |
| MEP1 MIP1 MEP2 |
BWD PW/LSP | <---------------------------o |
| V-------------*-------------V |
| MEP1' MIP1' MEP2'|
(S1)<============>
(S2)<==========================>
Figure 2: Example of OAM Relying on Per-Node MIPs and MEPs
To illustrate the difference between these two modes of operation, we
use fault detection as an example. Consider the case where the
client traffic between CE1 and CE2 experiences a fault. Also assume
that an on-demand CV test between PE1 and PE2 was successful. The
scenario in Figure 2 therefore leaves the forwarding engine (FW) of
PE2, the out-going interface of PE2, the transmission line between
PE2 and CE2, or CE2 itself as a potential location of the fault as
on-demand CV can only be performed on segment S2. Note that in this
scenario, the PWs or LSPs are to be understood as two examples (not
one), i.e., the figures do not show the layer structure of PWs and
LSPs.
The per-interface model in Figure 3 allows more fine-grained OAM
operations to be performed. At first, CV on segment S'4 and in
addition CV on segment S'5 can help to rule out, for example, the
forwarding engine of PE2. This is of course only a single example,
and other OAM functions and scenarios are trivially conceivable. The
basic message is that with the per-interface OAM model, an operator
can configure smaller segments on a transport path to which OAM
operations apply. This enables a more fine-grained scoping of OAM
operations, such as fault localization and performance monitoring,
which gives operators better information to deal with adverse
networking conditions.
Customer| Operator's Administrative |Customer
Domain | Domain |Domain
------->|<--------------------------------------->|<------
CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD PW/LSP | o-----------------------------------> |
| V-------*------*------*-----*-------V |
| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2|
| |
BWD PW/LSP | <-----------------------------------o |
| MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'|
(S'1)<======>
(S'2)<=============>
(S'3)<====================>
(S'4)<==========================>
(S'5)<==================================>
Figure 3: Example of OAM Relying on Per-Interface MIPs and MEPs
4. Requirements and Design Considerations for Internal-MIP Addressing
OAM messages for transit points of PWs or LSPs are delivered using
the expiration of the TTL field in the top LSE of the MPLS packet
header. OAM messages for the end points of PWs and LSPs are simply
delivered as normal. These messages are distinguished from other
(data) packets so that they can be processed as OAM. In LSPs, the
mechanism used is the presence of the GAL in the LSE under the top
LSE [RFC5586]. In PWs, the mechanism used is the presence of the PW
Associated Channel Header [RFC4385] or the presence of a GAL
[RFC6423]. In addition, two sets of identifiers exist that can be
used to address MIPs, which are defined in [RFC6370] and [RFC6923]
Any solution for sending OAM messages to the in- and out-MIPs must
fit within these existing models of handling OAM.
Additionally, many MPLS-TP nodes are implemented in a way that all
queuing and the forwarding function are performed at the incoming
interface. The abstract functional representation of such a node is
shown in Figure 4. As shown in the figure, the outgoing interfaces
are minimal and for this reason it may not be possible to include
MIP functions on those interfaces. This is the case for existing
deployed implementations in particular.
Any solution that attempts to send OAM messages to the outgoing
interface of an MPLS-TP node must not cause any problems when such
implementations are present (such as leaking OAM packets with a TTL
of 0).
---------------------
|------------ |
| MIP | |
| ---- | |
----->-| In | FW | |-->-Out-|->---
| i/f ---- | i/f |
|------------ |
---------------------
Figure 4: Abstract Functional Representation of
Some Existing MPLS-TP Nodes
OAM must operate on MPLS-TP nodes that are branch points on point-to-
multipoint (P2MP) trees. This means that it must be possible to
target individual outgoing MIPs as well as all outgoing MIPs in the
abstract functional representation shown in Figure 5, and to handle
the P2MP node implementations as shown in Figure 6 without causing
problems.
--------------------------
| -----|
| | MIP |
| ->-| |->----
| | | Out |
| | | i/f |
| | -----|
|----- | -----|
| MIP | ---- | | MIP |
| | | |- | |
----->-| In |->-| FW |--->-| Out |->----
| i/f | | |- | i/f |
|----- ---- | -----|
| | -----|
| | | MIP |
| | | |
| ->-| Out |->----
| | i/f |
| -----|
--------------------------
Figure 5: Abstract Functional Representation of an
MPLS-TP Node Supporting P2MP
----------------------
| ->-Out-|->----
| | i/f |
|------------ | |
| | | |
| MIP ---- | | |
| | | |- |
----->-| In | FW | |--->-Out-|->----
| i/f | | |- i/f |
| ---- | | |
| | | |
|------------ | |
| | Out |
| ->-i/f-|->----
----------------------
Figure 6: Abstract Functional Representation of
Some Existing MPLS-TP Nodes Supporting P2MP
In summary, the solution for OAM message delivery must behave as
follows:
o Delivery of OAM messages to the correct MPLS-TP node.
o Delivery of OAM instructions to the correct MIP within an MPLS-TP
node.
o Forwarding of OAM packets exactly as data packets.
o Packet inspection at the incoming and outgoing interfaces must be
minimized.
The first and second bullet points are obvious. However, the third
bullet point is also vital. To illustrate the importance, a rejected
solution is depicted in Figure 7. In the figure, all data and non-
local OAM is handled as normal. Local OAM is intercepted at the
incoming interface and delivered to the MIP at the incoming
interface. If the OAM is intended for the incoming MIP, it is
handled there with no issue. If the OAM is intended for the outgoing
MIP, it is forwarded to that MIP using some internal messaging system
that is implementation specific.
------------------------
|----- -----|
local OAM ----->-| MIP |----->------| MIP |
| | ---- | |
data =====>=| In |=>=| FW |=>=| Out |=>==== data
non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM
|----- ---- -----|
------------------------
Figure 7: OAM Control Message Delivery Bypassing
the Forwarding Engine
This solution is fully functional for the incoming MIP. It also
supports control of data loopback for the outgoing MIP and can
adequately perform some OAM features such as interface identity
reporting at the outgoing MIP.
However, because the OAM message is not forwarded through the
forwarding engine, this solution cannot correctly perform OAM
loopback, connectivity verification, LSP tracing, or performance
measurement.
The last bullet point is also an important requirement for any
solution to the internal-MIP addressing problem. Since OAM packets
that target an out-MIP need to be sent through the forwarding engine
and treated exactly as regular data packets, the determination of
whether to forward the packet or process it at the incoming MIP needs
to be fast; therefore, the processing overhead must be kept to a
minimum. In addition, there are a few OAM procedures that operate at
line rate such as OAM loopback. This adds to the requirement of
minimal processing overhead for both the in-MIP and out-MIP.
Most of the above superficially appears to be an implementation
matter local to an individual node; however, the format of the
message needs to be standardized so that:
o A MEP can correctly target the outgoing MIP of a specific MPLS-TP
node.
o A node can correctly filter out any OAM messages that were
intended for its upstream neighbor's outgoing MIP, but which were
not handled there because the upstream neighbor is an
implementation as shown in Figures 4 and 6.
Note that the last bullet point describes a safety net in case OAM
messages leak beyond their intended scope, but implementations should
take care that messages do not leak so that the safety net does not
need to be used.
5. Security Considerations
OAM security is discussed in [RFC6371] and security aspects specific
to MPLS-TP in general are outlined in [RFC6941].
OAM can provide useful information for detecting and tracing security
attacks.
OAM can also be used to illicitly gather information or for denial-
of-service attacks and other types of attack. Implementations
therefore are required to offer security mechanisms for OAM.
Deployments are therefore strongly advised to follow the security
advice provided in RFCs 6371 and 6941.
Mixing of per-node and per-interface OAM on a single node is not
advised as OAM message leakage could be the result.
6. Acknowledgments
The authors gratefully acknowledge the substantial contributions of
Zhenlong Cui. We would also like to thank Eric Gray, Sami Boutros,
and Shahram Davari for interesting input to this document through
discussions.
7. References
7.1. Normative References
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, September 2011.
[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the
Generic Associated Channel Label for Pseudowire in the
MPLS Transport Profile (MPLS-TP)", RFC 6423, November
2011.
[RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts,
"MPLS Transport Profile (MPLS-TP) Identifiers Following
ITU-T Conventions", RFC 6923, May 2013.
7.2. Informative References
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
Security Framework", RFC 6941, April 2013.
Authors' Addresses
Adrian Farrel
Juniper Networks
EMail: adrian@olddog.co.uk
Hideki Endo
Hitachi, Ltd.
EMail: hideki.endo.es@hitachi.com
Rolf Winter
NEC
EMail: rolf.winter@neclab.eu
Yoshinori Koike
NTT
EMail: koike.yoshinori@lab.ntt.co.jp
Manuel Paul
Deutsche Telekom
EMail: Manuel.Paul@telekom.de
AI ELI5
On this page
§1MPLS Operations and Maintenance Checkpoints
MPLS Transport Profile (MPLS-TP) is a version of MPLS designed for carrier-grade transport networks. Like all networks, MPLS-TP requires Operations, Administration, and Maintenance (OAM) capabilities to detect and diagnose faults.
OAM functions include connectivity verification, traceroute, loopback testing, and performance monitoring. These operations need to check status at various points along a Label Switched Path (LSP) or Pseudowire (PW). Maintenance Entity Group Intermediate Points (MIPs) are the checkpoints placed at these locations.
Historically, one MIP was placed somewhere inside each node (per-node model). However, to enable more precise fault localization, RFC 6371 defines the concept of per-interface MIPs: multiple MIPs per node, placed on the incoming interface (before the forwarding engine) and outgoing interface (after the forwarding engine). This document elaborates on the requirements and design considerations for addressing these per-interface MIPs.
MPLS-TP is used by telephone and cable companies for important networks. OAM is the testing and troubleshooting system. MIPs are the checkpoints where you can test. The old way put one checkpoint per router; the new way puts one on each side of the router's forwarding engine to find problems more precisely.
§2The Addressing Problem
OAM messages travel through the network using standard packet mechanisms. For messages targeting a transit point (MIP), the mechanism is the expiration of the MPLS Time-to-Live (TTL) field. For endpoint messages, they are simply delivered as normal. The content of OAM messages is distinguished from data using a Generic Associated Channel Label (GAL) in LSPs or a PW Associated Channel Header (PWACH) in Pseudowires.
However, when multiple MIPs exist on a single node, these mechanisms provide no way to address one particular MIP out of the set. If an OAM message arrives at a node with per-interface MIPs and says "check the connectivity here," which MIP should handle it—the incoming one or the outgoing one?
Any mechanism to solve this must work within the existing OAM framework and be standardized so that different vendors' equipment can interoperate correctly.
The old OAM system had no way to say "the incoming checkpoint, not the outgoing one." Without standardized labels, different companies would invent different ways to address them, and the equipment wouldn't talk to each other.
§3Per-Node vs Per-Interface OAM Models
In the per-node model, there is one unspecified MIP per node. All OAM requests to that node target the same location. This simplifies implementation but limits fault localization. If a link works fine to the node but client data stops flowing, the fault could be in the node's forwarding engine, on the outgoing interface, or beyond.
In the per-interface model, there are two (or more) MIPs per node: an in-MIP on the incoming interface (before the forwarding engine) and an out-MIP on the outgoing interface (after the forwarding engine). This enables much finer-grained fault localization.
For example, if incoming connectivity tests pass but outgoing tests fail, you know the problem is in the forwarding engine. If connectivity to the outgoing interface of one node fails but the incoming interface of the next node works, the problem is definitely on the link between them. Per-interface MIPs enable operators to quickly narrow down exactly where a fault exists.
The old system: one checkpoint per box. You test it and know something between here and the next box is broken, but not what. The new system: two checkpoints per box (before and after the forwarding engine). Now you know if it's on the link, in the box, or beyond the box.
| Aspect | Per-Node Model | Per-Interface Model |
|---|---|---|
| MIPs per node | 1 (location unspecified) | 2 or more (in and out) |
| Fault localization | Coarse (fault on link or in node?) | Fine (know exactly which part) |
| Testing granularity THIS RFC | Coarse (whole node) | Fine (incoming interface, forwarding engine, outgoing interface separate) |
| Implementation complexity | Simple | More complex (requires addressing mechanism) |
§4Design Requirements for MIP Addressing
Any solution for delivering OAM messages to in-MIPs and out-MIPs must satisfy several critical design requirements:
Correct delivery to the right node and right MIP: OAM messages must reach the correct MPLS-TP node and the correct MIP within that node.
Forward OAM packets exactly like data: This is vital. OAM messages intended for an out-MIP must travel through the forwarding engine normally, as if they were regular data packets. If OAM messages destined for out-MIPs are intercepted at the in-MIP and forwarded via some internal messaging system, certain OAM functions fail—specifically loopback, connectivity verification, LSP tracing, and performance measurement all require the OAM message to transit the actual forwarding engine.
Minimize packet inspection overhead: Because OAM packets targeting out-MIPs must be forwarded through the forwarding engine, and because some OAM functions like loopback operate at line rate, the processing overhead for determining whether to process a packet at the in-MIP or forward it must be minimal.
Handle implementation variations: Some existing MPLS-TP nodes implement all queuing and forwarding at the incoming interface; there is no real outgoing interface to attach a MIP to. Solutions must not cause problems with these implementations (such as OAM packets with TTL=0 leaking out).
Support point-to-multipoint: OAM must work correctly on P2MP nodes that have multiple outgoing interfaces, allowing targeting of individual out-MIPs or all out-MIPs at once.
The addressing mechanism must: (1) get the right test to the right checkpoint, (2) send out-MIP tests through the forwarding engine like normal data, (3) not slow down the network with extra checking, (4) not break older routers, and (5) work on multicast paths.
- Incoming interfaceIncoming OAM checkpoint (in-MIP)
- Forwarding engineWhere packets are switched and routed
- Outgoing interfaceOutgoing OAM checkpoint (out-MIP)
§5Implementation Considerations and Safety
Although the message format and addressing mechanism must be standardized, much of the per-interface MIP implementation is local to individual nodes. However, standardization ensures that:
Senders can target correctly: A Maintenance Entity Group End Point (MEP) can correctly address an out-MIP of a specific MPLS-TP node, even when that upstream node might be an older implementation without out-MIPs.
Filtering provides safety: If an OAM message intended for a neighboring node's out-MIP leaks beyond its intended scope (because the neighbor is an old implementation that doesn't have out-MIPs), the downstream node can correctly filter it out rather than processing it incorrectly.
Mixing per-node and per-interface OAM on a single node is not recommended, as it can result in OAM message leakage where messages reach unintended MIPs.
Security for OAM is covered in RFC 6371 and RFC 6941. OAM can be used to detect attacks but can also be misused for information gathering or denial-of-service; therefore, implementations must provide security mechanisms and deployments should follow the guidance in those RFCs.
Different routers might use different versions of per-interface MIPs. The solution must be flexible enough to work with new and old equipment, with safety filters to prevent test messages from going to the wrong place.