6. OAM Functions for On-Demand Monitoring
In contrast to proactive monitoring, on-demand monitoring is
initiated manually and for a limited amount of time, usually for
operations such as diagnostics to investigate a defect condition.
On-demand monitoring covers a combination of "in-service" and "out-
of-service" monitoring functions. The control and measurement
1. A MEG can be directed to perform an "on-demand" functions at
arbitrary times in the lifetime of a transport path.
2. "Out-of-service" monitoring functions may require a priori
configuration of both MEPs and intermediate nodes in the MEG
(e.g., data-plane loopback) and the issuance of notifications into
client layers of the transport path being removed from service
(e.g., lock reporting)
3. The measurements resulting from "on-demand" monitoring are
typically harvested in real time, as they are frequently initiated
manually. These do not necessarily require different harvesting
mechanisms than for harvesting proactive monitoring telemetry.
The functions that are exclusively out-of-service are those described
in Section 6.3. The remainder are applicable to both in-service and
out-of-service transport paths.
6.1. Connectivity Verification
The on-demand connectivity verification function, as required in
Section 2.2.3 of RFC 5860 , is a transaction that flows from the
originating MEP to a target MIP or MEP to verify the connectivity
between these points.
Use of on-demand CV is dependent on the existence of a bidirectional
ME or an associated return ME, or the availability of an out-of-band
return path, because it requires the ability for target MIPs and MEPs
to direct responses to the originating MEPs.
One possible use of on-demand CV would be to perform fault management
without using proactive CC-V, in order to preserve network resources,
e.g., bandwidth, processing time at switches. In this case, network
management periodically invokes on-demand CV.
An additional use of on-demand CV would be to detect and locate a
problem of connectivity when a problem is suspected or known to be
based on other tools. In this case, the functionality will be
triggered by the network management in response to a status signal or
On-demand CV is based upon generation of on-demand CV packets that
should uniquely identify the MEG that is being checked. The on-
demand functionality may be used to check either an entire MEG (end-
to-end) or between the originating MEP and a specific MIP. This
functionality may not be available for associated bidirectional
transport paths or unidirectional paths, as the MIP may not have a
return path to the originating MEP for the on-demand CV transaction.
When on-demand CV is invoked, the originating MEP issues a sequence
of on-demand CV packets that uniquely identifies the MEG being
verified. The number of packets and their transmission rate should
be pre-configured at the originating MEP to take into account normal
packet-loss conditions. The source MEP should use the mechanisms
defined in Sections 3.3 and 3.4 when sending 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 each packet received.
If the expected number of on-demand CV reply packets is not received
at the originating MEP, this is an indication that a connectivity
problem may exist.
On-demand CV should have the ability to carry padding such that a
variety of MTU sizes can be originated to verify the MTU transport
capability of the transport path.
MIPs that are not targeted by on-demand CV packets, as well as
intermediate nodes, do not process the CV information; they forward
these on-demand CV OAM packets as regular data packets.
6.1.1. Configuration Considerations
For on-demand CV, the originating MEP should support the
configuration of the number of packets to be transmitted/received in
each sequence of transmissions and their packet size.
In addition, when the CV packet is used to check connectivity toward
a target MIP, the number of hops to reach the target MIP should be
For E-LSPs, the PHB of the on-demand CV packets should be configured
as well. This permits the verification of correct operation of QoS
queuing as well as connectivity.
6.2. Packet Loss Measurement
On-demand Packet Loss Measurement (LM) is one of the capabilities
supported by the MPLS-TP Performance Monitoring function in order to
facilitate the diagnosis of QoS performance for a transport path, as
required in Section 2.2.11 of RFC 5860 .
On-demand LM is very similar to proactive LM described in Section
5.5. This section focuses on the differences between on-demand and
On-demand LM is performed by periodically sending LM OAM packets from
a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP
(if a co-routed or associated bidirectional transport path) during a
pre-defined monitoring period. Each MEP performs measurements of its
transmitted and received user data packets. These measurements are
then correlated to evaluate the packet-loss performance metrics of
the transport path.
Use of packet loss measurement in an out-of-service transport path
requires a traffic source such as a test device that can inject
6.2.1. Configuration Considerations
In order to support on-demand LM, the beginning and duration of the
LM procedures, the transmission rate, and, for E-LSPs, the PHB class
(associated with the LM OAM packets originating from a MEP) must be
configured as part of the on-demand LM provisioning. LM OAM packets
should be transmitted with the PHB that yields the lowest drop
precedence as described in Section 5.5.1.
6.2.2. Sampling Skew
The same considerations described in Section 5.5.2 for the proactive
LM are also applicable to on-demand LM implementations.
6.2.3. Multilink Issues
Multilink issues are as described in Section 5.5.3.
6.3. Diagnostic Tests
Diagnostic tests are tests performed on a MEG that has been taken out
6.3.1. Throughput Estimation
Throughput estimation is an on-demand out-of-service function, as
required in Section 2.2.5 of RFC 5860 , that allows verifying the
bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before
it is put in service.
Throughput estimation is performed between MEPs and between a MEP and
a MIP. It can be performed in one-way or two-way modes.
According to RFC 2544 , this test is performed by sending OAM
test packets at increasing rates (up to the theoretical maximum),
computing the percentage of OAM test packets received, and reporting
the rate at which OAM test packets begin to drop. In general, this
rate is dependent on the OAM test packet size.
When configured to perform such tests, a source MEP inserts OAM test
packets with a specified packet size and transmission pattern at a
rate to exercise the throughput.
The throughput test can create congestion within the network, thus
impacting other transport paths. However, the test traffic should
comply with the traffic profile of the transport path under test, so
the impact of the test will not be worse than the impact caused by
the customers, whose traffic would be sent over that transport path,
sending the traffic at the maximum rate allowed by their traffic
profiles. Therefore, throughput tests are not applicable to
transport paths that do not have a defined traffic profile, such as
LSPs in a context where statistical multiplexing is leveraged for
network capacity dimensioning.
For a one-way test, the remote sink MEP receives the OAM test packets
and calculates the packet loss. For 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.
It is worth noting that two-way throughput estimation is only
applicable to bidirectional (co-routed or associated) transport paths
and can only evaluate the minimum of available throughput of the two
directions. In order to estimate the throughput of each direction
uniquely, two one-way throughput estimation sessions have to be set
up. One-way throughput estimation requires coordination between the
transmitting and receiving test devices as described in Section 6 of
RFC 2544 .
It is also worth noting that if throughput estimation is performed on
transport paths that transit oversubscribed links, the test may not
produce comprehensive results if viewed in isolation because the
impact of the test on the surrounding traffic needs to also be
considered. Moreover, the estimation will only reflect the bandwidth
available at the moment when the measure is made.
MIPs that are not targeted by on-demand test OAM packets, as well as
intermediate nodes, do not process the throughput test information;
they forward these on-demand test OAM packets as regular data
126.96.36.199. Configuration Considerations
Throughput estimation is an out-of-service tool. The diagnosed MEG
should be put into a locked state before the diagnostic test is
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.
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.
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 188.8.131.52).
184.108.40.206. Limited OAM Processing Rate
If an implementation is able to process payload at much higher data
rates than OAM test packets, then accurate measurement of throughput
using OAM test packets is not achievable. Whether OAM packets can be
processed at the same rate as payload is implementation dependent.
220.127.116.11. 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
6.3.2. Data-Plane Loopback
Data-plane loopback is an out-of-service function, as required in
Section 2.2.5 of RFC 5860 . This function consists in placing a
transport path, at either an intermediate or terminating node, 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. The traffic is looped back
unmodified except for normal per-hop processing such as TTL
The data-plane loopback function requires that the MEG is locked such
that user data traffic is prevented from entering/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 as 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, and
this may interfere with other measurements.
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. It should also be noted that
MIPs can be addressed with more than one TTL value on a co-routed
bidirectional path set into data-plane loopback.
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.
It should be noted that 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.
18.104.22.168. 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.
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.
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
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.
The route tracing function, as required in Section 2.2.4 of RFC 5860
, 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.
Route tracing might be implemented in different ways, and this
document does not preclude any of them.
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, and 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.
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.
6.5. Packet Delay Measurement
Packet Delay Measurement (DM) is one of the capabilities supported by
the MPLS-TP PM function in order to facilitate reporting of QoS
information for a transport path, as required in Section 2.2.12 of
RFC 5860 . 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.
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.
On-demand DM can be operated in two modes:
o 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.
o 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
MIPs, as well as intermediate nodes, do not process the DM
information; they forward these on-demand DM OAM packets as regular
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. DM OAM packets should
be transmitted with the PHB that yields the lowest drop precedence
within the measured PHB Scheduling Class (see RFC 3260 ).
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
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 , is a command allowing a MEP to instruct the peer MEP(s) to
put the MPLS-TP transport path into a locked condition.
This function allows single-side provisioning for administratively
locking (and unlocking) an MPLS-TP transport path.
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/used.
MIPs, as well as intermediate nodes, do not process the Lock Instruct
information; they forward these on-demand LKI OAM packets as regular
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.
A MEP, upon receiving an LKI request from its peer MEP, can either
accept or reject the instruction and 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
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.
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.
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).
The peer MEP, upon receiving an LKI removal request, can either
accept or reject the removal instruction and 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.
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.
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.
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.
8. Security Considerations
A number of security considerations are important in the context of
OAM traffic can reveal sensitive information, such as performance
data and details, about the current state of the network. Insertion
or modification of OAM transactions can mask the true operational
state of the network, and in the case of transactions for
administration control, such as lock or data-plane loopback
instructions, these can be used for explicit denial-of-service
attacks. The effect of such attacks is mitigated only by the fact
that, for in-band messaging, the managed entities whose state can be
masked is limited to those that transit the point of malicious access
to the network internals due to the fate-sharing nature of OAM
messaging. This is not true when an out-of-band return path is
The sensitivity of OAM data therefore suggests that one solution is
that some form of authentication, authorization, and encryption is in
place. This will prevent unauthorized access to vital equipment, and
it will prevent third parties from learning about sensitive
information about the transport network. However, it should be
observed that the combination of the frequency of some OAM
transactions, the need for timeliness of OAM transaction exchange,
and all permutations of unique MEP to MEP, MEP to MIP, and
intermediate-system-originated transactions mitigates against the
practical establishment and maintenance of a large number of security
associations per MEG either in advance or as required.
For this reason, it is assumed that the internal links of the network
are physically secured from malicious access such that OAM
transactions scoped to fault and performance management of individual
MEGs are not encumbered with additional security. Further, it is
assumed in multi-provider cases where OAM transactions originate
outside of an individual provider's trusted domain that 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
In case of misconfiguration, some nodes can receive OAM packets that
they cannot recognize. In such a case, these OAM packets should be
silently discarded in order to avoid malfunctions whose effects may
be similar to malicious attacks (e.g., degraded performance or even
failure). Further considerations about data-plane attacks via G-ACh
are provided in RFC 5921 .
The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF, and the
Ad Hoc Group on MPLS-TP in ITU-T) involved in the definition and
specification of the MPLS Transport Profile.
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
10.1. Normative References
 Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
 Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
 Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
 Bocci, M. and S. Bryant, "An Architecture for Multi-Segment
Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
 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.
 Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
 Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS
