RFC 6375

A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks

📅 published September 2011, from ietf

RFC 6375: A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks ✨

Okay bestie, the title block first 🎀. This one is Informational, which means it's published for information and is not an Internet Standards Track spec 🌸. It was written by Dan Frost (editor) and Stewart Bryant (editor), both from Cisco Systems, and it's dated September 2011. Its ISSN is 2070-1721 💜. The header doesn't list any Obsoletes or Updates entries, so it isn't replacing or changing another document 🧚.

Abstract

Okay so the big measurement rulebook for MPLS is RFC 6374 🦋. It covers how to measure packet loss, delay, and throughput efficiently and accurately, which is honestly iconic.

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions you use to build and run packet-switched transport networks 🚆.

This doc describes a profile of the general MPLS loss, delay, and throughput measurement techniques. It's a trimmed-down version that's enough to meet the specific requirements of MPLS-TP 💅.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort. The goal is to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures, so they can support the capabilities and functionalities of a packet transport network as the ITU-T defines them 🌈.

Status of This Memo

This document is not an Internet Standards Track specification. It's 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 every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🫶.

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6375 ✨.

Copyright (c) 2011 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 read these carefully, because they spell out 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 they're provided without warranty as described in the Simplified BSD License 💜.

1. Introduction 🌸

Okay so the procedures for measuring packet loss, delay, and throughput in MPLS networks are defined in [RFC6374]. This document describes a profile, which is a simplified subset of those procedures, that's enough to meet the specific requirements of MPLS-based transport networks [RFC5921] as defined in [RFC5860]. The profile is written for implementors who only care about the transport network context, so it's basically made for them 🎀.

The profile in this document is purely optional 🦋. Implementors who want extra functionality that's within the scope of [RFC6374] but outside the scope of this profile may add it, whether or not their implementation is limited to the transport network context.

The assumption here is that the devices in a measurement operation are configured for measurement by something outside the measurement protocols themselves. For example, that could be a Network Management System (NMS) or a separate configuration protocol 🧚. The manageability considerations in [RFC6374] apply, and you can find more info about MPLS-TP network management in [RFC5950] 💅.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort. The goal is to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures, so they can support the capabilities and functionalities of a packet transport network as the ITU-T defines them 🌈.

2. MPLS-TP Measurement Considerations 💖

The measurement considerations in Section 2.9 of [RFC6374] also apply in the context of MPLS-TP. The exceptions are these, which relate to topologies that are excluded from MPLS-TP 🙈:

  • Equal Cost Multipath considerations (Section 2.9.4 of [RFC6374])
  • Considerations for direct Loss Measurement (LM) in the presence of Label Switched Paths constructed via the Label Distribution Protocol (LDP) or utilizing Penultimate Hop Popping (Section 2.9.8 of [RFC6374])

3. Packet Loss Measurement (LM) Profile ✨

Okay, when an LM session is configured externally, several protocol parameters can be fixed ahead of time at the endpoints in the session. That means they don't need to be negotiated 🔥. Here are those parameters and their default values under this profile:

Parameter                                 Default Value
----------------------------------------- --------------------------
Query control code                        In-band Response Requested
Byte/packet Count (B) Flag                Packet count
Traffic-class-specific (T) Flag           Traffic-class-scoped
Origin Timestamp Format (OTF)             Truncated IEEE 1588v2

A simple implementation may assume that external configuration makes sure both ends of the communication are using the default values for these parameters. That said, implementations are strongly advised to validate the values of these parameters in received messages, so configuration inconsistencies can be detected and reported 👑.

LM message rates (and test message rates, when inferred LM is used) should be configurable by the network operator on a per-channel basis. The following intervals should be supported 🦋:

Message Type   Supported Intervals
-------------- ------------------------------------------------------
LM Message     100 milliseconds, 1 second, 10 seconds, 1 minute, 10
               minutes
Test Message   10 milliseconds, 100 milliseconds, 1 second, 10
               seconds, 1 minute

4. Packet Delay Measurement (DM) Profile 🌈

Same energy as LM, bestie. When a DM session is configured externally, several protocol parameters can be fixed in advance at the endpoints in the session, so negotiating them isn't required 💅. Here are those parameters and their default values under this profile:

Parameter                                  Default Value
------------------------------------------ --------------------------
Query control code                         In-band Response Requested
Querier Timestamp Format (QTF)             Truncated IEEE 1588v2
Responder Timestamp Format (RTF)           Truncated IEEE 1588v2
Responder's Preferred Timestamp Format     Truncated IEEE 1588v2
(RPTF)

A simple implementation may assume that external configuration will make sure both ends of the communication are using the default values for these parameters. However, implementations are strongly advised to validate the values of these parameters in received messages, so configuration inconsistencies can be detected and reported 🫶.

DM message rates should be configurable by the network operator on a per-channel basis. The following message intervals should be supported: 1 second, 10 seconds, 1 minute, 10 minutes 🍓.

5. Security Considerations 💀

Okay this section is serious, so read it carefully 🚨. This document delineates a subset of the procedures specified in [RFC6374]. As such, it introduces no new security considerations in itself. The security considerations discussed in [RFC6374] also apply to the profile presented in this document. General considerations for MPLS-TP network security can be found in [SECURITY-FRAMEWORK].

6. References 📚

6.1. Normative References

[RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
           Operations, Administration, and Maintenance (OAM) in MPLS
           Transport Networks", RFC 5860, May 2010.

[RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
           Measurement for MPLS Networks", RFC 6374, September 2011.

6.2. Informative References

[RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
           Berger, "A Framework for MPLS in Transport Networks",
           RFC 5921, July 2010.

[RFC5950]  Mansfield, S., Gray, E., and K. Lam, "Network Management
           Framework for MPLS-based Transport Networks", RFC 5950,
           September 2010.

[SECURITY-FRAMEWORK]
           Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
           Security Framework", Work in Progress, May 2011.

Authors' Addresses 💌

Dan Frost (editor)
Cisco Systems

EMail: danfrost@cisco.com


Stewart Bryant (editor)
Cisco Systems

EMail: stbryant@cisco.com

That's the whole thing, bestie. ✨💖🦋

📦 where this page comes from