RFC 6374
Packet Loss and Delay Measurement for MPLS Networks
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
queuing.
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
formats.
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 case. 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 misordered packets. 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" registry 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 (DLM+DM) 0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374 (ILM+DM)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 Timestamp 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: Query Codes Code Description Reference ---- ------------------------------ --------- 0x0 In-band Response Requested RFC 6374 0x1 Out-of-band Response Requested RFC 6374 0x2 No Response Requested RFC 6374
Response Codes Code Description Reference ---- ----------------------------------- --------- 0x0 Reserved RFC 6374 0x1 Success RFC 6374 0x2 Data Format Invalid RFC 6374 0x3 Initialization in Progress RFC 6374 0x4 Data Reset Occurred RFC 6374 0x5 Resource Temporarily Unavailable RFC 6374 0x10 Unspecified Error RFC 6374 0x11 Unsupported Version RFC 6374 0x12 Unsupported Control Code RFC 6374 0x13 Unsupported Data Format RFC 6374 0x14 Authentication Failure RFC 6374 0x15 Invalid Destination Node Identifier RFC 6374 0x16 Connection Mismatch RFC 6374 0x17 Unsupported Mandatory TLV Object RFC 6374 0x18 Unsupported Query Interval RFC 6374 0x19 Administrative Block RFC 6374 0x1A Resource Unavailable RFC 6374 0x1B Resource Released RFC 6374 0x1C Invalid Message RFC 6374 0x1D Protocol Error RFC 6374 IANA has indicated that the values 0x0 - 0xF in the Response Code section are reserved for non-error response codes. The range of the Code field is 0 - 255. The allocation policy for this registry is IETF Review.
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.10. Acknowledgments
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. References
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, December 1998. [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.Authors' Addresses
Dan Frost Cisco Systems EMail: danfrost@cisco.com Stewart Bryant Cisco Systems EMail: stbryant@cisco.com