A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks
A simplified profile of MPLS loss and delay measurement for MPLS transport networks.
Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011, <https://www.rfc-editor.org/info/rfc6375>.
@misc{rfc6375,
series = {Request for Comments},
number = 6375,
howpublished = {RFC 6375},
publisher = {RFC Editor},
doi = {10.17487/RFC6375},
url = {https://www.rfc-editor.org/info/rfc6375},
author = {D. Frost and S. Bryant},
title = {{A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks}},
pagetotal = 5,
year = 2011,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Frost, Ed.
Request for Comments: 6375 S. Bryant, Ed.
Category: Informational Cisco Systems
ISSN: 2070-1721 September 2011
A Packet Loss and Delay Measurement Profile
for MPLS-Based Transport Networks
Abstract
Procedures and protocol mechanisms to enable efficient and accurate
measurement of packet loss, delay, and throughput in MPLS networks
are defined in RFC 6374.
The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol
functions applicable to the construction and operation of packet-
switched transport networks.
This document describes a profile of the general MPLS loss, delay,
and throughput measurement techniques that suffices 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 to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T.
Status of This Memo
This document is not an Internet Standards Track specification; it is
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 all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6375.
Copyright Notice
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 review these documents
carefully, as they describe 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 are provided without warranty as
described in the Simplified BSD License.
1. Introduction
Procedures for the measurement of packet loss, delay, and throughput
in MPLS networks are defined in [RFC6374]. This document describes a
profile, i.e., a simplified subset, of these procedures that suffices
to meet the specific requirements of MPLS-based transport networks
[RFC5921] as defined in [RFC5860]. This profile is presented for the
convenience of implementors who are concerned exclusively with the
transport network context.
The use of the profile specified in this document is purely optional.
Implementors wishing to provide enhanced functionality that is within
the scope of [RFC6374] but outside the scope of this profile may do
so, whether or not the implementation is restricted to the transport
network context.
The assumption of this profile is that the devices involved in a
measurement operation are configured for measurement by a means
external to the measurement protocols themselves, for example, via a
Network Management System (NMS) or separate configuration protocol.
The manageability considerations in [RFC6374] apply, and further
information on MPLS-TP network management can be found in [RFC5950].
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T.
2. MPLS-TP Measurement Considerations
The measurement considerations discussed in Section 2.9 of [RFC6374]
apply also in the context of MPLS-TP, except for the following, which
pertain to topologies excluded from MPLS-TP:
o Equal Cost Multipath considerations (Section 2.9.4 of [RFC6374])
o 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
When an LM session is externally configured, the values of several
protocol parameters can be fixed in advance at the endpoints involved
in the session, so that negotiation of these parameters is not
required. These parameters, and their default values as specified by
this profile, are as follows:
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 will
ensure that 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 that 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
When a DM session is externally configured, the values of several
protocol parameters can be fixed in advance at the endpoints involved
in the session, so that negotiation of these parameters is not
required. These parameters, and their default values as specified by
this profile, are as follows:
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
ensure that 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 that 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
This document delineates a subset of the procedures specified in
[RFC6374], and as such 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
AI ELI5
On this page
§1Purpose of the Profile
Procedures for measuring packet loss, delay and throughput in MPLS networks are defined in RFC 6374. RFC 6375 describes a profile, meaning a simplified subset of those procedures, that meets the requirements of MPLS-based transport networks (RFC 5921, RFC 5860).
Use of the profile is purely optional, and implementors may offer more of RFC 6374. It assumes devices are configured for measurement by external means, such as a Network Management System, and not by the measurement protocols themselves. It comes from a joint IETF and ITU-T effort on an MPLS Transport Profile.
This is a short version of a big guide, for people who only run one kind of network. You do not have to use it.
§2What Carries Over from RFC 6374
The measurement considerations of Section 2.9 of RFC 6374 apply to MPLS-TP too, except two that concern topologies MPLS-TP excludes. These are Equal Cost Multipath, and direct Loss Measurement with Label Switched Paths built by the Label Distribution Protocol or using Penultimate Hop Popping.
Most of the old advice still applies. Two bits are skipped because this kind of network never does those things.
§3Loss Measurement Defaults
When a Loss Measurement (LM) session is configured externally, the endpoints can fix parameters in advance so none are negotiated. The defaults are: query control code In-band Response Requested, Byte/packet Count (B) flag set to packet count, Traffic-class-specific (T) flag set to traffic-class-scoped, and Origin Timestamp Format Truncated IEEE 1588v2.
Simple implementations may assume both ends use these defaults, but are strongly advised to validate received values to detect configuration inconsistencies. Operators should be able to set rates per channel. LM messages should support intervals of 100 milliseconds, 1 second, 10 seconds, 1 minute and 10 minutes. Test messages (used for inferred LM) should support 10 milliseconds, 100 milliseconds, 1 second, 10 seconds and 1 minute.
Both ends agree on the settings ahead of time, so they never need to chat about them. They still double-check each message.
| Message type | Supported intervals |
|---|---|
| LM message | 100 ms, 1 s, 10 s, 1 min, 10 min |
| Test message | 10 ms, 100 ms, 1 s, 10 s, 1 min |
| DM message | 1 s, 10 s, 1 min, 10 min |
§4Delay Measurement Defaults and Security
For Delay Measurement (DM), the defaults are the same In-band Response Requested query control code, and Truncated IEEE 1588v2 for the Querier Timestamp Format, the Responder Timestamp Format and the Responder's Preferred Timestamp Format. The same advice to validate received values applies. DM messages should be configurable per channel with intervals of 1 second, 10 seconds, 1 minute and 10 minutes.
The profile introduces no new security considerations, and those of RFC 6374 apply, along with the MPLS-TP security framework.
Timing checks use the same kind of pre-agreed settings. They can be sent every second, or less often.