5. Implementation Disclosure Requirements
This section summarizes the requirements placed on implementations
for capabilities disclosure. The purpose of these requirements is to
ensure that end users have a clear understanding of implementation
capabilities and characteristics that have a direct impact on how
loss and delay measurement mechanisms function in specific
situations. Implementations are REQUIRED to state:
o METRICS: Which of the following metrics are supported: packet
loss, packet throughput, octet loss, octet throughput, average
loss rate, one-way delay, round-trip delay, two-way channel delay,
packet delay variation.
o MP-LOCATION: The location of loss and delay measurement points
with respect to other stages of packet processing, such as
o CHANNEL-TYPES: The types of channels for which LM and DM are
supported, including LSP types, pseudowires, and sections (links).
o QUERY-RATE: The minimum supported query intervals for LM and DM
sessions, both in the querier and responder roles.
o LOOP: Whether loopback measurement (Section 2.8) is supported.
o LM-TYPES: Whether direct or inferred LM is supported, and for the
latter, which test protocols or proxy message types are supported.
o LM-COUNTERS: Whether 64-bit counters are supported.
o LM-ACCURACY: The expected measurement accuracy levels for the
supported forms of LM, and the expected impact of exception
conditions such as lost and misordered messages.
o LM-SYNC: The implementation's behavior in regard to the
synchronization conditions discussed in Section 2.9.8.
o LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).
o DM-ACCURACY: The expected measurement accuracy levels for the
supported forms of DM.
o DM-TS-FORMATS: The supported timestamp formats and the extent of
support for computation with and reconciliation of different
6. Congestion Considerations
An MPLS network may be traffic-engineered in such a way that the
bandwidth required both for client traffic and for control,
management, and OAM traffic is always available. The following
congestion considerations therefore apply only when this is not the
The proactive generation of Loss Measurement and Delay Measurement
messages for purposes of monitoring the performance of an MPLS
channel naturally results in a degree of additional load placed on
both the network and the terminal nodes of the channel. When
configuring such monitoring, operators should be mindful of the
overhead involved and should choose transmit rates that do not stress
network resources unduly; such choices must be informed by the
deployment context. In case of slower links or lower-speed devices,
for example, lower Loss Measurement message rates can be chosen, up
to the limits noted at the end of Section 2.2.
In general, lower measurement message rates place less load on the
network at the expense of reduced granularity. For delay
measurement, this reduced granularity translates to a greater
possibility that the delay associated with a channel temporarily
exceeds the expected threshold without detection. For loss
measurement, it translates to a larger gap in loss information in
case of exceptional circumstances such as lost LM messages or
When carrying out a sustained measurement operation such as an LM
operation or continuous proactive DM operation, the querier SHOULD
take note of the number of lost measurement messages (queries for
which a response is never received) and set a corresponding
Measurement Message Loss Threshold. If this threshold is exceeded,
the measurement operation SHOULD be suspended so as not to exacerbate
the possible congestion condition. This suspension SHOULD be
accompanied by an appropriate notification to the user so that the
condition can be investigated and corrected.
From the receiver perspective, the main consideration is the
possibility of receiving an excessive quantity of measurement
messages. An implementation SHOULD employ a mechanism such as rate-
limiting to guard against the effects of this case.
7. Manageability Considerations
The measurement protocols described in this document are intended to
serve as infrastructure to support a wide range of higher-level
monitoring and diagnostic applications, from simple command-line
diagnostic tools to comprehensive network performance monitoring and
analysis packages. The specific mechanisms and considerations for
protocol configuration, initialization, and reporting thus depend on
the nature of the application.
In the case of on-demand diagnostics, the diagnostic application may
provide parameters such as the measurement type, the channel, the
query rate, and the test duration when initiating the diagnostic;
results and exception conditions are then reported directly to the
application. The system may discard the statistics accumulated
during the test after the results have been reported or retain them
to provide a historical measurement record.
Alternatively, measurement configuration may be supplied as part of
the channel configuration itself in order to support continuous
monitoring of the channel's performance characteristics. In this
case, the configuration will typically include quality thresholds
depending on the service level agreement, the crossing of which will
trigger warnings or alarms, and result reporting and exception
notification will be integrated into the system-wide network
management and reporting framework.
8. Security Considerations
This document describes procedures for the measurement of performance
metrics over a pre-existing MPLS path (a pseudowire, LSP, or
section). As such, it assumes that a node involved in a measurement
operation has previously verified the integrity of the path and the
identity of the far end using existing MPLS mechanisms such as
Bidirectional Forwarding Detection (BFD) [RFC5884]; tools,
techniques, and considerations for securing MPLS paths are discussed
in detail in [RFC5920].
When such mechanisms are not available, and where security of the
measurement operation is a concern, reception of Generic Associated
Channel messages with the Channel Types specified in this document
SHOULD be disabled. Implementations MUST provide the ability to
disable these protocols on a per-Channel-Type basis.
Even when the identity of the far end has been verified, the
measurement protocols remain vulnerable to injection and man-in-the-
middle attacks. The impact of such an attack would be to compromise
the quality of performance measurements on the affected path. An
attacker positioned to disrupt these measurements is, however,
capable of causing much greater damage by disrupting far more
critical elements of the network such as the network control plane or
user traffic flows. At worst, a disruption of the measurement
protocols would interfere with the monitoring of the performance
aspects of the service level agreement associated with the path; the
existence of such a disruption would imply that a serious breach of
basic path integrity had already occurred.
If desired, such attacks can be mitigated by performing basic
validation and sanity checks, at the querier, of the counter or
timestamp fields in received measurement response messages. The
minimal state associated with these protocols also limits the extent
of measurement disruption that can be caused by a corrupt or invalid
message to a single query/response cycle.
Cryptographic mechanisms capable of signing or encrypting the
contents of the measurement packets without degrading the measurement
performance are not currently available. In light of the preceding
discussion, the absence of such cryptographic mechanisms does not
raise significant security issues.
Users concerned with the security of out-of-band responses over IP
networks SHOULD employ suitable security mechanisms such as IPsec
[RFC4301] to protect the integrity of the return path.
9. IANA Considerations
Per this document, IANA has completed the following actions:
o Allocation of Channel Types in the "PW Associated Channel Type"
o Creation of a "Measurement Timestamp Type" registry
o Creation of an "MPLS Loss/Delay Measurement Control Code" registry
o Creation of an "MPLS Loss/Delay Measurement Type-Length-Value
(TLV) Object" registry
9.1. Allocation of PW Associated Channel Types
As per the IANA considerations in [RFC5586], IANA has allocated the
following Channel Types in the "PW Associated Channel Type" registry:
Value Description TLV Follows Reference
------ ---------------------------------------- ----------- ---------
0x000A MPLS Direct Loss Measurement (DLM) No RFC 6374
0x000B MPLS Inferred Loss Measurement (ILM) No RFC 6374
0x000C MPLS Delay Measurement (DM) No RFC 6374
0x000D MPLS Direct Loss and Delay Measurement No RFC 6374
0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374
9.2. Creation of Measurement Timestamp Type Registry
IANA has created a new "Measurement Timestamp Type" registry, with
format and initial allocations as follows:
Type Description Size in Bits Reference
---- ----------------------------------------- ------------ ---------
0 Null Timestamp 64 RFC 6374
1 Sequence Number 64 RFC 6374
2 Network Time Protocol version 4 64-bit 64 RFC 6374
3 Truncated IEEE 1588v2 PTP Timestamp 64 RFC 6374
The range of the Type field is 0-15.
The allocation policy for this registry is IETF Review.
9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry
IANA has created a new "MPLS Loss/Delay Measurement Control Code"
registry. This registry is divided into two separate parts, one for
Query Codes and the other for Response Codes, with formats and
initial allocations as follows:
Code Description Reference
---- ------------------------------ ---------
0x0 In-band Response Requested RFC 6374
0x1 Out-of-band Response Requested RFC 6374
0x2 No Response Requested RFC 6374
9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry
IANA has created a new "MPLS Loss/Delay Measurement TLV Object"
registry, with format and initial allocations as follows:
Type Description Reference
---- --------------------------------- ---------
0 Padding - copy in response RFC 6374
1 Return Address RFC 6374
2 Session Query Interval RFC 6374
3 Loopback Request RFC 6374
127 Experimental use RFC 6374
128 Padding - do not copy in response RFC 6374
129 Destination Address RFC 6374
130 Source Address RFC 6374
255 Experimental use RFC 6374
IANA has indicated that Types 0-127 are classified as Mandatory, and
that Types 128-255 are classified as Optional.
The range of the Type field is 0 - 255.
The allocation policy for this registry is IETF Review.
The authors wish to thank the many participants of the MPLS working
group who provided detailed review and feedback on this document.
The authors offer special thanks to Alexander Vainshtein, Loa
Andersson, and Hiroyuki Takagi for many helpful thoughts and
discussions, to Linda Dunbar for the idea of using LM messages for
throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and
Ben Mack-Crane for their valuable comments.
11.1. Normative References
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] 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,
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3270] 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.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
11.2. Informative References
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding
Equal Cost Multipath Treatment in MPLS Networks",
BCP 128, RFC 4928, June 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
Delay Measurement Profile for MPLS-Based Transport
Networks", RFC 6375, September 2011.
[Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and
Mechanisms for Ethernet based Networks", February 2008.
Appendix A. Default Timestamp Format Rationale
This document initially proposed the Network Time Protocol (NTP)
timestamp format as the mandatory default, as this is the normal
default timestamp in IETF protocols and thus would seem the "natural"
choice. However, a number of considerations have led instead to the
specification of the truncated IEEE 1588 Precision Time Protocol
(PTP) timestamp as the default. NTP has not gained traction in
industry as the protocol of choice for high-quality timing
infrastructure, whilst IEEE 1588 PTP has become the de facto time
transfer protocol in networks that are specially engineered to
provide high-accuracy time distribution service. The PTP timestamp
format is also the ITU-T format of choice for packet transport
networks, which may rely on MPLS protocols. Applications such as
one-way delay measurement need the best time service available, and
converting between the NTP and PTP timestamp formats is not a trivial
transformation, particularly when it is required that this be done in
real time without loss of accuracy.
The truncated IEEE 1588 PTP format specified in this document is
considered to provide a more than adequate wrap time and greater time
resolution than it is expected will be needed for the operational
lifetime of this protocol. By truncating the timestamp at both the
high and low order bits, the protocol achieves a worthwhile reduction
in system resources.