RFC 6371
Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
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 implications are: 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 [11], 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 alarm indication. 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 configured. 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 [11]. On-demand LM is very similar to proactive LM described in Section 5.5. This section focuses on the differences between on-demand and proactive LM. 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 synthetic traffic.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 of service.
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 [11], 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 [12], 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 [12]. 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 packets.6.3.1.1. 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 started. 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 6.3.1.2).6.3.1.2. 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.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.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 [11]. 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 decrement. 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.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. 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 configured.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 [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. 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 [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. 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
originating MEP.
MIPs, as well as intermediate nodes, do not process the DM
information; they forward these on-demand DM OAM packets as regular
data packets.
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 [17]).
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.
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.
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 data packets.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 command. 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 applications. 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 employed. 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 considerations. 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 [8].9. Acknowledgments
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 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