Generic Associated Channel", RFC 5586, June 2009.
 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.
 Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile
User-to-Network and Network-to-Network Interfaces", RFC 6215,
 Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
Transport Profile Data Plane Architecture", RFC 5960, August
 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.
 Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Service", RFC 2475,
 ITU-T Recommendation G.806 (01/09), "Characteristics of
transport equipment - Description methodology and generic
functionality", January 2009.
10.2. Informative References
 Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for
MPLS based Transport Networks", Work in Progress, June 2011.
 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.
 Grossman, D., "New Terminology and Clarifications for Diffserv",
RFC 3260, April 2002.
 Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS
Traffic Engineering (TE)", RFC 4201, October 2005.
 ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
interface for the synchronous digital hierarchy (SDH)", January
 ITU-T Recommendation G.805 (03/00), "Generic functional
architecture of transport networks", March 2000.
 ITU-T Recommendation Y.1731 (02/08), "OAM functions and
mechanisms for Ethernet based networks", February 2008.
 IEEE Standard 802.1AX-2008, "IEEE Standard for Local and
Metropolitan Area Networks - Link Aggregation", November 2008.
 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,
 Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile
(MPLS-TP) Identifiers", RFC 6370, September 2011.
 Winter, R., Ed., van Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions", Work in Progress, July
11. Contributing Authors